Game Programmer
Blob-Lobber
Blob-Lobber was a first-person shooter in which you had the task of exterminating the slimes that had infected a space station. The main mechanics was to vacuum up the slimes and then use them as ammo to kill other slimes, giving you a few different ammo types in your arsenal. I primarily worked on a visual scripting system heavily inspired by Unreal’s Blueprints.
Node Editor
The plan was to create a visual scripting system that could be used by our designers to create and trigger different kinds of events in the game, as well as to create the enemies' behaviour trees.
I started out by trying to implement the same system that I had used earlier in visual scripting related school assignments, which had a code base for the logic written by a teacher and was visualized as a tool using the graphical user interface library Dear ImGui’s Node Editor.
Soon I encountered a few very strange problems. The codebase would run properly, but it would not register certain input inside the scripting area.
Debugging
I spent a lot of time trying to debug what was happening, using almost every debugging tool in my toolbox. I used breakpoints where the input happened, searched through the code base for every related variable and checked where they were used, I asked my programmer colleagues and teachers for help, and other people I knew worked with the same task, I removed parts of the code and slowly reintroduced it piece by piece to find where the error sprung from, I tried it on a different computer etc., etc. Sadly, nothing brought me closer to the answer.
ImNodes
At that point, my last resort was to try something else entirely, so I removed everything I had tried and done while debugging and restarted on a clean slate. I decided to try another one of ImGui’s extensions called ImNodes, and from that point on everything went so much more smoothly. My theory is that because the extension called Node Editor’s ImGui version was a little older than ImNodes version, it wasn’t completely compatible with some other ImGui extensions we had in the editor in our engine.
Having lost a lot of time on debugging, I wanted to get going again as fast as possible. I got help from a team member to set up the internal logic for handling the data flow, still developed based heavily on the code base our teacher had written. Even though I wanted to create something new after all the trouble I had gone through, there simply wasn’t enough time.
Graphs
When the underlying logic and the visual representations were ready, I started to work on the systems in the middle, what I called the graphs. The graph base class was designed to hold all the data needed to form a node tree and provide an interface to manipulate them that the tool would use through the graph manager.
I designed the graphs to be able to work as a base for creating a lot of different kinds of graphs, which made the process of creating the graphs and their supporting systems more difficult than it could have been. The positive outcome of this is that I now easily can create new subclasses to handle different kinds of needs that may arise in the future, even though it meant taking a long time to set up the system.
Entity Graphs and Behaviour Trees
The first type of graph that I implemented was the entity graph, a graph that was connected to one of the entities in our entity component system. After implementing a few entity related nodes, this meant that our designers now could use the trigger boxes that they could place in our editor to script a few different kinds of events wherever they wanted to in the levels without the help of a programmer.
Secondly, I implemented graphs that supported editing the behaviour trees that one of my teammates had created. Unlike the entity graphs, that were created when someone started to edit them on an entity, I created three behaviour tree graphs from the beginning, and that was it, since we only needed one for each enemy type in the game.
Other Tasks
I did have time for a few other things at the end of the project when the visual scripting was working properly. Most of these things were relatively small and sometimes pure bug fixing, but still very important to create a polished game.
My work included health regeneration for the player, a small rework of how we loaded the main menu scene, implementing a follower component and system and placing a few of the visual effects in the correct places and a few extra quality-of-life features for the visual scripting system when time allowed it, among other things.