Mobile Tamagotchi Game

Transcription

Mobile Tamagotchi Game
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) ________________________
Mobile Tamagotchi Game
Summar y
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
i
Mobile Tamagotchi Game
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
ii
Mobile Tamagotchi Game
Table of Contents
SUMMARY ................................................................................................................... I
ACKNOWLEDGEMENTS ..........................................................................................II
TABLE OF CONTENTS ............................................................................................ III
1. INTRODUCTION..................................................................................................... 1
1.1 STRUCTURE OF THE P ROJ ECT ...................................................................................................1
2 RESEARCH ............................................................................................................... 2
2.1 ALTERNATIVE TO J 2ME............................................................................................................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 M OBILE P HONES T HAT SUPPORT J AVATM ................................................................................6
2.3 H ISTORY AND F UNCTIONALITY 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 PROJ ECT .........................................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
iii
Mobile Tamagotchi Game
5.2.2 Questionnaire ....................................................................................................................32
6. PROJECT MANAGEMENT .................................................................................. 34
6.1 I NITIAL SCHEDULE ..................................................................................................................34
6.2 ACTUAL SCHEDULE .................................................................................................................34
7. CONCLUSION AND FUTURE WORK ............................................................... 37
7.1 C ONCLUSION ............................................................................................................................37
7.2 F UTURE W ORK ........................................................................................................................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
iv
Mobile Tamagotchi Game
1. Intr oduction
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 Str uctur e of the Pr oject
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,
Anna Ivanova
MSc in Information Systems
1
Mobile Tamagotchi Game
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 Resear ch
2.1 Alter native to J 2ME
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.
Anna Ivanova
MSc in Information Systems
2
Mobile Tamagotchi Game
Figur e 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.
Anna Ivanova
MSc in Information Systems
3
Mobile Tamagotchi Game
Figur e 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.
Figur e 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].
Anna Ivanova
MSc in Information Systems
4
Mobile Tamagotchi Game
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 12345 and 637829 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.
Figur e 2.1.4: J 2ME configur ations and pr ofiles
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].
Anna Ivanova
MSc in Information Systems
5
Mobile Tamagotchi Game
2.2 Mobile Phones That Suppor t J ava TM
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.
Anna Ivanova
MSc in Information Systems
6
Mobile Tamagotchi Game
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
Anna Ivanova
MSc in Information Systems
7
Mobile Tamagotchi Game
•
•
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
Anna Ivanova
MSc in Information Systems
8
Mobile Tamagotchi Game
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].
Figur e 2.5.1: State Diagr am
Source: R. Gregory Taylor, (1998), Models Of Computation and Formal Languages
Figur e 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
Anna Ivanova
MSc in Information Systems
9
Mobile Tamagotchi Game
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.
Figur e 2.5.3: Example of the Mar kov Model for a pet between age 3 and 15.
20
Sleep
30
20
20
30
20
30
Still
5
5
Play
25
30
30
0
25
30
0
5
10
20
25
Toilet
0
0
15
5
Sick
100
Anna Ivanova
MSc in Information Systems
10
Mobile Tamagotchi Game
Figur e 2.5.4: Hidden Mar kov Model
Play
Sleep
Food
Medicine
Mar kov
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.
Figur e 2.5.5: Connection between two neur ons
j
Wij
i
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
Anna Ivanova
MSc in Information Systems
11
Mobile Tamagotchi Game
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.
Figur e 2.5.6: Feedfor war d neur al networ k
Hidden layer
Output layer
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.
Anna Ivanova
MSc in Information Systems
12
Mobile Tamagotchi Game
Figur e 2.5.7: Recur r ent Networ ks
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.
Anna Ivanova
MSc in Information Systems
13
Mobile Tamagotchi Game
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 pr oject
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.
Anna Ivanova
MSc in Information Systems
14
Mobile Tamagotchi Game
Figur e 3.2.1: Incr emental 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.
Anna Ivanova
MSc in Information Systems
15
Mobile Tamagotchi Game
Use Case diagram:
Tamagotchi Game
Feed the pet
General publi c
Clean after i t
Tell him to sleep
Keep i t healthy
Play with it
Check pet's stats
get alerts in crucia l stage s
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.
Anna Ivanova
MSc in Information Systems
16
Mobile Tamagotchi Game
Class Diagram:
<<enti ty >>
Stats
(from Use Case Vi ew)
Score
<<boundary>>
Mai nScreen
getStats()
calculateScore()
(fro m Use Case Vi ew)
displayAlert()
CleanPlace()
FeedPet()
giveMedicine()
PlayW ithPet()
SwitchOffLight()
checkStats()
DisplayResults()
<<entity>>
Alert
<<control>>
CharacterControl
(from Use Case Vi ew)
checkProblems()
deleteTrash()
checkHunger()
checkMedicineTime()
CheckPlay()
CheckSleepness()
checkGeneralInfo()
(fro m Use Case Vi ew)
<<entity>>
Character
(from Use Ca se View)
ge tCharacte r()
Upda teCharact er()
<<entity>>
AgeClock
message
(from Use Case Vi ew)
getAlert()
age
day
year
hours
mins
getAge()
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.
Anna Ivanova
MSc in Information Systems
17
Mobile Tamagotchi Game
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 J 2ME 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.
Figur e 4.1.1: J 2ME Wir eless 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
Anna Ivanova
MSc in Information Systems
18
Mobile Tamagotchi Game
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.
•
For m class
The Form class is responsible for displaying the objects on the screen. For example, images, readonly 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
Anna Ivanova
MSc in Information Systems
19
Mobile Tamagotchi Game
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).
•
Thr eads 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
. . .
}
Anna Ivanova
MSc in Information Systems
20
Mobile Tamagotchi Game
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) {
// some code
}
// left key
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
Anna Ivanova
MSc in Information Systems
21
Mobile Tamagotchi Game
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.
Figur e 4.1.2: Spr ites animation
The frames though need to be changed manually
previousFrame() or setFrame(int) methods.
by
calling
nextFrame(),
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.
•
Recor dStor e 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.
Anna Ivanova
MSc in Information Systems
22
Mobile Tamagotchi Game
•
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().
•
Intr o.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 tFor m.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.
Anna Ivanova
MSc in Information Systems
23
Mobile Tamagotchi Game
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
Anna Ivanova
MSc in Information Systems
24
Mobile Tamagotchi Game
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
Anna Ivanova
MSc in Information Systems
25
Mobile Tamagotchi Game
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.
• Char acter Contr ol.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.
•
CatStor e.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 Scr eenshots
Some sample screenshots are shown below to show the different screen stages for different classes.
Anna Ivanova
MSc in Information Systems
26
Mobile Tamagotchi Game
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
Anna Ivanova
MSc in Information Systems
27
Mobile Tamagotchi Game
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.
2.
3.
4.
5.
6.
7.
8.
9.
The game does not crash when it runs for at least half an hour.
The game works when the user exits the main game and starts again.
The game works when the user pauses the game.
The game works when the pet dies and user starts the game again.
All commands are working and the graphics actually represent the commands.
Statistics represent the actual information about the pet.
The states are changing without user interference.
The cursor reflects the actual button pressing on the phone by the user.
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.
Anna Ivanova
MSc in Information Systems
28
Mobile Tamagotchi Game
Figur e 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
Anna Ivanova
MSc in Information Systems
29
Mobile Tamagotchi Game
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.
Figur e 5.2.1: NeoPets game
Source: http://www.littlewoodsindex.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.
Anna Ivanova
MSc in Information Systems
30
Mobile Tamagotchi Game
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.
•
Gr aphics
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
Anna Ivanova
MSc in Information Systems
31
Mobile Tamagotchi Game
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:
Diagr am 1:
Diagr am 2:
Anna Ivanova
MSc in Information Systems
32
Mobile Tamagotchi Game
Diagr am 3:
Diagr am 4:
The pet's behaviour patterns are realistic
Strongly
disagree Strongly agree
Not sure Disagree
0%
0%
10%
10%
Agree
80%
Anna Ivanova
MSc in Information Systems
33
Mobile Tamagotchi Game
Diagr am 5:
It is straightforw ard to play this gam e.
Strongly
disagree
Indifferent
Disagree
Strongly agree
Agree
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. Pr oject 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
Anna Ivanova
MSc in Information Systems
34
Mobile Tamagotchi Game
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.
Anna Ivanova
MSc in Information Systems
35
Mobile Tamagotchi Game
Figur e 6.1: Initial Pr oject schedule
Tasks
6thJ une
13thJ une
13thJ une
20thJ une
20thJ une
27th J une
27thJ une
18thJ uly
18thJ uly
25thJ uly
25thJ uly 1st Aug
1st Aug 8th Aug
8thAug 15thAug
15thAug 22nd Aug
22nd Aug
29th Aug
29thAug
5th Sep
6thJ une
13thJ une
13thJ une
20thJ une
20thJ une
27th J une
27thJ une
18thJ uly
18thJ uly
25thJ uly
25thJ uly 1st Aug
1st Aug 8th Aug
8thAug 15thAug
15thAug 22nd Aug
22nd Aug
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
Figur e 6.2: Actual Pr oject Schedule
Tasks
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
Anna Ivanova
MSc in Information Systems
36
Mobile Tamagotchi Game
7. Conclusion and Futur e Wor k
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 Futur e Wor k
7.2.1 F uture 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.
Anna Ivanova
MSc in Information Systems
37
Mobile Tamagotchi Game
7.2.2 MIDlet impr ovements
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 Pr obability 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 Futur e of Neur al Networ ks
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.
Anna Ivanova
MSc in Information Systems
38
Mobile Tamagotchi Game
Bibliogr aphy
[1] Polson Enterprises, (1997 - 2003), Recent Developments and Trends in Keychain
Virtual pets
URL: http://www.vir tualpet.com/vp/futur e/tr ends1a.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/br ew/about/aboutbr ew.html [4th of May 2003]
[4]
Qualcomm Inc, (2002 - 2003), BREWTM and J2METM, A Complete Wireless Solution for
Operators Committed to Java TM, White paper
URL: http://www.qualcomm.com/br ew/images/about/pdf/br ew_j2me.pdf [4th of May
2003]
[5]
Kylas Group LLC, (2003), Welcome To LearnMobile.Net
URL: http://www.lear nmobile.net/dDefault.aspx [4th of May 2003]
[6] Microsoft Corporation, (2003), Mobile Development with Asp.NET
URL: http://msdn.micr osoft.com/vstudio/device/mobilecontr ols/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.micr osoft.com/vstudio/device/mobilecontr ols/devices.aspx [4th of May
2003]
[9] Kim Topley, (2002), J 2ME 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/Ar ticles/Index.cfm?Ar ticleID=19051&Extension=pdf [4th of May
2003]
[11] Sun Microsystems, Inc, (1995 - 2003), J2ME devices
URL: http://wir eless.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), Ar tificial Life, An Overview
[14] R. Gregory Taylor, (1998), Models Of Computation and For mal Languages
Anna Ivanova
MSc in Information Systems
39
Mobile Tamagotchi Game
[15] Dr. Andy Bulpitt, (2003) , PSS Lecture notes
[16] L.J. Landau and J.G. Taylor, (1998), Concepts for Neur al Networ ks, A Survey
[17] Georgios Paliouras, Vangelis Karkaletsis, Constantine D. Spyropoulos, (), Mahcine
Lear ning And Its Applications, Advanced Lectures
[18] Sun Microsystems, Inc, (1994 - 2003), Sun ONE Studio 4 update 1, Mobile Edition
URL: http://wwws.sun.com/softwar e/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://wir eless.java.sun.com/midp/ar ticles/midp20/ [30th of August]
[20] Roger S.Pressman, (1997), Softwar e 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)
Anna Ivanova
MSc in Information Systems
40
Mobile Tamagotchi Game
Appendix A: Per sonal 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.
Anna Ivanova
MSc in Information Systems
41
Mobile Tamagotchi Game
Appendix B: Pr oject Objectives and Deliver ables For m
Anna Ivanova
MSc in Information Systems
42
Mobile Tamagotchi Game
Appendix C: Mar king Scheme and Inter im Repor t comments
Anna Ivanova
MSc in Information Systems
43
Mobile Tamagotchi Game
Anna Ivanova
MSc in Information Systems
44
Mobile Tamagotchi Game
Appendix D: Diagr ams
1st Class Diagram:
Alert
message
getAlert()
Stats
Sc ore
Age
W eight
Healt h
Hunger
Happine ss
Clock
year
day
hours
min
Pet
name
type
getAge()
calculateAge()
getHours()
getMin()
calc ulat eScore()
calc ulat eWeight ()
Character
type
weight
age
health
happiness
changeCharacter()
changeHealth()
changeActivity()
changeHappiness()
playW ithPet()
Health
stateofHealth
stateofActivity
giveMedicine()
giveFood()
takeToBed()
Clean()
getHealth()
Collaboration Diagram 1: Check Pet Statistics
2: getStats()
1: CheckStats()
: General public
: MainScreen
: Stats
4: getCharacter()
6: getAge()
: AgeClock
3: checkGeneralInfo()
: CharacterControl
5: displayResults()
: Character
: MainScreen
Collaboration Diagram 2: Tell Pet to Sleep
Anna Ivanova
MSc in Information Systems
45
Mobile Tamagotchi Game
1: Swi tchOffLight ()
2: Check Sleepnes s()
: MainScreen
: General p ublic
3: UpdateCharacter()
: Ch aracter
: CharacterControl
Collaboration Diagram 3: Play With Pet
2: CheckPlay()
1: PlayW ithPet()
: MainScreen
: General public
3: UpdateCharacter()
: Character
: CharacterCont rol
Collaboration Diagram 4: Keep Pet Healthy
2: checkMedicineTime()
1: giveMedicine ()
: MainScreen
: General public
3: UpdateCharacter()
: Character
: CharacterControl
Collaboration Diagram 5: Feed the Pet
1: FeedPet()
: General public
2: CheckHunger()
: MainScreen
3: UpdateCharacter()
: Character
: CharacterControl
Collaboration Diagram 6: Keep Pet Clean
1: CleanPl ace()
: General public
2: Delete Trash()
: MainScreen
3: UpdateCharacter()
: Character
: CharacterControl
Collaboration Diagram 7: Display Alerts in Crucial Stages
1: dis play Al ert()
: General public
3: getAlert()
: MainScreen
4: CheckProblems()
: Alert
2: getCharacte r()
: CharacterControl
: Character
Final class diagram:
Anna Ivanova
MSc in Information Systems
46
Mobile Tamagotchi Game
< < b o u n da r y > >
V i P e ts C a n v a s
(f ro m U s e C a se V i e w )
w id t h
h e ig h t
ru n n ing
ru n n ing 2
s top
d i s p la y
dam e
s p rit e
s p rit e S lee p
s p rit e P lay
s p rit e F o o d
s p rit e T o ile t
s p rit e M e d ic in e
s p r i t e T ra s h
s p rit e D e a t h
s p rit e S ic k
s e q u en c e
s e q u en c e 2
s e q u e n c e S le e p
s e q u e n c e S le e p 2
s e q u e n c e P la y
s e q u e n c e P la y 2
s e q u en c e F o o d
s e q u en c e F o o d 2
s e q u en c e M e d ic in e
s e q u en c e M e d ic in e 2
s e q u en c e D e a th
s e q u en c e D e a th2
s e q u e n c e S ic k
s e q u e n c e S ic k 2
g
t im e
t o t a lA g e
c ur
c u ro s X
c u rs o rY
p o s it io n
x
y
cc
im a g e T ra s h
t ra s h
d e la y
s e le c t
ra n d o m S e le c t
ra n d o m D e la y
m ax
s tate
t h re a d
c t h re a d
< < c o n t ro l> >
V iP e t s
(f ro m
U se C a se V i e w )
d is p la y
s t a rt A p p ()
g e t D is p la y ()
p a u s e A p p ()
d e s t ro y A p p ()
e x it ()
< < b o u n d a ry > >
In t r o
( f ro m
U se C a se V i e w )
gam e
fo r m
< < c o n tr o l> >
C a t S t o re
(f ro m
U se C a se V i e w )
cc
C a t S t o re ()
g e tC C ()
w rit e T o S t o re ()
re a d S t o re ()
In t r o ( )
< < b o u n d a ry > >
S t a rt F o rm
( f ro m
U se C a se V i e w )
gam e
fo r m
p la y C o m m a n d
ab o u tC o m m a n d
e x it C o m m a n d
c o n t in u e C o m m a n d
e x i t C a n va s C o m m a n d
e x it P a u s e C o m m a n d
c a n va s
lis t e n e r
p la y
s c o re S c re e n
cc
a le rt H e lp
a le rt A b o u t
cs
S t a rt F o rm ()
s e t C o m m a n d L is t e n e r()
h e lp ()
a b o u t ()
re a d S t o re ()
c o m m a n d A c t io n ()
V i P e t s C a n va s ( )
s t a rt ()
s t o p ()
c h e c k R ul e s ()
a d j u s tR u l e s ( )
re s t ric t R a n d o m ()
k e y P re s s e d ()
g e t S c o re s ()
in it ()
p a in t ()
c a t ()
c a tS 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 ra s h ()
c a t D e a t h ()
c a t S i c k ()
c u rs o r()
fo o d Ic o n ( )
s t a t s Ic o n ( )
h e a lt hI c o n ()
l i g h t Ic o n ( )
p l a y Ic o n ( )
c l e 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 rTi m e ()
s e tS t a te ()
s e t S t o p ()
g e t S t o p ()
Anna Ivanova
MSc in Information Systems
< < c o n t ro l> >
C h a ra c t e rC o n t ro l
(fro m
U se C a s e V i e w )
s ta te
ra n g e
s i z e O fR a n g e
hunger
c h a n g e H u n g e rR a t e
c h a n ge F e e d R a te
m ax H unger
w e ig h t
m a x W e ig h t
s ic k
is S ic k
m a x S ic k
h e a lt h
m a x H e a lt h
age
m es s age
C h a ra c t e rC o n t ro l()
g e t W e ig h t ()
s e t W e ig h t ()
g e t M a x W e ig h t ()
s e t M a x W e ig h t ()
g e t W e ig 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 rR a t e ()
s e t C h a n g e H u n g e rR 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 ic k ()
g e t S ic k ()
s e t Is S i c k ( )
is S ic k ()
g e t M a x S ic k ()
s e t M a x S ic k ()
g e t H e a lt h ()
s e t H e a lt h ()
g e t M a x H e a lt h ()
s e t M a x H e a lt h ()
g e t A g e ()
g e t A g e L o n g ()
s e t A g e ()
ra n g e ()
s e t R a n g e A t ()
s e t B o u n d a ry ()
g e t R a n g e E le 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 in im 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 ()
is D e a d ()
47
Mobile Tamagotchi Game
Appendix E: Dr awing of Cats
Cat 1 (0% of Votes):
Cat 2 (21.7% of Votes):
Cat 3 (6.7% of Votes):
Cat 4 (5% of Votes):
Cat 5 (3.3% of Votes):
Cat 6 (1.7% of Votes):
Cat 7 (1.7% of Votes):
Cat 8 (0% of Votes):
Cat 9 (0% of Votes):
Anna Ivanova
MSc in Information Systems
48
Mobile Tamagotchi Game
Cat 10 (6.7% of Votes):
Cat 11 (3.3% of Votes):
Cat 12 (5% of Votes):
Cat 13 (1.7% of Votes):
Cat 14 (1.7% of Votes):
Cat 15 (0% of Votes):
Cat 16 (6.7% of Votes):
Cat 17 (18.3% of Votes):
Cat 18 (3.3% of Votes):
Cat 19 (0% of Votes):
Cat 20 (0% of Votes):
Cat 21 (3.3% of Votes):
Anna Ivanova
MSc in Information Systems
49
Mobile Tamagotchi Game
Cat 22 (0% of Votes):
Cat 23 (1.7% of Votes):
Cat 24 (3.3% of Votes):
Cat 25 (3.3% of Votes):
Cat 26 (1.7% of Votes):
Cat 27 (0% of Votes):
Anna Ivanova
MSc in Information Systems
50
Mobile Tamagotchi Game
Appendix F: A Sample Questionnair e
Questionnair e
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:
Anna Ivanova
MSc in Information Systems
51