koobas.hobune.stream
How to avoid one engine class controlling the game flow getting too large
Hey guys,
I'm currently finding myself in a problem in terms of designing proper code architecture. I have a main GameEngine class which contains the list of players, GameMode enum, GameState enum, functions that handle the logic for each game state and it also subscribes to events related to new packets arriving over the network. The problem is that the class becomes too big.
I thought about splitting the logic of different game states of each game mode to different classes, but then I arrive to another problem. What if I'll work on a game mode that is going to be very similar to this basic one I'm currently working on (say a game of Deathmatch vs Capture-the-flag...both the modes will use mechanics such as killing enemies, respawning, picking up items, what have you). So I was thinking that I could put back those common mechanics to GameEngine. But then I'm returning to the same initial problem - GameEngine being too big. What would you propose?
I'm a big fan of inheritance in those situations where I need similar, but different classes. Sometimes I even use inheritance just to separate out certain functionality (or rather add-in functionality to the derived class). In your case the base object could maintain the list of players, the next decendant implements event subscriptions, and the packets managed by yet another decendant. Sometimes this means I'll have a bunch of abstract or do-nothing functions in the base class, but so what.
"so what" is a bunch of needless, confusing code I$$anonymous$$O. For what you are describing you want a component-based architecture, not inheritance. Inheritance is a useful OO principle, in moderation, but over- or mis-use leads to confusing & unperformant code.
I happen to disagree with you regarding that being confusing, in fact, it helps keep things simpler for me, that's why I do it. I'm willing to add some extra code (mostly in the form of declarations) in order to achieve that simplicity, and modularity. There are $$anonymous$$ANY reasons to use abstract classes with abstract functions, simplifying is just one. The very BEST use of OO, is to create classes that are similar, but different. (Which only touches on part of the question, and why I only commented, rather than answered.) I'm very interested to see how much inheritance affects run-time performance, I'll do some research now; my experience has always shown it be negligible. (Edit: after a bit of research I've not found anything to indicate inheritance hurts performance: how do you come to that conclusion?)
Personally, and bear in mind that you can adopt any number of styles according to personal taste, I'd recommend splitting off functionality for your game modes and logic handling into even smaller chunks and classes. Rather than having a class that handles all of the asset management, networking, initialization, etc. try making a class for each one. And instead of a class for each game mode break down what happens in each mode into smaller classes so they can be re-used across any number of modes.
The real problem then becomes what made you gravitate towards a GameEngine class in the first place: inter-class communication. One of the best ways I've found of doing this is through an event manager. Either a custom implementation or by hooking into Unity's event system with your own custom events. The advantages of such a system are that you can have classes who subscribe to a particular signal but don't need to know anything about how it goes about getting sent. Likewise, the class sending the signal doesn't need to be tightly bound to those who are receiving it, it just sends out the signal "blindly" and everything that's subscribed then acts on it. This de-coupling of classes lets you separate your logic into smaller chunks because you don't need to keep track of tightly bound connections in a monster class, you can edit and change your classes without affecting the logic in others, and it clearly labels and forces you to recognize what parts of your code are significant and... eventful.
This is one way of doing it and I would also recommend using inheritance and other methods in combination as well. But one thing I would strongly recommend is this: scrap the GameEngine class altogether, it will challenge you to refactor in a way that will help you in the long run.
You are mentioning GameMode enum and GameState enum. So I am assuming that your game controller is build upon a Finitite State Machine (FSM). The source of your problems is likely to be intrinsic to the usage of FSM.
FSM is appropriate when your problem involves few states and few transitions. But it becomes a hell to manage when your problem grows in complexity. Since any modification requires to modify the transitions. Furthermore, FSM is hardly resuable: it's hard to isolate an interesting part of an FSM and reuse it for building another FSM (again because of the high inter-dependency of the states due to the explicit transitions).
An alternative to FSM, that does not have these disadvantages, is Behaviour Tree (BT). BT stays manageable as your logic grows in complexity (because of its hierarchical nature) and you can easily reuse whole or part of the tree to define other BTs. This is possible because the transitions from one node to another is not explicitly defined, rather they depends of the position of the nodes in the tree. That's make it easy to insert/move/delete a node, therefore it makes modifications extremely easy.
If you are looking for a Behaviour Tree framework, I suggest Panda BT (www.pandabehaviour.com). It is a script-based BT framework that I am maintaining. If you have questions about using this tool, your are welcome on this thread.
Have a look at the Game Programming Patterns site. The whole lot is a definite read, entertaining and accessible. It doesn't just preach, it comes from the perspective of real-world problems and takes first-draft code and refines in ways that are simple & make sense, not just academic for the sake of it.
I've tried several times to get into design patterns, and that site helped more than anything, and got me starting to use patterns more and knowing where they might be appropriate. It's not a set of instructions, but a set of techniques to try out and ease into when you're comfortable.
If you didn't understand that, just look into Component, Update & Game Loop sections specifically at first. Those techniques hugely help organising sprawling code.
