Why?

Because the rules of play have changed, specifically with the advent of App Stores – be it the iTunes App Store, the Xbox Live Indie Games and Arcade Games stores, the Playstation Network PS Store, Wiiware, various Flashgame hubs (Kongregate etc), the ever-present Facebook games, Steam and a growing number of independent publishers on the web specializing on publishing downloadable and free to play games for the masses and niches.

The result of this onslaught of new game titles, the release of more game titles over various platforms has to result in the abandonment of the “captivate the player within 15 minutes” rule. It no longer holds true, maybe with the exception of expensive, high-quality productions where players might be a little more patient with games – but even that bastion is slowly succumbing to the sheer quantity of titles a player can select from. Players are increasingly becoming impatient with games, many times not even enough to give a game a trial run for 15 or even just 5 minutes. But if you’re actually lucky enough that the player chose to download and start your game, what should be the most important goal to make the most of this fortunate event?

Of course:

Engage the Player within 15 seconds!

That is the new rule: “Engage the Player within 15 seconds!”
… “or you’re screwed” I wish to add. 😀

This rule tweaks two crucial aspects, the most obvious being that the time frame is now one sixtieth of what it used to be.

The other is the change from captivation – which to me means any game that puts the player in a state of excitement and exposure to game mechanics that lets him forget the surrounding world and everyday business – to the word “engage” – which means to actuate the warp drives and accelerate past the speed of light. Or in non-Star Trek terms: to give the player something meaningful to do, something to play with, something to go on. It doesn’t need to excite, it doesn’t need to shut off reality, it certainly doesn’t have to be so immersive that mobile players walk blindly on the street right in front of a truck. But it should give the player an experience that’s new to him, that’ll spur his interest, a small “A-ha!” moment, the “oh that’s nice” thought, or just a smile on his face.

The new rule doesn’t mean that you should aim lower than before. In fact it could well work together with the old rule. It’s more a change in priorities, down to the point where we have to question a lot of traditions and standard ways of doing things, like the ubiquitous main menu being the game’s first interactive experience for the player. The new rule does tell you that it has become and will continue to become ever more important to engage players first and very, very quickly before you even have a chance at proving to captivate the player. Because most games these days will be dismissed by most people – and most certainly this includes game reviewers – within a very, very short period of time.

To engage, you need to get to business ASAP

That it the essential message of the “engage player within 15 seconds” rule. Your first priority – and this is even more important the lesser known you, your company and your game’s brand are – is to not bother the player telling him about who you, your company and your game’s brand are. At least not as the first thing the player experiences, and especially not if this costs valuable seconds of the player’s time. Put your logos elsewhere. Postpone the gist of your wonderful story until the player innocently stumbles over the story root himself.

To make it even possible to engage the player within 15 seconds, you need to get rid of old conceptions that used to define how a game is started the first time. Most games today follow the traditional sequence that often includes a series of company logos, an intro video, a main menu with too many options, multiple selections to make before the game is actually loaded. Keep in mind that most pre-game selections like difficulty have consequences that only become clear while playing the actual game, when it may already be too late to change the difficulty. Another intro video or animation sequence or ingame cutscene can be deferred until after the basic gameplay has been experienced. And certainly don’t do a text-message based tutorial alienating both experienced gamers and newcomers alike when better options like context-sensitive visual hints are the less intrusive alternative.

I dare you …

… to re-imagine the game you’re currently working on and figure out a way to put the player in control of the actual game as soon as it has launched. No logos, no main menu, no difficulty selection, no intro video, no cutscene. Just put him right into the game (*), and allow him to figure out the game all by himself.

Use text, icons or other visual or audio indicators to guide the player and have him find out how the game is played organically. If he wants to start killing things right away, let him try it. If he fails you might want to tell him why he failed – many reasons are pretty easy to discover programmatically: he didn’t side-step, he didn’t jump, he shot the wrong weapon, he focused on suboptimal targets, and so on. In essence, allow the player to be in the game right away and learn it like a baby does: by experimenting, by failing often, by having an advisor point him in the right direction, pointing out flaws in his approach and giving suggestions for improving his skills and tactics the next time.

(*) = Minus the necessary and accepted selections of course, for example on consoles you usually have to have the “Press Start to Play” screen followed by the selection of the storage device. But other than that, the player should be in the game right away.

Oh, and …

… don’t piss off the player!

Things that piss off players, and little kids for that matter, include anything that is forced upon the player and goes against the nature of being in control or how a game is normally played. Actually, if this happens among human players it’s usually cheating and frowned upon.

Forcing the player to flee, to die, to not do anything goes completely against the idea that the player should be in control. In the games I worked on, we had a number of such scenarios that required you to do the unusual. For us it was innovative, and some players really, really enjoyed those scenarios because we managed to make them fun and entertaining and fit the flow of the game nonetheless. But the times it was forced onto the player, for example by sending ever stronger waves of enemies at the player, the players started to get frustrated. They did not want to flee, so they failed over and over again. Some even found exploits that made it possible to survive but with the scenario being designed that it has to be completed by fleeing instead of fighting, the result was a feeling of emptiness. The player achieved the impossible but he wasn’t rewarded for it, the game did nothing to acknowledge his achievement.

But there are more subtle ways to force something onto the player. The aforementioned sequence of company logos that you can’t skip. An intro video or cutscene that can’t be skipped or fast-forwarded. Having to complete seemingly unrelated or mundane quests or chores (*). Buttons that are too small to tap correctly 100% of the time. Button sequences and combos that require perfect timing or the reaction time of a 12-year-old on steroids.

(*) = It works for World of Warcraft and most other MMOs. But keep in mind that these games are about social interaction, and the gameplay is designed to keep the players in the game as long as possible. In other words: MMOs are designed to be time-sinks for players because without many players staying online an MMO is pretty much worthless. In that sense MMO design is completely different from regular game design, which IMHO also explains why so many new MMO game developers fail. They want to make their MMO more “fun” but that’s not what an MMO does. MMOs challenge the player’s resilience to perform (mostly) mind-numbing tasks in order to gain a relatively miniscule reward or achievement. Over time, accumulation of these micro-achievements give you a sense of greater achievement and bragging rights, especially in the social context that MMOs have. Or, as I like to put it: MMOs are modern religions, the players are minions united under a common belief (aka reward) system, the guild leaders are clergymen and the successful game developers become gods while the beta-testers of soon-to-be-released MMOs have to have a lot of faith.

Inconsequently implemented design features are also great offenders, for example mouse-over-highlighting only some of the game’s items but not all of them. Making deadly bombs suspiciously similar-looking to health packs so that you’re usually close enough not to be caught in the detonation is only fun for the sadistic developers. Making the game adapt the difficulty as soon as one player is leading, for example a sports game that gives the opposing player or CPU team a noticable boost when they’re behind. Especially in sports you would rather frequently see the other team taking a hit on morale when they’re behind, so this design clearly goes against our real world experiences (Hello, Fifa 10!).

I could go on … I’m sure you’ll have your own list of grievances. Feel free to share them with me in the comments!

Tagged with:  

I think this topic is of general interest, so i’m reposting it for those who only read the GamingHorror blog.

Please visit www.learn-cocos2d.com to learn why you should ignore everything you’ve read about App Store Piracy!

Tagged with:  

Update: apparently this has also been discussed in the Unity forum and they reached about the same conclusion. It also shows more evidence that Unity Apps are hit pretty severely by the loss of compression due to the encryption process, 4-5 MB was what most users reported with some even much more than that.


I’m working on a calculation to at least determine the upper size of an App after Apple has had a go at it after a successful approval.

First of all we need to understand what Apple adds to the .app bundle after approval. I found a post that sums up the files that are added by Apple:

“additions are the iTunesArtwork file (70k), iTunesMetadata.plist (2k), files in the new SC_Info folder (12k) and the updated CodeResources file (9k)”

All in all about 100 KB in additional files. So where’s the rest of the bloat coming from? After all, some people even report an increase in size after approval of several Megabytes!

The answer is surprisingly simple: Apple is encrypting the executable file. By doing so its size doesn’t change much but its contents do which usually can no longer be compressed as much as before. By putting all this together i came up with a way to calculate the maximum size of your App in the App Store (it will most likely be less than this):

  1. open the .app bundle via right-click -> Show Package Contents (on Mac)
  2. locate the executable file and remember its (uncompressed) size (Size “A”)
  3. delete the executable from the bundle
  4. zip the bundle and remember the bundle’s compressed size (Size “B”)

Size “C” are the 100 KB from the additional files added to the bundle by Apple. The final calculation for the maximum size of your App is as follows:

A + B + C = maximum size of your App after approval

The calculation put in words:

(uncompressed executable size) + (app bundle compressed but without executable) + 0,1 MB = maximum size of your App after approval

I only have one App (51 Japanese Characters) in the App Store right now, so i can only test it with this App. The submitted App is 3,9 MB zipped and 4,3 MB on the App Store. The executable file is 1,0 MB and the App compressed without the executable is 3,6 MB. By my calculation i get:

1,0 MB + 3,6 MB + 0,1 MB = 4,7 MB

That is more than the 4,3 MB the App’s actual size on the App Store but remember: we calculated the maximum size the App might have. Depending on your code and more likely the engine you use (i use cocos2d exclusively till now) the amount of compression lost by Apple’s encryption varies greatly. Especially if assets (images, sound, music) are embedded in the executable (so don’t do that!). I hear that Unity iPhone applications can suffer a great deal more, however i don’t know if there was anything particular about the App nor which version of Unity iPhone was used, so take it with a grain of salt.

Now, how can we get closer to reality with this calculation? By introducing a good (upper) value for how much the executable file can still be compressed after encryption. In the case of 51 Japanese Characters it amounts to about 60%. So if we modify the calculation with a compression factor “F” we get:

(A * F) + B + C = maximum size of your App after approval

In the case of 51 Japanese Characters F would be 0,6.

I would very much appreciate it if you could do the calculation with your app(s) and post your results here. I’m most interested in your value for F, the more reports we can get the closer to the (mean average) compression factor for the encrypted executable. At this point i can only say it’s 0,6 in this particular case but it might as well be 1,0 for other Apps. Please post your results here!

Tagged with:  
Page 1 of 212