Docstoc

Abstract

Document Sample
Abstract Powered By Docstoc
					C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




Abstract
This report is going to discuss the process of building a game with a mobile phone as
the target device. The report will deal with all the aspects that have been involved in
the process of creating a game, from the first ideas to the final product. Some parts
of the process are of more importance than others in accordance to the Computer
Games course, among these parts are subjects such as the implementation and the
use of artificial intelligence (AI).


AI is a theme that will be discussed thoroughly in this report, not only in accordance
to the game itself but also as an independent theme. We will discuss some of the
different type of AI, such as agents, flocking, neural networks and pathfinding
algorithms. These are often used in computer games and we will investigate how
they can be used in games for mobile devices. Pseudo code is used to show how the
different types of AI could be incorporated into the CyberTank3000 game.


We have concluded that AI in right the context can be used to enhance the game
play on mobile phones.




                                                                                                       1
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




Foreword
Before reading this report, we would like to draw your attention to a few instructions
for reading the report.


Quotations will be presented in italics with indentation. References will be made
using numbered brackets [] within the text. On the attached cd-rom, please review
the ReadMe file for content information.


When playing our game CyberTank3000 on the attached emulator, small artifacts
may appear unintentionally. It should be noted that these do not appear when
playing on the N-Gage mobile target device.


Anders Bo Pedersen, 20030033




Mads Nørgaard, 20023199




Jesper Mouritzen, 20023188




Per Christensen, 20023183




Allan Kay, 20030210




                                                                                                       2
 C YB E R TA N K 3 0 0 0       |   C O M P U T E R     G A M E S    S P R I N G    2 0 0 4    |   GR O U P    7




1 Index
Abstract........................................................................................................ 1
Foreword ...................................................................................................... 2
1 Index ........................................................................................................ 3
2 Introductions .............................................................................................. 5
   2.1 AI and the narrative structure ................................................................. 5
   2.2 A shot ’em up game. But why? ................................................................ 6
   2.3 Game Background ................................................................................. 7
3 Theme exploration....................................................................................... 9
   3.1 Why the AI theme?................................................................................ 9
   3.2 Game AI’s evolution .............................................................................. 9
4 Problem Statement.....................................................................................12
   4.1 System definition .................................................................................12
   4.2 Problem Definition ................................................................................13
   4.3 Project Limitations................................................................................14
   4.4 Project Goals .......................................................................................14
5 Building the game ......................................................................................15
   5.1 Building the architecture of the application...............................................15
   5.2 Implementation ...................................................................................18
   5.3 Testing and optimization .......................................................................19
   5.4 Deployment and target devices ..............................................................21
   5.5 Software used......................................................................................21
   5.6 Final testing and User Feedback .............................................................22
6 AI in games...............................................................................................24
   6.1 What is AI in Games?............................................................................24
   6.2 Agents................................................................................................24
   6.3 Flocking ..............................................................................................27
   6.4 Pathfinding ..........................................................................................29
   6.5 Neural networks...................................................................................33
7 AI’s affect on the narrative structure .............................................................35
   7.1 AI at present time ................................................................................36
   7.2 Autonomous AI ....................................................................................37
8 Technical discussions ..................................................................................39
   8.1 API’s used in the game..........................................................................39


                                                                                                                  3
C YB E R TA N K 3 0 0 0        |   C O M P U T E R    G A M E S    S P R I N G    2 0 0 4   |   GR O U P    7



      8.1.1 MIDP (Mobile Information Device Profile) ...........................................39
      8.1.2 Nokia UI API..................................................................................40
      8.1.3 The Mobile Media API ......................................................................41
   8.2 Game HCI ...........................................................................................42
   8.3 Game AI .............................................................................................44
      8.3.1 Alien Aim .....................................................................................44
      8.3.2 Homing Missiles .............................................................................45
      8.3.3 Boss Laser ....................................................................................46
9 Marketing..................................................................................................49
   9.1 Cyber tank marketing ...........................................................................49
   9.2 Game comparisons ...............................................................................50
   9.3 Graphics .............................................................................................52
   9.4 Sounds ...............................................................................................54
   9.5 Target audience ...................................................................................55
10 Future improvements ................................................................................56
   10.1 Possible extensions & improvements .....................................................56
   10.2 Further AI .........................................................................................57
11 Conclusions .............................................................................................59
12 References ..............................................................................................61
13 Litterature ...............................................................................................63
14 Code............................................................. Error! Bookmark not defined.
   14.1 Execute.java ............................................ Error! Bookmark not defined.
   14.2 SplashScreen.java .................................... Error! Bookmark not defined.
   14.3 CountDown.java ....................................... Error! Bookmark not defined.
   14.4 MainMenuScreen.java ............................... Error! Bookmark not defined.
   14.5 AboutScreen.java ..................................... Error! Bookmark not defined.
   14.6 HelpScreen.java ....................................... Error! Bookmark not defined.
   14.7 GameCanvas.java..................................... Error! Bookmark not defined.




                                                                                                                4
C YB E R TA N K 3 0 0 0     |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




2 Introductions


2.1 AI and the narrative structure

Aristotle’s stated in his Poetics [1] that a story in its whole should have a beginning,
middle, and an ending, told in that exact order. What Aristotle’s stated back then is
still used in storytelling today as well as in film productions.


Scientists has analyzed and described this storytelling pattern and made a
storytelling model. In the film industry this model is known as the Hollywood model.
The model is divided into 7 parts where each part has its own function in the
combined plot. [2]




Fig. 1 Hollywood narrative model


To some extent, this model has been used in conjunction with computer game
production, but with the increasing use of AI in games, can this model still be used?


It should be noted that this model is only used in this report as an example of the
narrative structure in games. There are many different opinions on how to analyze a
computer game’s narrative theory, as Jesper Juul states [3]:


        Brenda Laurel has tried to describe the computer with terms from dramaturgy (1991),
        Theodor Nelson has proposed we should examine computers like we’d examine movies
        (1990), Peter Bøgh Andersen has tried to apply semiotics (1990), George P. Landow



                                                                                                         5
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



       has used poststructuralist literary theory (1992, 1997). All of these initially assume a
       correspondence between their theory and the new field of study.


In his thesis, Jesper Juul seeks not only to find similarities but also the differences
from his own field in literary theory compared to computer games. In this paper we
have no intention of favoring one analytical approach over another. The narrative
structure model is merely used to analyze how AI influences the narrative in games.


This report is going to take a look at AI used in games today, and as already stated
analyze what effect it has on the story in games. The different types of AI is
expanding and evolving. This paper will focus on the use of agents, neural networks
and search algorithms. Finally we will discuss autonomous AI and the impact it will
have on how a narrative is structured.




2.2 A shot ’em up game. But why?

With a project theme of AI, the genre choice for the mobile game to be developed
should be obvious. A choice of adventure, role playing game (RPG) or strategy would
meet the obvious demands and allow the group to incorporate advanced AI and
narrative into our game idea. So why didn’t the choice fall on any of these? Before
commencing the brainstorm process for the game idea, the group realized important
points of notice. First of all, the entire group is first time J2ME™ programmers and
only one group member had prior Java™ programming experience. Secondly we
knew that today’s handheld units have their limitations. These limitations manifest
themselves in limited CPU speed, RAM and Human Computer Interaction (HCI)
possibilities, setting hardware boundaries for our creative development potential.
Third, the group had a certain perception of the consumer tendencies of the ‘mobile
player’. We had a belief that this segment doesn’t immerse itself in mobile games as
the ‘normal player’ does. Playing games only while e.g. waiting for the bus or taking
the train was the picture that we had of this consumer group.


The above observations led to three focus points regarding our game:
   •   Because of our limited programming skills a simple game was to be
       developed.




                                                                                                       6
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



   •   The game’s hardware demands should be limited based on the general limits
       of handheld device today.
   •   Great game play and simple HCI should be top prioritized all through the
       project since ‘mobile players’ aren’t loyal gamers.


With the above focus points in mind the group decided that the first obvious genre
choices would be too advanced projects. The choice therefore fell on the simplest
classical action based game type of them all; the shoot ‘em up. This genre lived up
to the points of focus and enabled a rich creative process as well. The
implementation of shoot ‘em ups have been done countless times by now and on the
surface don’t seem innovative at all. The group quickly came up with ideas that
would give the classical game structure a twist and motivate for the rest of the
development process [see Chap.4.1.1].


At this point the mobile development platform was defined as well. We chose the
Nokia N-Gage [4] mainly because of its high-level color depth (in mobile phone
terms), Joypad HCI ability and build-in Nokia Java classes. Despite the ‘first version’
flaws of the N-gage the group believes in the future of phone/game combo units and
therefore sees this choice as an investment in the future.




2.3 Game Background

With the game genre and mobile platform defined the game idea generation
commenced. Since game play was in focus, this phase took its offset in old Amiga
500 games [5]. One thing similar for the old games of the Amiga period is simple
HCI and great game play, just like we were looking for. Back then you only had one
‘fire’ button and one joystick, making the games very simple by HCI limitations,
often resulting in great games because of flat learning curves. The hardware specifics
of the Amiga platform also matched our chosen platform ensuring that it would be
possible to develop such games.


Old classics of the shoot ‘em up genre, was rediscovered on the internet and
replayed through PC emulators [6]. Games like Hybris [Fig.2], Battle Squardron
[Fig.3] and S.W.I.V [Fig.4] were our main source of inspiration. These are all 2D ‘top
down view’ games where you control a player avatar whose only mission is to



                                                                                                       7
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



destroy everything encountered. Simple and fun. The 3 games all use classic ‘tile
graphics’ level structure and ‘collision detection’ as presented in the Computer
Games classes. Hence we found making such a game a fathomable task.


The 3 games did differ on one point though. The game AI of the enemies really
evolves from the 1987 Hybris to the 1991 S.W.I.V. The group wasn’t completely sure
whether or not it would be able to implement AI features such as ‘homing missiles’,
‘aimed shots’ and ‘player centred movement’ but set off to do so.




Fig.2 Screendump from             Fig.3 Screendump from Battle            Fig.4 Screendump from
Hybris (1987)                     Squardron (1989)                        S.W.I.V (1991)


From the above research, the group developed a game idea with elements from each
of the games of inspiration and added new elements of our own imagination. This
resulted in the system definition [see 4.1.1] that would function as a work plan for
the ‘CyberTank 3000’ development for the rest of the project.




                                                                                                       8
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




3 Theme exploration

3.1 Why the AI theme?

With the resent success of AI in games, the AI industry has received more and more
acknowledgement. The implementation of AI in a game has evolved from being a last
minute rush job to whole departments working with the task of implementation AI in
game production. As a result of this AI in games are increasingly more used, and
also discussed more now then ever. (In the next subchapter AI’s evolution will be
discussed more thoroughly). When an area gets as much attention as AI gets at the
moment you are bound to see some amazing results. This group predicts that there
will be a “space race” between the game companies on the development of the
newest and most realistic AI in the forthcoming years. This issue is not only
interesting from a programmer’s point of view; it is also interesting to analyze the
affect AI has on narrative structure.


But back to the question: Why the AI theme? Well, during the initial development
process of the mobile game CyberTank 3000 many questions were addressed in
team discussions regarding the usage of AI in our game. These were questions like:
Is it really necessary with AI in a simple shoot ‘em up game? Is it even possible to
implement interesting AI on a game developed to a mobile phone? With the question
asked along with the statements written in the first paragraph, it was determined
that the AI theme would be an extremely interesting and relevant issue to dick
deeper into.




3.2 Game AI’s evolution

The field of computer Chess goes back to the early 1950s where mathematicians
proposed the basic search and evaluation strategies [7]. These strategies are still
used in chess games today, now known as decision trees or game trees. Decision
trees are similar to the conditions in the “if-then” statements. A typical game playing
program will use backtracking to move through this tree from the root node and find
the best possible solution to the problem at stack.



                                                                                                       9
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




The 1970s was the first decade of commercial video game development. It was also
here the first AI was designed for games like Pong and Space Invaders. These games
used a handful of very simple rules and scripted sequences of actions combined with
some random decision-making to make their behaviour less predictable (Rabin,
2002). Due to the lack of computing power in the video consoles, this was a rather
primitive form of AI.


A strategy game often needs far more than good graphics; hence this genre pushed
the AI development forward. Civilization is a good example where the computer
provides the Artificial Intelligence which determines the moves of the rival
civilizations. It is similar to the top chess computers like Deep Blue; you have to
figure out how the computer makes decisions if you want to have a chance of
beating it. [8] In the 1990s Real-time strategy games (RTS) hit the market. Games
like Warcraft and Age of Empires demanded even greater AI, because of the need to
perform movement for hundreds of computer controlled enemies at a time.


Today, more and more developers incorporate Artificial Life (A-Life) in their games.
A-Life strives to get computers to simulate the practices of nature accurately. By
looking at algorithms that imitates nature, an accurate simulation of for instance bird
flocks could be created. [9]


Machine learning technologies are anticipated to be one of the most important
advances to be made in game AI. A game like Black and White features techniques
where the characters adapt and learn through the experiences happening in the
game.


The primitive form of AI we saw back in the 1970s can in some cases still be
appropriate, when for instance (as in our case) creating games for a mobile phone.
The mobile phone lacks computer power just as the old game consoles did. Hence
there is no idea in over-engineering your code for mobile games or as Einstein said:


        Everything should be made as simple as possible, but not simpler. - Albert Einstein
        (Minsky, 85)




                                                                                                   10
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



This little part of history is given as an introduction to some of the issues that is
going to be discussed during this report. It should be noted that there are numerous
other milestones not mentioned here in the evolution of AI, but to keep the focus on
the themes of this report, they are not include here.




                                                                                                   11
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




4 Problem Statement
This chapter will define the problems, limitations and goals of our project.


4.1 System definition

This group’s task is to develop a mobile game for the Nokia N-Gage mobile phone.


The game idea:
Cyber Tank 3000 is set in space with alien enemies attacking an earthly orbital
station defended by the player in the shape of a cyber tank.


System requirements


   •   The scene should be able to scroll vertically down the display at a specified
       speed. It should also scroll horizontally when the player avatar draws near
       the edges of the screen.


   •   The player avatar should be able to move in all 8 directions. The gun tower
       should have a similar shooting angle and when a certain key is pressed the
       tower should stay in the specific direction although the unit moves in another
       direction. The gun can shoot projectiles at enemy units and obstacles.


   •   The player avatars lifespan should be measured by an energy bar displayed
       on the screen. When this is exhausted the game is over.


   •   The enemies should be capable at shooting at the player. Shots should be
       aimed directly at the player position by applying some AI to the enemies.
       Player should loose energy if hit.


   •   Some enemies should be able to fire Homing Missiles (intelligent missiles) at
       the player. Player should loose energy if hit.


   •   If caught behind an obstacle and squashed due to the scrolling map, player
       should loose energy.


                                                                                                   12
C YB E R TA N K 3 0 0 0    |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




   •   When an enemy or an obstacle is hit, there should be an explosion or reaction
       hence giving the player constant feedback.


   •   Sound effects should occur when player is hit, Aliens explode etc.


   •   At the end of a level a Boss arrives (a strong enemy). The Boss can receive a
       certain amount of shoots before it is destroyed. When this happen the level is
       complete.




4.2 Problem Definition

From the project theme and system definition of the game idea, the problems of the
project are:


   •   How is AI used in computer games and to what extend can this be transferred
       to mobile unit games?
          o    How does AI influence the narrative structure and game play in mobile
               games?
          o    What possibilities lie in future use of AI in mobile games?


   •   Is it possible for a group of first time J2ME™ developers to create a
       compelling mobile game?
          o    What elements should a mobile game contain to keep the player
               entertained?
          o    How should game HCI be structured to obtain a flat learning curve and
               great game play?
          o    How should the game be implemented to accommodate the chosen
               platform?
          o    Is it possible to implement simple forms of AI into the game?
          o    How should a mobile game be promoted to accommodate the target
               audience?




                                                                                                    13
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




4.3 Project Limitations

The set limitations of the project are as follows.


   •   All implementation and development are aimed at the Nokia N-gage mobile
       phone. The limits of this mobile unit therefore also apply to this project.
   •   All limitations of the System Definition [see 4.1.1] apply throughout the
       project.
   •   Only one level of the complete CyberTank 3000 game will be implemented.
   •   Only 2D graphics will be used.




4.4 Project Goals

From the problem definition and limitations the following goals of the project can be
derived. The main goals in the project are:
   •   To research today’s Game AI and give suggestions to how the attributes of
       this can be transferred to mobile gaming.
   •   To develop a compelling game based on the simple practices of classical
       gaming.
   •   To create one fully functional level of CyberTank 3000 in respect to the
       system definition.
   •   To use and understand AI to some extent.




                                                                                                   14
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




5 Building the game

5.1 Building the architecture of the application

Rich picture
When the group had decided the concept and the general rules of the game, the rich
picture was made. The purpose of the rich picture is to give an overview of the
different problem areas and possible conflicts in the application.




Fig. 5 Richpicture


Criteria diagram
The criteria diagram is made to secure the quality of the program and to make sure
that developers have focus on the areas that are important for the specific program.
The diagram below illustrates that it is not only the intended users who are taken
into consideration when designing the program, but also the hardware platform. An
example of trade-off among the criteria’s is the importance of efficiency compared to
flexibility.




                                                                                                   15
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



Criteria:        Very           Important        Less             Irrelevant
                 important                       important
Usefulness                                                        X
Security                                                          X
Efficiency       X
Reliability                     X
Usability                       X
Simplicity                                       X
Moveable                                         X
Flexibility                                      X
Easy to test                    X
Fig 6


State diagram
The state diagram is made to show the dynamic flow of the application. The diagram
was not important for the development of the game itself, but it was made before
the implementation of the menu system began. It was important to chart out which
options to give the user and how they were connected.


As the state diagram shows, one of our ideas was to lead the user through the
application without too many choices. Only the ‘About’ and ‘Help’ screens give the
user the choice of going back and forth. This decision was made to keep the players
focused on the game itself.




Fig. 7 State diagram



                                                                                                   16
C YB E R TA N K 3 0 0 0       |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



Sequence diagram
The sequence diagram is made to illustrate the dataflow of an action. In this case we
have chosen to show the dataflow of a full game session.


The ‘User’ comments illustrates decisions made by the user, the ‘System’ comments
illustrates decisions made by the system. The dotted line is to show that more than
one action is possible.




Fig. 8 Sequence diagram



Event table - bringing together classes
Due to the limited system resources, mobile applications often have a very simple
rather than flexible architecture. This often involves as few classes as possible. The
playable part of the CyberTank3000 application originally consisted of 4 classes, this
number was important to reduce to save as much system resource as possible. To
find out which of the 4 classes that could be aggregated we made an event [10]
table containing the most common events and the classes used in the playable part
of the application.


                          Tank             Map            Enemy events                  System
                          events           event                                        events
Classes:                  Move     Shot    Draw map       Spawn      Move     Shot      Thread    Paint

GameCanvas                X        X       X                         X        X         X         X




                                                                                                       17
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



PlayerGraphics        X        X       X
SceneGraphics                  X       X                         X
EnemyGraphics                  X                      X          X
Fig. 9 Event table



By looking at the table above, it is clear that all the shown events are involved in the
GameCanvas class. When realizing this, it was obvious that we should try to move
the content of the three other classes into the GameCanvas class. The elaborated
code resulted in the following event table which is considered as final.


                      Tank             Map            Enemy events                  System
                      events           event                                        events
Classes:              Move     Shot    Draw map       Spawn      Move     Shot      Thread    Paint

GameCanvas            X        X       X              X          X        X         X         X
Fig. 10 Event table




5.2 Implementation

The group started implementing the game using object oriented techniques such as
building the application using classes and methods for wide-range tasks. One
example is using only one method for the different explosions, etc. The reason for
taking this approach was to avoid mishaps when working two people on the same
code simultaneously. Without access to any version control software it was very
important that the code could be written in stand-alone classes and methods, then
be tested and thereafter get aggregated – and all this without ending up with
different explosion methods. Another precautionary measure was to occasionally use
extreme programming [11] methods such as two coders sitting at each computer,
discussing the code and switching places at the keyboard. This extreme way of
programming turned out to be very successful for the group. We solved problems
very quickly and often the code was very well written.


Right from the beginning we had discussed the functionality of the game into details
so we had clear intermediate goals when the implementation phase began. We
started out by implementing basic versions of the fundamental functionality such as
player movement, drawing of the map, user controls, etc. Once the code was



                                                                                                   18
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



working to our satisfaction we went on to the next area. Every now and then we
obtained some knowledge that could be useful for functionality we had already
programmed. When we had gained enough knowledge about an area we started to
re-implement the code, because it takes time to get familiarized with earlier written
code we made sure to gather so much knowledge that we only had to re-
implemented code one or two times.


When all functionality was in place we started the testing and optimization phase.




5.3 Testing and optimization

We had two ways of testing the written code.


       1. Running the application on the emulator and phone, searching the game
          for errors or possible leaks of resources by simply playing the game.


       2. Setting up a testing environment with MIDlet debugging support.


The first option has been used throughout the project. It has not been very efficient
measured in time. One advantage using this method is that we have been in most
likely every situation of the game, and because of this we can be very sure that if
there is a bug in the game – we know about it.


We decided to set up a testing environment in the Eclipse [12] IDE using the
EclipseME [13] plug-in. This program supports both compile time and runtime
debugging and is known in developer circles as very efficient. Unfortunately the
mobile setup was more time demanding than first assumed and the EclipseME plug-
in doesn’t have full support for the Nokia API. Because of this we were not able to
carry out the runtime debugging. The compile time debugging found five minor
issues that were sorted out. The issues were about importing packages that were not
used and variable assigned with no effect.


Even though our test environment was kept very simple we managed to do some
extensive optimization. By use of the guidelines of the class slides, tips on the net
and common knowledge, we’ve managed to make our game run on the N-gage at



                                                                                                   19
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



the same speed as on the emulator and also minimized the code with close to a
thousand lines of code. The optimization areas include but are not limited to:


   •   Method Number Minimization: Upon completing the implementation phase
       we’ve gathered methods of relevance into single methods. This has saved a
       lot of computations since numerous for loops were discarded.
   •   Stacked Variables: Where ever possible we’ve used stacked variables to
       speed up the MIDlet.
   •   Bitwise Operators: Where ever possible we’ve used bitwise operators for
       multiplication and division (<<1 == *2. >>1 == /2). This has also resulted
       in a faster MIDlet.
   •   Local Variables: We’ve moved as many variables as possible under the
       methods in which they are used. This minimizes the heap when running the
       game.
   •   Minimized Data types: We have used the smallest data types possible for our
       variables throughout our classes hence further minimizing the heap.
   •   Minimum Computations in Thread: Other groups have experienced problems
       when doing massive computations or object calls in their thread. We therefore
       structured our game so that our Midlet would keep such to a minimum.
   •   Compressed Images: we’ve made sure that all our images are as compressed
       as possible without loosing relevant details.


As a part of our testing we have had different people playing the game throughout
the optimization. This form of testing has given us valuable feedback on both game
play and information on where it was necessary to optimize. The third party user
testing has resulted in changes all along the implementation face.


Nokia Sweden was kind enough to lend us an N-gage unit throughout the project. It
should be noted that the high level of service we received from them is
unprecedented to anything we’ve ever experienced before. We therefore encourage
all future generations of the Computer Games course to contact these kind people
early in their projects regarding the loan of relevant mobile units.




                                                                                                   20
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




5.4 Deployment and target devices

When we decided to stop developing on CyberTank3000 game it was time to figure
out the last deployment details.


We decided to use obfuscation on our jar file. This choice was made out of two
reasons. One reason was that we found it practical to be able to wobble our code and
hence protect it from decompiling. The other reason was to see if we could shrink the
size of the jar file this way. The jar file was 1 Kb smaller after obfuscation – but
every bit counts.


As mentioned numerous times by now the target device of the project is the Nokia
N-Gage mobile phone. Some of the more obvious reasons for this choice are:


   •   Large screen
   •   High screen resolution
   •   Color display
   •   Joypad
   •   Registration of two buttons pressed simultaneously.
   •   Cheap compared to other mobile phones with the same features.


We had deployed the game to the N-Gage many times during the implementation so
at this point the deployment was a standard procedure that didn’t course any
problems.




5.5 Software used

The following software was used in the implementation face.


GEL, version 1.0.0.0 RC38.2
http://www.gexperts.com/
Programming IDE, was primarily chosen because it was supported by AUE hardware.


Eclipse, version 3.0.0M9


                                                                                                   21
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



www.eclipse.org
Java Programming IDE, was used because of its debugging properties.


EclipseME
eclipseme.sourceforge.net
Mobile plugin for Eclipse.


Nokia Wireless Toolkit, version 2.1
http://java.sun.com/products/j2mewtoolkit/
Used to build jar and jad files.


ProGuard, version 2.0
proguard.sourceforge.net
Used for obfuscation of the jar file.


Emulator, Series 60 MIDP Concept Beta 0.3.1 Nokia Edition
http://www.forum.nokia.com/main/0,6566,034-243,00.html


RingMaster, version 4.0.33, http://www.colornokia.com/other/other.htm
Used to create the OTA and MIDI files used in game.


Adobe Photoshop, version xx, www.adobe.com
Used to create graphics for the game.


Adobe Illustrator, version xx, www.adobe.com
Used to create graphics for the game.


Maya3D, version xx, http://www.alias.com
Used to create graphics for the game.




5.6 Final testing and User Feedback

After implementing the last optimizations the final testing began, this was done to
ensure the quality of the game. In general the test audience was very pleased with
our game and especially the graphics which the test audience complimented. A few


                                                                                                   22
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



things were however altered after feedback from the test audience. Prior to the final
version of the game, the tank would be destroyed if pressured in to a wall - this was
altered after consulting with the test audience.


A general issue was the difficulty of the game. This was altered several times during
the production. We believe to have found a level of difficulty that appeal and
challenges most of our target audience. Still one feature has been topic of
discussion, namely the ‘lock’ on the gun tower when chancing direction. We have
now made an explanation in the help function to accentuate this feature.




                                                                                                   23
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




6 AI in games

6.1 What is AI in Games?

There are different opinions on what should be considered Game AI. A better name
might be “agent design” or “behavioral modeling”. [14]


In 1950 Alan Turing proposed the question, Can machines think? [15] This was one
of the first times AI in machinery was considered. Today scientist has yet to prove
that machines can think, but they have come a long way in the making of or
simulating AI in machines. In the gaming industry AI is receiving increasing
acknowledgements and is now a big part of game development.


The term AI in this report is used as an indication of the game simulating intelligence
in order to perform complex tasks. This is often seen when computer controlled
opponents is simulating autonomous reasoning when responding to the players
actions.


In the following chapters we will look at AI types which could be interesting to
implement in a mobile game such as our shoot em’ up game CyberTank 3000.




6.2 Agents

An agent is anything that can perceive and adapt what happens in its surrounding
through sensors and then come up with an output by generating actions performed
through effectors (see figure 11 below). A human agent has eyes and other organs
for sensors and hand and legs works as the effectors [16]. Marvin Minsky proposes
that the human mind is made of small agents. Where each agent by itself only can
do simple things that need no mind by is self, but when joining these agents in
societies in a special way it leads to intelligence. Hence Minsky also propose that it is
possible to create intelligence from non intelligent agents, each mindless by itself
[17].This is not exactly the type of agents which will be dealt with here, although
there are many similarities.



                                                                                                   24
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




In a robotic agent, cameras substitute the human eyes as sensors and different
motors substitutes the arms and legs for the effectors. A software agent which is
what we’ll be dealing with here has encoded bit strings to perceive and perform
actions. [18]




Fig. 11 Software agent



A rational agent is an agent that does the right thing. This is defined by evaluating
what actions the agent has to perform in order to be most successful. To do that, the
agent needs to know what it has to do to be a success. This problem could be solved
by incorporating some “built in knowledge” in the agent, which then is used to act
upon the sequence of different perceptions. In a game situation this could be
incorporated by providing the agent with a task environment and some “built in
knowledge”.


To make sure there is a clear definition of the agent’s possible percepts and actions
along with the agent’s goals and the environment it should operate in is it a good
idea to make a PAGE (Percepts, Actions, Goals, Environment) description. [19]
Andrea Valente [20] has made a little different description, which is the PEAS
(Performance, Environment, Actuators, Sensors) description. For a software agent
operating in a game we find the PEAS description more useful.


In the task environment for each problem we have to specify [21]:
    •   The Performance measure, what we want to maximize and/or minimize
    •   The Environment that the agent will interact with. The simpler the
        environment the easier it is to build the agent.
    •   The Actuators available (i.e. the actions that can be performed)


                                                                                                   25
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



   •   The Sensors available, what kind of informations they provide


In the following game example there will be a description of how we could make use
of agents for our game CyberTank 3000 along with the PEAS description for the
agent. This example will be the first of a total of four examples, each finishing of an
AI chapter.


Game example # 1
The following game examples are not implemented in the game; they are all based
on an idea for a second level taking place on the planet which the CyberTank in level
1 is orbiting on a space station.


On the planet the CyberTank should be attacked by some ground units in the form of
small alien creatures called Creliens. These Creliens could have some build in
knowledge:


   •   Approach the tank until you are 40 pixels away from it, and then start
       shooting at it.
   •   If the CyberTank fires in your direction, flee away from the tank until you are
       100 pixels away from it. Then begin approaching it again.


The task environment for the Creliens:
   •   The Performance measure - Get as many shoots fired at the CyberTank as
       possible.
   •   The Environment - A simple landscape with a few obstacles the Creliens has
       to avoid, when approaching the CyberTank.
   •   The Actuators – Movement, and shooting device.
   •   The Sensors - Encoded bit strings, evaluating the CyberTank’s movement.


The agent should then be able to perceive the CyberTank’s movement, reflect on this
perception and perform the best possible action (approach, shoot or flee).


Below is a simple example of the above mentioned written in pseudo code. The
perceptions of the tank are the DistanceToTank and tankShotDirection, from these
perceptions the action is chosen. The memory of the tank is the currentAction.




                                                                                                   26
C YB E R TA N K 3 0 0 0    |   C O M P U T E R   G A M E S   S P R I N G    2 0 0 4   |   GR O U P     7




               Method Crelien(distanceToTank, tankShotDirection) {
                       Private currentAction: approach, attack, flee
                                 Memory -> choose action from perception
                       return newAction
               }




6.3 Flocking

Flocking is part of Artificial Life, or ALife. Alife is the study of virtual life and can be
used to watch or simulate how natural systems work, such as flocking.


In 1986 Craig Reynolds [22] invented a computer model which generically simulated
flocking creatures. The model called Boids, describes how a group of agents can be
made to move in a naturalistic way using 3 steering behaviors; separation, alignment
and cohesion. In an interview with generation5.org [23] Craig Reynolds was asked a
question of how he came up with those rules. Here is a bit of the answer he gave:


       I just tried to mentally put myself inside a flock and imagine what I would have to do
       to fly with them. I'd have to make sure I didn't get too close to any of my local flock
       mates. I'd want to be flying at the same speed and in the same heading as my local
       flock mates. (This also means I'm unlikely to collide with them in the near future.) And
       finally, if I noticed that all of my local flock mates were on one side of me, I'd want to
       drift over towards them. - Craig Reynolds



He ended up with 3 rules necessary to simulate flocking. The following figure made
by Reynolds himself illustrates the Boids model [24]:




Separation:   steer   to   avoid   Alignment: steer towards the            Cohesion:      steer   to       move




                                                                                                       27
C YB E R TA N K 3 0 0 0      |   C O M P U T E R   G A M E S   S P R I N G     2 0 0 4   |   GR O U P   7



crowding local flock mates           average heading of local flock          toward the average position of
                                     mates                                   local flock mates
Fig. 12 Boids model


In the figure the grey circle represents the area the specific creature reacts too. It is
measured from the center of the creature. The creatures outside the grey area have
no influence of the specific creature’s movement. Of course all the creatures have
there own grey circles, which all together creates the naturalistic looking movement
of flocking.


Game example # 2
It would give a great effect if our Crealiens from game example # 1 were attacking
in a flock. This could be created by adding some more performance measures to the
agents. The added measures would be:


    •   Avoid crowding with local Creliens of a distance of 30 pixels from current
        position.
    •   Move towards the average heading of local Creliens in a distance of 30 pixels
        from current position.
    •   Move towards the average position of local Creliens in a distance of 30 pixels
        from current position.


This would of course have to be incorporated with the “move towards the
CyberTank” code, which has already been implemented on the Creliens.


The pseudo code below is an extended version of the pseudo code from Game
Example 1. The code shows that the flocking feature requires three new perceptions
for the Crelien in order to fulfill the requirements of the flock, although it still has the
same performance measure.


                 Method Crelien(distanceToTank, tankShotDirection, flockAlignment,
                 flockSeperation[], flockCohesion[]) {
                        Private currentAction: approach, attack, flee
                        Private currentFlockAction: steerDirection
                                   Memory -> choose action from perceptions and steer
                                   accordingly to the perceptions.
                        return newAction



                                                                                                        28
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



              }


A forth rule could be added; the avoidance rule, where the agent avoid non-flock
objects in the environment. This rule could also be used to avoid enemies and enemy
projectiles [25] and thereby make the Creliens a more aggressive and tactical
enemy.




6.4 Pathfinding

In order to make the computer-controlled characters capable of making tactical
decisions, suitable algorithms are often required. A tactical decision could be finding
the way from point A to point B. In this chapter we will first take a look at how to
find a path through a maze using a decision tree and thereafter we will take a look at
one of the most commonly used pathfinding methods in games: the A* algorithm.
Finally there will be a game example.


Decision Trees
There are typically two kinds of decision trees: the depth first and the breadth first.
The difference is that depth first travels all the way from the root node to the last
leaf node before going back and starts searching another node. Whereas in the
breadth first, the root node is explored first, then the next level of nodes is searched
and so on, trying to find the quickest path that way. The following example is of the
depth first tree. In the maze (see figure 13 below) an agent has to move from room
A to room B. The agent can move from room to room through the paths provided,
but the agent has no idea how many rooms and paths it has to search in order to get
to the leaf node.




                                                                                                   29
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




Fig. 13 Maze



To understand and later program the agent’s behavior it is useful to make a sample
session [26]:


    •   The agent moves from room A to room 1.
    •   From here the agent can move either to rooms 2 or 3. Room 2 is chosen.
    •   The agent has no choice but to move to room 4.
    •   Dead End. The agent returns to room 2, and sees that there are no more
        choices.
    •   The agent goes back to room 1, and chooses room 3.
    •   From here the agent can move either to rooms 5 or 8. Room 5 is chosen.
    •   From here the agent can move either room 6 or 7. Room 6 is chosen.
    •   Dead End. The agent returns to 5 and chooses 7.
    •   The agent has no choice but to move to room 4.
    •   Given a choice between rooms 5 and 6, room 6 is chosen.
    •   Another choice between 7 and 8, room 7 is chosen.
    •   Dead End again. The agent returns to 5 and sees that there are no more
        choices.
    •   The agent goes back to room 3, and chooses room 8.
    •   The agent sees room B, moves to it, and completes the path trough the
        maze.


This sample session could then be made into pseudo-code.


function AgentPathfinding(RoomNumber)
begin




                                                                                                   30
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



if RoomNumber has been visited, return.
       for each room connected to this room
         if ConnectedRoomNumber == B, the path has been found
         else CheckRoom(ConnectedRoomNumber)
       end for
end function [27]


The Agent has now succeeded in finding the path through the maze, by taking
recursive steps. At each step the agent checks if the path has been found - if not it
continues through the branch. If the branch has been explored all the way to leaf
node, it switches to another branch in the tree, until the path has been completed.


A* Algorithm
In the previous decision tree example there was only 1 main concern, namely getting
from A to B. In more advanced pathfinding there are other elements to be
considered besides the obvious getting from A to B. These elements are:


   •   How to get around obstacles?
   •   How to find the shortest path?
   •   How to find the path quickly?


In contrary to the depth first and the breadth first decision trees just discussed, the
A* algorithm goes under the title best first algorithm. This basically means that the
nodes are chosen for expansion based on an evaluation function. The A* traverses
the map, and at the same time creates nodes with a value that correspond to the
various positions it explores. The evaluation function then selects the best node
based on the assigned value. The A* finds the lowest cost path between the start
node and the end node. This is defined below as:


f(n)=g(n)+h(n)
Where g(n) is the cost of the path from the start node to the n node. H(n) is the
estimated cost to get from the n node to the goal. This is also know as the heuristic,
which is a guess based on evaluation. F(n) provides an estimate of the cost for the
path, the lower the cost the better the path. (Rabin, 2002) Hence the A* always
goes to the neighboring node with the lowest value of f(n)=g(n)+h(n). The




                                                                                                   31
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



evaluation cost of the selected node is then added to an open priority list. If a
shorter path is found the A* can move back to a node where the shorter path starts
and continue on from there.


Game Example # 3
In game example # 1 we gave our Creliens the following build in knowledge:
approach the CyberTank until you are 40 pixels away from it, and then start shooting
at it. But in order to approach the CyberTank they need to find a path towards it,
and here the use of the A* algorithm come in hand. Unfortunately the A* is quite
computationally heavy, to solve this problem the A* could be incorporated on a
Crelien leader, the other Creliens could then be content with having an extra
performance measure like: stay within 40 pixels of the leader. Hence, avoiding to
apply A* on all of them. The Creliens know have two performances measures, “follow
the leader” which has the highest priority and “attack the tank”.


The map of level 2 could include mud or water tiles, which would take longer time to
traverse, hence more “expensive” to move on, making the pathfinding more
interesting. The leader will find the least cost expensive path, hence the quickest.


The pseudo code below now also includes a Crelien flock leader with extensive
knowledge of the surrounding environment. This knowledge is used for pathfinding.
A new performance measure has been added to the Creliens. This performance
measure is to follow the Crelien flock leader and has a higher priority than the
performance measure already assigned.


              Method LeaderCrelien(distanceToTank, tankShotDirection,
              environment) {
                      Private currentAction: approach, attack, flee
                      Private currentPath: direction
                                Memory -> choose action from perceptions.
                      Return newAction
              }


              Method Crelien(distanceToTank, tankShotDirection, flockAlignment,
              flockSeperation[], flockCohesion[], leaderPosition) {




                                                                                                   32
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



                      Private followLeader: direction
                      Private currentAction: approach, attack, flee
                      Private currentFlockAction: steerDirection
                                Memory -> choose action from perceptions and steer
                                accordingly to the perceptions.
                      return newAction
              }




6.5 Neural networks

In his book “The society of Mind” Marvin Minsky propose that the human mind is
made of enormous amounts of simple agents connected to each other in huge
networks.


       I’ll call “Society of Mind” this scheme in which each mind is made of many smaller
       processes. These we’ll call agents. Each mental agent by itself can only do some
       simple thing that needs no mind or thought at all. Yet when we join these agents in
       societies—in certain very special ways—this leads to intelligence. [28]



In artificial neural networks intelligence emerges from the connections and
interactions between huge numbers of rather simple processing units. Basically
neural networks are attempting to model the human brain’s inner workings. Each
neuron has a certain number of inputs. Whether the input is excitatory or inhibited
there is added or subtracted a weight to the neuron’s overall weight. The weight
received from the inputs is an indication of how important the incoming signal is.
When a threshold is exceeded, the neuron fires or outputs a signal, to all the other
neurons it is connected to. [29]


Learning
A programmer can provide clues for the AI as to where the player is likely to stop for
rest, but different players will naturally have different preferences. If the AI could
learn from these preferences and adapt to each individual game, then the game
would certainly seem more real.




                                                                                                   33
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



Neural networks have the ability to adapt to the environment and learn from the
successes and failures it might encounter. If the frequency of the failures is reduced
due to the experiences happening to the network then learning is achieved. [28]
There are different rules of learning but generally, most rules can be categorized into
two areas - supervised and unsupervised. The supervised learning rules need an
“instructor” telling what a desired output should be to the input. Whereas the
unsupervised rules do not need any instruction, they produce an output which is
evaluated.


The Delta rule is a supervised rule and is one of the most commonly used learning
rules [30]. It learns from the failures or errors occurring during the game. In for
instance a path finding example if an unknown pattern, but yet similar to a known
pattern is presented, then you get a plausible response to the unknown pattern.


Game example # 4
To finish of the game example from the previous chapters, it would be interesting to
apply some learning on the Creliens. Let’s assume that a Crelien leader can adapt to
the preferences made by the individual player, hence being able to make a more
strategic pathfinding. If this knowledge was shared between all the Crelien flock
leaders the leaders entering the later part of the game would benefit from the
knowledge achieved by the earlier leaders.
The pseudo code now includes learning. The new perception called attackDirection
contains the direction the tank is turning when the Crelien flock leader is attacking.
Aside from registering the tank direction the number of shots fired in the attack is
stored in the memory. This way the Crelien flock leaders can learn the possible best
attack direction due to the individual player.
              Method LeaderCrelien(distanceToTank, attackDirection,
              tankShotDirection, environment) {
                      Private currentAction: approach, attack, flee
                      Private currentPath: direction
                      Public bulletsFiredInDirection[][]: direction, amount
                                Memory -> choose action from perceptions and change
                                attacking direction according to adaption.
                      Return newAction
              }




                                                                                                   34
C YB E R TA N K 3 0 0 0      |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




7 AI’s affect on the narrative structure
This chapter will look upon the narrative structure of interactive computer games,
and discuss some of the issues involved when dealing with AI in respect to these
structures.


As mentioned in Chapter 2 of this report, the gaming industry has made use of
different narrative storytelling models in the attempt to produce dramatic storylines.
If we were to look at the traditional Hollywood model (See Chapter 2, Fig. 1)
imposed on a computer game like the 3D-first person shooter game Max Payne, the
model would look something like this:




Fig. 14 Narrative model of a first person shooter game


Starting with an introduction or ‘strike of attention’, the basic story-elements and
main characters are presented. Similar to the traditional model a Point of no return is
reached, but worth noting is how this point often is placed before the actual game
begins. The main part of the game where the player acts out the story in real-time
evolves through a number of levels with increasing difficulty and multiple attempts
from the player to succeed. These levels are often intervened by small non-
interactive segments of story elaborations – usually brought on by a narrator.
Whereas the respective levels incorporate a high degree of interactivity, the overall
storyline and sequence of events lies completely solid.




                                                                                                      35
C YB E R TA N K 3 0 0 0      |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



This combination of interactivity and determinism seems necessary in order to keep
the story evolving and to keep the player engaged without losing interest. However,
a significant element in terms of keeping the player engaged is the use of Artificial
Intelligence. But to which extent does AI affect the narrative structure of computer
games?




7.1 AI at present time

Below is a simplified analysis of hypermedia structures in a modern first person
shooter game:




Fig. 15 Hypermedia structure of a first person shooter game



In a game such as this, AI would most likely be found in the form of enemy
characters which the player has to overcome within the respective levels. But how
intelligent are these enemies? Typically, the characters are not really characters but
merely simple agents that have pre-built knowledge and very few options to follow.
First of all, they know that if someone enters their territory, it must be the player
and therefore they will shoot at you and attempt to avoid your bullets. Second, they
might have an option of going to a nearby room and throw a grenade at you if you’re
too slow. The smart ones may actually form group formations in order to defeat you,
but they are still built on simple rules of sense- and reaction attributes. Hence, no
real intelligence or acts of free will can be derived from them and consequently, no
opportunity should arise where these characters can alter the structure of the
narrative. Naturally, countless examples exist of how AI can mess up a game play,



                                                                                                      36
C YB E R TA N K 3 0 0 0       |   C O M P U T E R    G A M E S    S P R I N G    2 0 0 4   |    GR O U P   7



not because they exceed their mandate, but as a result of unforeseen sequences of
events.




Fig. 16 This ingenious AI built a ‘Great Wall’ in the South Pole. (From Civilazation I, 1991)



A certain amount of control is required in order to ensure that the player reaches
key-points in space and time, within the frame of game play (i.e. level entries/exits).
Often this type of control is imposed onto the AI characters by rules like space
confinement, time specific insertion points of a character, helpers that provide hints
to the player, etc.


In a way, these rules resemble how some online multi-player games are controlled
by a staff of game supervisors. Games like Everquest, Anarchy-online and Eve are
supervised to avoid inappropriate events and obstacles that potentially endanger the
narrative continuity. The experience from these controllers could very well prove to
be helpful knowledge in the future to come as AI draws closer to real intelligence.




7.2 Autonomous AI

If we (as in humans) were to implement true autonomous AI in future interactive
computer games, developers would face serious challenges in terms of controlling
narrative structure.


Say autonomous AI can be used to create believable electronic characters that are
able to intelligently sense and understand you as a gamer, and at the same time
possess the ability of free will. Indeed the player could have fascinating encounters,
conversations or battles, but the anarchistic behaviors of these characters could also
lead to uncharted territories completely irrelevant to the story. So we might conclude
that an even larger amount of control is needed to keep the story on track. This
relationship of interactivity and narrative control has been subject of much discussion
among game designers and the general view is that they simply do not seem to
match very well. As Jesper Juul states:




                                                                                                           37
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




       Narrative and interaction cannot exist simultaneously: Where the first
       presumes leaping and compressed time, the other is continuous real time.
       [31]


Admittedly, the discussion concerning autonomous AI is highly hypothetical and
might find itself cancelled out by the invention of entirely different types of game
play. Perhaps autonomous AI will rid game designers of traditional level designs and
make way for character-based games set in environments with extreme potential of
complex interaction and exploration for the gamer.


Considering computer games from past to present, we could argue that successful
games often lets the game play itself act as the narrative catalyst as opposed to
more recent tendencies, where narratives are often imposed onto the game play,
making it less interactive. The popular Civilization from 1991 [32] holds a high
ranking in that the incorporated AI successfully adds substance to both the narrative
structure and the game play in addition to making no two games alike.




                                                                                                   38
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




8 Technical discussions

8.1 API’s used in the game

This chapter is an introduction to the different API’s used in the implementation of
the CyberTank 3000 game. We will briefly explain how and why these API’s have
been used in the application.


8.1.1 MIDP (Mobile Information Device Profile)

The MIDP profile provides the three following features:


     • Simple LCD based GUI classes
     • Basic networking facilities
     • Persistent data


There are currently 2 released versions of the MIDP; The MIDP 1.0 (MIDP1) [see
Fig.x] which is implemented on most java enabled phones and MIDP2 which is a
rather new version and therefore not implemented on many phones yet. For this
project we have been working with the MIDP1 version since this is the one installed
on the Nokia N-gage platform.


The most useful API in MIDP1 has been the MIDP1 UI API which provides
functionality designed for use with small screens based upon single display areas. It
gives access to display objects and canvasses. Through the Canvas subclass we were
able to implement the paint method which gives access to draw lines, rectangles,
text and images which were all used in our application. The Canvas subclass also
gave us access to user events through the keyPressed and keyReleased methods.
The diagram below shows the structure of the MIDP1 UI API [33].




                                                                                                   39
C YB E R TA N K 3 0 0 0       |    C O M P U T E R   G A M E S    S P R I N G     2 0 0 4   |   GR O U P   7




Fig. 18 The MIDP v.1.0 UI



One feature that was important for us to use was the ability to play the game in full
screen. This feature is not supported by MIDP1 so we needed to implement this
otherwise.


8.1.2 Nokia UI API

The Nokia UI API [see Fig.19] was used because it supports full screen on our chosen
target device. The API was easy to use and didn’t cause any trouble during the
implementation phase, but as mentioned in chapter 5 the Eclipse IDE we had chosen
to use as debugging did not have support for this API.


Aside from the full screen drawing feature the Nokia UI API also supports other Nokia
specific   features    like       sound,   vibration    and      device   light     control.     The   Nokia
DirectGraphics object was e.g. used to make the lasers of the Boss transparent.




                                                                                                           40
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




Fig. 19 The Nokia UI




8.1.3 The Mobile Media API

MMAPI [34] is part of the MIDP 2.0 standard but has also been implemented on a
few phones only supporting MIDP1, one of them being the Nokia N-Gage. This API
provides a high-level interface to sound and multimedia, it has several advantages
such as enabling basic sound routines with simple controls, enabling media
synchronization and having a low footprint. Multimedia processing using MMAPI can
be broken into two parts


      • Protocol handling
        Reading from a data source such as a file, video camera or sound recorder.


      • Content handling
        Decoding or rendering to an output device such as a screen or speaker.


Three objects are used to get data from the original source to device.


      • DataSource, protocol handling.
      • Player, content handling.
      • Manager, creates a Player that is able to handle the data given by the
      DataSource.




                                                                                                   41
C YB E R TA N K 3 0 0 0       |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




Fig. 20 The MMAPI structure



We have used the MMAPI to control the music score and all sound effects of the
application. Most of the sound effects are stored in the virtual memory when the
game is loading using the prefetch method, this way we are able to play the sounds
in short term notice.




8.2 Game HCI

The design of the interface for our Mobile game concerns several key-areas of
attention.


• Target audience
• Target device
• Learning curve
• Innovation
• Simplicity
• AI
• Feedback


The first criterion concerning target audiences for mobile games demands, that the
game has to be playable by virtually anyone, since mobile devices and the increasing
popularity of games have become a widespread phenomenon. Everyone from
teenage students to lawyers and waste disposers seem to enjoy this contemporary
bus-stop-entertainment. Furthermore, the increasing globalization dictates a cross-
cultural embracement that suggests a simple and instinctive approach to the
interface design.




                                                                                                       42
C YB E R TA N K 3 0 0 0     |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



The choice of target device somewhat narrows the scope of the target audience. Due
to practical game play advantages, we chose to develop ‘Cyber Tank 3000’ for the N-
Gage mobile device. Being that this device is specifically targeted for more advanced
users of mobile games, we could leave out considerations for those new to this type
of entertainment. The choice of the N-Gage device was led on by obvious advantages
in the form of a simple and easy-to-use navigational button (positioned left in the
picture below) – a setup that resembles current game consoles. This allows the
player to drive the tank in a more intuitive way as opposed to using the number pad
on the right.




Fig. 21 The N-Gage Mobile device



Another important issue when addressing Human-Computer Interaction is the so
called learning curve. No game of this type should require more than a few seconds
from the player to get the basic skills down. If a game has too many instructions that
have to be studied or too advanced methods of controlling the game play, it is likely
that the game will live an unsuccessful (and short) life in the midst of popular mobile
games. In short, the learning curve should not be steep [35].


On the other hand, a criterion for a successful game is the ongoing demand for a
minimum of innovation. We have tried to accommodate this by implementing an
intelligent way of controlling the tank and its gun tower. Using only the arrow pad on



                                                                                                     43
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



the left combined with the fire button (number key 5) on the right, we enabled the
player to turn and lock the gun tower of the tank for a heightened level of control
and game play. This however, summons up the player interactions during game play
which makes our game meet the listed demand for simplicity.


The initial intention for our game was to develop multiplayer features [36] to make
up for intelligent responses to the interactions of the player(s). To compensate this
lack, we implemented a small amount of AI to create a minimum of excitement and
level of difficulty as well as unpredictability.


Equally important to the HCI is the need for consistent feedback to the player during
game play. This requirement was met by implementing simple score counters and
events like explosions when the tank or an enemy is destroyed. Sound effects also
play an important role here, so we developed a series of event sounds to match the
progression of the game.




8.3 Game AI

CyberTank 3000 v.1.0 contains 3 simple AI implementations which will be
documented in the following.


8.3.1 Alien Aim

The method alienShotSpawn of the GameCanvas class creates enemy fire aimed in
the direction of the player. So the aliens have some degree of intelligence since they
are able to determine where the player is and from that where to shoot.


This effect is achieved by first segmenting the screen into 4x4 areas. It is then
determined where the CyberTank is positioned in this area mask and the horizontal
and vertical speed of the shot is set accordingly. This gives a total of 64 possible
shooting directions from the alien spaceships.


We do realise that for greater precision generation a linear function between the
alien and the player avatar would have been required. But at this point in the




                                                                                                   44
C YB E R TA N K 3 0 0 0      |   C O M P U T E R   G A M E S    S P R I N G   2 0 0 4   |   GR O U P   7



implementation process it hadn’t been discovered how to generate such a precise
function using only the integer data type and not doubles or floats.




Fig. 22 Graphical interpretation of the alienShotSpawn method




8.3.2 Homing Missiles

Instead of firing in the tank’s direction the ground units is firing homing missiles. The
missiles is reading the tank’s x and y (X2,Y2) coordinates every time the thread of
the game is running. These coordinates are used as a aiming point for the missiles x
and y (X1,Y1) coordinates which is adding or subtracting to the X1 and Y1 value
depending on their distance to X2 and Y2. The goal of the missile is not only to move
towards the tank but also to do it within a specified range of time; if it does not
succeed it explodes.




                                                                                                       45
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




Fig. 23 Homing missiles




8.3.3 Boss Laser

The design and implementation of the level boss of our game was one of the last
tasks done before the game was complete. When we reached this point we decided
to do something special. We had been talking about using methods of the Graphics
object, besides drawImage, for a while and therefore designed a boss after these
wishes [see fig.24]. The boss was to shoot lasers directed at the player from its two
arms and shoot from its eye in the same manner as the other aliens [see chapter
8.4.1]. The lasers were to be implemented using the drawLine of the Graphics object
and a transparency of these lasers was to be made using the setARGBColor from the
Nokia UI object DirectGraphics.




                                                                                                   46
C YB E R TA N K 3 0 0 0      |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




Fig. 24 Boss design and function draft



To make the boss lasers work the need for precise linear functions using integers
surfaced again. This was needed not only to aim the lasers at the player but also to
detect collisions. Through dialogue with assistant teacher Rune Andersen, the
responsible       programmer             was   introduced       to    fixed      point       arithmetic
[http://mathworld.wolfram.com/FixedPoint.html]. With this theory in hand the
‘integer problem’ was overcome and the laser was successfully implemented.


The firing process of the laser consists of 3 phases [see fig.25]. In the first phase a
linear function between the boss arm and the player is generated and an ‘aiming
laser’ is fired. This is done using fixed point arithmetic. In the second phase the
aiming laser seeks out the player by x if the incline of the linear function is above 1
and by y if it is below. In phase 3 the killing laser is fired and collision detection
takes place. In this phase a new linear function is generated and the Xmin, Xmax, Ymin
and Ymax coordinates of the player is checked against the linear function [see fig.26].
The boss laser detects collision correctly at least 75% of the time.




                                                                                                      47
C YB E R TA N K 3 0 0 0     |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




Fig. 25 Boss Laser shooting phases                       Fig. 26 Boss laser collision detection



The implementation of the ‘aim’ and ‘seek’ of the boss laser can be found in the
alienDraw method of the GameCanvas class and the collision detection can be found
in the playerAlienFireCollision method of the same class.




                                                                                                     48
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




9 Marketing

9.1 Cyber tank marketing

The mobile game industry is expected to earn about 6 billion US dollar in 2006.
Prognoses like this have made the mobile game industry expand more than ever.
Right now Asia stands for 80-90 % of the mobile game industry but analysts state
that there is a huge interest among the European operators and game developers to
invest in the European mobile game marked.


The most common way to access mobile games is by SMS, where you buy the game
trough an internet web page or by a WAP page and get the game transferred by SMS
to you Mobile. The operators normally charge the consumer by overcharging the SMS
which contains the game, the general price for a small Java application like our game
is around 5$.
Out of these 5$ the game developers often gets around 10% [37], the rest goes to
the operator which then makes the game available for as many as possible.


Because our game is made especially for the Nokia N-gage the Nokia tradepoint
could be an obvious choice for promoting our product because of their large network.
There are of course many web-pages on the web where you can buy mobile games
in Denmark - places like Ahot and TDC fly would be desirable places to have our
game represented.


Another obvious way to promote our game would be our own web page from where
interested consumers would be able to see details and screen dumps from the game.
Because of the groups background in web designs this approach will also be a cheap
way to promote the game. For other advertising channels could magazines as the
Danish Chili [38] or Frikvarter [39] come into consideration for an advertising
campaign.
These magazines address the youth and could therefore be a possible channel to
use.




                                                                                                   49
C YB E R TA N K 3 0 0 0     |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




9.2 Game comparisons

The computer industry is one of the largest entertainment industries in the world and
there is produced a countless amount of games every year. It is therefore almost
impossible to create something that has not been seen before. If everything has
been seen before why should people buy new games?


In this chapter we will take a look at the best games to the N-gage according to
www.gamespot.com and next we will look at some similar games of Cyber Tank
3000 to see how and where it differentiates itself.


Almost all the games in the top 10 list on Game Spot are games with 3D graphics
using 3D views or First person view. This alone differentiates them from Cyber Tank
which is purely 2 dimensional with a top down view, but these games also cost
around 7 times more than a game like Cyber Tank 3000 should cost. Games like
FIFA Soccer 2004 [40] and Splinter Cell - Pandora Tomorrow [41] are made for
several platforms like Play Station 2, Xbox, and PC etc. This gives them a huge
advantage when it comes to production and marketing because of the large budgets
spent on the projects. These games are programmed in C which gives the developers
more freedom as opposed to programming in JAVA where you are limited by the
MIDP [see chapter 8.1].




Ashen | Publisher : Torus          Spider-Man 2 | Publisher :         Pathway to Glory | Publisher:
Games                              Activision                         Nokia


Fig. 17 Top three games for Nokia N-gage according to Game Spot




                                                                                                     50
C YB E R TA N K 3 0 0 0     |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



If we were to compare our game with other games for the N-gage then it should be
games in the same price class like Base Defender or Target Earth. These games are
sold on www.ahot.dk for the price of 5$ a piece. The concept in these games is the
same as in our game - you have to shoot everything that moves to accomplish the
mission. A major difference between our game and Base Defender is the quality of
the graphics. We can honestly claim that our graphic is on a much higher level.
Another thing that differentiates our game from the masses is the gun tower lock.


In general if we look at the games for the N-gage, we must say that there is a game
for every taste. In some of these games you will get what you pay for but in other
cases we must conclude that not all the games that cost 35$ is worth the price [42].
If you are used to PC or Play Station, the graphics on the N-gage will seem very
rough but never the less there are many good games to play and we believe that
Cyber Tank 3000 is one of these games with nice graphics and a good game play.




http://www.spil-mobil-spil.dk/ | Price: 5$




http://www.spil-mobil-spil.dk/ | Price:5 $


Fig. 17 Selected mobile games




                                                                                                     51
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




9.3 Graphics

Cyber Tank is a classic top-scrolling game which is known from endless numbers of
games. This does not make it a poor game; it may even emphasize a nostalgic
feeling you can get when playing the game.


The level created for the game is taking place on a futuristic space station where an
unknown alien species have taken over the station. The idea is that in the final game
the design will vary significantly from level to level to give the player a richer
experience. The graphics is made from a combination of 2D and 3D graphics to
obtain the details desired by this team. The inspiration for the design of the game
came from a number of movies [43], games [44] and web-pages [45] and was
created using Photoshop, Maya and Illustrator.


Opponents
There are tree kinds of opponents in the level which we have designed. The first
ones are the ground units, which are basically gun towers firing homing missiles.




Fig. 27 Gun towers



The second group is the three different alien spaceship-units, designed in 3D and
finalized in Photoshop. The shape and color of these units was chosen to emphasize
the fact that they are inherently different to the tank and the space station which are
designed in a more ‘Earth’ familiar fashion.




Fig. 28 Alien ships



The third and last entity is the “boss”. The shape and color of this alien separates it
from the others to emphasize climax of the level where the hero unit fights the boss
to finish the level.




                                                                                                   52
C YB E R TA N K 3 0 0 0       |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




Fig. 29 The Boss



Design of the hero unit (Cyber Tank)
When designing the tank it was important for us that it associated something that
could come from earth. We therefore decided to use a classic tank shape with some
modifications. It was very important that the gun tower was visible in all direction,
because of the feature that makes the tank able to shoot in one direction and drive
in another.




Fig. 30 The hero Cyber Tank



Buildings
The many different space compounds give the gamer enough variation so that the
game doesn’t becomes monotonous. The level is divided in two different styles of
compounds to create more variation and tension as the player draws closer to the
“boss”. One of the biggest challenges in making the compounds was to make very
few structure-elements from which we could build entire complexes – the object
being to reduce the overall number of tiles used in the game. The surface of the
space-station was designed to reveal space (universe) through certain areas. This
was made to enhance the feeling that you actually are in space and on a space
station. As with the alien units, some of the buildings were made in 3D and finalized
in Photoshop.


                                                                                                       53
C YB E R TA N K 3 0 0 0     |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




Fig. 31 Examples of different space compounds



The inspiration to the design of the compounds came among other from the Alien vs.
Predator games and the Alien film-trilogy.




9.4 Sounds

Due to the extreme limitations concerning the implementation of sound in our game,
we have tried to produce very simple yet effective sound effects to match key events
during game play. These include sounds for shots, explosions and collisions.
Furthermore we have produced an overall music-theme to underlie the entire game
play.


The MIDP 1.0 Media API only supports the use of monophonic sounds which is
basically single tone-bibs placed in sequence. In order to produce somewhat more
interesting and complex sound effects we adjusted the speed (BPM [46]) at which
the sounds were played. For instance, with the gunshot of our Cyber tank, we placed
a series of very short notes in sequence, creating harmonies which almost give the
illusion of the sound being polyphonic [47]. In dealing with the harmonies, our goal
was to obtain a sort of space feel which matched the scenery of the game itself.


As it turned out, the implementation of our sound effects proved to be too
demanding for the N-gage processor, so we ended up only using sounds on
explosions, missile collisions and music-theme.


To author the sounds for the game we made use of the Nokia PC Composer 4.0. It
provides an easy to use Midi interface with options for changing speed and applying
simple effects.




                                                                                                     54
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




9.5 Target audience

The target audience for the N-gage is 18-35 [48] years which makes the target
audience a little older than for the GameBoy Advance. When it comes to gaming the
two devices are very much alike, though there is produced more games for the
GameBoy than the N-gage. In cost the Nokia N-gage is twice as expensive as the
GameBoy Advance which automatically makes the target audience a little older.


A game like Cyber Tank can be played by almost everybody because of the simple
game-play but since of the target audience for the N-gage starts at 18 years,
marketing strategies should take this in to consideration.


The target group itself is limited to consumers with the Nokia N-gage mobile phone
which world-wide is around 9 million [49] people. This is not much when we look at
the total mobile market. Hence, it would increase the target group tremendously if
we made the game compatible to other mobile phones like the Nokia 3310 - one of
the best selling mobile phones in Europe in 2003 [50].




                                                                                                   55
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




10 Future improvements
As with any prototype, the idea is to produce first of all a concept, and second a
plausible implementation of part of this concept. In our case, we have suggested a
concept for Cyber Tank 3000 by developing a game concept built from a modified
version of previous arcade games from the 90’s. In developing our prototype we
have succeeded to produce a working game engine that meets the demand of our
concept in terms of functionality, game play and interaction. We have creatively
designed graphics that captures the mood and feel of our initial idea. However, the
word prototype entails that there be future improvements and elaborative extensions
to the game as a whole before it can be unleashed to the public.




10.1 Possible extensions & improvements

As mentioned earlier, the intention was to develop multiplayer features for our
game. Though we have succeeded in implementing a small amount of AI, nothing
present seems to match the intelligence and unpredictability of humans interacting
with humans. Using either Bluetooth technology or internet-based interactions, we
feel that the overall excitement during game play would increase dramatically. This is
also supported by the expanding popularity of multiplayer games in general,
although this team has yet to experience the feature on mobile device games.


The prototype in question reveals a game set in space with alien enemies attacking
an earthly orbital station defended by the player. As interesting as this might be, the
concept and storyline of the game undoubtedly calls for a ‘sequel’. Despite the fact
that we have not developed a complete storyline for the game, ideas have risen of
subsequent levels taking place on alien planets or perhaps on earth, depending on
the outcome of level 1. A fully developed interactive storyline would require
extensive enquiries in terms of hypermedia structures and storytelling arts in
computer games – a subject that exceeds the scope and ambition of this project.
Considering the rather primitive nature of the concept for Cyber Tank 3000 however,
it is not likely that such an inquiry will ever become relevant.




                                                                                                   56
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



In the discussion on more specific features and improvements for the game play, our
concept implies that potential future developers could implement moving ground
units like friendly or enemy tanks, turn guns that actually turn as the player passes
by, perhaps a wider court that enables the player to choose between multiple routes
etc. Also, the fully developed game should hold a place for improved statistics,
power-ups for the player and polyphonic sounds [51].




10.2 Further AI

At present Cybertank 3000 contains AI in three game elements: Homing missiles,
Alien-aim and the Boss-laser (see chapter 8.4. Game AI). Common for these
elements, is a more or less simple agent strategy that reacts directly to an input
concerning the position of the player.


This approach was prioritized due to the processing limitations of the target device,
which along with our comprehensive graphics, entailed that we could not implement
too steep AI in terms of complexity. However, on sequential levels one could favor
the use of more intelligent behaviors over graphics since the general concept and
surroundings have been established in the first level.


To give an example, level 2 could make use of obstacles, not only for the tank but
also for shots and missiles. If say, a missile was unable to fly over buildings they
would have to find their way around them, which would require them to be rational
agents capable of making decisions between multiple options; hence pathfinding
agents should be implemented. This would also prove relevant if the game was to be
developed for multi-players. Here, the agents would have to make choices of which
target to attack based on anticipated success rates.


The paths of the enemy spacecraft could also be extended to execute pathfinding
decisions based on the A* Algorithm perhaps combined with flocking abilities that
would enable them to make unpredictable or various formations when attacking.


For more advanced encounters the enemies could be altered into a series of agents
with learning capabilities. If they were able to ‘decode’ certain behaviors of the
player and use this information to adapt their knowledge base, one could imagine a



                                                                                                   57
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



series of entities forming neural networks as seen on larger scale computer games.
However, it is unlikely that this level of AI could be implemented with success given
the size and scope of Cybertank 3000.




                                                                                                   58
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




11 Conclusions
The 2 main areas of this project has been the implementation of the game and the
report including AI research.


The main goal of the game part was to create a fully functional prototype. In our
opinion the development of the game from idea to graphics to final implementation
of the code has been accomplished to our full expectations.


The idea with a simple and known shoot’em up type of game has proven to work well
on a mobile phone. The game universe based on the idea of an outer space
environment containing a space station orbiting a planet could seem difficult to
visualize with the small amount of storage available. Due to these limitations the
final graphical design has been met with appreciations from all sides. The audio part
of the game failed to meet our expectations. The sound effects works fine when
plunging in some earphones in the N-gage, but when played through the speakers it
falls in and out. Although sound is not very important for mobile games as is the
case for a normal pc or console games, we would have liked to experiment a bit
more with audio.


During the course lectures a lot of code has been presented to use as a skeleton for
a game. From the beginning we had ambitions of creating all of the code ourselves.
This resulted in many difficult task to overcome, but has resulted in unique code,
which is specifically optimized for our game. A big issue in this whole project has
been the use of AI. We have applied AI on the enemies, the boss and their missiles.
We would have liked to use even more AI, but due to our main goal of creating a
fully functional level, this implementation will have to wait until the next level is
developed. At these final hours of the project we see the game as our own
independently developed product.


The 2 main goals of our report were to communicate the whole game development
process and to examine how AI techniques could be used to improve mobile game
play. In the report we have described the areas we find relevant in order to make
the project comprehensible to readers. We have examined some of the interesting AI



                                                                                                   59
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



techniques. The AI techniques we decided to evaluate were all some that we thought
we could make use of in the development process. Some techniques, like the use of
agents, were implemented in level 1 of the game. At this point we already feel that
the use of this relatively small amount of AI has improved our game play by making
the enemies appear intelligent. In the report we have given game examples including
pseudo code on the other AI techniques discussed, which we hope to implement on
level two. By doing this we feel we have shown that we understand the capabilities
of the discussed techniques. From writing the game examples we have great
expectations on how these techniques could improve our game play for a possible
level 2. Another sub-goal of the report was to analyze the effect AI has on the
narrative structure of the game. We feel that this analysis has given us some useful
answers to make sure we are using AI in the right context and under the sometimes
necessary restrictions.




                                                                                                   60
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




12 References
[1] Aristotle’s
[2] For more information on the Hollywood model see:
http://www.dfi.dk/dfi/undervisning/dengode/plottet.html
[3] http://www.jesperjuul.dk/thesis/
[4] http://www.newlc.com/article.php3?id_article=25
[5] http://www.old-computers.com/museum/computer.asp?st=1&c=65
[6] http://www.amigaforever.com
[7] http://www.sciencenews.org/pages/sn_arc97/8_2_97/bob1.htm
[8] http://www.duke.edu/~tlove/civ.htm
[9] http://www.generation5.org/content/2000/alife.asp
[10] When an occurrence involves one or more methods it is called an event.
[11] http://www.extremeprogramming.org
[12] http://www.eclipse.org
[13] http://eclipseme.sourceforge.net
[14] Rabin, 2002
[15] http://www.abelard.org/turpap/turpap.htm#universality_of_digital_computers
[16] Norvig, 1995
[17] Minsky, 1985
[18] Norvig, 1995
[19] Norvig, 1995
[20] http://cs.aue.auc.dk/~conor/courses/computer_games/index.htm
[21] Valente, 2004
[22] http://www.red3d.com/cwr/boids/
[23] http://www.generation5.org
[24] http://www.red3d.com/cwr/boids/
[25] Tom Scutt, AI Game Programming Wisdom
[26] http://www.siteexperts.com/tips/functions/ts20/page2.asp
[27] http://www.siteexperts.com/tips/functions/ts20/page2.asp
[28] Minsky. 1985
[29] http://cs.aue.auc.dk/~conor/courses/computer_games/res/
week16and17_MED6_connectionism.ppt
[30] http://uhavax.hartford.edu/compsci/neural-networks-delta-rule.html
[31] Translated from his thesis ‘A battle between Games and Story’


                                                                                                   61
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7



[32] http://www.duke.edu/~tlove/civ.htm
[33] http://www.forum.nokia.com/seap/
MIDP_APIs_and_Nokia_Extension_APIs_Hemant_Madan.pdf
[34] http://www.jcp.org/en/jsr/detail?id=135
[35] http://www.javaworld.com/javaworld/jw-11-2003/jw-1107-wireless.html
[36] This feature escaped our prototype due to our limited production time.
[37] http://www.forum.nokia.com/html_reader/main/1,,2768,00.html
[38] http://www.chilinet.dk/content/article.asp?articleId=7737
[39] http://www.chilinet.dk/frikvarter/frikvarter.asp
[40] http://www.gamespot.com/ngage/sports/fifasoccer2004/index.html
[41] http://www.splintercell.com/
[42] http://www.gamerankings.com/itemrankings/simpleratings.asp
[43] http://www.finalfantasy-spiritwithin.com/ and http://www.sciflicks.com/aliens/
[44] http://www.enlight.com/x2/
[45] http://ghoul.flipcode.com/
[46] Beats per minute.
[47] Layered sound with several tones or frequencies playing simultaneously.
[48] http://www.telecom1.com/pdf/GA16.pdf
[49] http://www.xboxusersgroup.com/forums/showthread/t-20803.html
[50] http://www.nokiainfo.net/info/article3c.php
[51] This would require an upgrade to the MIDP 2.0 media API.




                                                                                                   62
C YB E R TA N K 3 0 0 0   |   C O M P U T E R   G A M E S   S P R I N G   2 0 0 4   |   GR O U P   7




13 Litterature

Marvin Minsky 1985, ‘The society of mind’
Steve Rabin, 2002 ‘AI Game Programming wisdom’




                                                                                                   63

				
DOCUMENT INFO