During December of 2018 and January and February 2019, I worked with three peers on a game inspired by the Ex-Machina movie. This was the second of three assignments in the “Low-Level Programming” module in the Games Technology course at UWE.

Week 1: Movie & Pitch

On November 30th, we watched the Ex Machina movie. This was because this game is meant to be inspired by the movie, so this was for the benefit of those who hadn’t seen it. Afterwards, our groups were put together and we were given a week to come up with a concept that we would then pitch.

We shared some ideas, such as a stealth game or a puzzle game, but eventually combined those ideas into a platforming game with a series of levels. However, these levels would be unique as each would contain two methods of progression, one that was significantly easier and one that was harder. The harder route, if consistently taken, would lead to the ‘true’ ending. The intention behind this was to add significant replay value to the game.

Additionally, the player would be able to briefly activate a super powered state at times, which would be a temporary powerup that would grant the abilities needed to take the harder route, but it would only be able to be used a limited amount of times. This feature was inspired by Ex Machina’s Eva having greater control over the facility than even her creator is aware of.

We pitched our idea on December 7th and got greenlit.

Week 7: Initial Development

Because the pitch took place towards the end of the semester, little progress was made towards the project due to the Christmas break. Once we returned to university in early January, we immediately met as a group in person and discussed on how we would distribute parts of development.

My role in the project was eventually decided to be a level system, allowing different types of tiles to be placed in a 64x64 grid with additional freedom on a block’s collision and other variables, such as if the 64x64 block was damaging to the player. Each individual tile would be represented by a line on a text file.

My role was to make a level system that could do these things while being simple enough for other members of the team to understand so they could create additional levels for the game with relative ease, as well as simple enough for level design tweaks to be made fairly easily.

Week 8, 9 & 10: An Optimized Level System

This part of the development was focused on the developing my assigned level system. I knew I would use what I learned from the Basic Reb0rn game, specifically reading from a text file, for the purpose of generating a level. My objective was to have the data each level needed in its own text file, ranging from the graphic needed to be displayed to other variables that could be tweaked.

This involved learning how to read individual parts of a string, which is something I struggled to do with Basic-Reb0rn, but with this game, I researched further and found a well optimized approach that took everything from the first character to the first space, but after doing so, erased that part of the string, so for when the for loop looped back around, the second word in the string would now technically be the first.

This part of development was also spent figuring out the best way to render everything effectively. I eventually decided on rendering row by row starting from the bottom, then resetting the X position and adding 64 to the y position for the next set of renders. This led to an interesting oversight where I accidentally starting render a row below the screen which was a troublesome half an hour as I tried to figure out why the number of blocks displaying on the screen vs how many were supposed to be there didn’t add up.

Week 11: Blocking

On this week, I learned how hindering blocking could be, but also the best way to deal with it. Collision had been added by this point, but the only way to appropriately test it would be to add the playable character in, which was another member’s job to create. I had thought of adding a simple debug object that could be moved left, right, up and down to test, but I decided it would be best to help my team member.

This was beneficial as I also wanted to learn how the collision interacted with their jump, so I paused my level system to help them so we could eventually merge both our progress into a new branch.

Week 11 & 12: Additional Optimization & Making the Actual Levels

Additional optimization was done to the level system during these two weeks, including adding support for multiple levels. Before this point, the code only looked for “level.txt”, but because there would eventually be a ‘level1.txt’, ‘level2.txt’ and so forth, so the ability for the level system to read in a passed in value was added.

The job of creating the levels themselves was originally going to part of another member’s role, but their other responsibilites took focus and I decided to create the levels as at this point, I had systems such as the playable character ready to use. Because I was most familiar with the level system and how to appropriately edit the text files due to countless tinkering, I managed to make levels fast.

Week 13: Finalizing

This week was the final week of the project before its due date. I used this week to continously test the system for bugs. I also tried to see if it could ignore blank lines which could then be used to separate each individual row for the sake of easier readability, but doing so took up too much time so I put that aside.

While the rest of my team focused on finishing up and debugging their systems, I finally took advantage of my system’s ability to display a graphic of your choice for any block and made the levels somewhat resemble a facility, rather than just being a white void.

Post-Mortem:

The Ex-Machina game went well. It was the first time working together on a team on a project that involved actually making a game. We stayed in contact reguraly, gave each other feedback and advice and all played our part.

One feature that I would have liked to have added was a scrollable level, where after reaching the middle part of the first section, the camera would ‘scroll’ to show more of the level. Doing so would add more functionality to my level system.

This would realistically have been done by moving the terrain rather than the player, but unfortunately due to deciding to focus on optimizing the features already in development, this feature couldn’t be added and we decided on having multiple one-screen levels as an alternative instead.