BRITISH COMPUTER SOCIETY

Kingston & Croydon Branch

Notes of the BCS Branch Meeting held at 7.30pm on Tuesday 14th November 2006 at BT Delta Point in Croydon, Surrey

Immo Huneke, Branch Secretary

1 Developing Mobile Games – the challenges Andrey Collison, Denkzone

1.1 Introduction

Denkone is a very small company developing games for mobile phones. It has a number of different distribution partners.

The portfolio includes Ozumi (a PacMan emulation), Santa Panic (a variant on a platform game involving shunting parcels around a sorting office), SuDoKu, Band Quest (a graphical adventure) and Mountain Bike Rampage.

Denkzone was originally formed to provide IT consulting services, mainly to banks. Despite its success in that area, the company turned to developing games software a few years ago, because the company’s members saw a chance to work in the field of computer graphics, the subject that they had originally studied at university.

1.2 The Mobile Games Market

Huge market potential: 970M mobile phone devices sold in 2006 (estimated) compared to around 40M games consoles. Most of them are capable of running modest games. Early home computers such as the ZX Spectrum (1982) are comparable in terms of memory available and screen resolution, yet gave rise to a lively games industry. Some of the early games are very creative and playable even by today’s standards. Small companies have a chance here: the first Java-enabled phones can only load small applications (up to 64KB), which can be produced on a low budget. They could not compete with Electronic Arts and the like, who are highly specialised to develop games for consoles and have comparatively enormous marketing budgets. Lastly, developing games can be fun!

British Computer Society 14th November 2006

0BDeveloping Mobile Games – the challenges

Page 1

Kingston & Croydon Branch 14th November 2006

Developing Mobile Games – the challenges

Page 2

As of March 2006, about one-quarter to one-third of mobile subscribers (depending on country) had played at least one game on a mobile phone (Britain leads the world with 31.8%). But only 2.5% to 4.2% had downloaded a game in the last month (source: M:Metrics). There must be a barrier to downloading. Seamus McAteer (senior analyst of M:Metrics) puts this down to the mobile operators: “This data shows that operators must do a better job at converting those that played a mobile game into a player of downloaded games”.

The time to download is short – a minute or two – but the process of download purchasing is quite tedious and error-prone. And the cost to buy the game is probably another inhibitor.

The market is still growing, but only slowly. In the survey, only 20% to 30% of downloaders were repeat purchasers. In other words, the users didn’t find the experience compelling and they didn’t want to repeat it.

In terms of the value chain, the developers are a long way from the consumer – there are aggregators, mobile operators and other distributors in the way. Every step of the way needs to increase value. As a developer, you have very little control of how your product will be promoted. The game concept has to make it compelling to both distributors and aggregators to promote the game, and to consumers to download and buy it (and word-of-mouth promotion from consumer to consumer works best).

1.3 Game Concept

The goal is to think of a game concept that chimes with all parts of the value chain. For example, interactive multi-player games are appealing to consumers as well as to operators (because they generate network traffic).

So the biggest challenge is to develop the right game – how many failures can your company withstand?

1.3.1 Key decisions

What kind of game?

• Copy of an existing game (e.g. PacMan, Tetris) – customer recognition and well-defined requirements

• Copy an existing game concept but adapt and improve it

• Develop a new and original game concept – challenging and fun, but it can be a very long-winded process (double the amount of time to establish how it should behave, no familiarity on the part of customers)

It is much the same in the movie industry!

Kingston & Croydon Branch 14th November 2006

Developing Mobile Games – the challenges

Page 3

The Santa Panic game was originally designed for Swiss Railways as a promotional effort, but the project got cancelled, so Denkzone adapted it with different graphics to become a parcel-sorting game with a Christmas theme. Although the game is addictive to play it wasn’t very successful – probably because it didn’t have a clearly defined audience.

1.3.2 Game Concept development

• Brainstorm with your team for a few hours to generate ideas

• Beer and a change of location helps to loosen up the imagination

• Consolidate the collected ideas into one or more concepts

• Reduce the game concept to key ideas and make them as simple and concrete as possible

• Evaluate and compare the concepts

There is a checklist that Denkzone uses to help evaluate concepts.

1.3.3 Lessons learned

Time spent on developing the game concept carefully is time well spent.

• Create more than one game concept to choose from

• Give the artists a key role early on

• Let the artist do an early draft of the look and feel of the game and its characters – it often sparks a completely new departure in thinking

• Tune the gameplay to provide the right look and feel

1.4 Implementation and Testing

1.4.1 Requirements

Functional requirements are documented as user stories (e.g. when the player passes the finish line, the game displays the total time of the run in the top right corner of the screen).

Stories are used as the unit of estimation and prioritisation (e.g. into essential, optional and follow-up game).

The Pacman-style game was done in three months by one person – there was not even a creative artist involved. On the other hand, Santa Panic took over a year (with gaps). Band Quest was developed in just two months, but it is really just a demonstration version at present. It should be finished by around February 2007 (total time worked on it about 9 months).

The mountain biking game has taken over a year already and still isn’t finished. This is because it has a specialised “real physics” engine inside, which has posed some unique implementation and playability challenges. The time needed to tune the engine and add rider behaviour

Kingston & Croydon Branch 14th November 2006

Developing Mobile Games – the challenges

Page 4

on top of the physics was originally underestimated. However, with the experience gathered, Denkzone will be able to produce future games based on the physics engine a lot faster and have a competitive advantage, as most other development companies are not offering physics-based motion in their mobile games.

1.4.2 JVP Requirements

JVP = Java Verified Program.

The Unified Testing Initiative was launched by a consortium of mobile operators and vendors. It lays down important test criteria that every mobile application must meet – including GUI standards, internationalisation / localisation, personal information security and so on.

On top of this, Denkzone has its own quality criteria such as the maximum number of keystrokes needed to invoke any particular function.

1.4.3 Development Practices

Executables are rebuilt hourly. Getting frequent feedback on the look and feel of the game is very important. Requirements are changed often to improve the game. Feedback from external players is considered more important than automated rigorous testing – outsiders spot a lot more UI and playability flaws than test engineers!

Denkzone generally creates special tools (generators or editors) to make the design of game levels easier.

1.4.4 Market Fragmentation

There are so many different phone models out there, with vast differences in terms of

• Screen resolution

• API support (availability, conformance, version – e.g. Bluetooth)

• Performance

• Available memory

• Sound support

that it’s necessary to develop between 3 and 10 different versions of the executable and test it across a large number of phone models.

On top of this, operator-specific requirements (e.g. network firewalls and proxy servers) and different languages (e.g. ten countries times three different operators) mean that you could have up to 300 versions of the executable.

Kingston & Croydon Branch 14th November 2006

Developing Mobile Games – the challenges

Page 5

1.4.5 Realistic Gameplay

To get the biker game to act realistically, Andrey built a physics engine that simulates rigid body dynamics in 2D – forces and torques act on objects and the objects’ positions and angles are determined through integration. The rider is modelled as bike frame, wheels and limbs of the rider each with their own mass. Where objects hit the ground contour, spring forces are inserted to prevent the objects falling through the ground, and friction forces are used to accelerate or brake the bike.

Early versions of the game failed because the keyboard controls are too crude (full power or none) to control physical parameters such as the acceleration of the bike, resulting in the rider falling on his back while accelerating or riding uphill. So artificial intelligence has to be applied to reduce the force (torque) on the back wheel as soon as the front wheel lifts off the ground. This simulates the reflex action of a real rider. The player controls the character’s intentions more than directly controlling his actions.

Also the rider’s power to climb hills had to be exaggerated to make it look exciting and enable spectacular stunts to be performed.

You learn a lot from the experience of developing such a game. For example, Andrey had a lot of trouble trying to discover realistic values for the amount of friction between rubber and the ground.

1.4.6 Environment

Program development is done in Eclipse. A packager is used to create the executable, which is distributed as a jar file. Initial testing is done in a phone emulator.

Real-time interruptions might be expected to cause problems, but in fact Andrey hasn’t found that there were many issues. But there have been occasions when the physics engine produced anomalous results and this was difficult to reproduce in the lab. In the end, what helped was to visualise all the forces acting in a particular situation and analyse a videotape of the game in play on a real phone, frame by frame, to see whether the model responded correctly to those forces.

1.5 Contacts

• www.denkzone.com

• www.thebandquest.com

• Denkzone GmbH, Spitalgasse 4, 3011 Bern, Switzerland