Note: This post can be viewed on my tumblr with code inline!
http://goshdarngames.tumblr.com/post/126517339735/architecture (Not a shameless plug - it just has prettier code!)
System Architecture!For this project I have decided to try and contain all the Game Objects for the main game in one scene in Unity.
In the first game I made using Unity (
Jet The Pack) I put each level in a different scene. The major drawback of this method is that if I had decided to add an object to all levels I would have to update every scene individually. It’s always a pain to make a major design change halfway through development but it would have been pretty horrible having to click ‘open scene’ 40 times.
In the second game I made in Unity (
Spacebomb) I had a separate scene for the Main Menu, Gameplay and Game Over screens. The main disadvantage that I encountered was that if there was a Coroutine that ran while the scene changed it could cause a null-pointer exception. This lead to a difficult to reproduce bug where the scene changed while the player was respawning it would make the player completely invincible on their second go. I didn’t catch this in my testing because I tended to only play through the game once - it was only when a friend was playing that it occurred and I had to watch them smugly play the game with infinite health.
For Bogey Green Golf I have decided that I will store all the game objects in one Unity Scene and manage the state of the game with the State Patten, described here:
http://gameprogrammingpatterns.com/state.htmlThe state machine and state that I created for the project can be found in this gist:
https://gist.github.com/goshdarngames/a150b34995de00726206State.cs specifies an interface that objects must implement if they are to be used as States. This interface provides methods to set up, update and tear down the state.
The State Machine class allows any object to have one or more state machines as properties and provides public methods to change the state. Most objects will only need one state machine but it’s possible to have more.
The first object that will make use of the Finite State Machine is the Game Manager. This object is responsible for controlling the logic of the game. It uses a Finite State Machine to control the logic and holds a reference to a ‘Game Data’ object that can be used to share data between different parts of the system. I am storing all the game data in a dedicated class so that it will be easier to implement saving and loading later - just store all the data in this class.
https://gist.github.com/goshdarngames/617aceea1eb0d9fa5e77The ‘Single Player Gameplay State’ is an object that implements the ‘State’ interface defined earlier. It does nothing at the moment but the logic that controls the single player mode will go here.
https://gist.github.com/goshdarngames/11327d21f9129d12dd62As well as implementing the ‘State’ interface the Single Player Gameplay State inherits from an abstract class called ‘Game State’.
This Game State is a common base type for all the states that are part of the Game Manager. Having this common inheritance means that it is possible to define data and methods that all the Game Manager states will have access to. At the moment the Game State provides only a constructor which grants access to the ‘Game Data’ defined earlier.
https://gist.github.com/goshdarngames/0a71e615d8c3da75c9baAlthough this is all a load of code that does nothing it is an important step towards defining the system architecture of the game. Hopefully these classes will provide a good structure to organize the code.
Community
