|
|
 |
 |  | | | | |  | |||
 | ||||||
          |  |  | ||||
|
Postmortem: The Games Kitchen's Wireless PetsWhat Went Wrong1. 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. ConclusionWireless 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.
________________________________________________________
|
||||||||||||||||||
|
|
Resource
Guide 
