Update 1.2

It has been too long since I have updated this game. I have been working on a lot of the background stuff for my game to make it easier to work with in general. I updated the UI, so it looks a bit nicer than the very lacky UI from the previous build. I am also working on an in-game level editor. I will touch on all of these subjects in this devlog that I am creating in relation to "Finish Your Game" Jam 2022.

Menu System

I needed a system to control menu navigation and so on. The previous release of the game featured a rudimentary title screen and a very simple pause screen and in-game UI (I consider it a menu). What I wanted was a system that where it was easy to add menus to, have the different menu screens to support animations when the screens swap, and a "back button" feature to go to the previous screen. A simple chart of the different menus and how they connect with each other is seen below.

Menu screens overview.

The menu system would need to manage all menus, and the in-game UI as well. I'm splitting the system into three components: (1) the menu manager, (2) the menu controller, (3) a specific screen controller for each screen. The purpose of the menu manager is to decide which menu should be opened at any one time. It is also responsible for remembering the previous menu. The menu controllers' job is to control the opening and closing of a specific menu. It is basically just controlling the fade in/out animations of a screen and makes sure all components are activated on that screen. The specific screen controller is dependent on which menu screen we talk about. For instance, the title screen menu would handle the buttons message from the Unity Message system, and then take those messages and turn them into events (more on that later). A special screen such as the chapters selection screen would also control the initialization of the level list. An overview of the system can be seen below.

Menu system overview. The dotted lines indicate Unity Messages from buttons. The solid arrows with circles is system events. The normal arrows are function calls.

Event System and Component Independence

Why not use function calls? The reasoning for this is that many other systems have to react to certain situations, or events, such as the act of "loading a level" or "pausing the game". If I were to use functions, then I would have to make references to all objects that needs to act on these events and then hard code function calls into the systems. There are various ways to get around this, such as using class interfaces, and probably other solutions as well. Heck, it could be that just calling the functions using hard coding and references would be a good enough solution - but regardless I ended up using an event system to solve this issue. Let's imagine that I want to load a level. I could create a function for that, and then reference all other scripts that needed to do something when I wanted to load the level - or I could invoke an event and then let all scripts that has subscribed to that even perform the necessary things when the event is issued, as seen below.

Event triggering actions in multiple independent scripts. In this example the onLoadLevelEvent could be invoked from the chapter's selection menu. Why would the menu system or screen controller need to know about the level loading manager or game manager when it only needs to look after the menus

Then, using this system I can create events for common actions that occur in the game such as an event for pausing or unpausing, player death, or the pickup of an item.

In-game Level Editor

I was working on an in-game level editor however it is not quite ready yet, and honestly, I am not entirely sure how I want to use this yet. It is embedded as a secret button somewhere in the menu screens - it should not be too hard to find.