Implemented a LevelHandler
What?
The most recent implementation that I did was a so called “Level Handler” which is an object that you pull into a game scene, that lets you decide how this entire scene should behave during gameplay.
It has the possibility to easily manage the behavior of the entire level, changing spawn positions and change scenes and the different graphical user interfaces that we might need such during pause functions, cutscenes and so on.
It also keeps track of win and lose conditions and all the variables are changeable from the inspector so that the game designer can easily change them during play testing to see what works.
A note is that after its varibles in the inspector has been assigned, it automatically handles everything for the behavior of the game.
How?
I started off by creating a simple statemachine that the current scene could be in. I used “enums” for declaring what these would be and an example could be the pause state, running the game state or a cutscene state. This would let me easily see what would happen when it is in one certain state at one time since each state had its own function. An example is that when pressing a button for the pause function, it would switch state to the “Pause State” from that only certain things would work as well as displaying a GUI element on top of the screen that you could press and also pausing the game while in this state.
The entire handler would have as many variables public as possible for being easily changed by the game designer, and also using objects that are needed for the handler such as the player object, all the different scenes as well as GUI elements appropriate for this specific scene that the handler has been added to.
Since the handler got all the specific objects needed from the inspector, I could grab the components needed within the handler to check whether a state was true such as if the health of the playerobject had been depleted or if it had been killed by the mob that constantly chases the player. These would then call for either a scene or a cutscene depending on if there is a cutscene applied to the handler or not.
Basically, the handler just uses the other game objects within a scene and checks for conditions and do stuff if something is true or false, such as changing the scene.s
Why?
At one point in our game development, we felt that we needed a clear goal instead of aiming for small parts of it. That’s where we discussed how to handle all the behavior of a scene and found that creating such a manager would suit us well.
We wanted it to have all the possibilities of changing and playtesting different win and lose conditions. Since our game is quite short, predeclaring different states was appropriate of this manager so that testing the different conditions was beneficial and easily changeable.
The game designer needed to see what works the best and just by switching one of two variables in the inspector, the entire winning state could change.
Switching scenes and levels was also a big question for us, so this manager would also switch to cutscenes, change scene and also pause the game.
What else needs to be fixed?
– Fix a state for killing a certain amount of enemies, even though it is implemented, it recently got some bug.
– Being able to manager the other managers such as the enemymanager, depending on game state(Though this might be included in an upcoming “Event Handler”
Christian Edberg 
Christian has written about how he implemented the level handler for his groups game.
He clearly describes how it is functioning in the first section of the blog post which gives the reader a clear understanding of what the blog post is about.
How he designed the level editor is the main topic of the second section as a follow up to the first section. The what and how section is clearly divided by a bold text row that indicates the beginning of the new section. Christian describes more in depth what the level handler is capable of here. An example of the depth: He describes how the level handler focuses on different states that are affected by certain events triggering in the scene.
Just as the previous “How” section, the “Why” section is also clearly separated from the other sections with a clear bold text indicator. This section begins with describing the series of events that led up to him designing it and why it is useful for their team. This is also clearly put fourth.
The post is overall very well written, I as a reader gain a clear understanding of the thinking process that took place in order for this level handler to be necessarily created. I find this post valuable because it also makes me as a reader gain understanding of the design choices made by another team that I will be able to carry further. Christian also mentions some cons with the design that I also find interesting and that is going to be fixed.
If there’s something id like to see more of.. That would be to read more about the “struggles” experienced during the design process. We all learn from our mistakes and it is valuable to me to learn from others mistakes as well!
Overall well & clearly written.
Good job :)<3
LikeLike