Author: by David McQueen

When The Games Kitchen began Wireless Pets, WAP (Wireless Access Protocol) was as much in its infancy as the company and the publisher was.

Let me give you some background. The first WAP enabled mobile phones had just reached the market, and network operators were pushing them to customers as 'the Internet on your phone', which it isn't, or at least not in any useful sense. It would be much more accurate to say that it was AN Internet on your phone, as only websites in WML (Wireless Mark-up Language; a variant of HTML based on XML) could be viewed. There were virtually no websites and no applications, games or otherwise. However, WAP was not yet seen as the donkey it is now commonly viewed to be, and everyone was jolly excited.

The Games Kitchen had been going for almost a year before we started the contract for Wireless Pets; however, we were only two people (business partner David Thomson and myself). Digital Bridges (DB) had been started just up the road from us (we are both based in Scotland), and we had worked together on a few simple projects, such as Roulette and Fruit Machine, back when DB were also only two people.

Wireless Pets was an ambitious title. We'd never done anything that big or complex, we had to expand the company for this title, and DB had to expand their platform to handle it. Heck, we weren't even sure if WAP (or, more accurately, the usually poor implementation of WAP found on the new devices) could handle it. But we did it anyway, and it became the biggest WAP game in Europe, with over 15 million minutes of airtime on 18 operators. The SMS version looks set to repeat that success. This is the story of both WAP and SMS versions.

What Went Right

1. Simple Interface. WAP is an browser based online only environment; nothing resides or runs on the device. Playing a WAP game means selecting choices by selecting a link, which communicates back to the server, and the server generates a new page for you to view based on what you've just done, and updates your game state. Everything runs on the server, and thousands of people from multiple countries can be accessing at once. In this respect, it is a lot like massively multiplayer games, except that there's no client application other than the browser.

The medium really forces the design to be menu-driven; indeed, there is virtually no other way for the user to have any meaningful choice. The issues with this are:

So what most users will be faced with are lists of text links, and indeed only a very small window onto the list (four options visible at a time at most). There's not even anything like drop-down menus which are typical in the Windows interface. Therefore, a significant issue is designing a simple user interface in which the user won't get lost, but which still offers a good number of choices to the user.

Wireless Pets achieved this fairly successfully; the reason we know this is that not one of the over 350,000 players has complained about the interface. If it doesn’t get in the way, it must be OK. Also, there are over 60 ways to interact with the pet, giving the user plenty of flexibility.

The simple interface hides a relatively deep game. Like games such as Creatures, Wireless Pets is surprisingly complex, although most of this complexity is hidden and the game seems simple to the user. The pets have many hidden statistics and variables, as do the food, drink and play objects, and each object has a different effect on each of the 6 pets. Having this end of the game running on the server meant that it could be as complex as we wanted it to be without worrying about device limitations, so the choices the user makes can have interesting and complex effects. For example, pets may get any one of a number of illnesses if their health variable gets low; and incidentally, there's no way for the user to directly affect the heath variable.

SMS is an even more limited technology. Text messages are sent to and from the user and server; just ASCII text, nothing else, and with a limit of 160 characters. Try designing a game for that! Thankfully, we weren't trying to replicate the WAP gaming experience for SMS - the WAP version has more than 60 different ways to interact with the pet, and it is impossible to let the user know what 60 options they have in only 160 characters of instructions.

Therefore, the interface for SMS game is very limited, as it has to be It is much more like the Tamagotchi games than the WAP version is, having only 3 real options (feed, play and clean). Again, though, this did not mean that the pets were as simple as that, although they were less complex than those found in the WAP version.

2. Personality. It may seem odd to talk about personality in media which can have 70x40 black and white graphics (WAP) or 160 characters of ASCII text (SMS), but this is what we recognised we had to do. The user must feel some sort of emotional attachment to the pet, otherwise it's entirely meaningless.

Before we did any game art, all of the characters were designed on paper then as full colour vector graphics. This was extremely useful for marketing support materials. All of the pets were designed so that they would reduce down well to 40 pixels in height.

Since the game graphics are so small, we knew we had to do more to convey personality, and we did this by having the pet write a diary each night. It's worth pointing out at this point that the game is 'always on'; the user links up (WAP) or sends a message (SMS) to interact, but if they don't see their pet for a few days it will get hungry, bored and very lonely. At midnight on the server, the game does a daily update, which includes changing some of the pet's variables and also writing a new, three sentence diary. The sentences are selected from a database based on the pet's variables and the priority of individual pets (for example, the dog is more worried about the amount of exercise it's getting than the ghost is). Diary entries are not as simple as 'I feel hungry'; they convey personality. Sample diary entries for feeling hungry are:

What Went Wrong

1. Text. The amount of text I had to write for this game almost killed me. There are 500 unique diary entries for each of the 6 pets in the WAP version, and 350 unique diary entries for all six pets (featuring four new pets) in the SMS game. It was insane; 50 different ways of saying "I'm hungry" for ten different animals, each in a way that conveys a bit of personality.

One solution to this would be dynamic text generation. However, when the game is translated into many languages, this is very problematic. English is fine, but other languages have new and unusual forms of sentence construction to torment you with, not to mention gender specific nouns, verbs and adjectives (not necessarily the same gender in every language). The programmers had lots to do; as well as producing the game, I was doing the art and text, and there's virtually no art. To get it out the door ASAP, I took it upon myself to complete what I did not realise would be such a monumental task.

There are over 40,000 words of text between the text games. I wrote my first novel without realising it. I'm never doing that again. Localization cost a fortune too; thankfully the publisher shouldered that burden.

2. Testing. Testing was something that really should have gone better. At the time, we had no way to load test the WAP version of the game. So, when the game was launched on the first operator, they load tested the game on Friday, simulating 10,000 users accessing it at once. It fell over, and what's more, the game was due to launch on Monday. Monday couldn't be pushed back as the operator had already done loads of marketing to users. Let me tell you, that was one busy weekend, but we got it done.

Even the tiniest flaw adds up to big problems when there are so many users accessing the game. Now, DB have load testing tools and also better guidelines on garbage collection and preventing memory leaks. In fact, these were ready for the SMS release of the game, and we had no problems with the launch of that.

3. Limited Scope. One of my personal disappointments about the project is the lack of any real multi-player mode. Since everyone is playing on the same server (or more accurately, three servers), the system is set up nicely for some sort of user-user interaction. However, we had a limited timescale and budget, and we were pushing the platform as it was, so we shelved the concepts we had.

The only part of the game that is in any way multi-player is the pet shows. They are very simple though; users choose to enter their pet in the shows, and at midnight on Sunday all the entered pets are compared using a weighted total of all their stats. The winner, and those within a certain number of points of the winner, get extra in-game money as prizes. Although it is multi-player, it doesn't feature any user-user interaction.

It's a shame really as, since the devices have to be connected to a network in order to play the game, it seems obvious to use this (perhaps the only) advantage the device has over other gaming devices to create a better user experience. Time and budget won out, but on the plus side, keeping the scope limited did mean that we delivered on time.

4. Publisher friction. Now for everyone's favourite bit of the postmortems; the bitchy developer's revenge. Actually, I'm sorry to disappoint those of you looking for a slagging match, but DB is not at all bad to work with, it's just that some conflicts of interest arose. The issues have now been resolved, we work with DB regularly, and we have a constructive and friendly working relationship.

One feature of the contract is that The Games Kitchen would retain the Wireless Pets IP. To begin with, DB used the characters, logos and other materials on a number of occasions without our permission or approval. This was the cause of constant consternation, and some heated emails were exchanged. Now DB has an approval loop system in place and know where they stand when using external IP. Our disagreement with DB at the time meant that they had their system in place before they worked with IP belonging to companies who go around packing fully loaded lawyers and who aren't afraid to use them.

Another issue that arose requires a little more explanation of WAP, so bear with me. When WAP was released, many operators were unprepared for it and had not implemented any sort of billing system. Since implementing such a system would mean that they'd only have to pay out to content suppliers, they were in no rush to do it. DB were understandably keen to get into as many operators as possible, and so gave many of them the game for free on the understanding that they would pay when their billing system was implemented. Of course, this made implementing the billing system even less attractive for operators, and we missed out on quite a few months of royalties because of this.

We felt that DB should have stood firmer, though we do understand their point of view, and certainly it achieved their aim of being on many operators. We are happy to report that all operators (or at least all those Wireless Pets is on) now have their WAP billing mechanism sorted, so this problem has gone away, and in the long term DBs tactic has achieved the same end result. Although we were unhappy at the time, we look back without any anger. This has never been an issue for SMS; since text messaging has been popular for some time, billing has been in place for quite a while.

All of the friction arose as both The Games Kitchen and DB were young companies at the time. They did not yet have their systems in place for working with IP, and we wanted the royalties too quickly. Both companies are better for the experience and a lot wiser on developer-publisher relations, a fact evidenced by our good relationship today.

5. Ongoing support requirements. One of the features of operators implementing their billing systems was that we sometimes needed to change the code so that it would register billing points and so on. As new devices came out, the code would sometimes need changed. Annoyingly, future releases of UNITY were not always backwardly compatible, so on occasion we needed to change the code as the platform changed. The data was also designed to be flexible, so we could add new pets and objects in over time, which we did, including a promotional pet for the Big Brother game show.

All of this meant that the support required was greater than we had originally anticipated, and sometimes ate into other projects that we had running for DB. Generally, DB was quite accepting of the need to compromise on support and new development, though there was some understandable friction from time to time. Knowing what we know now, we should have allocated more time for support of Wireless Pets to prevent any future project slippage.

Conclusion

Wireless Pets was a landmark title for us. It was The Games Kitchen's first major project, and it was an incredible success, immediately making a name for us in this emerging market. For DB, it proved their business model worked and that there is a market for mobile games.

Wireless Pets is good software delivered on time, and that has certainly given us the confidence to tackle bigger projects. This is essential for us as a company; mobile devices are getting more and more powerful and complex, and better and better technologies are emerging. We learnt a lot which has stood us in good stead in our future projects.