We’re in the holiday spirit here at Koduco, so we’ve decided to open source PongVaders. Here is a preliminary release! It’s broken as it stands but we’re working to clean up the codebase for a proper release. The code is under GPLv3 and the assets are under CC BY-SA.

<3

Cole & Jon

First, we made an ad system to let people know when we release new products. We looked at competitors’ ad servers and thought that they were kind of lacking. Generally, they served either static notices that required updating the app, or the ad view would be ‘frozen’ while a server was pinged and the ad was loaded, thus blocking usage of the application. So we built our own ad server and ad client. We cache ads in the background so product notices are seamless and don’t block usage any more than is necessary. You can find an image of one of our ads above, but you should see it in action in either 3D Checkers or PongVaders Max.

We also wanted to explore the realm of DLC, so we released a series of board packs for 3D Checkers. You can now buy three-packs of skins for a buck each. We think the boards look pretty decent; idk.

We also remixed and remaster PongVaders for iPhone. We tripled the length of the game, refined our player feedback loops, added some new twists, rewrote the script, and added a ton of personal touches all over the place. It’s a much more polished game now and we hope you enjoy it.

And we’re continuing to soldier on our path to a new game. We’ve made a lot of one-off prototypes and made practice minigames to hone our gamefeel. But our main push is on something code-named ‘RocketSquid’ (excuse the trochee-noun), an iPad game intended to have emergent multiplayer opportunities since the squid’s 10 limbs of articulation map nicely to varying numbers of fingers belonging to varying numbers of hands belonging to varying numbers of humans, and would probably produce fun ‘finger twister’ scenarios necessitating verbal coordination to solve.

Note: I am going to ignore mice in this article. They’re kind of a weird hybrid abstracted-touch technology. Earlier drafts dealt with mice, and it made things unnecessarily complicated and, let’s face it, games that utilize the mouse usually have specific reasons for doing so. That is, people don’t haphazardly design mouse games the way many people haphazardly design touch games.

Let’s start with the basics. Games have traditionally been played with clearly abstracted interfaces utilizing joysticks, buttons, and d-pads. I call these interfaces abstracted because the joystick is not your avatar* and the act of pushing a button is, in most contexts outside of games, not associated with a person making a physical action. In some cases, every input feels the same on a physical phenomenological level. Taking Mario as an example, running, jumping and shooting a fireball all feel the same: the press of a button. Which also feels the same as firing a gun (or hiding) in Metal Gear Solid, or rotating a piece in Tetris, or accelerating a car in a racing game. Other games adopt control schemes designed around complex multi-button simultaneous input. Fighting games are perhaps the most ubiquitous games with complex control schemes – the percussive button presses mixed with the fluid directional input cannot be found elsewhere. Other examples of expressive multi-button input include the rhythmic double-tap of a button for a double-jump in Metrovania type games, the physical sensation of holding z before tapping jump in Super Mario 64, and experimental games like QWOP and GIRP. Buttons are by no means outmoded; they represent a form of input that is more abstracted than touch input.

* Starting a timer until someone makes a meta-game where the avatar is a joystick.

The introduction of the touch screen is dramatic. It is now a familiar technology, having first appeared in a mass-market consumer entertainment device in 2004 with the launch of the Nintendo DS (the Palm obviously pre-dates this yet I found few examples of Palm applications utilizing the stylus for things other than pointing or writing). I would argue that the most important change that touch interaction brings is phenomenological. By this, I highlight that the screen can be touched in a plethora of ways which enables concepts like ‘direct input’ and creates immediate physical metaphors for interacting with the game world. Using The World Ends With You as an example, the act of casting a healing spell is performed by tapping, the act of slashing an enemy is performed by scribbling the stylus back and forth across the display, and a spell’s area of effect can be literally drawn with a circle. Each of these acts feels different from each other, and feels different from, say, creating ramps by drawing smooth calligraphic movements in Kirby’s Canvas curse, or investigating a dark room with a flashlight in Phoenix Wright by dragging. (Note the dual verbs per example: the game verb and the gesture verb.) These gestures are natural and their meaning and effect are extended in the game world.

That there is a joy in the tactility of direct input is without question – look at the legions of Angry Birds fans enjoying the simple physicality of slingshotting objects and watching the havoc it creates. That’s all there is to the game. The level design is generally not excellent, but that’s irrelevant; the game succeeds best as a toy, almost like firing a virtual Nerf gun at building blocks. Yet it’s crucial that slingshotting the bird is performed by touching the screen and dragging the finger (and the bird) backwards then releasing. Angry Birds on consoles, controlled with joysticks and buttons, has been, well, less than a hit, and I don’t believe it’s due to demographics differences or market saturation. The natural quality of touch interactions is also crucial to accessibility: Angry Birds took off with ‘non-gamers’ because it could be picked up and played, without explanations or a heavy GUI or tutorial explaining the nuances of dragging birds around.

It’s worth noting that the touch screen means that the user’s access time for interactive elements in the game world conform’s to Fitts’s Law. This equation governs the time it takes a user to point to a target and it is primarily a logarithmic function of target distance and target size. The equation does not hockey stick with the addition of new targets (at least not until there are so many targets on screen that the targets shrink, in which case, potential ouch). Compare this to button-based navigation of targets. If the number of targets maps neatly to the number of buttons such that each button acts as an index to a target, targets can be accessed in a small constant time. Think about a large number of targets (letters) paired with sufficient buttons (your keyboard), or a small number of targets (4 weapons) paired with a d-pad (four directions) as in Gears of War. Fast.

But when few keys are used to navigate large arrays – consider navigating inventory in a console JRPG – it’s a slog. Forget navigating the list of inventory items in real-time. In short, with key-driven interfaces to lists of objects, each additional object results in additional button-presses and extra time to access a given object. An action-puzzler like the iOS game Cut The Rope is possible only on a touch interface. It is a physics-driven game involving a piece of candy, a goal, obstacles, interactive elements such as whoopie cushions, plus ropes to connect all of these objects. In a typical challenge, the player will cut the rope that is holding the candy and quickly tap other objects to redirect the candy around obstacles into the goal. Touching these objects in time poses little problem since the amount of time to move the finger across an iPhone screen can be measured in fractions of a second. With half a dozen or more manipulable objects on screen, keying through each one with a button would be time-consuming and imprecise. Other examples of games which benefit from touch driven input include Lemmings* and World of Goo.

* Summary: Fitts’s Law governs the time that it takes a user to point to a target. It is a function of distance and target size.
* I acknowledge that Lemmings has had console ports utilizing a d-pad controllable cursor but I challenge you to look me in the eyes and tell me that they’re not a pain in the ass.

Multi-touch displays bring the ability to, yes, track multiple touches. This is not a sea change like the introduction of the touch screen, yet its ubiquity with the success of the iPhone and Android smartphones makes it important to consider. I have isolated two points: an increased capacity for modality and an expanded vocabulary of natural gestures. First, modality. In short: the number of active finger-presses determines the mode of the interface which changes the meaning of the given gesture. An example would be using one finger drags to move game pieces and two-finger drags to scroll the visible game world in the viewport. I’m not yet certain of the importance of the expansion of natural gestures. Single-touch devices can use the natural gestures of the tap, the press (and hold), and the drag. Multi-touch devices introduce two-finger gestures for expansion, contraction, and rotation. If I’m missing any crucial natural gestures, please let me know.

Despite the brevity of the previous paragraph on multi-touch smartphone screens, I believe that simply enlarging the screen brings a host of new potential interactions. The first is that multi-tasking (using multiple touches to track multiple objects) via bimanual input are possible. Though this is technically possible on small multi-touch screens, I assert that bimanual input is inconvenient on a phone-sized device since two simultaneous hands can easily occlude the entire screen. I have not seen many games make explicit use of the multi-tasking capability, but I will note that it is possible to get furiously fast times in Cut The Rope by using both hands, which halves the average distance from any hand to a target. Large screens are easy to share which encourages emergent multiplayer activities. Emergent multiplayer is the event where a single player game is seamlessly played by multiple players by either dividing screen segments or aspects of control. (Note that none of that is encouraged, enforced, or limited by the rules of the game; it is the players who are inventing these interaction patterns*.) Games like Flight Control are great for this, where multiple objects need to be sorted simultaneously. Players can easily agree to sort the objects on a given side of the screen. Creative toy-like applications like a pottery simulation are also good for sharing, as players can take turns shaping the clay before it is fired, and verbally contribute even while not physically interfacing with the game. Same for puzzle games, where the level of information input to the game is low in relation to the level of information output from the game – that is, two people can easily share a puzzle game with only one person in control, since most of the playing of the game – solving puzzles – is performed outside of the game, in the player’s brains, thus inter-player speech is a perfect interface.

* DEATH OF THE AUTHOR

Explicit multiplayer on a shared large multi-touch device remains a largely unplumbed avenue. This play configuration results in much shared information between players, as well as shared physical space. It is the latter aspect that results in players both touching and being touched (by other players). Sharing a device with another person has a unique immediacy. Bodily presence, mood, posture, and more are all apparent to the other players, contributing to a shared emotional state. Because all the control occurs on the screen itself, players also have absolute information regarding the current and upcoming input as well as player intent. That is, because hands perform the input, and the shared screen is the locus of input, players can see each other’s input. This should play a factor in multiplayer games: it can be exploited for bluffing via falsified input or for coordination in cooperative tasks. A basic example of the latter occurs in PongVaders, a Pong/Space Invaders/Arkanoid mashup, with dual paddles on opposing sides of the screen. There is a powerup that causes one paddle to shoot projectiles which must be blocked by the other paddle. The blocking player must follow the shooting player’s finger; it’s a smoother experience than if the players were wielding separate controllers. Sharing an input area also results in issues regarding personal/controlled space as well as the potential for physical contact.

It’s now appropriate, if not past due, to talk about what sorts of tasks and games are unlocked with the intersection of all the qualities described above. To start, it’s worth rehashing the research of Stacey Scott surrounding territoriality. The rundown is that when people share a surface, there is a notion of personal spaces – the areas nearest the users – and public space in a central location apart from the users. Users are uncomfortable reaching into another user’s personal space or having their personal space invaded. Public space is a grey area that is difficult to define and navigate. You should already be imagining ways to build games around those conflicts.

Entire games can be built around territoriality. The emergent multiplayer aspect of Flight Control is an excellent example. Planes flying in from all over the screen must be directed to airports. Who directs which planes? A simple answer is to divide the screen into halves, but there will always be edge cases that are awfully close to the center, where either verbal or physical signals will be required to declare intent and territory. And what happens when planes originate in one player’s territory and must be directed to another player’s territory?

Given a shared input device, ‘above the board’ physical competition is possible. Due to the inability to disambiguate touches between players (that is, the device has no idea to /whom/ each touch belongs), it is easy to create games that are readily ‘broken’ by players blocking input from each other or touching each other’s avatar/game pieces. Of course, one can consider that there is a risk/reward scenario to exploit related to the idea that every finger or hand spent futzing with another player’s (real life) fingers or (in game) resources is one less hand spent defending one’s own (real life) hand or own (in game) resources. The best example of this physicality is Chicanery, a game by Auntie Pixelante and ported to the iPad by Bennett Foddy. In this game, each corner of the device has an image of a pad. Each player must hold a pad. The last person still holding a pad wins. In terms of the game, very little happens on the device/in the game world itself. The device acts as referee and that’s about it – the majority of the action occurs between the bodies of the players themselves as they strike and push each other to force players to let go of the device. The presence of the other people is also important, from being able to anticipate and dodge (real life) punches and kicks from other players, as well as being able to discern limits based on other players’ emotional states. Combined with questions of territoriality, one can imagine a resource-hoarding game where players strive to physically block other players from dragging resources from the shared middle of the screen to their personal stockholds, or to steal resources from other player’s stockholds for their own, at the cost of using those fingers to defend one’s own resources or collect ‘fresh’ resources from the middle of the screen.

One last task that holds potential is coordinated input. Let’s consider coordinated input of a single avatar. Using separate controllers, this would be immensely difficult. Halo allows one player to drive a car while another player controls the turret, yet it compensates for the rotation of the car in the aiming of the turret such that the driver never has to warn the gunner that a sharp right is upcoming – words are too slow to communicate frequent micro-adjustments, and the lag between 1) the driver’s input, 2) the driver’s input translated in the game, 3) the gunner’s visual perception of the driver’s input in the game, 4) to the gunner’s compensated input is too great. I believe that by cutting the chain down to 1) the driver making an input, 2) the gunner directly seeing the driver’s input, and 3) the gunner making compensated input, the control scenario should be feasible. In addition to solving some information problems sharing a physical input device also brings new physical challenges. Imagine a game where two players share the control of a single squid, a sea creature with ten obvious controllable facets (8 tentacles + 2 ‘arms’). One player could scrub the arms to make the squid paddle in the water while the other player controlled the tentacles to gather food and fend off dangers. Or both players could control tentacles. If all goes as planned, the game should, at times, devolve into finger twister.

While this is clearly not a definitive guide to design patterns and considerations when making games for multitouch phones and tablets, I do hope that it serves as a useful summary and starting point so we’ll see more new types of games that are possible with these new classes of devices.

SPECIAL THANKS: Jonathan Blow and Cole Krumbholz.

At first, I paid little attention to Uncharted’s camera. It was silky and mostly unobtrusive, yet generally out of mind. Then I noticed how it moved during platforming segments, gently tilting and tracking to suggest the next platform to pursue. Kinda neat – the camera plays as much of a role in distinguishing climbable and walkable parts of the environment as the contrasting texture-work. (Aside: many extruded elements of the environment appear white-washed. Is this coloring from dried salty ocean mist or from perched birds?)

Where Uncharted’s camera-work is the strongest, however, is in its ability to affect the player’s perception of the scale of the environment. This ranges from obvious wide-angle shots to establish grandiosity to more subtle effects which build a dramatic irony between the designer’s knowledge of the world and the player’s knowledge of same. One example of this occurs while the protagonist is scaling the wall of an old castle mid-way through Chapter 6. The player begins close to ground level, hopping from one extruded detail of the wall to another. The camera is above the player, facing down. After a half-dozen vertical leaps up the wall, the camera is about even with the protagonist’s shoulders. It feels like it’s about time to look for some stable footing. None is found. Further leaps cause the camera to fall behind the player’s vertical progress, at which point the camera begins to tilt up, slowly revealing the enormity of the structure. I laughed at this unexpected realization. The designer knew the height of the wall. So would the protagonist. The player is the last person clued in to the scale of the wall, and the tension the camera creates between the player and the designer grants the player a sense of surprise and excitement that is not seen in many games.

We were wrong.

First of all, there was personal context. They knew that I could be a prankster, so they found it funny that the ‘powerups’ in the game were generally ‘powerdowns’. Secondly, these were engineers. They liked solving puzzles. Any opacity in our game systems was seen as a fun problem to solve. Some of the opacity was intentional; some of it was not. Nevertheless our playtesters enjoyed deciphering the rules of our game.

Post-launch, we had an opportunity to show the game at PAX. If we weren’t thick-skinned and willing to undergo severe pain on our quest to make you, our audience, happy, this trip would have been about as fun as being on the receiving end of a disciplinary lecture from one’s elementary school principle. To the unwashed masses general gaming public, the powerdowns were confusing and frustrating, as was puzzling nature of the non-critical game systems (points, volleys, etc). What we had hoped would be a simple mashup of two classic games was in practice difficult for people to play. Oops.

We’ve remedied this in our upcoming update after we took a week to …

SPEND EXTRA EFFORT ON PLAYER COMMUNICATION / JUICINESS
This tip comes straight from a heavy-weight game design expert who will remain nameless because it would seem mostly like I’m namedropping. He told us that player communication makes a game ‘juicy’ and aids in learning the systems at work.

He gave examples of how backgrounds in Braid had linear movement that was identifiable as ‘forwards’ and ‘backwards’ (such as falling water) that both enhances the time-reversal mechanic as well as communicates to the player exactly _what_ is happening. Limbo was another example, with its use of falling detritus to communicate the vector of gravity while the orientation of the scene/gravitational force changed (compared with And Yet It Moves, which does the player few favors in determining orientation). Sound effects were also highlighted as a critical piece of creating ‘juiciness’.

When creating a game, we have a limited range of output to the player – mostly image and sound. Juiciness comes from creating something believable or believably tangible. In addition to sounds and visual effects acting as blatant signifiers of things that happen in the game (think of the sound of Mario collecting a mushroom, or the nitro-charge noise of bumping a chain in Rock Band by another ten notes), they can serve as signifiers of _properties_ of things in the game. A simple example: using a lower pitch when a ball collides with a lengthened paddle in Arkanoid or KODUCO GAMES’ very own PONGVADERS anchors the paddle (and, to a secondary degree, the ball) as a physical object with physical properties within the world of the game.

Play your favorite games (as well as some best-selling games) with this in mind and pay attention to what’s behind every sound effect and flourish. Does it help you learn and play the game? Do you crave certain sounds, such as the satisfying ‘clank’ of a dropped shield in Halo, the ‘slap’ at the end of a stage in Super Meat Boy, or the relieving ‘bleep’ of hitting a checkpoint in VVVVVV?

TRUST YOUR COLLABORATORS / CONTRACTORS (DON’T MICROMANAGE)
It’s good to have a vision – no one’s going to deny that. Yet there’s a difference between having a vision and being overbearing. If you are outsourcing e.g. art and/or music, that means that you’re not an expert in that field (in biz-geek terms, it means that it’s not your “core competency”). If you are unable to show your collaborators your game so far and tell them to go nuts within a specific budget, I would argue that you are either a control freak or that you are not working with good people. I’ve been on both ends of a contract, and I can assure you that when my client has micromanaged me or given terrible specs, my enthusiasm and work have suffered. Only work with people who will improve the vision of your project, then allow them to do so.

WORK ON SOMETHING ELSE FOR A WHILE IF YOU GET BUMMED
After receiving a bum rap in the AppStore due to a particularly lengthy lead-time on a patch release, we were not at our peak performance for a couple weeks while working on further patches, ports to our games, and infrastructure to cross-promote our games. We took some time out in October to head back East to see some old friends and hang out with the fine folk at MIT’s GAMBIT Game Lab. During our time there, we dropped our current projects and did things such as play with construction paper and Play-Doh until we felt that we hammered on a good touch interaction. Then we mocked up a game utilizing that interaction. When we came back to the KODUCO GAMES studio we were re-invigorated and were able to draw up and execute laundry-lists of things-that-aren’t-directly-related-to-games such as creating an in-house ad network, prepping in-app purchase and creating the associated DLC, etc.

Short version: working at a slow pace drained momentum which resulted in yet slower work. Working quickly on something else for a week restored our momentum.

THE BURRADILLA
Mexican cuisine is difficult because it’s all so delicious and it’s hard to decide what you want to eat. Do you want a taco? A burrito? A quesadilla? Doesn’t it all sound great? Here at KODUCO GAMES, we do food mashups as well as game mashups. Our inaugural Hacker Snacker recipe is THE BURRADILLA, the Frankenstein-like portmanteau of the burrito and the quesadilla.

INGREDIENTS
2 tortillas
Cheese
Refried beans
Salsa and hot sauce

PREPARATION
Put a tortilla on a plate. It doesn’t matter which side is up. Spread cheese on the tortilla. We found that shredded cheese is the easiest to deal with. For optimal results, use cheese from free-range no-kill no-hormone farms so your meal isn’t tainted with guilt.

Place in a hot pan and lay another tortilla on top of the first tortilla. This may seem like a lot of tortilla but I have faith that you can handle it.

Heat the refried beans. Microwaves are the fastest, but they come at a cost of your culinary cred, which credibility already took a hit by reading this recipe.
Wait for the tortillas to be slightly browned and for the cheese to melt. If you’re the antsy sort, just think of waiting as patience training and you’ll feel like you’re doing something. At this point you have a slightly undercooked quesadilla.
Place beans, salsa, and hot sauce on top of the quesadilla. You can also add grilled vegetables or rice.

Roll up like a burrito.

Hold burrito up to mouth, insert into oral cavity slightly, clench jaw to remove portion of burrito, masticate as appropriate, repeat until full.

Now go for a run before you get fat!

EXCEPTION: For 3G phones and iPads without background capability, applicationWillResignActive is not called when the home button is pressed. I will update the diagram soon.

This diagram may not reflect the latest changes to the iOS SDK. Please leave a comment if you see a mistake, and I will correct it.

Late last week I found myself feeling under the weather. I curled up in bed with some SERIOUS LITERATURE and my iPad. After reading to the point of vague mental exhaustion, I turned on the iPad and downloaded a game that Cole (the other half of Koduco Games) had recommended to me, Super Mega Worm.

It’s a humorous, well-produced game about a voracious worm (née Wojira in a nod to Godzilla’s original name, Gojira). The first challenge is the control scheme: players only control the clockwise or counter-clockwise rotation of the worm. Before this is mastered, Wojira will frequently dig in circles as it starves to death. Once the player has tamed the worm, priorities such as eating increasingly hostile humans and destroying vehicles take the forefront. Scoring can be bolstered in several ways: Wojira can lure clusters of humans in one spot and detonate a bomb, skim across the surface of the ground eating and spitting fire at a dozen foes at once, or it can bounce from vehicle to vehicle, Doodle Jump style, going from truck to airplane to satellite to international space station. I played the game for a solid hour and a half straight and had a fantastic time.

This morning, Adam ‘Atomic’ Saltsman tweeted that Super Mega Worm was a clone of Death Worm.

The two games are exceedingly similar. Super Mega Worm clearly has more polish and, generally, more to do and explore with its new control scheme and additional ways to build combos. But it’s also very clearly in debt to Death Worm.

Now let’s consider DoDonPachi and Castle Shikigami, both manic shooters.

Shikigami succeeded DoDonPachi and introduced more intricate bullet patterns and twists to the scoring system. Is it a clone? Or is it a genre-game?

The most egregious cases are of course brand-confusion based clones such as Veggie Samurai aping the multi-million selling Fruit Ninja.

What’s the difference here? Is it that cloning a big company is less offensive than cloning an indie? Is it that shmups are a codified genre and after Galaxian and Gradius it’s a free-for-all? Does it have to do with the specificity of an idea – one can imagine patenting Death Worm, whereas, even in the beginnings of the shmup world, it would be impossible to imagine patenting ‘a third-person experience of ship flying through space shooting things’? Maybe the key is the potential breadth of iterations on a game – it’s hard to imagine Death-worm style games becoming a genre, whereas it was clear from the beginning that Wolfenstein 3D and DooM were the progenitors of something big. Thus Medal of Honor and Call of Duty are both seen as members of the genre of first-person shooters, whereas Super Mega Worm is a criticized as a (highly polished) clone.

What do you think?

This is your apartment:

This is your apartment on crunch:

Readers, please plan your development cycles responsibly.