Shortly following the release of Arcade Trap, Adam Walker Studio produced two games featuring characters and themes from the short film: Memory Bytes and Critter Rush.
Adam Reed was the lead designer working on both games, and I spoke to him about the processes involved with the development of video games at AWS.

Hi Adam, we’ll begin with Memory Bytes. Can you describe the game for those that didn’t or haven’t played it? Sure. Memory Bytes was initially based around the game Memory, where players match tiles, by creating pairs and the goal is to eventually clear the gameboard. We thought we’d take that fundamental gameset and improve upon it with our own ideas. We thought: “What if we played Memory, but with skills that reinvented how the game was played.”

We also set the game in themed environment from the film; in the forest with the critters, or an oriental theme for the ninjas. We added characters that would move around on the gameboard, so you have the protagonist walking about, and if you failed to clear the board in the time limit, you’d have the enemy characters from the film pummel the main character.

So what do you mean by skills? Well, there are specific skills that you earn through the game, and you can use these to aid yourself. We introduced a time-limit to the game, and on the higher difficulties you really do need to use these skills to get through by slowing down time, freezing time, revealing tiles for longer periods of time, etc.

Were there any skills that you cut? That didn’t work? We developed the skills from the design document from the onset. There were a few that we added during development, but there weren’t any that we actually cut. We took the approach of having the core concept, and then thinking about what we could add to make it better.

And Memory Bytes is playable from within a browser, while the second Arcade Trap game, Critter Rush, was a downloadable file that people had to install. Do you think that one of those methods of delivery worked better than the other? In terms of how the games were deployed, initially, we thought that downloadable installers were a good way of doing it, but we found that more people preferred to play their games through a web environment, allowing them to gain instant access, rather than going through the trouble of installing. It makes sense to deploy on a web environment for that reason.

Is that more difficult? Web technology is getting so good these days that that’s becoming less of an issue as it used to be, but that was still a consideration as to how it would render within a browser and what sort of browser they were using.

The second Arcade Trap game was an entirely original concept – tell us about that. Critter rush began as a scene in Arcade Trap of all these critters, these characters, that would rush the Game Boy in this forest setting. We thought it’d be quite interesting to turn this simple idea into a game. So, after making various design documents, thinking about what would and wouldn’t work, we decided to go ahead with it. The key feature was that we wanted it to feel like the Game Boy is in his own world, defending himself from these creatures that are attacking him, and the player’s role is that of a god, in which you’re there to help him out.

We wanted to convey a sense of a mad, chaotic rush, and then you have to help out the boy – once we decided upon that, we moved into the development phase, and decided what skills we wanted to give the player, how we wanted to design the various aspects of the game and its layout and enemies. We started with a prototype, which was really simple, just the boy in the centre of a forest, and one type of critter came towards him. Once we established that that type of game would work, we went ahead with developing it further.

So is the final game very much like the initial concept that you had? Or did it change over time? The game did evolve over time in a few ways. One of the things we wanted was to develop the game as simply as possible, to have the mechanics be as simple as possible. For example, initially we didn’t want to have a pathfinding element for the critters at all, we wanted them to run in a straight line towards the player, but then there were a few special types of critters with which that approach didn’t work as well, so we had to develop a way for them to walk around the game environment that avoided the boy.

I’ll come back to those changes, but regarding inspiration, were there any cues from other games that you took in designing Critter Rush? Well, if you know games such as Gauntlet, we wanted to give a similar sense of the character being overwhelmed and having to overcome these huge waves of enemy forces.

Any direct inspiration to the gameplay itself though? Well, with the way the skills are activated, once used they have a cooldown period during which you need to wait until they become available for use again. That’s pretty similar to the way in which spells and abilities in a game like World of Warcraft are handled.

I actually had a bit of difficulty playing the game with a laptop track pad, but it was fine when using a mouse. Was the way the player would experience the game ever a consideration? Well, we always assumed that most people would be playing the game on a desktop with a mouse. The game gets quite hectic at times, and the player really needs to focus on pulling the critters off of the Game Boy, which a mouse is really necessary for, especially on the higher levels. But then, at those higher skill levels you need to be utilising the skills as well, so a mouse is really the ideal control method.

What sort of considerations did you give to the sound design of the game? Well, when critters are introduced to the game area they make a noise, which alerts the player, and a similar thing occurs when items or skills become available. One important thing was that because the game is so frantic, and the player’s attention is going to be focused on the Game Boy or the critters at all times, we needed to have a way of alerting the player to when the Game Boy was low on health. So what we did was introduce a dominant heartbeat sound so that the player is aware of their health status without having to actually look at the health section of the interface.

So how long did it take to complete the game? It took close to three months to make the game from initial concept to end product. But, a lot of time was spent on application stability and performance and beta testing.

So, tweaking things? Tweaking things, fixing bugs that we found, sorting those things out. Most of the skills were designed from the start, but some were improvised, introduced to the game at a later stage to directly compensate for gameplay problems. An example is that we had trees that pop up and obscure the board, and there’s an axe skill that’s a way of clearing that problem. But then we introduced a gardener critter that created trees faster than the player could clear with the axe. We found that the player’s view was being obscured too quickly. To compensate, we introduced a tree bomb skill that destroyed all trees within a certain radius. We did that a bit, introducing new elements to compensate for imbalances.

Did you ever worry about the player becoming confused? During the early stages of the game we wanted the player to understand what it was they were supposed to do. So we added an in-game how-to instruction for them to read. But we found through our experience of playing commercial games that generally people don’t bother reading this, they just want to start playing the game. One of the problems we found as we were beta testing the game we found that people were getting confused with what they were supposed to be doing, and weren’t utilising key gameplay features. So we created a video of a game in progress and explained the various features in that. Then we embedded that into the game itself so that the players are prompted to watch the video when they start.

That’s another thing that came out of Critter Rush: in-game hinting is also a massive consideration.

Like pop-up information? Yeah, in-game hints that pop up and offer help or information. One problem was that we had all these critters and creatures, and they really weren’t getting the attention they deserved. So we brought in a system whereby when the critter came out the player would be informed of what it did. So the user is made aware of these new elements as they become introduced to the game. There’s nothing worse than having a game in which the user has no idea what they’re doing – they’ll lose attention straight away. They were the kind of things that came out of the beta testing phase. We realized that we needed to implement this kind of learning curve.

When we set out to make Critter Rush, we really didn’t want a steep learning curve, we wanted people to be able to pick it up and play it, and that was it.

Did you have to alter anything then? Did you make the game and then find that the learning curve was a bit too steep or was that progressive throughout the development stage? Yeah, we did find out that the learning curve was a bit too steep, especially for the people who weren’t familiar with playing games. They don’t play casual games or video games, so we needed to provide various ways to inform the player that this is how you do it.

One key thing about beta testing and the game was getting the player to interact with the various enemies and skills and developing their own play strategies, and using these play strategies it allowed us to not so much change the basic gameplay, but to tweak the various skills and items. If there was a skill that was too powerful or too weak we had to change it. It’s all balancing. A big stage of the beta testing was tuning the gameplay, balancing the enemies with the skills, while keeping it all interesting for the player.

It sounds quite daunting. Oh, gameplay balance can be a nightmare. It can make or break a good idea.

But regarding the actual design of games, is there anything that occurred or that you learned that informed how you went about making games in the future? We’ve worked on a few games since Critter Rush, but one of the initial problems that Critter Rush taught us was that we used to come up with the initial concept of a game, we’d prototype that, and then we’d start production. But we found ourselves appending new ideas to the game while we were into the development stage, such as adding new skills. The problem is that that this blows out the production time. We realised that we needed to have solid design documents from the onset – the basic structure, the features to include, and stick to a set development time.

But then, it’s quite easy to have an idea and develop it in a technical environment and understand how things work, but to have the user understand and enjoy it is equally importants. We need to remember that the people that are going to be playing the game are outside of the development process, and try to think about how they’ll see the game

How did you test that for Critter Rush? Initially we had studio members testing it, but of course the problem with that is that they were involved in the development.

They were a bit too close to it? Yeah. In the future, we might spend a bit more development or beta testing using external sources. Commercial games, companies spend thousands of dollars on beta testing their games, and they spend months beta testing before the game is released to the public. We don’t have the luxury of that, but it’s something we’ve got to be aware of.

Have you had any moments where you’ve thought “That’s an amazing idea for a game?” Yeah, I’ve had a lot of good ideas for games, but the problem is really just the production time. We’re finding that a lot of the casual games that you get these days are very simple ideas, but they’re really nicely executed. They’re good games that you can pick up for 5 minutes, put them down and then come back to later.

And do you think that that’s the overall execution or do you think that that’s the fundamental game design underneath? I think that that’s an issue of design, but it all depends on the game that you want to make. We’re focusing, with our experience from Critter Rush and the other games we’ve done, that we want to make games that take a few weeks to develop and are interesting to play. One of the main aspects is the artwork that we can provide to make the games visually appealing. A lot of the AWS film stuff and our 3D knowledge allows us to incorporate that nicely into the games we make, whereas people without that knowledge don’t have that advantage.

At the end of the day though, our goal is to make the user feel good, and have a good experience playing the games that we make.

Arcade Trap Week Links:

Monday: Lead animator Aldrich takes us through a video breakdown of the animation process, shedding light on the nuts and bolts of animating Arcade Trap’s many fight sequences.

Tuesday: We look at the character design stages of Arcade Trap, from early concept sketches to the final models used in the finished piece.

Wednesday: Get yer ears ready, as Aldrich’s back. This time he’ll be showing us how the sound was engineered and implemented within the short.

Thursday: I’ll be talking to game designer Adam Reed about his involvement with the two Arcade Trap videogames that AWS produced, Memory Bytes and Critter Rush.

Friday: I try my hand at constructing some of the AWS-produced papercraft models designed to celebrate Arcade Trap’s release. Scissors and glue attack!