hey guys,
i ve playing around with unity for almost a year now (not everyday) and i ve come to a point that i need to structure my code in a way that has been done professionally.
Professional code is often awful as well, because we have deadlines to hit.
However, don't let that dissuade you - better code organisation is a good thing to strive for.
the internet is just a garbage of information. everything i found was how to show health bar (ofcourse everything in 1 file and with one variable like float hp = 100). how is it done professionally ? buff / debuff ? damage on time ?
This sounds like several questions in one:
a) How to display a gameplay value as a UI element
b) How to manage gameplay values that can be buffed/debuffed/etc
c) How to structure game code effectively in general
The first one depends on your rendering system, but usually a good idea is to separate out the 'view' from the actual gameplay logic (sometimes called the 'model'). Each frame the UI or view code can call a function on the gameplay object to ask how much HP is there and what the maximum value is, and can draw everything based on that. The graphical part doesn't need to know or care about buffs, just like the gameplay part doesn't care what colour the bar is or how wide it is.
Managing values that can experience changes over time and temporary changes based on spells/skills/status effects/etc is a complex topic. As such, there have been lots of threads on how to approach it:
https://www.gamedev.net/topic/622135-time-related-state-effects-buffsdebuffs-what-are-manageable-code-designs/
https://www.gamedev.net/topic/528041-buffspowerups/
https://www.gamedev.net/topic/646569-generic-rpg-stats/
https://www.gamedev.net/topic/528574-looking-for-player-stat-management-designinfo/
I suggest reading them all, thinking about the needs of your specific game, and then coming back to ask a specific question if you don't know how to proceed.
How to structure code effectively is also a massive topic, and one that programmers struggle with throughout their career. Guidelines that help me include:
- Each class should ideally have just 1 central purpose, and should be named accordingly.
- Code for gameplay logic should be separate from code for display logic, and that display code should read from game code, not the other way around.
- Avoid globals, singletons, static variables, and anything else that's widely shared, because that becomes difficult to maintain later.
- If you find yourself writing the same thing twice or more, factor it out into a function. If you have 2 classes that do similar things, consider whether they could actually just be 1 class. Try to reduce code duplication.
another problem that occurs is, i dont know which concept i need to apply to what or when. e.g. state machine, sounds good but how to actually implement it is a big problem. event system ? perfect, but how ?
Someone linked you to the game programming patterns site which is great. But on the whole this is something you'll only learn by repeated reading and by continued experience. Part of the problem is that you need to not worry now about the big picture, but deal with each issue as it comes up. There is no 'guide to everything a game programmer needs to know' that we can give you as preparation - you just have to learn as you go.
