Part of the way that I have always worked is by identifying key parts that I either want to implement/learn to implement, such is the bane of having a passion for learning new things. This being the case, means that the design and development side of things will jump around quite a bit. In the previous post, I mentioned a list of elements that I would be utilising; the first of which was the dungeon generation.
The dungeon in this game took inspiration from the movement of ‘Shroom and Gloom’ in that it needs to unfold ‘infront’ the player. I will elaborate more on the movement in a future post, but the key concept here is that the player will not be able to backtrack.
The dungeon should unfold as below:
“Player chooses a direction” – The player, at max, will be able to move in one of three directions; Left, Right, Forward. This is exclusive to the progressive movement and will be clarified further in a future post related to the movement. The manager needs to make sure that the player is always visually presented with a dungeon tile, when facing any direction – whether they can travel down this path should vary according to how far through the game they are and thus be visually represented (big ol’ boulder blocking the path…etc).
“The dungeon considers where the player is” – This refers to progression monitoring and how it is reflected in the dungeon. This means that as the player progresses further down the narrative path, the dungeon will reflect this through a change in aesthetics and event triggering. Did the player pick a path that eventually ends up in a swampy area? The dungeon aesthetics will gradually become boggier and boggier. Further to this, we would also consider the events that can be triggered at certain points of the experience. This will be covered by a further post related to progression.
“The dungeon spawns a tile” – The outcome of the above. We would also consider optimization through object pools and dynamic prefabs.
“The player moves to this tile” – The outcome of the above. Will be covered more in a post related to movement.
The dungeon creator should thus be able to:
- Determine how far through the game the player is and adjust aesthetics accordingly.
- Determine the navigation decisions of the player and adjust aesthetics accordingly.
- Determine any events that need triggering.
- Efficiently produce the path forward.
For the first stage (POC) of this project, I have created a manager that takes in the players faced direction and spawns a tile when they face a new direction. This dungeon manager only spawns one tile in any given position. This will do for the moment, as I want to shift focus on the player movement as this will validate the design decisions above, through play testing and I’m hesitant to sink too much time into this aspect until I’ve played with the movement.
It shouldn’t be a surprise then, that the movement will be the next topic for consideration.