During my MA Games Development course, my team was tasked to create an 'infinite runner' for Android devices, I was the lead artist on the team and I created the characters, levels and animations for the game. The end result was quite successful although the scale of the project, even though it was small, proved to be quite an experience for the team.

 

So, the game is yet to be released, but I think the best way to reflect on this project, with respect to the fact is a full game, is to do a short postmortem.

 

The concept was based on a criteria given to the Studio One team that was simply "It must be on android" and "It must technically be an infinite runner. The actual design was thought up about an hour later. Simply with the concept of a 'two-touch' mobile control scheme, based around switching characters. The aesthetics came later.

​

​

​

​

​

​

​

​

​

​

​

​

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

What Went Right

 

1. Quick Prototyping

 

Development got to a head-start and had an easy time meeting milestones. The original design for Dr. Deckyl & Mr. Joe was to allow room for more characters beyond the two that fell under the minimum viable product. However the team decided that each subsequent character would exponentially increase the complexity of the game’s design as it would create an entire scope of new rules that level design and other aspects of the game must then accommodate for. 

​

 2. Game Feel

 

The team’s decision to focus primarily on the moment-to-moment gameplay had presented an important question: what steps need to be undertaken in order to perfect the correct feeling through gameplay? The concept of game feel is defined as “The tactile sensation of manipulating a digital agent.” It is, to him, something that is governed by the time between when the thinks of an action and said action taking place on screen – as well as the appropriate feedback being given as it happens.

 

We took this approach to heart when designing the player controller, making sure the hitboxes, weighting and relative jump heights and speeds all had the correct feel that the game remains satisfying even during the process of repeatedly failing before the player can get used to the way the game controls.

 

2. Iterative Design

 

There was a system in place to allow for testing instances to be consistent throughout. Testers were always given the same instructions and asked the same questions with each testing run. The primary question, however, was one posed to the developers themselves: does the player have fun.

 

The majority of instances of feedback were acted upon.This includes areas such as identifying where testers often get stuck or where they often have questions. For example, players during one testing phase often were confused at the difference between background and foreground objects. This was never explicitly mentioned by testers but observation made it reasonably evident. The solution was simply to go back into the level editor and experiment with different ways in which to obscure the background without making it completely unnoticeable.

​

What Went Wrong

 

1. Scoping for an audience

 

It's common knowledge among those of us developing for the mobile market that you are marketing to an extremely wide audience. That was the original intention, but quickly, the our respective ideas of who this game was actually for quickly got lost in translation. 

 

In any real game development, it's far too easy to fall away from designing for the audience you have in mind, to designing for yourself. This is especially true when the potential audience is significantly younger, older, or at different skill levels to yourself. As I said, our quick prototyping, testing, and iterating based on the results helped with this. However it became apparent in later stages of the project that this caused us to gear our adjustments towards the particular demographics of the people we were conducting testing on: Those of a similar age to us, with a similar level of interest in games as a whole. 

 

The result was something far more challenging than your average Play Store infinite runner. It was actually somewhat difficult for us to conceptualize something easier, because that wouldn't be fun, would it? 

 

The answer is no, not to us. But the majority of people we might want to market to, we create a barrier to entry. So now we have this issue of having a game we enjoy, but is inaccessible to most of the casual market. Do we adjust, or do we carry on and just aim for the niche? Not even this, we could agree on. In the end, we decided to keep much of the level design the same, but adjust the speed and positioning of the character to make it just that tiny bit fairer.

 

2. Burn-out

 

Finally, perhaps the biggest challenged this project presented was working on the code while also keeping four other developers working at a consistent level of efficiency throughout. A crash course on project management would have you believe that a well-detailed Gantt chart is all you need to keep people working on everything consistently. However, what we actually found was that in later stages work was still getting done, but was all too often last minute, and this harmed the process of iteration and review that our quality standards hinged on.

 

The issue was that without constantly having a build to test, and without re-adjusting deadlines accordingly, you find yourself in a situation where we become less motivated to do the initially scheduled work, and we fail to address the additional tasks that arise mid-project. The result is everything becoming crammed, which causes everything else to suffer. 

 

At the indie level, you really do need to take a review of what you really still need to do at various stages, rather than just the start.

​

Programs Used

Unity 
Adobe Photoshop CS6

Spriter Pro

​