subzero.eu might be better known for its iOS utility apps than for videogames, but did that app design experience facilitate Zen Wars’ development in any way?
I’ve been creating iOS apps for a while now, most of them for other companies. The more apps you develop, the better you become at Objective-C, working with Xcode, and the App Store process in general.
Have you wrestled with any particularly nasty technical or logistical challenges in implementing a solid multiplayer mode for Zen Wars?
One of biggest challenges when writing multiplayer systems is how to deal with lag. Early on I had the idea of creating a multiplayer system that works no matter how much lag you have. Now, the developers reading this are probably thinking I’m crazy, so let me explain. Creating a lag independent system only works through some trickery. Zen Wars uses a peer-to-peer model to communicate with the other devices. Each device is in charge of maintaining its player’s part of the play field and its units, but not the others. This means if player A and B are repairing their castle and have 2 seconds of lag, each time player A places a wall piece it takes 2 seconds to reach player B. But with clever game design choices, it doesn’t matter if player B sees the wall appearing immediately or 2 seconds later, as he can’t build where player A can build anyway; the lag does not affect player B’s gameplay.
The only important moment is at the end of the round, whether player A completed his repair in time or not. Player B may experience a 2 second “waiting” time for player A while the devices are “syncing” at the end of the round, but while playing, the game feels like there is no lag. There are other examples of these design choices scattered in the game, and it’s probably the coolest Zen Wars technical feature that players will never notice.
When a developer builds a game with non proprietary software like cocos2d, players might get the impression that the team is sort of plucking a package out of a box and running with it. In other words, it’s easy to forget that in the case of open-source software, there’s a two-way street situation. What improvements did you lend to the cocos2d framework that other developers might benefit from down the road?
When starting Zen Wars two years ago I initially tried working with a 3D game engine. But back then, the iDevices simply weren’t powerful enough to display the amount of objects that Zen Wars required at an adequate frame rate. I scrapped that idea and tried a few 2D engines: Unity, Torque2d, and cocos2d. I chose cocos2d because it was free, open source, and written in Objective-C, a language that I knew well.
The nice thing about open source projects is that if you stumble across a bug or missing feature you can often simply add it yourself, and if it makes sense, share your fix or feature with everyone else using the project, however big or small. If enough people do this a project can make enormous strides in a short time, like the cocos2d project has. So over time I’ve improved the built-in scripts to generate sprite sheets, added support for preloading movies so that playing them doesn’t cause a flicker, helped fix a few small bugs, and tried to help other developers on the cocos2d forums when I had time.
We rather enjoy the rotation ring system used for orienting and placing reconstruction blocks in Zen Wars. Were any alternative control schemes ever considered for this function, or did you zero in on this from the beginning to address the challenge of adapting a Tetris-like game mechanic to the touchscreen?
I’m glad you like it. Initially Zen Wars had more indirect controls: you had rotate left and right buttons, and a tick and cross button to place or cancel. While this worked too, it constantly broke the player’s focus: the player dragged a piece into place, then had to look at the rotate menu and tap there, then had to look at the place menu and tap there.
iDevices have no joystick, no mouse, no buttons, etc. You are usually directly touching what you want to interact with. I think that if you want to do a good iDevice game, you have to accept this and use it to your advantage. Don’t try to implement d-pads or other indirect controls, but allow your players to directly touch what they want to do.
So I dropped the buttons and used gestures players will already know from using their iDevice: drag to move, drag the ring to rotate, tap to place. It took many iterations to get the size, speed and sensitivity right, but in the end this turned out to be more intuitive, allowed players to remain focused on what they’re doing, and gave them the feeling that they’re interacting with the objects directly.