Mid-Course Correction

Mobile Design & Scripting

Mid-Course Correction is the product of an assignment created in my 2nd year of Game Design. The project had a 2 month development cycle and was created as a proof of concept by a 4 person team, though development was mostly led by myself and 1 other person, Shannon Umerez (Check her out here!).

Mid-Course Correction is a game designed for mobile. The gist of the game is that there is a “ship” that the player has to control on either side of the player’s screen. Players can only interact with one side of the screen (the side they control flips every 5 seconds), but the movement of one ship is mirrored by the other ship. Players must navigate an endless series of randomly generated levels to accumulate the highest score.

The random level generator was handled by me, and developed fully from scratch. It was important to make sure that the level never creates a layout that was unbeatable, so the levels could not be fully random. Likewise, however, levels cannot be too predictable, else they become uninteresting. The random generation also needed to be modular, and needed to be able to adjust based on the level’s length (which is dynamic based on how many levels the player has progressed).

My solution to this problem was something like this:

When the level is first loaded up, the game instantiates something that I called a “Spawn Terminal”, which are represented by the big yellow dotted rectangles you see above. Each Spawn Terminal was essentially just a group of 6 things called “Spawn Points”, represented by the small dotted green circles you see above. These Spawn Points are what instantiated the actual obstacles that players have to avoid.

The game instantiates a certain amount of Spawn Terminals an equal distance away from each other. How many are instantiated depends on how long the current level is. Then, the Spawn Terminal activates a maximum of 4 out of the 6 Spawn Points it contains – a maximum of 2 on each side. This is to ensure that the level is always solvable – there always needs to be a path through on both sides of the map. If 3 obstacles are active on one side of the screen, it’s likely to create a blockade that the player cannot get through. These obstacles have a randomized width and height, and also a randomized rotation, meaning that no two obstacles would ever have the same orientation.

Postmortem – Mid-Course Correction

Mid-Course Correction was actually a project that I joined in “late”, in a sense. By that I mean this project was split up into an ideation phase (which was done individually) and a development phase (which was done as a group). When our group joined together, Shannon already had created an early version of this idea and had a working prototype to showcase the mechanic of mirroring movement on both sides of a split screen. Shannon and I both agreed that this was an interesting mechanic and we wanted to pursue it further.

We felt that we could use this mechanic to create an “endless runner” style mobile game. None of us had experience designing a game for mobile before, but we were excited to give it a shot. We decided early on that we wanted to have a minimalistic visual style that relied on shape, colour, and particle effects to be striking.

Noone on the team had much in the way of programming experience other than myself, so I decided to fulfill this role in the project. This was the first time that I would be taking on a lead programming role, but it was a challenge I wasn’t going to back down from. It took me about 2 weeks to develop and implement the system that you can see above – something I was quite proud of since I had never developed a system such as this before.

However, the greatest challenge that our team had to overcome was, of course, Covid-19. The first lockdown began after development of Mid-Course Correction was already in full swing, so we had to pivot our development strategy hard. During this time, 2 of our 4 team members unfortunately had personal matters arise due to the pandemic. I was totally understanding to their situations, but it still meant that we had to pick up the slack. I worked extra hard to adjust to a remote workflow, communicating with Shannon regularly and not letting ourselves fall behind. I took on extra work so that we could make sure we get everything implemented on-time, including creating (simple) visuals for the game. We adjusted the best that we could and worked extremely hard to get everything that we wanted into the final submission.