You received a letter from the former owner that wants you to take over his old rusty workshop to make your first steps within the amusement park industry. Cleanup, collect materials and get to work as you are about to create your first simple products for some local parks. Expand, manage and organize your growing company and employ workers that automize the processes you used to do on your own!
5 Months
Winter 2024/2025 - Master Semester
PC
Solo Developed
Prof. Thomas Bremer
DE:HIVE @HTW Berlin
For my master thesis, I did select similiar to my bachelor thesis, as topic to create a game. To be exact, a economic simulation wihin the amusement park industry. I was very precise with the setting and generally the topic of the thesis as I knew exactly what I would like to achieve and create this time.
In fact, I already worked on the core concept for whole year already.
Similiar to the bachelor project Shifted, I would have to do most of the work myself of course. I planned out what areas I would need to consider third party assets right at the beginning as fields like character animations would require way too much time to do on my own.
A key difference to my bachelor project was, that this project itself wouldn't be rated directly. The only thing that really counts is the written assignment this time so I would need to be careful of my time management.
In fact, I planned out my entire assignment parrallel to the development process to always be up to date.
The master project began just a few days after the release of One S'More so I was still fixing bugs for our company project while starting out with the first game loop flow charts.
The whole project began with the usual questions. What Engine to use, what's the perspective, 3D or 2D etc. Since I was testing out the Godot Engine early 2024, I was truly considering using this open source engine for the project. However, because I was aware of the still present performance issues when it comes to the 3d renderer of Godot, I would need to do more tests. So for my master project, the first thing I did was a crowd simulation test for both, Unity 6 and Godot 4.3. Of course I wouldn't have much time to just focus on this test so everything I could put my hands on would be done in parallel.
The full development process itself was quit a journey itself. Halfway through the prototype, I still hadn't any real game loop finished so I could let people playtest the game. It just were too many ambitious features.
Since my concept was actually two whole game concepts combined I would need to make a choice. The original concept was a "Stardew Valley meets Rollecoaster Tycoon" like game. Basically, you would have to building your own theme park with resources you would find or buy and to produce materials and attractions through machines.
The players would have started out with a small workshop of which they aim to craft attractions as products to receive there first money from the sales.
This starting concept would become the entire game itself after I restructured the project.
NPC AI was a crucial component in this game. Since I missed out on earlier projects on really learning about established behaviour patterns, this was the moment to really dive into the materials and figure out, what would suit the best for this game.
I started out with behaviour trees which I quickly ran into more maintenance problems then actually writing the behaviour. Godot and Unity both don't have a good (or any kind of) solution to work with. I was searching for alternatives and certainly felt like an idiot as I stumble about the Finite State Machine pattern. It was simple, easy to understand for me and easy to implement at first. This pattern was enough to get started with but I was far from done.
As I was encounting multiple problems especially with the integrated navmesh system by Unity, I tried out custom A* solutions but unfortunatly hadn't the time to fully implement it in the end.
At the last two months of development I ran in huge problems with my current state machine setup and I wasn't sure anymore if it really was the solution I was hoping for. My professor then gave me hint about the GOAP system. In fact, there was a well build solution on github that could have been a great fit. Unfortunatly after taking a week to evalue the system, I was afraid I couldn't implement it correctly into my current system. However it gave me a crucial inspiration to rewrite my own state machine again. This time with the movement stages already done by the states itself. This was one of the main issues I had with the old state machine. With that, I was able to get it run incredibly well in the end!
The shader work was pretty simple. As I was aiming for a cozy fluffy visual style, I took quit some inspiration from the Overworld Shader I did for One S'More as well as the custom lighting I did with my previous work on this concept before I was doing this as master project.
With the prior projects inside Godot and Unity, I did experiment a lot more with custom lighting and learn about how to achieve the exact outcome I was looking for.
The lighting really did most of the style choice combined with a gradient color function to either colorize entire objects without a texture or use it for tints and faking ambient occlusion on the building for example.
There were also shader driven foliage I implemented at the very end of the project. Since I already have lots of grass instances on the gpu, I was searching for a better "remove grass" solution when building and placing paths, trees and rocks on the ground. For that, I took inspiration of how we made the water and level boundaries in One S'More. Basically, I create a bitmap on the fly, using it's rgb values as mask for the scale of the grass in world space. With an additional function inside the terrain generator I look for grass that can be culled out completly and so I more or less achieved a smooth looking transtion from the grass to placed objects on the ground.
For the terrain generation, I wasn't sure how to properly handle it since the amount of work to put in such a system was a risk.
I tried out just the traditional way of procedural mesh generation by sewing in code defined quads together and structure them into chunks. However the look of it really wasn't what I wanted and so I researched about better methods. One of such was Marching Cubes. After much trial and error, I found a fitting outcome with this method. The most important part of this to me, was the scalability to add other terrain relevant features later.
For this project I was highly dependent on custom editor tools to quickly configure items, stats etc. I tried to make them as basic but simple to use as possible for me and also to aim for reuseability in later projects. Especially the item library and id based inventory system took quit a huge chunk of my time as I was really careful about stability and fail safe coding.