newwby / puppy_time_police-prealpha Goto Github PK

unused art assets included in repo, need identifying and removing

weapon style data is currently held inside a gdscript file
should be rewritten into a json file, and logic added to interpret on game load, so it can be externally edited

see actor/player sprite scaling function,
move to globalfunc and apply to new projectile sprites based on proj_set_size(?) variable

weapon style data does not include collision extent data for alternatively shaped projectiles
this can be seen when utilising the disabled 'bolt lance' weapon, the hitbox does not match the sprite because the default projectile hitbox is expecting a circular

proposed solution is to define two separate properties in the weapon style data

1. what collision shape to set the hitbox to
2. vec2 of extents for the collision shape

ideally can set these automatically by getting sprite dimensions or an intended sprite size value (see issue #19 'projectile sprites should utilise sprite scaling function')

would be nice if could colour code enemy projectiles; I.e. red piercing, green homing, blue basic etc
player is able to easily identify projectiles of different types

may be irrelevant if utilising weapon nodes on foe

add bool for whether to show the target sprite (see sniper shot implementation)

signal conflict for 'check_state' signal
have been unable to recreate recently

review both node_state_manager.gd and class_state.gd
conflict with check_state signals
one is redundant, identify said signal and remove
(if mistaken, refactor the least used)

state_attack // base variables
are state_attack wait timers still in use by enemy parent?
review code
if not, remove defunct variables
if so, tie their calculation to parent reaction gamestat

AudioController to replace 2dAudioStreamer (extend)
functionality:
/# controlling multiple audio nodes and audio resources
/# controlling subtitles, playing and stopping,
/# selecting random sounds from audioArray

enemy class creates fake current_mouse_target & firing_target vectors to satisfy weapon node requirements
rewrite weapon node to be properly extensible by class_enemy.gd

weapon node should convert class_player.gd args to weapon node args
current behaviour is to use player args as weapon node args and give enemy args at time of call as though it was a player
instead player args and enemy args should be passed to weapon node and converted as appropriate

account for projectile sprite size when applying projectile spread spacing (previously 'additional spread' var, since refactored)
current functionality will overlap fat projectiles unnecessarily

class WaveSpawnHandler needs to be reviewed and rewritten to handle area based enemy spawn handling
current implementation is a placeholder

see 'check_enemy_count' func in WaveSpawnHandler on enemy_defeated signal from class_enemy.gd for behaviour, then build from there

functionality should include:

• number of enemies in wave (size of wave comp array)
• wave composition (enemy classes)
• auto-built wave-complete-on-defeated-enemy-count (size of spawn)
• multiple waves
• wave spawning locations (different pos2d passed by worldenvironment master)
• spawn delay between area entry/wave complete and wave start
• spawn delay variability (slight, for visual)

reproduce by bringing debug window into focus whilst game is windowed
error -> 'scene/gui/text_edit.cpp:5742 - Index p_line = 204 is out of bounds (text.size() = 201)'
may be a godot bug, check known issues

player can keep pace with some of the slower projectiles
thinking will increase all projectile speeds
slightly slow the player (they can evade enemy shots too easily as is)
and implement a movement slowdown whilst holding the fire button (player only)

projectiles currently are not handled by any specific node, instead being applied to the root viewport
potential issue, and certainly messy during debugging
create node2d handler for newly spawned projectiles

weapon data script includes values for minimum and maximum range (DataType.AI_MIN_USE_RANGE and DataType.AI_MAX_USE_RANGE respectively) groups, to prevent weapon and targeting logic being called at incorrect times
these are not currently implemented and should be before attempting new enemy types

Certain weapon styles have incorrect expiry rates for their respective segment timers in the UI

approx ratio est. 33%
Reproduce by switching to sniper shot or triple burst shot (review others but these two are confirmed)
Investigate if due to standing shot speed buff legacy code

linked issue for #11 (now closed but could use some future work)

potential issues if maximum approach distance is bigger than maximum fire range
either:

1. add handling for reversing movement velocity once beyond minimum fire range
2. or automatically restrict approach distance by minimum weapon range

additionally there is a problem with lag when console logging
enemies should check less frequently when they are allowed to fire
previously attempted a fix but encountered a problem with enemy targeting line refocusing on moving players (likely due to check_state func sneaking through a bunch of calls to state_action that it shouldn't have)

see [weapon_ability.gd // func cleanup_orbital_node_holders]
band-aid fix, run function only if no projectile spawned recently
long term orbital handling logic needs rewrite

in state_hunting.gd (child of state manager) the function track_and_move_toward_target is called before state is set; could add logic to yield processing until readied, or ignore if state isn't set, but may result in undesired behaviour. Instead try reproduce and isolate case where this occurs.
currently no information on reproduction

node_detection_manager.gd functions 'get_players_in_range_group' and 'get_nearest_player_in_range_group' were written before the implementation of the range group calling dictionary.
Both functions would benefit (future proofing/extensibility) from rewriting to utilise said call_dict

to reproduce - on switching to sniper shot (from another weapon style), the actor's targeting line fixes toward mouse cursor point at time of acquiring shot, whilst attacking direction behaves as normal (toward mouse cursor location at time of attack input)

could resolve by applying target line function on gaining sniper shot?

ui_player_hud is currently preloading weapon data store script
if func 'update_ui_weapon_cooldown_graphic' is moved to weapon collectable script, perhaps passing information via a signal, this dependency could be removed

add default pos2d to player and enemy for bullet spawning
add rotation to said pos2d
keep on target-sprite?

Change the implementation of the enemy scene approach/minimum distance function so can have a parameter passed instead of using a hardcoded value

with excessive projectiles creating and freeing scenes on call may become demanding of the player
monitor performance for now, may be a future issue, but consider implementing an object pool for projectiles later

implement gamestat class which returns calculation when called (accounting for modifier class variables)

make sure is only called on instantiation and change, updating a local variable
i.e. don't perform calculations every time

implement different bullet spawn location implementations for different weapons
add as enum (w/pos2d node setup on enemy node) and/or pixel offset

instead of including different behaviour within the class_projectile.gd code block, implement a parent projectile class and basic projectile child class, along with orbiting projectile child class and radar projectile child class
would simplify code block and make it extensible in future

bug - projectiles are not currently following correct cursor->target vector, angling at seemingly random orientations
offset/projectile rotation code has been expunged (utilising constantly rotating circular projectiles instead) but would be interested in reintroducing once behaviour can be reproduced reliably

see how targeting lines and cursor are oriented for correction - may be a sprite issue also

//apply base sprite_rotate to get pointed angle
/new_projectile.rotation_degrees = 90
var offset = owner.position - owner.firing_target
var offset = owner.firing_target - owner.position
new_projectile.rotation -= offset.angle();/

store wait aiming time randomisation on instantiation of enemy node, don't call it every time
perhaps include call to re-random at opportune times
just don't call globalfunc.returnrandrange every time due to otp randomisation call
(perhaps utilise standardised randrange func?)