Since leaving my last job, I've spent a lot of time making miscellaneous system demos and learning more about my craft. However, I never published any of these because I felt that they weren't presentable enough to go on my portfolio. This was a big mistake. I've now built a number of pretty cool mechanics and systems that I'm actually proud of, and learned a huge amount in the process, but to any potential employer I've been sat with my thumb in my mouth for the past couple of months.
As a result, two weeks ago I set out to make a short game jam game. The pitch was 5 features to implement in two weeks. A friend and I sat on a call and decided on what I was going to do, so the pitch we came up with was "a boomer shooter set in Innsmouth", and the five features to implement were:
- 1 level
- 2 Enemy types
- 2 Weapons
- Resource management (health and ammo)
- Movement system
What went wrong and what I learned from it
This is all fine in theory, I mean I'm confident that I could finish that project if I did it all in blueprint, especially now that I've got a set of assets to work with. The problem was a little more fundamental than that. For context, Unreal's C++ API works with blueprints in the same way as an inherritance tree - in fact that's exactly what it is.
When you create a new C++ class in Unreal Engine, you can pass that class around to other C++ classes, or you can create a blueprint class which inherits from it. The important thing to note is that blueprints are always further down the inheritance tree than any C++ classes. This means that variables created in BP, or a derived BP class, can't be accessed from C++. This was something I knew, but failed to take into consideration when I started doing the programming for this project.
This shouldn't have been a problem, but there were some things I was able to implement in C++, but there were a few things I did in Blueprint which I forgot to set up in C++ first. This meant they weren't exposed to broader class definitions, and suddenly accessing simple variables within functions because frustrating and difficult because I set everything up badly. This mistake didn't become significant or noticable until towards the very end of the project, which meant by the time it became apparent, I had the choice to either start again, or just pull the plug and move onto the next thing. I made the choice to just move onto the next thing.
This was actually a super beneficial experience for me. I learned a lot about structuring an Unreal project which uses both C++ and Visual Script. Until now I've mostly done data management in C++, passing values around, integration with other API's like Amazon Web Services, writing information out to disk, and generally setting things up like that. This time around I did more gameplay scripting and system setup in C++. The problem was that I found some things much harder to do in C++ than in Blueprint, and ended up making a few bad choices early on which made it next to impossible to get anything working by the end.
Gameplay scripting in C++ is one of my weaker points and under a tight deadline I felt I couldn't get things implemented as I might have liked to. I think this means I need to spend more time implementing features in C++. I can prototype and iterate quickly in visual script, but as I understand it, C++ ends up faster after compilation, and I like the additional control it allows me.
What went well
While the programming side of this project fell by the wayside, I actually had a lot of success with Unreal's Material system. I set up a number of cool materials and textures, and continued to get more comfortable making okay looking things in the material editor. I also found something called the effect texture maker, which turned out to be really useful for quickly creating textures and normal maps. I made a couple of things with the system such as an animated flame spirit and a blood texture, shown in the gallery. The flame effect was especially cool because I followed a tutorial for it which taught me how to get a flat image to always be facing the player, classic Doom style. That was fun and felt fitting for the initial boomer shooter premise.
I also got to revisit something I haven't done since I was at college in 2021, which was creating a dynamic landscape material. This used the vertical slope of whatever it was applied to in order to create a material which would dynamically shift between rock and grass depending on what kind of slope it's on. It's a cool little system. The materials I used were from Quixel Bridge, and I found I had trouble with tiling, so I included some noise to help with that.
The other thing this project taught me was to be strict and careful about establishing infrastructure. In not outlining those boundaries early, I got my gameplay scripting mixed between C++ and Visual Script, and this brought about complex variable wrangling which slowed me down significantly, and made finishing the project a lot harder than it needed to be. Lesson learned, I suppose.
