Because it’s gotten really tiring referring to our “flagship product” as our “flagship product”, we’ve decided to codename the thing “Project One” and tag our related posts with it so that anyone who’s interested can follow the story of how the game is progressing by reading through the tag.
Our development in Project One is still at the beginning stages where we’re working mostly with fill in art and temporary graphics, just enough to be able to test some of the mechanics we’ve been working on and to add features to the game engine itself. It’s been a really fascinating process, not just because we’re beginning to see how different aspects link up but because we’re finding out whether some of the concepts we have been basing our assumptions on are working out.
The top among this is how players will be able to control our hero in the game. For games of this type, controls are usually placed on the screen. To us, this has several downsides, namely that the controls take up screen real estate by being there as do people’s thumbs when using them but, and perhaps more importantly, they’re hard to keep track of because, unlike a traditional console controller, there’s no feedback besides what’s on screen to let a player know that they’re using the right controls.
This isn’t much of a problem for many mobile games. Angry Birds, after all, doesn’t require you to feel the actual bird. Once you touch and draw backwards, the bird is disconnected from where your actual finger is while still reflecting the angle and distance it’s being held at. Plus, you’re only touching the screen in one place, so your fingers aren’t hiding much of it. Both the type of the game and the pace of the game make this control workable.
On a fast moving game with fixed controls, however, this becomes problematic, especially when touching the wrong place could mean player death and having to begin the level over again. Remember that a traditional controller offers feedback that you may not even be aware of. You feel when a button presses. Modern controllers even vibrate under certain conditions. All of this is feedback, alerting you to what you’re doing.
None of this exists on the iPhone. The interface is just a flat surface with no feedback to when buttons are pressed.
To overcome this problem, as well as the idea of leaving your fingers on the screen, blocking the available view, we’ve been working on a novel control system to manipulate the character within the world. To some extent, it removes fine grained control from the player once a command has been issued as it automates an action until that action is cancelled but it helps keep the game “casual” and will allow players to better see the obstacles that are headed their way.
The best part about this system is that it uses something all mobile users are familiar with: gestures!
By using a set of simple gestures that will be explained via a really quick in-game tutorial at the beginning of level one, players will be able to guide our hero through the world, dodge obstacles, and fight enemies, all while being able to see the screen. And this is what our gameplay demo is allowing us to test.
It’s funny, when looking at the screenshot of the emulator above because it looks so primitive. But, when working on it, I hardly even see the graphics any more. For me, it’s all about the iteration, running it in the emulator, testing the gesture, returning to XCode, tweaking the handling code, and running it again with the changes.
At some point, Dan and Mike will begin designing the levels in earnest and dropping in new assets and I’ll no doubt be amazed when that happens… that is if I’m not so focused on the code, I miss it.