mobile tamagotchi game - university of leeds · mobile tamagotchi game anna ivanova msc in...

Mobile Tamagotchi Game

Anna Ivanova

MSc in Information Systems 2002/03

The candidate confirms that the work submitted is his own and the appropriate credit has been given where reference has been made to the work of others.

I understand that failure to attribute material which is obtained from another source may be considered as plagiarism.

(Signature of student) ________________________


Anna Ivanova MSc in Information Systems i

Summary The ‘Mobile Tamagotchi Game’ is much deeper than just a game that people want to play. It is an attempt to learn new software for a new developing market of communication devices, it is a research of the Artificial Intelligence and Artificial Life that stimulate evolution and learning and, finally, it is a challenge of how to bring these two parts together to fit in the limited memory of the mobile phone. Therefore, the current project investigates into the Java 2 Micro Edition software platform that can create applications on the mobile devices, concentrates on the implementation of the ‘Tamagotchi’ or a virtual pet and researches into AI algorithms. This prepared the scope for the further adjustments in the behavioural model and enhanced functionality of the virtual pet, thus setting the stage for future research and development in this area.


Anna Ivanova MSc in Information Systems ii

Acknowledgements I would like to thank my supervisor Dr Andy Bulpitt for all the support and encouragement throughout the project. He was always there for me to provide all the help required and guide in the right direction towards a good result. He always made me feel that the limit of a human’s abilities is the ‘sky’, and there is always something ahead of us that can be learned. A beautiful thing about it though was that we actually can. Special thanks to my assessor Dr. Julika Matravers for all the understanding during the demonstration about all the nervousness and worries that always accompany human nature. She was very helpful in identifying some problems in the game, and her suggestions were very useful later in the writing of the project. My best regards to all my friends who stayed with me all this time listening, understanding and encouraging. Thank you to Dima for the constant reminder of how hard a human can work and how supportive he can be to the others. Thank you to Udoyon for being there when needed. Thank you to Tejan, Rahul, Indi, Diana, Amrita, Halima and many others for the opportunity to get to know them and be their friends.


Anna Ivanova MSc in Information Systems iii

Table of Contents

SUMMARY ................................................................................................................... I

ACKNOWLEDGEMENTS ..........................................................................................II

TABLE OF CONTENTS............................................................................................ III

1. INTRODUCTION..................................................................................................... 1

1.1 STRUCTURE OF THE PROJECT ...................................................................................................1

2 RESEARCH ............................................................................................................... 2

2.1 ALTERNATIVE TO J2ME............................................................................................................2 2.1.1 BREWTM...............................................................................................................................2 2.1.2 Microsoft.Net Mobile Development Environment...............................................................3 2.1.3 Java 2 Micro Edition...........................................................................................................5

2.2 MOBILE PHONES THAT SUPPORT JAVATM................................................................................6 2.3 HISTORY AND FUNCTIONALITY OF ‘TAMAGOTCHI’ .................................................................6

2.3.1 History of a Virtual pet........................................................................................................6 2.3.2 Functionality of a Virtual Pet..............................................................................................7

2.4 THE LOOK OF THE VIRTUAL PET ..............................................................................................8 2.5 VIRTUAL PET AI ........................................................................................................................8

2.5.1 Turing Machine ...................................................................................................................9 2.5.2 Markov Model ...................................................................................................................10 2.5.3. Neural Networks...............................................................................................................11 2.5.4 Genetic Algorithms............................................................................................................13

3. ANALYSIS AND DESIGN.................................................................................... 13

3.1 DESIGN DECISIONS...................................................................................................................13 3.1.1 Applications Development Environment ...........................................................................13 3.1.2 MID Profile considerations...............................................................................................14 3.1.3 Choice of a pet...................................................................................................................14

3.2 METHODOLOGIES USED IN THE DEVELOPMENT OF THE PROJECT .........................................14 3.2.1 Incremental Model ............................................................................................................14 3.2.2 Diagrams...........................................................................................................................15

4. IMPLEMENTATION ............................................................................................. 18

4.1 J2ME FOR VIRTUAL PET ........................................................................................................18 4.1.1 Wireless Toolkit.................................................................................................................18 4.1.2 API.....................................................................................................................................19 4.1.3 Classes and Functionality of the Virtual Pet.....................................................................23

4.2 SAMPLE SCREENSHOTS............................................................................................................26 4.3 DOWNLOADING MIDLETS ON THE MOBILE PHONE ................................................................27

4.3.1 WAP...................................................................................................................................27 4.3.2 Bluetooth ...........................................................................................................................27

5. TESTING AND EVALUATION ........................................................................... 28

5.1 TESTING ...................................................................................................................................28 5.1.1 Testing the functionality ....................................................................................................28 5.1.2 Testing on the Mobile Phone.............................................................................................28

5.2 EVALUATION ............................................................................................................................29 5.2.1 NeoPets..............................................................................................................................29


Anna Ivanova MSc in Information Systems iv

5.2.2 Questionnaire ....................................................................................................................32

6. PROJECT MANAGEMENT .................................................................................. 34

6.1 INITIAL SCHEDULE ..................................................................................................................34 6.2 ACTUAL SCHEDULE .................................................................................................................34

7. CONCLUSION AND FUTURE WORK ............................................................... 37

7.1 CONCLUSION ............................................................................................................................37 7.2 FUTURE WORK ........................................................................................................................37

7.2.1 Future functionality and graphics.....................................................................................37 7.2.2 MIDlet improvements ........................................................................................................38 7.2.3 Probability class adjustments............................................................................................38 7.2.4 Future of Neural Networks................................................................................................38

BIBLIOGRAPHY ....................................................................................................... 39

APPENDIX A: PERSONAL REFLECTION............................................................. 41

APPENDIX B: PROJECT OBJECTIVES AND DELIVERABLES FORM............. 42

APPENDIX C: MARKING SCHEME AND INTERIM REPORT COMMENTS ... 43

APPENDIX D: DIAGRAMS...................................................................................... 45

APPENDIX E: DRAWING OF CATS....................................................................... 48

APPENDIX F: A SAMPLE QUESTIONNAIRE....................................................... 51


Anna Ivanova MSc in Information Systems 1

1. Introduction The Artificial simulation of a real life has always been a fascination of humanity. Viruses and robots are parts of the artificial experiments that simulate an artificial mind. Less complicated algorithms though are used in the computer games for children. The idea of ‘Tamagotchi’ presented by Bansai company in the beginning of 1997 has moved the science from the theory and researches known only to the specific circle of friends to the practice applications known by the whole world in the form of a game [1]. Games have always been the main means of entertainment for their ability to challenge and test human abilities. They have taken a special part in the hearts of the millions and developed and improved with the change in the technological world. Games went through a series of evolutionary steps, initially starting as active games on the air and later being transformed to the home computers and later on the mobile devices. The huge industry developed in order to supply the customer with a large variety of games, from action and adventure games to logic and strategy. The ‘tamagotchi’ game or a virtual pet that lived in a key-chain device has created a whole new wave in the industry. This children’s game was targeted at developing a need within a child to take care of a small creature and try to pay it the attention it deserves. This virtual pet was a living creature [1] that had to be fed, looked after, played with and taken care of. It was a digital representation of the home pet and had attracted many children for its unique characteristics and ability to evolve. Nowadays, it is very hard to find an original tamagotchi pet. The original fascination has decreased and the graphics are considered to be of poor quality. The most recent toy of a similar kind is NeoPets, which was developed based on the NeoPets website [2]. The next step for this game is to travel from the PCs to the mobile devices that are gaining higher popularity due to their small size and sophisticated functionality. Therefore, this project is concerned with the development of the software that can be used on the mobile phones to simulate a virtual pet. 1.1 Structure of the Project The initial objectives proposed in this project were to learn how to use Java 2 Micro Edition (J2ME) for implementing mobile applications, a background research into basic Artificial Intelligence technologies, implementing a basic functionality of a virtual pet on the mobile phone, enhancing a virtual pet’s functionality and improving the behavioural model of a pet. The last two proposals were not part of the minimum requirements and reflect the adjustments that can be made for this project once the primary objectives were met. The methodology being followed in this project is an incremental model that uses increments of the linear ‘Waterfall’ model to get relevant feedback from the customer and adjust the next increment based on the new requirements. The structure of the project reflects the stages of the model and starts with the background research, followed by analysis and design, implementation of the game, and finally testing and evaluation. Areas for future work have also been discussed. The background research starts by investigating the current platforms available for the creation of a game on the mobile device. Some alternatives are suggested and the final choice is explained. Later,



it investigates the history and functionality of virtual pets since the beginning of 1997 when the game was first introduced. Then, it continues by describing the mobile phones and their specifications. Finally, the Artificial Intelligence algorithms and their connections to Artificial Life are explained. The design chapter makes some choices regarding the software specifications and the reasons for these choices are explained. The methodology used in the development of this project and a set of diagrams showing the original design are also discussed. The difference between the initial and actual implementation is explained as well. The implementation part of the project describes the toolkit that is used for this project and mentions API documentation and classes used in the actual code. Later, the classes and their functions implemented for the ‘Tamagotchi’ game are mentioned, followed by their screenshots. The chapter finishes by talking about packaging and how the mobile application can be downloaded on the phone. The testing and evaluation chapter attempts to identify the set of test cases and then evaluates the project based on the questionnaire and by comparing a similar commercially available game with this one. Conclusion and future works conclude the project and describe the future adjustments possible for this game both in terms of functionality as well as artificial intelligence algorithms. 2 Research 2.1 Alternative to J2ME There are different software packages available on the market today that allow users to create mobile applications. Some of them were created using C/C++, some use Java and some use C#. However, the newer versions of the software packages tend to combine different programming languages thus giving a freedom to develop mobile applications in the way a customer wants. The main software packages that are available on the market are BREWTM, Microsoft.Net Mobile and Java 2 Micro Edition. 2.1.1 BREWTM BREWTM or Binary Runtime Environment for WirelessTM, developed by QUALCOMM, is a software solution for ‘wireless application development, device configuration, application distribution, billing and payment’ [3]. The interesting feature of this software package is that, apart from the usual SDK (Software Development Kit) and the BREW client software, it includes a distributed system application that helps developers to coordinate the billing and payment process as shown in Figure 2.1.1.



Figure 2.1.1: The BREW Solution

Source: http://www.qualcomm.com/brew/about/aboutbrew.html

BREW was initially written in C/C++, however it does support programming in Java, XML, Flash and other programming languages. It supports a Java Virtual Machine and microbrowsers for mobile applications. The BREW solution is similar to Java 2 Micro Edition (J2ME) software application and is its competitor. However, in reality the difference is that BREW is a complete deployment solution that supports JavaTM and provides a business model for distributing the developed applications, whereas J2ME does not [4]. 2.1.2 Microsoft.Net Mobile Development Environment Another competing software platform is the Microsoft.Net Mobile Development environment [5]. Unlike the BREWTM platform, .Net supports C# and Visual Basic.Net languages that are used in Visual Studio. In order to create a good mobile environment, Microsoft has come up with three Mobile.Net technologies as shown in Figure 2.1.2. The first two strategies are called .Net Compact Network (.NETcf) and Smart Device Extensions (SDE). The SDE is an add-on to the Visual Studio.NET in order to support C# and Visual.Basic.Net languages, together with the object library. The idea of using these technologies is that the applications produced on the computer can be easily transformed to mobile devices using the same language and tools. However, in order to run the applications on the mobile devices a .NETcf runtime code is required to be installed, which is approximately 2.1MB at the moment. Another technology that is used in Mobile.Net is the Microsoft Mobile Internet Toolkit or MMIT [6]. ‘MMIT is an extension to ASP.NET (Active Server Pages), which, through Microsoft’s IIS server software, allows web applications to be accessed by just about any internet-enabled mobile device’ [7]. It is free to download from Microsoft.Net.



Figure 2.1.2: Mobile.Net Technologies

Source: http://www.devbuzz.com/content/zinc_dotnet_going_mobile_pg1.asp

Programmers planning to use this software need to have knowledge of Visual Studio, a background of managing IIS servers and C# (similar to Java). The idea of this software is that it runs from the IIS web server and users are only required to have access to the Internet in order to use this software as shown on the Figure 2.1.3. Figure 2.1.3: Connecting to MMIS

Source: http://www.devbuzz.com/content/zinc_dotnet_going_mobile_pg1.asp

This way of managing users connected to the network has some advantages. These include identification of the mobile device and all its main features automatically, together with the connection speed. This toolkit takes care of the correct rendering of an application for the markup language (HTML, WML or cHTML) as well. Another advantage of this particular toolkit is that Microsoft has already tested it on more than 150 PDA’s, cell phones and other wireless devices [8].



2.1.3 Java 2 Micro Edition J2ME consists of two configurations. These are Connected Limited Device Configuration (CLDC) and Connected Device Configuration (CDC). The first one is aimed at small memory devices with around 512Kb of available memory. The small Java applications created for these devices are called MIDlets that come from Mobile Information Device Profile (MIDP). CDC devices are, on the other hand, lying between the CLDC devices and full desktop systems. They have more memory available and can be found in smart phones, web telephones, residential gateways and set-top boxes [9]. Each of these configurations consists of a virtual machine (VM) and a collection of Java classes to support the programming environment. However, some of the Java classes presented in Java 2 Standard Edition (J2SE) are not supported by the J2ME API due to the low memory available on the mobile phones and inability of the VM to support them. For example, floating points are not supported by J2ME and thus the Java data types �� and �� are not supported, together with most of the security classes. However, it is possible to create another virtual machine with all the features that are required for the particular application. Figure 2.1.4: J2ME configurations and profiles

Source: J2ME in a Nutshell, A Desktop Quick Reference, O’Reilly

A profile as shown in Figure 2.1.4 adds additional classes to the particular type of device. There are several profiles included in the final version of the Java 2 Wireless Toolkit. Mobile Information Device Profile is used to create networking, user interface components and locale storage to CLDC. This profile is mostly used and aimed at devices with limited memory. PDA profile is similar to MIDP and aimed at phones with better user interfaces and larger memory. Another, Foundation profile is aimed at next generation devices with 2MB or more memory, and includes extra classes for the CDC devices. Personal and Personal Basic profiles add extra user interface functionality to the CDC devices as well. Finally, the software platform that has been chosen for this project is Java 2 Micro Edition (J2ME). The major reason for choosing this platform is that it uses Java and thus many phones can support it. However, it is also arguable that for this project the type of the software provided by BREW is not entirely needed. The Microsoft product, on the other hand, uses C# or Visual Basic.Net along with ASP.NET, which the author is not familiar with. Therefore, J2ME was found to be the most suitable software platform for implementing this project [10].



2.2 Mobile Phones That Support JavaTM There are many Java based applications supported by mobile phones and a list of these phones is located on the Wireless Java web site [11]. The highest number of mobile phones with Java support has the trademark ‘Nokia’ [12]. Research was done among these phones in order to find the average phone characteristics that would help to develop the application.

• The first characteristic is display. The technology nowadays is changing from the black and white phones to the bright and colourful ones with 4096 colours and screen resolution 128 x 128 pixels.

• The next characteristic is memory. The amount of memory allocated to every phone differs

and influences the size of the phone. The maximum amount of memory that is given for one Java application is normally no more than 64Kb. However, it varies from phone to phone.

• Finally, types of sounds used are important for developing an application on the mobile

device. Most of the phones produced now have polyphonic rings. 2.3 History and Functionality of ‘Tamagotchi’ 2.3.1 History of a Virtual pet ‘Tamagotchi’ was first created in 1996 in Japan and was presented to the world in the beginning of the 1997 by Bandai. A large distributing system and proven suppliers could not meet the demand for this toy. Many shops had long waiting lists. Figure 2.3.1: Tamagotchi key chain

Source: http://www.virtualpet.com/vp/future/trends1a.htm

The figure above shows how ‘tamagotchi’ looked when it was first realised. Initially this small pet was created for girls but some boys and men liked it too [1]. This encouraged a new wave of toys targeted for men. Many manufacturers started to produce these toys with different functionalities and designs. The first ‘tamagotchi’ creature was a strange looking pet that developed and changed with time. The first pets that appeared after were a dinosaur, a cat, a dog, a chick and a baby. As time has passed many manufacturers have cloned the initial virtual pets, so that the cat and dog have changed their original look but retained their functionality. The later pets included a bigger variety of animals such as bats, fish, frogs, lizards, pandas, parrots, penguins and many others. Many non-existing creatures such as aliens have appeared too.



The complexity of these pets has increased a lot. More buttons and functions have appeared compared to the initial pets. Weather, for example, has started to play a big role in a pet’s functionality. Several pets in one have started to gain its popularity. The negative side of the ‘tamagotchi’ boom was problems regarding copyrighting and policy issues. Some other virtual pets were making noise that could not be turned off and children were distracted during the school lessons. Unfortunately, some of the ‘tamagotchis’ did not have any pause facility either. This led to creation of the houses for virtual pets where they could stay when their owner is at school. Another problem was that tamagotchi could be good and bad, and that might cause some problems with children’ development. They even created one virtual pet that drank beer, smoked cigarettes and stabbed people, though it was not permitted to be released to the market. Moreover, many virtual pets normally die. For a child it is a big tragedy for its pet to die and many virtual cemeteries appeared to bury the virtual pet [1]. 2.3.2 Functionality of a Virtual Pet Most of the virtual pets share a list of basic functionality. This is mentioned below. Some virtual pets could be named and their date of birth can be actually stored and later celebrated, as time goes by. An owner of the virtual pet had to feed it in order to keep him alive and happy. After some time, a virtual pet feels tired and wants to sleep. In this case there used to be some buttons to switch off the light to allow pet to rest. The cleanliness of the place is very important; the pet feels much happier if everything is clean. Going to the toilet is an everyday procedure and an important functionality of a virtual pet. Playing with a pet keeps it and its owner happy. These games could be shaking hands (guess which hand) or playing ball (help to catch ball) or fighting. Training and disciplining of the pet is yet another important functionality. Teaching the pet how to do tricks based on commands – reward procedure is an interesting process but punishing it if the pet does something wrong should not be neglected. Once the pet is sick, the pet needs some medicine and the owner calls the doctor. An extra button or a menu function shows statistics of the pet. This normally includes score, age, weight, health meter, sometimes happiness, hunger and discipline. Alert function can remind the owner that something is wrong with its pet. The evolution chart of the virtual pet is similar for every pet and is based on the principle of 1 day being 1 year. Final results are based on the latency of life of the virtual pet and look like the following:

• 0-5- try harder • 6-11 – well done • 12-16 – good job • 17-22 – excellent • 23+ amazing

In summary, the basic functionality of the virtual pet created for this project will include:

• Feeding • Sleeping • Playing • Cleaning • Doctor/Medicine



• Statistics • Alert

The more advanced functionality such as naming of the pet, training, disciplining and games for playing could be added later. 2.4 The look of the Vir tual Pet A small research in the graphical representation of the virtual pet has produced the results mentioned in the Appendix. From the list of around twenty-seven pictures, a person had to identify the cat he or she would prefer to see on the screen of the mobile phone. The result had two best choices: Cat 1: Cat 2:

The most preferable choice of the virtual pet’s drawing was the cat on the left. However, it is easier to express emotions and feelings with the more human-like version of the cat on the right. Therefore, the second cat has been chosen for the ‘Tamagotchi’ cat. 2.5 Vir tual Pet AI Artificial Intelligence is the science of the human intellectual abilities or logic, for example used in the grammar of the language. Definition of the Artificial Life, on the other hand, is different from the definition of Artificial Intelligence. Artificial Life is dealing with the properties of life such as adaptability and, hence, about survival in the surrounding environment. One of the big examples of the Artificial Life is a virus. Many models have been created to stimulate the evolution of viruses and make them compete for survival. There was an attempt to combine Artificial Intelligence and Artificial Life i.e. learning and effects of evolution in the ‘Baldwin effect’ [13]. Baldwin assumed that if the current life form has been doing something in its lifetime, then the offspring should be doing that as well. For example, in the similar way animals get to understand what is poisonous and their successor later gets this information from its birth. Therefore, the learning helps survival, so the animal that learns to



survive is likely to pass this information to its offspring and thus stimulate the genetic process in that area. 2.5.1 Turing Machine Turing created the Turing machine to represent every level of intelligence by states. Turing machines are used as a standard model of sequential computation, which can be represented by states. It has an infinite tape in both directions with squares on it. Initially, it is assumed that this tape is blank. The symbol B denotes that. A tape’s head reads or writes to the blank square and changes the machine’s state. It can move to the left or to the right based on the set of rules provided. The Figure 2.5.1 and Figure 2.5.2 shows the example of the state diagram and a tape of the Turing machine [14]. Figure 2.5.1: State Diagram

Source: R. Gregory Taylor, (1998), Models Of Computation and Formal Languages

Figure 2.5.2: Tape of the Tur ing machine

Source: R. Gregory Taylor, (1998), Models Of Computation and Formal Languages

The head of the Turing machine changes with the changes in the state diagram. The above state diagrams shows that if the current square is empty or B, then write it as a and change the state to q1. Later, if the current step is a then move the tape’s head to the right. The same procedure continues with b. This is an example of a simple Turing machine. The Turing universal machine is a machine that can find a universal answer for any problem. More complicated diagrams can be used in the language recognition and number-theoretic functions. Turing is sometimes called the founder of Artificial Intelligence. Rene Descartes, philosopher and polymath has put forward the proposal for a machine’s intelligence. He suggested that machine’s intelligence is concerned with the machine’s ability to use language. Turing machine has already an ability to recognise the language, however it needs something more for a successful use of language. Turing suggested a test to identify the intelligence of the machine. He suggested to have two rooms with a man called Interrogator in one and male and female in another room. Female and male identify themselves as X and Y and later the Interrogator needs to recognise the sex of the people based on their answers. Around twenty games are played and the male wins if he manages to trick the Interrogator. The further test involves a machine taking the male place. The task for a machine then is to trick the player and to mislead him on who is the computer and who is the female. The computer is considered to be more intelligent if the number of games won by the male in the first



Sleep

Sick

Still

Toilet

Play

20

20

25

5

series is close to the number of games won by the computer in the second series. Therefore, according to Turing the machine is intelligent only if the machine will be able to identify the human abilities and can trick the person to realise that he is not just a machine. 2.5.2 Markov Model The Markov model is similar to the Turing machine, however it does not have the same infinite tape. This model though can imitate the Turing machine as well as Turing machine can imitate the Markov model [15]. The Markov Model used in this project uses the states to represent the states of a virtual pet. They are Sleep, Play, Still, Toilet and Sick as shown in Figure 2.5.3. The probability shown between states says how probable it is for the pet to go from one state to another. The overall probability for one state to go to other stages has to be no more than 100 per cent. The Hidden Markov Model has extra states that are dependant on the user, so that the user can enforce them on the pet. At the same time it has links to the Markov Model and if the pet is not forced to go to one of the states then the Markov model starts again as shown on the Figure 2.5.4. Figure 2.5.3: Example of the Markov Model for a pet between age 3 and 15.

10

30

30

25

5

30

20

30

20

25

5

20 30

30

5

15

0 0 0

0

100



Figure 2.5.4: Hidden Markov Model

2.5.3. Neural Networks Neural Networks are used in many fields and one of them is Artificial Intelligence. Neural Networks is a machine that can imitate consciousness and thus be able to learn and adapt. Neural Network consists of a set of small parts called neurons [16]. Each neuron in a network can send a signal to the other neurons it is connected to via a wire. This wire has a weight attached to it. Therefore, if the initial neuron is j and the final one is i, then the weight between these neurons is wij. The Figure 2.5.5 shows how this connection looks. Figure 2.5.5: Connection between two neurons Source: L.J. Landau and J.G. Taylor, (1998), Concepts for Neural Networks, A Survey

When the ith neuron will receive a signal from the jth neuron, the activity it will receive will be wij. The total activity though will be

Ai = Σwijuj i

where uj is the activity of the jth neuron. The response of the ith neuron can be binary depending on the activities value. If the value of f(Ai) is bigger than some threshold value then the output is

Food

Medicine

Sleep

Play

Markov Model

j i Wij



1 and 0 otherwise. Another method is to use sigmoidal (such as [1] + exp(-Ai)-1) function to respond in a more probabilistic manner with the similar binary based output. However, this output tends to be noisy but it reflects better the actual work of the human brain. Finally the activity f(Ai) uses the similar sigmoidal function for calculation but the actual number is passed as a response. The idea behind Neural Networks is that the neurons learn based on the previous inputs and by changing the weights, however it is important to know the designed output to be able to vary weights to the solutions. It is possible to adjust the weights using a simple algorithm that reduces the weights if the desired output was meant to be low and increases it otherwise. There are two extreme cases of the neural networks. The feedforward network with several layers with neurons on them passes activities from 1st layer to the 2nd one and from 2nd to the 3rd, so the transformation goes from x to y. In such network the input layer transforms into a hidden layer that is not seen by the users and later passes into the output layer, which is shown in the Figure 2.5.6. Figure 2.5.6: Feedforward neural network Source: L.J. Landau and J.G. Taylor, (1998), Concepts for Neural Networks, A Survey

Another case is a recurrent network, where the output can be putt back into the input or any other layer. One of the most known examples of it is an example of one layered network by Hopfield. His recurrent network has a symmetric matrix wij = wji with wii = 0, which is shown in the Figure 2.5.7. The Markov Model used in this project is similar to this particular type of the neural networks, however it does not implement a learning algorithm and just implements defined probabilities between the states. One of the reasons for it is that the J2ME does not support floats and it is harder to update probabilities when the integers from 0 to 100 are used.

Hidden layer Output layer



Figure 2.5.7: Recurrent Networks

Source: L.J. Landau and J.G. Taylor, (1998), Concepts for Neural Networks, A Survey

The specific problems such as noise, poorly defined characteristics and changing environments will benefit from the neural networks [16]. However, the neural networks tend to push the learning process towards a specific directive. This means that a problem can arise if pet learns to adjust to the specific rule and is no longer able to behave in a probabilistic manner. 2.5.4 Genetic Algorithms Genetic Algorithms are based on the genetics and selection and are part of evolutionary computing. They act as search algorithms of possible solutions on the whole population by throwing away the parts that are found to be not sufficient enough to solve the problem or by combining two solutions to produce a better result or by changing a small part/character of the solution at random [17]. These are called selection, recombination/crossover and mutation processes in the population that is being guided by a separate process. These algorithms are used in the machine learning problems and can be applied to the neural networks for better results. 3. Analysis and Design 3.1 Design decisions 3.1.1 Applications Development Environment The J2ME software can be used with the Wireless Toolkit or as an alternative it is possible to use Sun Studio 4 Mobile Edition [18]. These two applications are not very different from each other because both use J2ME technology. However, Wireless Toolkit does not provide an editor and the source code has to be copied to the special directory on the disk. Sun Studio, on the other hand, provides all these services inside the program. Therefore, it was found that there is not much difference between the programs and thus Wireless Toolkit was selected as the preferred choice for the development of this project. Using the Wireless Toolkit, it is easier to understand the low level processes that take place inside the program. The editor used in this development was VIM.



3.1.2 MID Profile considerations There are two versions of MID Profile. The first original version has an API that implements a simple applications lifecycle, user interface and persistent storage. On the other hand, MIDP 2.0 has many advantages over the earlier version. It enhances the user interface and introduces the Game API class that helps in the development of games. This profile allows the use of layers, where one is used for a background and another for an actual drawing. GameCanvas class that is not implemented in MIDP 1.0, has its own off-screen buffer for fast rendering. The networking class has been updated in the newer version of MIDP. This ensures a stable, consistent foundation for wireless applications. Mobile Media API has been added as well to enhance the sounds effects used in library javax.microedition.media.Manager. In this way the sounds specified are very easy to implement. The Form class used new Layout algorithms, which are explained in the MIDP API. Another improvement of the MIDP2.0 is an ability to recognise the untrusted and trusted code and accept only those that are digitally signed by the developer and verified by the user’s signature. Therefore, it was found that the latest version of the MIDP gives more features that enable an improvement in the functionality of the games. Moreover, the technological industry is developing all the time and the current project is aimed at the latest technologies to be able to run on the latest mobile devices. In a paper dated November 2002, Sun Microsystems claim that the MIDP 2.0 devices are going to be available in large volumes in Summer 2003 [19]. This appeared to be true, however, most of the phones support the older version and need software upgrade. 3.1.3 Choice of a pet The cat has been chosen as a representation of a virtual pet for this project based on the author’s personal preference and the fact that children tend to prefer either a cat or a dog. 3.2 Methodologies used in the development of the project The methodology that has been decided upon to implement the above requirements was an incremental approach. Rational Rose Suite was used in order to create initial diagrams to represent the system being developed. 3.2.1 Incremental Model The incremental model starts as a linear or “Waterfall” model that includes several stages following one another, and ends by repeating this process until the final result. This is shown in Figure 3.2.1.



Figure 3.2.1: Incremental Model

Source: Roger S. Pressman, Software Engineering, A practitioner’s approach, 4th edition

The first stage of the Waterfall model described by Pressman [20] is analysis, where all the requirements and initial information gathering takes place. The second stage is design. This stage is concerned with the actual designing of the future system. Diagrams are created in this stage in order to understand the future system. Next stage is programming or coding as it is named by Pressman. Finally, testing takes place. Once the first increment finishes, the second process takes place that improves the system and delivers it to the customer as an example of the work. This approach is significantly better then the linear approach. The linear approach, or the “Waterfall” model, requires the implementation of the whole system from the start to the end. This means that the customer’s requirements are only gathered in the initial stages and thus the final work might not reflect the customer’s needs. The probability of an error during the work increases as well. The incremental model allows a customer to give feedback on the current system and later the process is adjusted based on the new requirements. However, there is a problem of the customer being too involved in the project and taking the prototype as the final release. 3.2.2 Diagrams The first diagram that has been created for this project was a Use Case diagram that reflects the general customer’s requirements. The customer in this case is the General public.



Use Case diagram:

Tamagotchi Game

Check pet's stats

get alerts in crucia l stages

Play with it

Clean after i t

Feed the pet Tell him to sleep

Keep i t healthyGeneral public

This diagram shows that there are several initial requirements:

• Feed the pet • Tell him to sleep • Clean after it • Keep it healthy • Check pet’s details • Play with it • Get Alerts in crucial stages

The next diagram created was the class diagram that was an attempt to find the classes needed in order to create such a system. However, it was realised later that this diagram does not reflect the real system because the system is based on screens, and thus will require extra classes to reflect the same. The method to revise the class diagram is to start with the Collaboration diagrams. Later, they can be analysed and combined into one final diagram. All these diagrams are included in the Appendix A. The second “Class” diagram used as a design for the system reflected the actual system in a better way.



Class Diagram:

Alert

message

getAlert()

(from Use Case View)

<<entity>>

MainScreen

displayAlert()CleanPlace()FeedPet()giveMedicine()PlayWithPet()SwitchOffLight()checkStats()DisplayResults()


<<boundary>>

Stats

Score

getStats()calculateScore()


<<enti ty >>

CharacterControl

checkProblems()deleteTrash()checkHunger()checkMedicineTime()CheckPlay()CheckSleepness()checkGeneralInfo()


<<control>>

AgeClock

agedayyearhoursmins

getAge()


<<entity>>

Character

getCharacter()UpdateCharact er()


<<entity>>

The class diagram shown above is the resulting diagram based on the collaboration diagrams. However, the final system was not fully reflected by this diagram. Some classes have not been used. For example, AgeClock class was not necessary because all the age attributes were calculated in the Main Screen and updated and checked in the CharacterControl class. Moreover, there was a small problem of the user modifying the time on the mobile phone and calculations going wrong. Therefore, the age is not calculated based on the current time on the mobile phone but rather on the time taken to execute one loop of the thread. Character class is another class that was not implemented for the reason that it can be used in the future to change the character of the cat, for example, from normal to lazy. The time limit given for this project was not enough to implement that. Alert and Stats classes have not been implemented as separate classes because they are very similar to each other. Alerts arise when the information about the pet is in its crucial stage. Statistics, on the other hand, give this information to the user. This information is based on the variables from CharacterControl class. Therefore, it was found more useful to implement these classes in the MainScreen class and use the information about it from the CharacterControl class. Another difference of this diagram from the actual one is that the MainScreen class in the program is called ViPetsCanvas class, and the StartForm class is the screen where the user can specify if he/she want to play the game or exit.



Extra classes that have been added to the class diagram are CatStore class that stores the information about the pet when the user wants to exit play mode, Intro class that shows the picture of the cat for several seconds and another important class called ViPets that actually starts the application. None of these classes have been included in the original diagram due to lack of coding experience in Java 2 Micro Edition software. The final class diagram that reflects the real system can be found in the appendix A as well. 4. Implementation 4.1 J2ME for Vir tual Pet The Java 2 Micro Edition software comes with a wireless toolkit, user guide, documentation that describes the classes available, emulation device, preferences, utilities, compiler and packaging tools. 4.1.1 Wireless Toolkit The Wireless Toolkit as shown on Figure 4.1.1 is the main workspace for any project. It is possible to access any other applications that come with the software, except for the documentation. Figure 4.1.1: J2ME Wireless Toolkit

The new project starts by pressing the button New Project. A new box with two fields will appear. The first field input has to be a name for the new project in the way it will appear on the mobile phone. The other field, called MIDlet class name, creates a directory where all the files for this project are stored. The directory is located by default in the same place as the one where J2ME is installed (<<J2ME.dir>>/apps). However, it is possible to change it by adding an extra line in the toolkit specification file and adjusting the preferable path. The toolkit specification file is located in the <<J2ME.dir>>/apps directory. The file name is ktools.properties. In order to change a directory path an extra line: kvem.apps.dir needs to be added, followed by a semicolon, and the new directory written with double backslashes and without spaces in the name. The command for this project will look like following: kvem.apps.dir: Z:\\MSCProj\\apps



Later, the directory will be created there with the MIDlet name. A first look inside will show that four extra directories were created inside by the toolkit, called: Bin, Classes, Lib and Res. The Bin directory has the manifest files that has all the information about the MIDlet created, and is used later on for the final packaging, together with the JAD file.

• Classes directory contains all the compiled classes used in the project. • Lib directory contains external class libraries or JAD or ZIP files. This project does not

include any files in that form and therefore that directory is not used. • Res directory has all the extra files used in the project, for example pictures. The pictures

by default can only be accepted in PNG format in J2ME. • Src directory includes all the source files that are created in the project. The toolkit does

not have any editor embedded into it and thus VIM is used. All the files created have to be in this directory.

On the first compilation a new set of directories are created, templib and tempclasses. They serve as temporary directories for lib (external files) and classes (.class files). The process of compilation starts once the “build” button is pressed in the Wireless Toolkit. Apart from the normal compilation, another process takes place afterwards. It is called preverification. The process of verification prepares classes and Jar files and class directories. Therefore, afterwards it is possible to package these classes into JAD files, making them smaller. The emulation of the actual phone is used in J2ME in order to test the game. 4.1.2 API The API documentation that comes together with Wireless Toolkit describes the classes available. Some of the main classes are similar to the ones that are used in Java 2 Standard Edition (J2SE), however not all of them are present in J2ME [21]. The Virtual Machine for mobile phones, that is responsible for running the classes, has to be small to fit in the limited space. Thus some classes were excluded for one of these reasons. Two other classes that are not used are Float and Double. The only numbers that can be used are integers and longs. The long class is more widely used partly due to the reason that it has the maximum range and the time measurements in Java return longs as well.

• MIDlet class A MIDlet is a program that uses the MID profile mentioned in the research chapter. A MIDlet is very similar in its structure to a Thread class. It has start application (startApp()), pause application (pauseApp()) and destroy application (destroyApp()) functions. If an application needs to be paused or destroyed, a function called notifyDestroyed() or notifyPaused() is thrown in order to prepare a MIDlet to reach that particular state. Every program starts with the startApp() method. This project’s MIDlet is contained in the class called ViPets.java.

• Form class The Form class is responsible for displaying the objects on the screen. For example, images, read-only text fields, editable text fields, editable date fields, gauges, choice groups, and custom items. It is a very useful for inputting details or giving statistical information. All the objects are added to the form by using the append() method. Layout and scrolling are easy to control using this class. It also enables line breaks and wrapping of the text in long sentences. A user can interact with this



class by being notified by the itemStateChanged() method and calling a listener to handle items being changed in the choice groups or in the custom items. The displayable objects such as buttons on the mobile are handled by the commandListener. To add a command to the screen the method addCommand() is called and setCommandListener() sets CommandListener.

• Command class

According to the definition given in the MID profile API, ‘the Command class is a construct that encapsulates the semantic information of an action’ [21]. This means that the information about an action is declared but not the actual implementation of it. The actual implementation of this action is handled by the CommandListener. Commands have labels, types and priorities. Label is a name for the command that is going to be displayed on the screen. Commands can be of different types such as BACK, EXIT, CANCEL, HELP, ITEM, OK, SCREEN and STOP. Logically, for the exit button, for example, the type will be EXIT and for the help button, HELP type will be set. Priority of the Command is the order of it being displayed on the Screen. For example, the exit command of type EXIT tends to be on the left side of the screen, so it is more convenient for user to press it when he wants to exit. Several buttons can be of the same priority, in which case the type of the command will specify which command is being displayed. The highest priority is 1 and it decreases with the increase in numbers.

• Image class Image class is a class that caries the image buffer. The picture is not visible until the relevant method is called, for example paint() or when it is placed within the Form screen. The Image class gets the buffer from the actual image by calling the createImage() method with width and height of the picture parameters. The only format of files that is supported in this API is PNG (Portable Network Graphics).

• Threads class A thread is a process that runs in the program. The number of processes in one program can be unlimited. Thus, multithreading is very common and many big applications support it. The communication between processes can be implemented with the get and set variable methods. In order to avoid two threads accessing and updating the same method at the same time, a word synchronized needs to be added to the method. There are several implementation methods of the Thread class. In the first case the class itself can extend Thread class and then run this thread using the run() method as shown in the example from MIDP API:

class PrimeThread extends Thread { long minPrime; PrimeThread(long minPrime) { this.minPrime = minPrime; } public void run() { // compute primes larger than minPrime . . . }



Another way is to implement the Runnable interface instead of extending Thread and use the run method in the same way. Running threads can be started, stopped for some time, can join and be prioritised in a certain way. However, the main method that has to be implemented for the thread to run, is a run method. A simple while loop inside the class needs to be implemented, for example, run until thread is true can be implemented to keep the process starting from the beginning again and again.

• Canvas and GameCanvas classes Canvas class handles low-level graphic events, whereas Form handles the high-level ones. It ensures that it is displayed on the screen correctly and handles game actions such as keys, for example. These key events have their own codes and are identified based on the same. The main method that draws graphics on the screen is paint() method, which is declared abstract in there. Therefore, implementation has to be provided for it. GameCanvas class extends Canvas and provides the basis for the user interface. This class has several methods that differ from the Canvas class for handling the keys, painting and flushing the graphics. It supports an off-screen buffer that is created for each GameCanvas instance. The game dimensions are specified by the getWidth() and getHeight() methods. Moreover, it has an ability to query key status. Therefore, the key actions are used in a different way from the Canvas class. public void keyPressed(int keyCode) { int keyState = getKeyStates(); if ((keyState & LEFT_PRESSED) != 0) { // left key // some code } The process of displaying the low-level graphics is different in GameCanvas as well. The game has to implement its own Thread to run the game loop and update the variables. The structure normally looks like

Graphics g = getGraphics(); public class GameThread extends Thread { public void run() { while(true) { // the actual game sprite.paint(g); // calles paint method } } Later, the graphics can be flushed and the background can be set to white either in the run() method or in the paint() method. Paint() method needs to be implemented as well, in order to render the off-screen buffer of the GameCanvas class. The flushGraphics() method used in GameCanvas flushes the off-screen buffer to the size of the GameCanvas.

• Random class Random class is another interesting class that was used in this project to stimulate the random behaviour of the pet, and at the same time control it using probabilities. Random class uses a



function that generates a random number, however if a Random has been created with a specified seed in it, then the pattern of the development in the program will be the same every time. Therefore, the Random class has a System.out.CurrentTimeMillis() seed as a default. This implies that their might be a problem of having large numbers in the probability. The maximum Long number by default is 264, whereas, the maximum Integer number is 232 number, the latter being used as a maximum number as well in this project. The actual number is being generated by the nextInt() or nextLong() method.

• Spr ite class Sprite is an object that can be rendered and has several frames to enable animation. The frames are stored in a PNG image and displayed in a sequence. Simple transformations can also be applied to the sprite such as rotation and translation. It can also become invisible or visible. Sprites are drawn using the paint() method. As a default the number of frames in the animation is the same as the number of frames in the picture and all of them are of the same specified size. However, it is possible to specify it by calling setSequence(int[]) method and animate the picture in a different order. The example of the PNG file is shown in Figure 4.1.2. However, frames start from 0 and finish by n-1 where n is the maximum number of frames. Figure 4.1.2: Spr ites animation

The frames though need to be changed manually by calling nextFrame(), previousFrame() or setFrame(int) methods. The position of the sprite can be set by using the setPosition(x,y) method that comes from the Layer class, since Sprite class inherits from it. The count of the position starts from the upper-left corner.

• RecordStore class RecordStore class allows a MIDlet to store information on the phone so that it can be accessed later. This project uses this class to store information about the pet when the MIDlet is stopped but the cat is still in the active state. Therefore, this ensures that when users come back to the game they will play the same game as they had been playing. The MID profile API claims that the platform is making its best effort to keep the information in the storage on many occasions, including battery charges and reboots. Once the MIDlet is removed from the platform, the information stored within the RecordStore class is removed as well. The names for the RecordStore are case sensitive and created in the openRecordStore(String, boolean) method. The second parameter in the storage needs to be created or just opened. The deleteRecordStore(String) method, on the other hand deletes the storage.



• Aler t and Aler tType classes The Alert class is a screen that allows data to appear and displays the information to the user. The information can be just a String of text or an image. AlertType class can enable some sound effects together with the Alert by calling AlertType.playSound() method. The types of the AlertType class are ALARM, CONFIRMATION, ERROR, INFO and WARNING. Help and About buttons in the menu have similar methods of displaying information about the game and helping the user to understand the game. 4.1.3 Classes and Functionality of the Virtual Pet The project consists of several classes. They are ViPets.java, ViPetsCanvas.java, Intro.java, StartForm.java, CatStore.java and CharacterCotrol.java.

• ViPets.java

ViPets class is a start file for the project. It uses a MIDlet class to run the program. Therefore, it has methods that allow MIDlet to run, such as startApp(), depstroyApp() and pauseApp().

• Intro.java This class displays a temporary picture of the cat on the screen. It is an introduction file that invites the user to the Virtual Pets. This class extends the Form class to be able to display a picture. It uses the Thread class to display this on the screen for a certain amount of time. In the constructor, Task class is called and a thread starts. To keep the picture on the screen Thread.sleep(DELAY) method is called, where DELAY is the amount of time the picture will be on the screen.

• Star tForm.java

This class implements the commands specified by the user. Commands are the actions raised by the user pressing buttons on the mobile phone. Therefore, all buttons in the menu such as ‘New Game’ or ‘Exit’ are implemented here. playCommand = new Command("New Game", Command.SCREEN, 1);

The example above shows the use of the Command class, where ‘New Game’ is a label, Command.SCREEN is a type and 1 is a priority. Later in the class the commandAction(Command c, Displayable s) is implemented to handle all the commands. In this example, c represents Command and s is a current Screen. Therefore, at the start of the game when the screen is changed and displayed in the ViPetsCanvas.java, the actual handling of the commands can still be implemented in StartForm class.



Moreover, this class checks if the pet has been played with before by trying to read using the CatStore.readStore() method. If the pet has been stored before in the persistent memory of the mobile phone, then the pet is restored with the variables later assigned to the CharacterControl class. Thus, the old pet is restored; otherwise, a new pet is constructed. The next step of this class is to display a line saying ‘Welcome to Virtual Pets’ and a simple graphic on the screen such as a picture of the pet. The picture and the text are appended to the Form in order to display it on the Screen. Picture is created by using the Image class. As mentioned before, StartForm.java uses CatStore class to store cat. Therefore, when the user exits the main screen and comes back to this screen, his current pet is being stored in the memory on the mobile phone and before exit, another screen is displayed that shows the statistics of the pet at that moment. The display of the statistics on the screen is done by calling the getScore() method from ViPetsCanvas class.

• ViPetsCanvas.java

ViPetsCanvas class is a class responsible for all the graphics and calculations of variables used later in CharacterControl class. This class has two threads for these purposes. One thread handles graphics and another one ensures that calculations are running at the same time as the graphics are displayed on the screen. Functions The constructor of the ViPetsCanvas class is simple, it declares the Icons on the screen, so that they can be displayed. The start() method, on the other hand, starts the actual game. It has a CharacterControl variable as a parameter because the class might need to use a different CharacterControl variable if the user has been playing this game before and his initial pet’s variables have been stored. Another interesting thing that should be mentioned is that start() method declares Random variables because the usual Math.random() class normally used for probabilities purposes in Java 2 Standard Edition does not exist in J2ME. The reason for that is that it returns variables from 0 to 1 and this means that the return value belongs to the Float class, which does not exist in J2ME either. The start() method has two variables that represent probabilities, one is delay and another one is select. The delay tells randomly how long the pet is going to be in one state, whereas select probability selects the state the pet will change to. However, delay and select are not the actual variables used, they just create new random number generator based the class Random. The randomSelect and randomDelay are the actual probabilities used in the work. The value they get comes from the method nextInt() used in the Random class. GetPositiveRandom() method, on the other hand, eliminates all the negative values that come after calling nextInt() function. The start() method starts the threads that are the main parts of the program. The first thread that is a GameThread imitates the Markov Model by having several states. All of them are called within and if statement. Initially though a current time is taken, so later it can be used to limit the time for the states to run. Therefore, the state will run by how long the current time



is plus the randomDelay variable. The rules are specified before the function goes into the state mode. Therefore, rules such as to sleep during night and limit amount of time spent on the food. The adjustRules() function, on the contrary, updates the probabilities once the state has been stopped. Two variables are used to specify if the user enforces the state or it is a part of the Markov Model. Position[x][y] is, therefore, the first and the state is the second. In the end of the thread randomSelect and randomDelay are being changed and a new maximum number being adjusted. Based on this the next state is found. The setState() function is a function that finds the state of the cat. CharacterControl class has a variable called range that is an array of five current states. The states probabilities are reflected in that array. For example, if range[] = {20, 40, 60, 80, 100}, then the probability of a pet to go to any of the states is equal. However, the probability is adjusted after one state has been finished as mentioned above. The second thread that is called TimeThread calculates the age of the pet, weight, sickness, health and hunger variables. However, hunger and health are adjusted at the same time in the first thread to reflect the state. The weight is calculated based on the condition of the hunger. If the hunger is more than 2/3rd of the maximum then the pet tends to put on weight and if the hunger is 1/3rd of weight, the pet tends to loose weight. The trash bin reduces the health of the pet and if it is very high then the health can decrease dramatically. Finally, age is calculated based on the time of one turn in the loop. That difference between the start of the turn and the end of the turn is calculated and the age is updated. Another function that has to be mentioned is getScores() function that displays the statistics of the pet at the moment. It returns Screen variable and is used in the StartForm class to display score when the user exits the game. Graphics The low-level graphics used in this class is provided by the GameCanvas class. This class enables displaying of the game on the screen and handles all the keys pressed during the game action. It uses its off-screen buffer to enhance the visual quality of the game. The animation of the cat is using the Sprite class to represent an object of the cat and create a sequence of movements. The paint() method in the ViPetsCanvas class has more parameters than just graphics object. It passes sprite and sprite’s positions on the screen. In this way it is possible to display sprites on the screen using just one method. However, the sprites need to be declared separately, where it can be secified, which picture they are using, and how big one frame in this picture is. The normal pictures of the icons on the screen are displayed by using drawImage() method and passing an Image object to it. The bin pictures are changing by changing the variable trash and thus changing the pictures stored. The init() method starts with the screen being white and then calls all the icons to be displayed together with the mouse cursor icon, which parameters for movements are being adjusted in the keyPressed(int) method and reflect the user actions. The sprites, objects on the screen, have a start sequence and the end sequence. This sequences are being updated once the cat grows i.e. becomes four years old. Initially, PNG files have double set of



frames. One is for the pet being young and another one is for the grown pet. Therefore, the sprite needs to update a sequence by setting setSequence(int[]) method with new one.

• CharacterControl.java CharacterControl class is a class that stores all the character features of the pet. It specifies how the pet will be. Initial numbers are presented in the constructor of the class, however another constructor exists to set the CharacterControl variables based on the other variables that are used in the CatStore class to restore the pet. Most of the variables have set and get methods for it and the same methods for the maximum number this variable can have. However, other functions exist. The important ones are the functions that use range to specify the probability. The SetRangeAt(int, int) method sets the probability at the specific point of the array called sizeOfRange with a number, whereas the setBoundary(int[]) method makes sure that that number is added to the range and the overall boundary is hundred per cent. It is also possible to get an element from the range at the specific point using getRangeElementAt(int) method or to get the whole array. The method that actually sets the sizeOf Range so that later the range can be updated is setRangeFor(String) method. It updates the probabilities for the specific state of the cat and for a specific age as well. The death functions include such methods as isDead() to identify is the pet is dead and use the particular messages to set the reason of death.

• CatStore.java CatStore class is a class that stores the pet’s characteristics before the user closes the MIDlet and restores it after the user logs in. It uses RecordStore class for this purpose. The CatStore class has two methods. One is writeToStore() that writes the information about the pet into the persistent store on the mobile device and another one is readStore() that reads the information from the store to create an existing pet. In the second case the CharacterControl constructor is called to update the pet. 4.2 Sample Screenshots Some sample screenshots are shown below to show the different screen stages for different classes.



Intro class:

StartForm class:

ViPetsCanvas class with the pet at the small age:

ViPetsCanvas class when the pet is grown up:

4.3 Downloading MIDlets on the mobile phone Different versions of mobile phones allow different ways of downloading the application into memory. However, the first step in this process is to package the application. This is done very easily by pressing the package button in the Wireless Toolkit. Once the application has been packaged, it is possible to find the packaged file in the bin directory of your application. Two files have been created: one is JAR and the other is a JAD. The JAR file is a description of the program, whereas the JAD file is an actual archive that contains all the files including the manifest file [22]. 4.3.1 WAP The first method of downloading the file into the mobile device is to locate two files on the server with the html file that has similar coding: <html> <head> <title>VirtualPets</title> </head> <body> <a href="VirtualPets.jad">VirtualPets.jad</a> </body> </html> The software provided with the mobile phone is usually set to look for the .jad files. Therefore, this should start the downloading process of the game on the mobile device. 4.3.2 Bluetooth Another way of downloading the application on the user’s mobile phone is to use Bluetooth and the program disk provided with it. Once the installation disk has installed the program and the program has identified the user’s phone, the JAD file can be sent by clicking on the right button of the



mouse. Later, the phone will get an application in the inbox and can install it from there to the application directory. 5. Testing and Evaluation

5.1 Testing 5.1.1 Testing the functionality It is not very straightforward to test the ‘Tamagotchi’ game. The possible tests could be to check if:

1. The game does not crash when it runs for at least half an hour. 2. The game works when the user exits the main game and starts again. 3. The game works when the user pauses the game. 4. The game works when the pet dies and user starts the game again. 5. All commands are working and the graphics actually represent the commands. 6. Statistics represent the actual information about the pet. 7. The states are changing without user interference. 8. The cursor reflects the actual button pressing on the phone by the user. 9. The pet is asleep at night.

The first, second, third and four tests are passed successfully. The fifth test has shown some problems in the medicine area. The pet could not be given medicine, and the health was decreasing every time instead of increasing. Later, it was possible to identify the problem, which was arising because the level of health was below the specified level. The checkRules() function used to keep the state of the pet to be ‘Sick’ because of that. The solution was found in increasing the level of health to the level above the threshold level after the medicine is given. Health is set to the forty per cent of the maximum level in the case of health being lower than the defined level, and the health is increased by ten per cent if the health is above that level. The sixth test has failed during the demonstration time. However, the problem has been solved later. The problem was that the game has been adjusted to run in the slower timings, however the age variable was not adjusted accordingly. Therefore, the statistics were showing the faster aging with the slower change in statistics. The seventh, eighth, ninth and tenth tests were also passed successfully. 5.1.2 Testing on the Mobile Phone The initial test had been done on the Nokia 7650 mobile phone that is shown in the Figure 5.1.1. This phone has a high-contrast colour display, a graphical user interface, Bluetooth, Symbian OS, MIDP JavaTM support and WAP [12]. Nokia 7210 has similar features including JavaTM and was used later to repeat an attempt to run the application on the mobile phone.



Figure 5.1.1: Nokia 7650 and Nokia 7210

Source: http://edition.cnn.com/interactive/tech/0203/nokia.phones/nokia.7210.jpg Source: http://www.nokia.co.uk/nokia/0,8764,18963,00.html

Initially, the task was to try to download the game on the mobile phone using WAP. The packaged file has been created and put on the web server, so it would be possible to download this file from it using an existing WAP. The attempt, however, did not work properly due to the lack of authorisation on this server. Therefore, another method using Bluetooth was used later. A disk provided with Bluetooth allowed the installation of the program for it. This program allowed the sending of a file from the PC to the mobile phone inbox. The application was then installed from that space into the application folder. However, the fact that this project is based on the use of MIDP 2.0 did not allow this application to be properly installed on the phone. Therefore, the test has failed. In the second case, when another phone was used, it was realised that it did not support Bluetooth and the only method that could be used was WAP. However, the web server did not allow the downloading of the file for the reason that it was not possible to identify the user from the mobile phone. Therefore, it would be possible to test the game on the actual mobile phone and not using an emulation if the latest version of the mobile phone had been used. 5.2 Evaluation The evaluation of the project is based on several methods. Firstly, the software developed was compared to the NeoPet example that was purchased from the shop and represents the latest wave in the development of the pets. Secondly, a questionnaire was created to let people try, experience and share their opinion on the potential of the product. Moreover, an actual virtual game has been already created using a cat as well. However, it was impossible to get hold of the mobile device that has this particular pet and thus could not be discussed in this evaluation chapter. 5.2.1 NeoPets ‘NeoPets’ game is based on the ‘NeoPets’ web site that was developed in 1999 as a follow up of the ‘Tamagotchi’ boom. ‘NeoPets’ websites gives the user a variety of choices in choosing, feeding and playing with the pet. The actual points gained by playing with the pet can be invested in the pet’s



food and different forms of entertainment. Moreover, the web site is not just a place where the virtual pet can be held but is a community of people interacting with each other by the means of their pets. This web site is still very popular and used by people all around the world. However, it is better known in Asian countries than in Europe. It has been claimed that this website is used as often as people check their e-mails. Every day, the owner will login to check on the condition of the pet [23]. The actual game has been created later and is based on the ‘NeoPets’ website principle of generating neopoints that can be used to buy food or toys for a pet. The picture of the game is shown in Figure 5.2.1. Figure 5.2.1: NeoPets game

Source: http://www.littlewoods-index.com/index/rf.inf.RFServlet?pathinfo=productpages/ProductPage.html&pca=103282704&row=2&col=1&displaybanner=N&page=2&version_id=568&category_id=94933639&rootcat_id=94933694

This game is different from the game that has been implemented in this project. To analyse it, it is better to look at it from different angles.

• Functionality The functionality [23] of the NeoPets is more advanced than the basic functionality of the game created for this project. The game starts with the specifying the name of the pet, gender, setting the current time for the pet, specifying what the pet likes to do (for example, explore or eat) and how your pet greet others (for example, by smile or tends to be scared of strangers). This sets the personal characteristics of the pet and identifies the initial strength, defence, movement, weight and height. The game then starts with the NeoPet appearing on the screen. Other parameters that are used in this program but are not implemented in the project include happiness and intelligence. Happiness and intelligence of the pet depends on the time of feeding and sleeping. For example, the neopet has to be fed at 9am, 12am and 7pm. If the feeding goes on time them happiness and intelligence increases, otherwise it decreases. Sleeping needs to be forced on the pet from 9 in the morning and waking should be done by pressing similar button at 7 in the morning. This also is reflected in the happiness points and intelligence points.



There are several games that can be played within this game and thus neopoints can be gained. However, these games give only three attempts a day to gain ‘neopoints’. Once these game do not return any more points, another game can be played that imitates a Jack Pot and can allow users to gain some extra points. The ‘neopoints’ can be spent later for food, toys and the pet store. Once the time for feeding is close, the food needs to be purchased and fed to the pet. The toys are kept in the burlap sack and can be used from there to play with pet. This type of game is very interactive and makes the user want to play games every day to be able to feed the pet to ensure that the pet does not die. The Virtual Pet game that was created for this project lacks most of the functionality that is used in the NeoPets version, and is not dependant on the time apart from the pet being asleep at night. The idea of the dependence on time for the food is a useful one and encourages children who use the game to follow a special regime. One small flaw though in the NeoPets functionality is the problem with clock. Firstly, the clock tends to slow down by few minutes a day, however it could be just a technical design issue. Secondly and more importantly, the adjustments in the clock can be done manually and if the clock is forwarded few hours ahead and then put back to the previous time, the information for the games is updated and not changed to the initial stage. Therefore, it is possible to cheat system by playing more than defined number of games at a time and getting points for them.

• Graphics The graphics of the NeoPets game are very simple. The main icons are displayed on the background of the actual game and a small screen that is located on the top shows the changing of the states and allows animation of the pet. However, this class is pixel based and not colourful at all. This gives an advantage to the actual game implemented here due to the wider variety in the colour and smoother animation for the cat.

• Sounds Sounds are not implemented in the current project due to the special emphasis on the actual implementation and graphics. However, a single sound in the whole game is implemented handled by the Alert class. MIDP 2.0 however uses Mobile Media API to create more advanced sounds. The NeoPets game, on the other hands, uses a restricted set of simple beeping sounds.

• AI Algor ithms The AI algorithm that is probably used in the NeoPets class is similar to the one used in this project. The only difference in it is the amount of states the cat can be in and extra functionality. However, it does not seem to reflect any learning algorithms because it defines by default the times for certain actions and does not allow space for learning.

• Usability The usability of the NeoPets class is not very complicated, however, the cursor movements across the screen allows only left and right movement and this takes some time to get to the right place. However, some functions can be accessed in a different way by putting the actual figure of a pet supplied with the game into one of the slots on the outside of the game. On the other hand, the



Virtual Pet game allows freedom of movement for the cursor and is very easy to understand due to the simplicity of functionality. 5.2.2 Questionnaire The questionnaire has been conducted in order to evaluate this project based on the people’s personal experiences with the Virtual Pet game. The questions concerned several aspects such as the functionality of the game, graphics, behaviour pattern, usability and the actual design to have this game on the mobile phone. The overall results reflect the interest and desire to have this mobile game with satisfactory levels in graphics, functionality and behaviour patterns. The diagrams below show this: Diagram 1:

Diagram 2:



Diagram 3:

Diagram 4:

The pet's behaviour patterns are realistic

Strongly agree10%

Agree80%

Not sure10%

Disagree0%

Strongly disagree

0%



Diagram 5:

It is straightforward to play this game.

Strongly agree

Agree

Strongly disagree

DisagreeIndifferent

However, the age group that has been asked is between 22 and 26, most of whom did not have prior experience of playing this type of game. More realistic results could have been obtained from younger children who are more determined to spend more time playing the game. On the other hand, the positive feedback from the adult population leads to the assumption that the younger generation is more likely to enjoy the game as well. The conducted questionnaire-based evaluation suggested adding extra comments about the game. Some suggestions were impossible to implement due to the lack of time. However, the less complicated functionality has actually been implemented. This includes the adding of the messages in the statistics screen when the pet grows or when the pet is in one of the crucial stages. A message giving the reason for death of the cat has been implemented as well, once the pet has died. Another suggestion was to use percentage as an output of the conditions of health and food at a particular moment, and this was implemented as well. 6. Project Management 6.1 Initial Schedule The schedule that is shown in Figure 6.1, was initially created to reflect the incremental model used for this report. The current version of the schedule reflects two increments that have been decided to follow in order to implement the objectives. The second increment starts from adding extra functionality to the pet by redesigning the classes, implementing new functionality and testing it on the phone. 6.2 Actual Schedule The actual schedule, on the other hand, shows the actual stages of the project development and how the model is being followed. Unfortunately, due to the extra time spent on implementation and testing, another increment of the model had to be discarded and that is reflected in Figure 6.2. It can also be seen from this figure that many stages have coincided with the time that the graphics and implementation of the game have been developed. Another problem arose from the difficulties in the implementation of the Artificial



Intelligence algorithm. Firstly, it was started later than planned due to the extra time required for the analysis and design stage and then later in the stage it was realised that the actual algorithm does not entirely represent the Markov Model. Thus, the algorithm needed to be redone.



Figure 6.1: Initial Project schedule

Figure 6.2: Actual Project Schedule

Tasks

6thJune 13thJune

13thJune 20thJune

20thJune 27th June

27thJune 18thJuly

18thJuly 25thJuly

25thJuly 1st Aug

1stAug 8th Aug

8thAug 15thAug

15thAug 22ndAug

22ndAug 29th Aug

29thAug 5th Sep

Further research into AI of the virtual pet Plan the analysis and design of the system

Start implementing the basic MIDlet Decide on the look of the virtual pet and implement all the variations of it

Create this pet on the software Apply AI techniques and implement simple functionality

Test the system on the mobile emulator and real phone

Writing up the project report Demonstration of the project

Tasks

6thJune 13thJune

13thJune 20thJune

20thJune 27th June

27thJune 18thJuly

18thJuly 25thJuly

25thJuly 1st Aug

1stAug 8th Aug

8thAug 15thAug

15thAug 22ndAug

22ndAug 29th Aug

29thAug 5th Sep

Further research into AI of the virtual pet Plan the analysis and design of the system

Decide on the look of the virtual pet Create this pet on the software Apply AI techniques and implement simple functionality

Test the system on the mobile emulator and real phone

Add extra functionality to the virtual pet Test the system on the mobile emulator and real phone

Writing up the project report Demonstration of the project



7. Conclusion and Future Work 7.1 Conclusion In conclusion, the current solution of the mobile ‘Tamagotchi’ game reflects a simple Artificial Intelligence model on the mobile phone using Java 2 Micro Edition Wireless Toolkit. Much research has been done in different areas such as virtual pets, mobile application platforms, artificial intelligence and artificial life and mobile specifications. The algorithm used in the production of this work proved to be quite satisfactory because it imitates the random model of the pet based on the defined probabilities. The game lacks most of the advanced and well-thought functionality of the NeoPets example. However, the questionnaire conducted seemed to produce promising results that this game can be popular on mobile phones. The newer version of Wireless Toolkit and thus MIDP gives more opportunities to develop a proper game. However, the downside of it is lack of support of the newer MIDP by the most of the mobile phones. Only the latest versions of the communication devices can download and run this game and it is very expensive to get them. 7.2 Future Work 7.2.1 Future functionality and graphics The people that have answered the questionnaire had a list of future suggestions in terms of the functionality. These included the following:

• An improvement in graphics of the game • Use of a colourful pet • Display the fat/ideal/thin cats as different graphics • A choice of a dog instead of a cat • Implement sounds • Level of difficulty for a pet, where the harder level gives a faster evolving pet • Extra variables that represent the character such as happiness or boredom • Ability to name the cat and store its information at the score board • Put some clothes on the cat • Enable communication with the pet in a form of a simple dialog • Extra functionality to make cat dance with specific tunes and change them when tired of one

Apart from all the suggestions by people who filled the questionnaire and who were a bit disappointed not to have the chance to try this game on the actual phone, there is some extra functionality that can be added to make the game more exciting. For example, to create actual games for the play state of the game, so the user can actually interact with the pet. Another interesting functionality used in the NeoPets game was that the pet had special timings for eating and sleeping. This can be implemented, but it would be more realistic to add some learning process to it. Thus, if the user keeps feeding the pet later than initially specified, the cat learns and adjusts accordingly.



7.2.2 MIDlet improvements At the moment the game is stopped, once the MIDlet is stopped, the information about the pet is stored on the persistent storage. However, it would be better to keep running the game on the background of the phone and not stop the game. Therefore, during the phone calls or another user’s activity on the phone, a thread is still calculating all the pet’s parameters. This, however, will require the battery power of the phone, and cause it to decrease faster than normal. Another solution to this problem could be to implement a server and send the actual pet to this server and keep it running there until the user starts the application again and his pet is downloaded back on the phone from the Internet. 7.2.3 Probability class adjustments Random number generation can be improved to be more random than the function in the MIDP API class provides. For example, it possible to create two random classes, then subtract one number from another or multiply one by another and, finally, create a new class with the seed being that function of these two random variables. 7.2.4 Future of Neural Networks Finally, the Artificial Intelligence model can be much improved as well by introducing Neural Networks in the system to imitate the learning process. It is possible to do so by adjusting the weights or probabilities. However, the problem with this implementation is that it is very hard to work with Integer values from 0 to 100, based on the fact the Floats are not allowed. A better class can be implemented with the ability to learn if the probability range will increase to a higher number, for example 10000. However, if finally this algorithm is implemented, then the pet is more likely to be disciplined and stay with the same states. To solve this problem, an extra process can be created to add some extra probability concept in the system to imitate real life more closely.



Bibliography [1] Polson Enterprises, (1997 - 2003), Recent Developments and Trends in Keychain Virtual pets URL: http://www.vir tualpet.com/vp/future/trends1a.htm [4th of May 2003] [2] Neopets, Inc, (1999 -2003), Neopets URL: http://www.neopets.com/ [3rd of September] [3] Qualcomm Incorporated, (2002 - 2003), About BREWTM URL: http://www.qualcomm.com/brew/about/aboutbrew.html [4th of May 2003] [4] Qualcomm Inc, (2002 - 2003), BREWTM and J2METM, A Complete Wireless Solution for

Operators Committed to JavaTM, White paper URL: http://www.qualcomm.com/brew/images/about/pdf/brew_j2me.pdf [4th of May

2003] [5] Kylas Group LLC, (2003), Welcome To LearnMobile.Net URL: http://www.learnmobile.net/dDefault.aspx [4th of May 2003] [6] Microsoft Corporation, (2003), Mobile Development with Asp.NET URL: http://msdn.microsoft.com/vstudio/device/mobilecontrols/default.aspx [4th of May

2003] [7] DEVBUZZ.COM, Inc, (2000 – 2003), Mobilizing with .NET – An Introduction and case study

overview URL: http://www.devbuzz.com/content/zinc_dotnet_going_mobile_pg1.asp [4th of May

2003] [8] Microsoft Corporation, (2003), Tested Devices URL: http://msdn.microsoft.com/vstudio/device/mobilecontrols/devices.aspx [4th of May

2003] [9] Kim Topley, (2002), J2ME in a nutshell, A desktop Quick Reference, O’Reilly & Associates

Inc., [10] Wireless Systems Design, Novermber 2002, John Blyler, Java Faces Competition From Brew

And .NET URL: http://www.wsdmag.com/Articles/Index.cfm?Ar ticleID=19051& Extension=pdf [4th of May

2003] [11] Sun Microsystems, Inc, (1995 - 2003), J2ME devices URL: http://wireless.java.sun.com/device [4th of May 2003] [12] Nokia, (2003), Phone Models: Europe, Africa, Middle East URL: http://www.nokia.com/nokia/0,5184,73,00.html [4th of May 2003] [13] Christopher G. Langton, (1997), Artificial L ife, An Overview [14] R. Gregory Taylor, (1998), Models Of Computation and Formal Languages



[15] Dr. Andy Bulpitt, (2003) , PSS Lecture notes [16] L.J. Landau and J.G. Taylor, (1998), Concepts for Neural Networks, A Survey [17] Georgios Paliouras, Vangelis Karkaletsis, Constantine D. Spyropoulos, (), Mahcine

Learning And I ts Applications, Advanced Lectures [18] Sun Microsystems, Inc, (1994 - 2003), Sun ONE Studio 4 update 1, Mobile Edition URL: http://wwws.sun.com/software/sundev/jde/studio_me/index.html [30th of August

2003] [19] Sun Microsystems, Inc, (1995 - 2003), What’s New in MIDP 2.0 URL: http://wireless.java.sun.com/midp/ar ticles/midp20/ [30th of August] [20] Roger S.Pressman, (1997), Software Engineer ing, A Practitioner’s Approach, 4th Edition [21] Sun Microsystems, Inc, (1999 - 2003), MID Profile API Documentation (provided with the

Wireless Toolkit) [22] Sun Microsystems, Inc, (1999 - 2003), User Guide (provided with the Wireless Toolkit) [23] Neopets Instructions, (2003), TIGER Electronics (provided with the Neopets game)



Appendix A: Personal Reflection This project has been as interesting experience for me because it deals with many areas of computing that I had no any knowledge about. The MSc Information Systems course has helped me with the initial stages of the project such as identifying the methodology and creating class diagrams. That was a good experience because it really helped later in work to have this class diagram as a rough example and it made it easier to implement the methods as well because I already knew even if approximately the classes responsibilities. The research and background reading was interesting but it was hard to find some information about other applications that create mobile applications and to understand they are difference. Moreover, the artificial life and artificial intelligence area was new for me, however, I later realised that some of the information I have learned in the computer science. This experience though made me actually realise what the models of computation can be used for, whereas it is sometimes very hard to understand the theory without actual practice. Things like neural networks are new for me and genetic algorithms have appeared to be very fascinating and I have realised that initially I was trying to implement the neural networks as well without good knowledge about them at that time. Articles found on the scientific website about AI and A-Life contained many information about robots, different types of viruses and other form of Artificial Life, that were not useful as such but fascinating. The actual leaning of the J2ME started when the Wireless Toolkit has been installed and I have started learning about MIDlets and trying examples from the books and examples provided by the toolkit. With some time I have realised that there are some similarities between graphical methods in J2ME and J2SE that I used before. However, the differences were quite significant as well. Implementation of the game took a long amount of time because it was hard to understand what is happening at the start; however, as time went by I have become more familiar with the uses of this or that class. Some of the skills that have been enhanced in the development of this project was an ability to draw cats in many different positions and types either on plain paper or on the screen of the computer on the pixel by pixel basis. Overall, it was a good experience with lots of learning that was very interesting and some fun during the cat’s development process.



Appendix B: Project Objectives and Deliverables Form



Appendix C: Marking Scheme and Inter im Repor t comments



Appendix D: Diagrams 1st Class Diagram:

Health

stateofHealthstateofActivity

giveMedicine()giveFood()takeToBed()Clean()getHealth()

Stats

Sc oreAgeWeightHealthHungerHappiness

calc ulat eScore()calc ulat eWeight ()

Clock

yeardayhoursmin

getAge()calculateAge()getHours()getMin()

Character

typeweightagehealthhappiness

changeCharacter()changeHealth()changeActivity()changeHappiness()playWithPet()

Pet

nametype

Alert

message

getAlert()

Collaboration Diagram 1: Check Pet Statistics

: General public : MainScreen

: MainScreen

: Stats : CharacterControl

: Character : AgeClock

1: CheckStats()2: getStats() 3: checkGeneralInfo()

5: displayResults()4: getCharacter()6: getAge()

Collaboration Diagram 2: Tell Pet to Sleep



: General public : MainScreen : CharacterControl : Character

1: Swi tchOffLight () 2: Check Sleepnes s() 3: UpdateCharacter()

Collaboration Diagram 3: Play With Pet

: General public : MainScreen : CharacterCont rol : Character

1: PlayWithPet() 2: CheckPlay() 3: UpdateCharacter()

Collaboration Diagram 4: Keep Pet Healthy


1: giveMedicine()2: checkMedicineTime()

3: UpdateCharacter()

Collaboration Diagram 5: Feed the Pet

: General public : MainScreen : Character : CharacterControl

1: FeedPet() 2: CheckHunger() 3: UpdateCharacter()

Collaboration Diagram 6: Keep Pet Clean


1: CleanPlace() 2: DeleteTrash() 3: UpdateCharacter()

Collaboration Diagram 7: Display Alerts in Crucial Stages

: General public : MainScreen : CharacterControl : Character : Alert

1: dis play Alert() 3: getAlert() 2: getCharacter()4: CheckProblems()

Final class diagram:



V iP e t s

d i s p l a y

s t a r t A p p ( )g e t D i s p la y ( )p a u s e A p p ( )d e s t r o y A p p ( )e x i t ( )

( f r o m U se C a se V i e w )

< < c o n t r o l> >

In t r o

g a m efo r m

In t r o ( )

( f ro m U se C a se V i e w )

< < b o u n d a r y > > C a t S t o r e

c c

C a t S t o r e ( )g e t C C ( )w r i t e T o S t o r e ( )r e a d S t o r e ( )

( f r o m U se C a se V i e w )

< < c o n tr o l> >

S t a r t F o r m

g a m efo r mp l a y C o m m a n da b o u t C o m m a n de x i t C o m m a n dc o n t i n u e C o m m a n de x i t C a n va s C o m m a n de x i t P a u s e C o m m a n dc a n va sl i s t e n e rp l a ys c o r e S c r e e nc ca l e r t H e l pa l e r t A b o u tc s

S t a r t F o r m ( )s e t C o m m a n d L is t e n e r ( )h e l p ( )a b o u t ( )r e a d S t o r e ( )c o m m a n d A c t io n ( )

( f ro m U se C a se V i e w )

< < b o u n d a r y > >

C h a r a c t e r C o n t r o l

s t a t er a n g es i z e O fR a n g eh u n g e rc h a n g e H u n g e r R a t ec h a n g e F e e d R a t em a x H u n g e rw e ig h tm a x W e i g h ts i c ki s S i c km a x S i c kh e a l t hm a x H e a l t ha g em e s s a g e

C h a r a c t e r C o n t r o l ( )g e t W e i g h t ( )s e t W e i g h t ( )g e t M a x W e i g h t ( )s e t M a x W e i g h t ( )g e t W e i g h t T y p e ( )g e t H u n g e r ( )s e t H u n g e r ( )g e t M a x H u n g e r ( )s e t M a x H u n g e r ( )g e t C h a n g e H u n g e r R a t e ( )s e t C h a n g e H u n g e r R a t e ( )g e t C h a n g e F e e d R a t e ( )s e t C h a n g e F e e d R a t e ( )s e t S i c k ( )g e t S i c k ( )s e t Is S i c k ( )i s S i c k ( )g e t M a x S i c k ( )s e t M a x S i c k ( )g e t H e a l t h ( )s e t H e a l t h ( )g e t M a x H e a l t h ( )s e t M a x H e a l t h ( )g e t A g e ( )g e t A g e L o n g ( )s e t A g e ( )r a n g e ( )s e t R a n g e A t ( )s e t B o u n d a r y ( )g e t R a n g e E l e m e n t A t ( )g e t R a n g e ( )s e t S t a t e ( )s e t R a n g e F o r ( )s e t M i n i m u m R a n g e A t ( )s e t M a x im u m R a n g e A t ( )g e t M e s s a g e ( )s e t M e s s a g e ( )i s D e a d ( )

( f r o m U se C a s e V i e w )

< < c o n t r o l > >V i P e ts C a n v a s

w i d t hh e i g h tr u n n i n gr u n n i n g 2s t o pd is p la yd a m es p r i t es p r i t e S l e e ps p r i t e P l a ys p r i t e F o o ds p r i t e T o i l e ts p r i t e M e d ic i n es p r i t e T ra s hs p r i t e D e a t hs p r i t e S i c ks e q u e n c es e q u e n c e 2s e q u e n c e S le e ps e q u e n c e S le e p 2s e q u e n c e P la ys e q u e n c e P la y 2s e q u e n c e F o o ds e q u e n c e F o o d 2s e q u e n c e M e d i c i n es e q u e n c e M e d i c i n e 2s e q u e n c e D e a t hs e q u e n c e D e a t h 2s e q u e n c e S ic ks e q u e n c e S ic k 2gt i m et o t a l A g ec u rc u r o s Xc u r s o r Yp o s i t i o nxyc cim a g e T r a s ht r a s hd e l a ys e l e c tr a n d o m S e l e c tr a n d o m D e l a ym a xs t a t et h r e a dc t h r e a d

V i P e t s C a n va s ( )s t a r t ( )s t o p ( )c h e c k R u l e s ( )a d j u s tR u l e s ( )r e s t r i c t R a n d o m ( )k e y P r e s s e d ( )g e t S c o r e s ( )in i t ( )p a i n t ( )c a t ( )c a t S l e e p ( )c a t P l a y ( )c a t F o o d ()c a t T o il e t ( )c a t M e d i c in e ( )c a t T r a s h ( )c a t D e a t h ( )c a t S i c k ( )c u r s o r ( )fo o d Ic o n ( )s t a t s Ic o n ( )h e a l t h I c o n ( )l i g h t Ic o n ( )p la y Ic o n ( )c le a n Ic o n ( )g e t P o s i t iv e R a n d o m ( )g e t M i n ()c h a n g e S u m m e r Ti m e ( )s e t S t a t e ( )s e t S t o p ( )g e t S t o p ( )

(f ro m U s e C a se V i e w )

< < b o u n d a r y > >



Appendix E: Drawing of Cats

Cat 1 (0% of Votes):

Cat 2 (21.7% of Votes):










Appendix F: A Sample Questionnaire

Questionnaire

1. Would you like to have this game on your mobile phone? It is a must [ ] Most probably [ ] Not sure [ ] Do not think that is for me [ ] Do not like it at all [ ] 2. Are you satisfied with the functionality of the game? Very satisfied [ ] Satisfied [ ] Indifferent [ ] Not satisfied [ ] Very unsatisfied [ ] 3. Are you satisfied with the graphics of this game? Very satisfied [ ] Satisfied [ ] Indifferent [ ] Not satisfied [ ] Very unsatisfied [ ] 4. The pet’s behaviour patterns are realistic. Strongly agree [ ] Agree [ ] Not sure [ ] Disagree [ ] Strongly disagree [ ] 5. It is straightforward to play this game. Strongly agree [ ] Agree [ ] Indifferent [ ] Disagree [ ] Strongly disagree [ ] 6. If you have any other comments please write them here:

mobile tamagotchi game - university of leeds · mobile tamagotchi game anna ivanova msc in...

Documents