Game Programmer
Spite: Blood Relic
Spite: Blood Relic was my first project using our own homemade engine. At first, we all worked on engine specific tasks, creating the foundation for our coming three projects. For the rest of the project, I mostly left engine work behind, focusing on gameplay and tool-related tasks. Among other things I made a few of the player abilities, some tools, level resets and player death handling, killed some enemy bugs and in general kept the game creation flow steady by lending a hand wherever necessary.
Engine
The base of the engine, like 3D rendering through DirectX11, was already finished when this project started, so we could focus on higher-level engine segments.
One of the first things we decided on was that we wanted to use an entity component system when programming, both because we hoped that it would give us better performance than object-oriented programming, but also because we wanted to try it out and learn something new.
It worked out great, and we used the ECS for seven months, to create both Spite: Blood Relic and Blob-Lobber.
Design Patterns
I wanted to try out some of the design patterns that we had learnt about earlier, that I thought would benefit our engine in the long term. I got the chance to create a postmaster and a state stack, both relatively simple patterns that serve a vital purpose in their respective areas.
The postmaster, designed to distribute information between unrelated parts of the program, is a huge help when trying to keep data separated logically while simultaneously needing to use said data in otherwise unconnected places.
A state stack is a way to easily change between the different states a game consists of, like menus, levels or cutscenes, while also keeping track of previous states to be able to revisit them if necessary. I felt like it provided a solid framework for the systems and scenes to work within.
Input and Scene Management
At the beginning of this project, I also took on the input and scene management systems. I created the foundation for them and then handed the coming iterations off to a colleague later when we needed to start working on the gameplay.
I had worked with input before and felt that I knew a little about it, but it was still interesting and a learning experience to redo it and avoid some of my previous mistakes. The new input system could handle a lot more input simultaneously and had a more reusable structure which I consider two important wins.
The scene management became a natural next step after my work on the state stack since my goal was to get the engine gameplay ready as soon as possible to enable testing early on.
Player Framework
Me and another programmer worked together on the player. I primarily did two of its abilities, and worked a little on a framework for the abilities, structuring and refactoring the code as the project came along. In the end, we still didn’t have a clear, consistent player system class, something that I regret, even though I still think that our priorities at the end of the project to focus on bugs and things that could be experienced in-game rather than reworking our fully functioning code was correct.
Working so closely together within the same system with another programmer was an interesting experience. I think we both would have benefited from talking more about the overarching structure of our code, but I also think that the result still was a good balance between our different programming styles, using the best of both our skillsets.
Player Abilities
The first ability I created was the shield the player could summon for a little while to take less damage from the enemy attacks. It could also be activated a second time, to send out a wave from the player, stunning nearby enemies. The second ability was the area of effect-attack that the player could place anywhere within the screen limits to damage all enemies within its circle.
Both effects had me working with the health system and the enemies and their state machines, to inform the enemies what was supposed to happen to them, as well as handling cooldowns for the player and making sure that they couldn’t activate multiple abilities at the same time, or when doing any other kind of animation or while being blocked by something else in the game.
Project Coordinator
Every project at The Game Assembly has a person who takes on the responsibility to keep the group on track. They usually also do the sprint review presentations, lead meetings and plan ahead somewhat to foresee upcoming problems and steer the group in the right direction. During this project, that person was me.
I really enjoyed structuring our work and making sure that tasks weren’t forgotten, even though it sometimes meant that I didn’t have as much time to take on tasks within programming. It was worth it though, as I learnt a lot about how groups function, really felt like I sharpened my skills at presenting information both within the group as well as outward to our teachers, and in general, grew as a team member.
Other Contributions
Beyond the previously mentioned responsibilities, I also did a few tasks that weren’t my main priorities, but where I chipped in a little either since the person responsible had too much on their plate or because the tasks were related to what I was doing.
These things included some cooldown UI work related to the player abilities, player-related tools, a few events for the event sequence when the boss fight starts, adding the visual effects to the player abilities, some enemy bug handling and of course all the general bug finding and fixing that takes place at the end of a project