I'm quite new to programming and my projects getting big by my own standards. When I go to add a new feature im really struggling to evaluate the different options how/where to add it and im getting overwhelmed to the point of not progressing. I find myself wanting to seek some generic guidance from someone whos experienced but I dont know what the right question is to even ask. I want to ask things like "how should I structure a project" or "What kind of patterns can I use to keep my project manageable" "what do I put in code comments"
Practice and experience, but is there anything I can do to find the right direction to go to learn? I dont have the words to know what im even looking for at the moment I just have "pattern" like a design pattern and a notebook with a lot of boxes and arrows trying to plan out some kind of structure. I want to read something at least slightly relevant to game design and start trying to follow some tried and true guidance.
I made this post because I wanted to ask about when to expand a class vs. create a new one.
The example: I have a script (ResourceManager) that handles the resources on the game map it tracks loose items,items in storage, reserved items, delivery demand.
I want to add a crafting bills. These bills will want similar things(to reserve items, to making delivery requests, checking resource stockpile and once available the bill activates) and I can reuse a lot of the logic if I just put it in the same place. But its kind of different crafting and management of resources but them am I going to make a new script for every new thing at some point I just got to put similar things together right.
What kind of things should I be looking at when trying to evaluate these choices?
it's all about managing abstraction. if things are similar enough you can make them derive behavior from the same base. with composition, you can build capabilities separately and then compose them into objects. so if the ResourceManager has an Inventory, so could the CraftingBill. if the ResourceManager has a Request and a Send method, break that out into a RequestHandler and give one to everything that should be able to do requests.
When working with an ECS implementation, game objects are usually just numbers. all the capabilities are separate functions that are associated to the game objects in a list. i'm not saying that you should be using an ECS if you aren't, but i am saying that modelling your systems so that new things can be built from small, common parts makes it way easier to expand. usually at some point you realise you don't even have to build new behaviors.
that said, try to keep it strictly hierarchical. like stones in a pyramid, you should only depend on things that are below or next to you. if you start creating relations to things further up the chain, your architechure might need rethinking. good news is that if you're modular enough you can junt move things around.