My reflection on week 3 of module 2 is about a week later than I would have liked. I wanted to wait until I’d achieved my primary goals so I at least had something to showcase, these being:
- Grey-box prototype of the game world using my own 3d assets
- Fully functional doors
- Walkable level
- Scene switch from level 1 to level 2 and back
- Destructable grey-box NPC
Figure 1 gives an overview of what I managed to achieve, albeit encroaching into week 4 slightly.
As you can see, I failed to implement the NPC within the timeframe as I derailed myself spending far too much time on a side-quest.
What went well?
I chose to use Blender to create the level models and found this much easier than I originally anticipated although I did have two attempts at creating Level 1. The first version was made using planes to create the floor and walls. This approach proved very quick. It was ideal for rapid prototyping the level as I suspected but suffered a fundamental drawback: to apply textures, I needed to rework the model to split the edges between the walls and floor. Unfortunately whilst doing this I managed to corrupt the model, necessitating a re-draw. This approach also suffered from inverted normals on a few faces so not ideal.
For the second attempt I built the level from cubes (Figure 3). Laying the floor and walls was similarly very quick. What I found most time consuming was having to go back into the model and add the colliders. Ultimately I had to model the scene twice: once for the walls/floors and once for the colliders which doubled the work.
Nevertheless, this was good practice with Blender and when I came to model Level 2, the process was much faster.
Much of the programming activity from this week is already covered on these two posts:
Taking a step back and comparing Unreal Engine 4 (UE4) to Unity, I was somewhat surprised at the similarities between the two. Each has their own ideosyncracies but when these are stripped away, the fundamentals, at the level I’ve been using them, were remarkable similar. It will be very interesting to see how far this extends once I start using some of the more advanced features of UE4.
The last item I want to discuss in this post is getting sidetracked.
I did go completely off-piste to find out how the UE4 test system works which led to me integrating my project into Jenkins. Unlike Unity, UE4 command-line builds are particularly convoluted and not well documented at all. Even now, I’m not entirely convinced the build is correct. It builds and runs unit tests but I’m certain there are some missing steps.
What could be improved?
The work I’ve done in Blender is very orthogonal. Creating levels with a more organic feel will add more veriety to the game.
Modelling workflow — there is a huge amount of scope to optimise the modelling workflow from sketch to engine import.
NPCs!!! The game isn’t a game at the moment. It’s just a walkthrough on a static level with sliding doors. There’s no interaction and nothing for the player to do.
Conclusion
It’s good to get back tp programming with C++ again. I like C# but it feels loose and floaty. As a language, I find C++ much more precise and, as a programmer, it gives me a lot more control. It also appears to be the language most studios are requesting.
The prototype was really fun to produce. I have the beginnings of a level design workflow from sketch to model to engine and there is definitely room for improvement. Once it stabilises I’ll share the process on my blog.
For a ‘Game Programming’ week I spent more time modelling than programming. This resulted in missing features such as NPCs, and the player shoot mechanic but this is outweighed by the knowledge I picked up in the basics of Blender and being able to create my own, simple levels.
List of Figures
Figure 1. THORN, 2021 Walkable grey-box level with scene switching
Figure 2. THORN, 2021 Blender Model – Level Design
Figure 3. THORN, 2021 Blocking out level 1
Photo by Faye Cornish on Unsplash
