Notes

Maybe change game to 'bullet hell' idea. So when generating the map, we pre-generate chests and other interactive objects and then in each level, enemies are constantly generated outside of the player's fov depending on their level. Now they can equip different guns and spells which get better the higher the level. So it's sorta like a bullet hell like dunegon crawler. Maybe have prefabs generated after rooms and a* can connect then (no idea how to store the room structure tho). Maybe pass a ExtraLevelConstants namedtuple in map.py that has the total amount of enemies (will need more thought considering enemy gen needs level to get different leveled enemies)

New idea for map gen: place just floors then use cellular automata to smooth it out then can place walls afterwards (can't use prefabs with this I don't think) + for item gen, maybe start at distance of 10 (no neighbours items within 10 tiles) and if 5 tries or so, then count down and repeat

Try and improve dummy imports

Try and convert vector field to pure functions (only problem is the initialisation which needs to run). Could further be optimised by limiting vectors to a range around the player (max enemy view distance (on each enemy level increase, could add max limit for each attribute so it doesn't get too big (so max level and max attribute)))

Plan out all of entity attributes and what sections they belong in

When changing to poetry groups, change build.yaml to use nuitka group when installing dependencies + maybe look at removing poetry altogether from this action (look at test.yaml)

Enemy and consumable level spawns should be normally distributed

Redo attack range for constructors since AttackData.attack_range is only used for limiting the enemy's reach when attacking the player

Maybe have melee shader scripts in python file

Maybe add jump point branch. In this branch, look at adding compass direction feature (add direction for each move to simplify placing (benchmark original vs this to see which is faster)) and maybe allow diagonals (if use compass direction idea, then maybe place box for diagonals)


Create lots of potion types. One could be a tank potion which slows down player but gives lots of defence and health. Would need to plan them all out (including the already implemented one). Maybe create collectible/item constants file which has namedtuples detailing what each collectible/item does. Will need more thinking about the structure. Could be part of a collectible-rewrite branch. Would need a collectible.py file in constants and can put everything in dataclasses or namedtuples


Change info box so it replaces nearest text. So it can display stats about a potion, etc (acts as a error or debug box). For stuff in upgrade screen, will use separate default box which gets changed then enabled when an item is selected. Maybe only do this if I create a 'learnt knowledge' or 'collectible' hall


New attributes which can be upgraded: inventory size, potion duration, ammo count. Extra upgrades like shop in-game or respawn ticket can be added to list/dict after theyre bought. Need to think about how to upgrade attacks. Plan for upgrades: Player can complete story mode and get coins to upgrade any character they choose, the player can also redo each mission and get a percentage of the total coins earned (to discourage infinite coins). For freeplay, they can go on for however long they like gaining coins on each level and being able to upgrade any character but can't replay easier levels (stop infinite money) and can't transfer progress to story mode (story mode can't transfer either) and once they die, freeplay is set back to level 1, More details: Shop is in central lobby, if they win a game in story mode, get them all coins (except for previous levels), but if they lose, give them a percentage of total coins