- Home /
Too subjective and argumentative. Big questions that require a conversation like this are better suited for the forums.
How do you bring your ideas to real code?
Hi everybody! I guess this is a question for the most experienced devs. Can please give good advice on methods or steps that you take to design the clases of your game? I find it's easy for me to imagine what needs to be happening in the game but have a hard time implementing it. Usually the way objects communicate with each other change along the way.
Do you use diagrams in a particular fashion? When you prototype do you completely forget about code correctness and start from scratch when the prototype is done? or rather reuse most of it? What is your take on layers vs tags? Do you use scriptable objects? Do you use singleton approach? how many classes do you consider ok implementing singleton? Any other approach that is important in any other aspect?
Thank you kindly!
Answer by cgarossi · Sep 01, 2017 at 01:04 PM
This is a big subject, but I will add my comments.
I am a software developer by trade. I only write games for a hobby as I love programming.
When I approach a problem, lets say a new game, I always break it down into distinct objects in my mind. Then I separate those out into responsibility.
To keep organised, it's all down to appropriate levels of abstraction and keep responsibility separate.
For example, if I walk into McDonalds and I order a Big Mac. To get a Big Mac certain levels of process have to be co-ordinated but they do not require knowledge of each other.
So, the areas of responsibility are:
Me - I am requesting the BigMac
The Server - He is accepting the request and turning that request into something that...
The Kitchen - ...can understand.
I am not responsible for creating the BigMac, neither is The Server, the components (kitchen staff) in The Kitchen are.
So when approaching a game (or any other software), the same is true. If I have a Spaceship that a player controls I must work out what areas are responsible for what.
I could create an Engine class which is responsible for movement. I can create a Weapon class which is responsible for firing Projectile classes which in turn are responsible for dealing damage.
Finding distinct areas of responsibility is key to not ending up with a complete mess. Analyse what actual objects will exist in your game and work out how they are going to interact with each other.
In another thread a guy had a problem with a Shotgun class in which is shot multiple bullets. The problem is, he was processing the damage by reading bullets that hit his player. In this instance, the responsibility can be delegated to the individual bullet, because in real life, if I am shot, my body does not work out how much damage I receive, the bullet applies it for me! (Unfortunately).
So getting this down early and correctly is essential imo.
Singletons and class Factories are useful tool in a very big box of tools that you will be using. I always create resource managers for instantiating objects (again, responsibility) and I have Singleton factories within that should I require them.
Hope this helps you.
thanks for a quick answer. I will post in the forum, which seems more appropiate.
Follow this Question
Related Questions
Unity architecture 3 Answers
Is it a good idea to use static classes? 0 Answers
How to avoid one engine class controlling the game flow getting too large 3 Answers
Decoupling state & graphics, while sequentially executing graphic updates 1 Answer
Is it good practice to have GameManager singleton in charge of highest level things? 1 Answer