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.
You’re only going to get so far by asking people for specific guidance. At some point you’ll need to either try stuff, get stung, and learn from it, or work on a big project with people more experienced than you, even if just a bit more experienced. Preferably both.
It shows a level of technical maturity that you’re asking.
If your code is open source, you could try posting code links and questions to relevant communities here on Lemmy.
Edit: You might attract users and collaborators that way, as well.
When things feel overwhelmingly big I usually refactor. The answer for me is usually folder by feature. Refactoring should be a natural part of the engineering cycle. You’ve learned a lot while getting to the point you are, and the structure reflects the outdated perspective.
Also don’t go out of your way to reuse logic. It’s a lot cheaper to adjust code that only has one dependency. If the duplication starts hurting, then consider converging. I usually start writing how I’d like to use the new code, then implement it to fit.
Hope my two cents helped
I’m admittedly not sure if I get what you want to do with the crafting bills.
But if you mean that the reservations, delivery requests and resource checking are modular for each bill, you can make a generic bill that takes in a class of type reservation, delivery request and any other bill class attribute you want to be modular.
That way, you might not need to check for specific cases for each combinations.
Also to answer your original questions, you mostly have to exercise in recognising situations where certain design patterns would be appropriate to use.
For certain application types though (games, design apps, data analysis apps, etc.), there are already popular design patterns that exist and are used all the time. Look at how other applications use them.
