Game Design and Artificial Intelligence - Bournemouth University

Game Design and Artificial Intelligence 

David Hopkins 


Contents 

Game Design and Artificial Intelligence..............................................................................................1 

Contents............................................................................................................................................1 

Abstract.............................................................................................................................................1 

Introduction......................................................................................................................................1 

Design...............................................................................................................................................2 

The Concept..................................................................................................................................2 

Design Research...........................................................................................................................3 

Background Story.........................................................................................................................4 

The C.O.M.P. (Corporation of Mineral Production)..............................................................5 

Hwetre ..................................................................................................................................5 

The Hwetrese Space Fleet ...................................................................................................5 

The Orains ............................................................................................................................5 

The Silver Bullet .................................................................................................................6 

Gameplay......................................................................................................................................6 

Character Statistics.......................................................................................................................7 

Primary...................................................................................................................................7 

Physical..................................................................................................................................7 

Mental ....................................................................................................................................8 

Social......................................................................................................................................8 

Special Skills..........................................................................................................................8 

Hidden Attributes...................................................................................................................8 

Spaceship Battles..........................................................................................................................9 

Implementation...............................................................................................................................12 

Handling data..............................................................................................................................12 

Artificial Intelligence and Finite State Machines.......................................................................13 

Space Combat.............................................................................................................................16 

The Heads up Display.................................................................................................................17 

Learning QT.........................................................................................................................18 

Problems Encountered................................................................................................................18 

Conclusion..................................................................................................................................20 

Acknowledgements........................................................................................................................21 

References......................................................................................................................................21 

Bibliography...................................................................................................................................21 

Abstract 

The aim of this report is to research into game development, build the foundations for a solid game 

concept and to research into Artificial Intelligence involved in game development. 

Introduction 

There are a whole series of games developed over previous years that have attempted to simulate 

Page 1 of 22


David Hopkins 

human behaviour through artificial intelligence. Many of these games however never seem to be 

entirely believable due to a lack of memory in the AI characters of player events. Understandably, 

many recent games are designed to leave only a small amount of processor speed dedicated to the 

Artificial Intelligence due to high quality graphics, large scenes and the game engine physics. This 

in turn means that the AI is left to emulate human behaviour using as little processor time as 

possible. It is up to the programmer to develop effective and efficient ways of representing human 

decision making through the AI. 

Many strategic Roll Playing Games often revolve around a central character aided by a small group 

of other chosen individuals, allowing the player to select a team that suits his methods and favoured 

strategies. This is a vital factor of the game design and if the player selects an unbalanced team, he 

will regret his actions later on. “Baldurs Gate” is the main reference here, although there are many 

others that use similar approaches (“final fantasy” , “ albion” etc.). Baldurs Gate uses a “ reputation” 

statistic which measures how famous/infamous the posse are. The non player characters (NPC) 

then use this number to build an opinion on the player. If there is a great difference between the 

teams reputation and the characters personality, the character will threaten to leave the group. This 

is a form of artificial emotion. 

Artificial Emotion is an intriguing feature which many games now use to assist the non player 

characters. It can be used for an NPC to keep track of specific player interaction, and thus allows 

some specific memory. It is an effective way of emulating some human emotions and therefore can 

be used to give effective and believable responses. The purpose of this project was to research 

computer game design and artificial intelligence as well as constructing a game design based on a 

concept I had been developing over the summer 2004. The concept for the game is based on 

working alongside a temperamental crew which reacts to the player actions, but through both small 

events and large alike. Through use of the artificial emotion rules, the non player characters will 

judge the player'sactions and will react accordingly based on its statistics. The final product will 

hopefully show some resemblance to the concept and provide a basis for much of the playability. 

Design 

The Concept 

Team based Roll Playing Games are often about selecting your squad and developing them through 

combat situations to give them experience allowing them to advance through levels and skills. It 

could be considered a form of man management in selecting your team and keeping the group 

balanced, but this project intends to take it a level further. The stories in these games tend to 

unravel based on the characters in the team through the prescripted story. This makes a game 

interesting the first time round, but once the player has seen the repercussions of having a specific 

character in his team, it is easy to adapt a second time round. For this game, although some stories 

are an inevitability, it would be a real innovation to have more unpredictable developments based 

on the characters. The best manner to address this would be through having the characters not only 

react to you, but with their fellow compatriots. 

The setting is sciencefiction. The players objective is to build a reputation. A reputation of good 

Page 2 of 22


David Hopkins 

will and peace by becoming one of the greatest traders in the pirate lands, or an egregious arrogant 

leader of a terrorist pirate organisation. The story is open ended and it is up to the player how he 

wishes to develop the narrative. The player acts as the leader of a small trading project and has the 

responsibility of rounding up a team of followers who can assist in the running of a starship. At the 

foremost stages of the game, the majority of the crew is chosen for him, so as to educate the basic 

functionality. However, the option then arises to restructure the team. The player then has to search 

for potential employees and it is here where the challenge begins. 

The main game elements involve: 

• Judging the non player characters; 

• Man management during missions; 

• Strategic space combat actions; 

• Earning money; 

• Developing a world reputation. 

Somewhere in between a historical naval battle and science fiction shows such as Star Trek is how 

the vision of the space combat sequence can best be described. The action should be viewed real 

time, although the damage is done sequentially. This is to allow the player to be able to react to any 

events that may occur in the ship. When events in the ship combat get tough, a poorly lead crew 

will exacerbate the situation. The more damage done to the ship, the less experienced characters 

become more likely to panic and the composure levels become of greater significance. 

Design Research 

“ This is just one of the as yet unsolved questions in games – if death is indeed trivial, if we can 

always have another chance, then how do we make a life a valuable commodity? We also never 

have any real consequences for our actions, so the lives of other ingame characters are likewise 

instantly devalued.” 

Lee Uren, [Uren00] 

This comment by Lee Uren provides a good foundation for the game idea. Many modern 

commercial games veer towards cinema in style of dramatics and these are expressed clearly 

through narrative stories and the characters. However with these overly emphasized situations the 

sense of believability can be degraded as most of these changes in plot may not be edited by a 

players actions. This is the same for many in game characters, no matter how the player interacts 

with them, they will always act the same way. The player often has little effect in changing the 

atmosphere within a game. This is something that this project wanted to explore. 

“ For every choice, a consequence” – Fable, Lionhead studios, box slogan. 

Peter Molyneux of Lionhead studios has attempted to fulfill this problem in “ fable” . The game 

promised more than it could deliver, but still ended up being a fun encounter. The main character 

carries two main “s ocial” attributes in the game which the NPCs react to, renown and alignment. 

The NPCs reaction do seem fairly believable in the game, although none of the characters have a 

Page 3 of 22


David Hopkins 

memory of previous events once you have moved into a different area and they solely react based 

on the players social attributes. 

“ The worst kind of game are those (usually adventure games) in which it'sobvious that the 

designer thought he he was writing a film or a novel. It'sthe frustrated author syndrome, and you 

know you're bearing the brunt of it when your choices in the game have shrunk to one linear path, 

or when you find yourself scrolling through never ending cutscene dialogues waiting to get to the 

action. These designers are entertaining nobody but themselves.” 

Dave Morris and Andrew Rollings [Rollings00] 

An engaging and believable story is one good way of drawing in the players attention, a good 

example of this is nintendo’ s “Z elda” series and all through the “final fantasy” series. The one 

setback to this is that the main story is often a linear event, and is not affected by the methods of 

how a player has gone through the story. Fable yet again has adhered to this, and has two potential 

endings , with both an ending for an evil and holy individual, although you are still forced to fight 

the inevitable final battle at the end. “Escap e Velocity: EV Nova” goes one better than this, and has 

a choice of six stories which support the main exploratory trading adventure. 

Many games now implement main stories with plenty of smaller stories and side quests. These help 

add a lot more detail to the game world and give the player options as to whether he wishes to fulfill 

these quests. “B aldurs Gate” utilizes this idea, and it certainly adds character to the world, but the 

main story is far too linear and there are many occasions where you are forced into encounters, or 

along specific routes. 

One of the main features of the concept is that man management will be key. One of the best 

current examples of this is the “championship manager” series by Eidos, or more recently 

“F ootball Manager 2005” by Sega. The main objective is to manage your football team through to 

league and cup success through shrewd market purchases and tactics. However this game also 

involves several interesting man management techniques. The players can be very temperamental 

at times, going through both good and bad patches of form regularly. Players that haven'tbeen 

selected for games recently may hand in transfer requests and become unhappy, affecting their 

overall performance in games. Other events similar to this can occur. All of them have been built 

around the player and could be avoided if the game was restarted. This is a terrific example of how 

the crew should be during the game. 

All of the games mentioned in this section have a lot that can be learned from, and hopefully much 

of this can be incorporated into the design and implementation. Though it is easy to get carried 

away at this point, it is best to try and keep things simple. 

Background Story 

The galaxy was once forged by a relationship between two races, the Orains and the 

Hwetrese. The Orains discovered the knowledge of the “ LightDrive” which allows spaceships to 

travel faster than the speed of light by converting a ship into molecules of light matter. Through 

this invention, the Orains become a race of discoverers and explorers and began setting up colonies 

Page 4 of 22


David Hopkins 

on other worlds. The Hwetre are a highly technological race which thrives on natural resources. 

However due to overwhelming demands from their spacecraft, The Hwetre have had to mine from 

other nearby planets for more fuel. To keep their homeworld habitable, they began researching into 

terrorforming environments, and after a few experiments have become successful. When the two 

races met, a new relationship was forged and a spacefleet designed to explore and keep order was 

created. This was known as the Trekan space fleet. 

Peace reigned throughout the galaxy for several decades. But the Hwetrese need for natural 

resources was proving too demanding as more citizens were being able to purchase more affordable 

space craft, and the need for fuel was highly extravagant. The Trekan space fleet issued demands 

that the Hwetrese should convert to natural energy. The C.O.M.P.are against this and force the 

Hwetrese government to stick with fuel but implore that they will begin researching effective 

manners of using solar or hydrogen based fuels. The tension between the two races mounted and 

this evolved into a full scale war when the Hwetrese agency along with the C.O.M.P. had developed 

a super sized ship, known as the “ Doombringer” . This ship had the ability to terrorform planets 

rapidly into uninhabitable lifeless rocks. 

Orais is destroyed by the Hwetrese space fleet in the “Ba ttle for Orais”, a nd the remaining survivors 

are forced to flee to the “pi rate lands” , unchartered areas which are ungoverned. 

The C.O.M.P. (Corporation of Mineral Production) 

The largest fuel producer of the known galaxy, and one of the biggest craft manufacturers. Began 

as a family business, and expanded greatly during the space age when it was selected as the 

manufacturer for the Hwetrese Space Research Company. Due to the status and supplements of the 

COMP, they own the highest position on the board for the Hwetrese Space Fleet. 

Hwetre 

This is the capital of the known galaxy, and home to the Hwetrese Space Fleet. This is heavily 

industrialized and the air is stale from fumes and the over pollution. The Landscapes vary from the 

architectural amazement of the great cities to the deserts and seas. There is little natural plant life 

left apart from several protected reserve areas. 

The Hwetrese Space Fleet 

Now Split into quadrants to help enforce their status within the galaxy. All quadrant overseers are 

part of the board, who share the responsibility of control. There are many patrols and spacedocks 

run by the Hwetrese fleet. 

The Orains 

Driven from their home planet by the Hwetrese, they now dwell in the unmapped territories. They 

are now a split race with few command ships to build an effective resistance. Despite this there are 

a few have sworn revenge on the Hwetre and formed pirate organizations to fight against the new 

Page 5 of 22


David Hopkins 

order. 

The Player 

The player is a halfbreed of Orain and Hwetrese and grew up living on Orais until the great war, 

during which he/she was separated from his/her parents. Brought up during the teen years in an 

orain refugee orphanage run by some exmilitary personnel in the pirate lands. He/she received a 

military education, disciplined in starship combat. It is now time to leave the orphanage and begin a 

new life. 

The Silver Bullet 

A modified armed transport craft. Runs on fuel. Solar Energy reserves. Not the fastest, but one of 

the most versatile. Modified for faster turning during combat situations. 

The ship has several hot spots. These are damageable zones in the craft, and if hit during combat 

when shields are down, will hinder the ship. If there is an engineer on board, these areas can be 

fixed. Some of these areas are vital to the game, if destroyed, the ship is destroyed. Some areas if 

damaged will cause severe problems. 

• Engines(left); 

• Engines(right); (if both of these are damaged then the ship cannot move) 

• Laser cannons (manual/auto)(top); 

• Laser cannons (manual/auto)(bottom); 

• Laser cannons front; (these are controlled by the pilot) 

• Shield generator; 

• Life support; (This is vital to the crew! They have a minute to get spacesuits on unless this is 

repaired) 

• The bridge; 

• piloting controls; 

• Computer mainframe; 

• Power Generator; (if this is damaged, the ship can be destroyed) 

• Fuel Tanks; (again if this is ignited, the ship can be destroyed) 

Another problem that could occur is a hull breach, which could easily happen without shields. If 

this happens to a section of the ship, the area will be quarantined and not accessible to crew 

members without a space suit. For the purpose of the demo, the damage will probably be restricted 

somewhat. 

Gameplay 

Select your crew: 

Pick which characters you want for your crew, assign wages at values based on player skills with 

rates(minimum, standard, generous, extravagant). crew above standard wages will be more likely to 

be content with the opposite being true for those with minimum wage. *in the full game, it would 

be my intention for the player to start off on a planet where he has to find a selection of characters 

Page 6 of 22


David Hopkins 

that he feels could fill the position. This gives the player a chance to learn more about the world 

and the characters before setting off on the first mission. This is very much in a similar style to 

“B aldurs Gate” . 

Assign positions: 

There are potentially 4 positions to fill, although they are all optional. The player could choose to 

have no crew, but this would be foolish as no one single character could run an entire ship during 

combat! 

• The Gunner is responsible for all ship fire including control over laser turrets and missile 

launchers. 

• The Engineer takes the position of having to redirect power through out the ship during combat, 

and is a general dogsbody around the ship. He can undertake or lead with an assigned apprentice 

repair and upgrade operations on the ship out of combat. 

• The Pilot has the all important job of maneuvering the ship. He follows the orders straight from 

the captain and should always be under strict supervision. 

• The Navigator has the role of scanning for ships and reporting back to the captain. He analyses 

tactics of opposing enemies and should have a good background knowledge on the various space 

systems. A very useful route finder for long missions. Not always necessary, but useful to have, 

especially for new players. 

Once the player has chosen his crew with allocated positions and wages, the mission briefing 

begins. Here the player gets to set longterm shifts and work for the crew (i.e. For when they're not 

in combat, do battle station drills or upgrade or mend parts of the ships). The journey route is set by 

the player, with assistance from the navigator (who can set the route automatically). (in the full 

version, supplies (eg. Missiles, ship upgrades, food) 

Character Statistics 

Any good game tries to keep things as simple as possible yet attempt to do something complex in 

nature. This game requires several base level stats which will be used throughout. These stats are 

billed into four main categories primary, physical, mental and social. All attributes are measured 

from 0 to 100. 

Primary 

• Age: This affects mainly physical attributes, the older the more degradation may occur. 

Learning is also affected. 

• Race: Different races often lead to discrimination due to the history of the world. 

• Reputation: Unknown to Legend. All characters will have some form of fame. 

Physical 

• Dexterity: This attribute is prime for many special skills, including engineering, piloting, 

gunning and weapon combat. Also key for additional skills like gambling. 

• Stamina: This judges how much physical labour a character can undertake. This judges 

how much a character recuperates during rest periods. 

Page 7 of 22


David Hopkins 

Mental 

• Wisdom: This is obviously key in many special skills and affects learning rates as well. This 

also key to decision making. 

• Composure: This is key in extreme situations, such as combat situations or when decision 

making. 

Social 

• Character: This describes the characters personality, ie good or evil. 50 is neutral, 0 is 

chaotic and 100 is angelic. 

• Influence: An important attribute that determines how much a character can persuade others, 

and is vital to a leader or captain. 

Special Skills 

On top of these basic skills, the characters also have traits and special skills. No character will have 

each trait, but they can learn new traits as the game progresses. If they don't posses a trait that is 

required during the game, a basic level will be created at level 0. All these attributes accumulate 

with experience and through learning. 

• Captaincy: A captaincy skill helps a captain gain respect from crew mates 

• Gunning: For the use of craft or vehicle laser cannons. 

• Engineering: This is important for repairing and modifying spacecrafts, vehicles and 

weapons. 

• Medicine: For doctors or medics, 

• Piloting: useful for being able to pilot ships 

• Navigating: This is important for discovering safer and faster routes through the galaxy 

• Shooting: this is shooting accuracy with pistols and rifles. 

• Electronics: For computing and rewiring circuitry. 

Additional Skills Traits 

These are mainly non academic skills and are just tend to add additional personality to the 

characters. For example, gambling, alcoholic, lechery, sport, politics ... etc. 

Hidden Attributes 

All the statistics listed above can be viewed within game by the player to help judge whether they 

are the character to hire for their ship. However there are also a list of temperamental attributes 

which can change dramatically based on specific events. 

• Opinion on the player: (between 100 to 0) This judges whether an AI character likes you or 

not. 

• Opinion on other AI character: (between 10 to 10) This can lead to friction between the 

Page 8 of 22


David Hopkins 

crew. 

• Longterm Happiness: A happy worker is a better worker! Keep your crew happy to avoid 

problems. 

• Stamina (cumulative): This is a random counter which decreases during heavy labour 

events, and recuperates during rest periods based on the characters nonhidden stamina 

attribute. 

Spaceship Battles 

The idea is that the player would have minimal control over what happens to his ship, and it is down 

to the rest of his crew to carry out his commands. This then makes it imperative to choose the 

correct crew and treat them in the right manner. The enemy is not outside, but inside. It is the crew 

that must be kept happy to keep them working well. 

As captain, the player can order the pilot to fly to any object (ideally he could point to a position on 

a map). This would mainly be flying to ships or navigation points (which allow the ship to leave 

the territory). A list of commands for combat should also be listed. 

Below are a couple of game references for the visuals that this space Combat simulation should 

look like. 

Page 9 of 22


David Hopkins 

Fig 1.1 – Operation : Inner Space 

Page 10 of 22


David Hopkins 

Fig 1.2 – Escape Velocity: EV Nova 

Page 11 of 22


David Hopkins 

Implementation 

When starting development of the game, a lot of time was spent designing the character and crew 

AI side of the program but most of the coding time was involved with the space combat system, as 

this was pivotal to getting a functioning and fun product. It required these visuals for understanding 

what the player is attempting to achieve. The main factor proved to be time and learning. At the 

end of this project, there was an emphasis on producing something that was fun to play and 

interactive with the player but could still carry across much of the concept work. Once the space 

combat system was developed, there was little time left to spend on the crew FSM system, however 

some items have been implemented to indicate what could have been if more time was available. 

Handling data 

When designing a skeleton structure of the game engine, the file system was split into three main 

sections. One of the sections would be dedicated to the interior of the ship, checking on the 

conditions of each of the crew members and working out the respective work rates. The second 

section consists of the ship fighting, updating and drawing all objects in the world space. The final 

section is the main section where everything must be handled including the opengl setup and calls 

to the other two sections. 

This was the first time I had attempted to do a programming project using multiple files, and 

therefore it was key that I passed the correct data around for the game engine to operate. The main 

pivotal point for this was between the ship combat and the ship interior. The player ship 

information needs to be passed to the heads up display, the crew work rates need to be sent to the 

combat system and both sections need to be able to handle key presses. The first attempts at 

producing the space combat system were flawed due to a lack of cohesion when attempting to pass 

data to and from the space combat file. After learning the uses of object orientation, this problem 

was simplified. Object orientation allows information that previously couldn’ t be shared from 

specific modular files (eg. shipCombat.cpp does not know of objects in crew.cpp) to be accessible 

by the use of placing the data in sets of interacting objects [macey00]. Using classes to contain the 

data, through inheritance and the use of the STL(standard template library) [bateman00] I was able 

to format a much neater and more accessible system. 

Page 12 of 22


David Hopkins 

Fig 2.1 – Overview of the data handling in the game 

During this project, it was imperative to try and keep the number of global variables to a minimum 

if possible as this would be more liable to errors due to repeating names. This was problem was 

solved by keeping most of the data rapped up in variables in lists with object orientation. The use 

of Object Factories [rollings01] could also have made a large difference in keeping the code tidy, 

but a lack of time for the implementation prevented this. 

Artificial Intelligence and Finite State Machines 

For this project, the Artificial Intelligence didn’t need to be overly complex, though at one point 

further research into genetic algorithms and neural networks [aijunkie01] looked a distinct 

possibility. Neural networks, based on genetic algorithms, try to simulate the way the human brain 

works by taking a number of inputs into a “ neuron” which effectively calculates a result and returns 

an output. As impressive as this method of AI is, it seemed needlessly awkward considering what 

the program required. 

During the first attempt at the space combat situation, I had already stumbled on the functionality of 

the FSM (finite state machine). I was working on a system that used a switch statement based on a 

state which was one of either, fly towards, stop or drift. This is an example of a very simple FSM. 

Page 13 of 22


David Hopkins 

Fig 2.2 – The layout for the crew AI working state. 

“ Because game character behaviour can be modeled (in most cases) as a sequence of different 

character “ mental states” – where change in state is driven by the actions of the player or other 

characters, or possibly some features of the game world – game programmers often find that finitestate 

machines are a natural choice for defining character AI.” – p284 AI wisdom [Houlette00] 

For the Crew AI, there are two FSMs. One that isn't fully implemented in the game which is the 

basic FSM for working state (see fig 2.2), the second is the emotion state machine. The working 

FSM is designed to find out whether an NPC is working on a job (eg. Gunning, piloting etc.) or is 

idle due to refusing orders or finishing a current one or if it is moving to a new location based on a 

new order. The emotion state machine works slightly differently but uses the same theories. 

Artificial Emotion. 

As previously mentioned in the design, the artificial emotion is a method for the NPCs to judge the 

player through the decisions made based on his statistics. Each NPC carries an OPINION statistic 

on each character in the crew, including the player. This counter, between 0 and 100, changes as 

the game progresses based on the input from the player and events happening through the ship. The 

emotion state machine then uses this counter as part of the calculations to figure if there any 

changes in emotional states. The class for the AI is defined below: 

class crewAI : public crewMember 

{ 

public: 

std::string getType(void); 

int state; 

int emotion_state; 

int wages;//WAGES is 14, 1 being minimum, 4 being max 

int aggression;// use this to judge orders. 

int discipline;// and this! 

bool refuse_order; 

int ORDER; 

double OPINION_player; 

double OPINION_crewAI; 

Page 14 of 22


David Hopkins 

double HAPPINESS_general; 

double HAPPINESS_daily; 

double FSM_TIMER; 

int FSM(); 

int emote_FSM(); 

void update(double); 

}; 

crewAI(int); 

~crewAI(); 

The key to the NPC’s judgm ent is based on the aggression value in the demo game, although ideally 

more statistics would be considered. Both the pilot and gunner can be given the commands based 

on their aggression, and both have their preferred aggression factors. If the gunner is an aggressive 

character, he will not appreciate being told to fire slowly and accurately. If this occurs during the 

game, the NPC’s OPINION_player will decrease by one. This is only a minimal amount, but if the 

player continuously issues this order the NPC will become more likely to refuse new orders and will 

switch to doing what he would rather do. However, good performance will counter this, every time 

experienced is gained, the OPINION_player will be increased based on the amount. 

The emotion state FSM often uses the OPINION_player to help with calculations to see if the state 

needs to be changed. Every five seconds the function will be called: 

If(refusing_order false) 

Test if orders to be refused(); 

If(refusing_order true) 

Test if Opinion has increased; 

Test if orders to be refused(); 

If true, refusing_order false; 

If(state is normal) 

{ 

if(FEAR function() returns true) 

return new_state; 

if(LUCK function() returns true} 

return new_state; 

} 

If(state is not normal) 

Check to see if state returns to normal; 

The above pseudo code will find out what emotion_state the NPC is in and if it is taking new 

orders. The program uses this information elsewhere in the program to change the NPCs attributes 

if needed 

Page 15 of 22


David Hopkins 

fig 2.3 – The bridge of the ship with the player character and the AI pilot 

Space Combat 

The space Combat was where most effort was based during the production of this project. For the 

demo, all though there was not enough time to implement a three dimensional version, it was 

possible to work on a two dimensional approach, with an x and y axis. Three attempts were made at 

producing the AI for the ships. The first experiment was creating a ship that would follow a target 

around. This was done by calculating the distance between the ship and the target in both x and y 

axis, calculating the angle between them and adding a velocity based on the angle. Much of this 

was taken from my previous programming project from last year, as this used the same theory to 

have an object always look towards a target. However there was a drawback with this. The ships 

could only rotate 360 degrees. Once the angle reached over 360 degrees, the object would have to 

rotate all the way round the other way as the object believes the angle to be a small value (as the 

value over 360 would then switch to 0). This method required some tweaking which would allow 

the object to follow an object by rotating around the quickest way. The way this was solved, was 

through working out the difference between the current ship rotation and the desired angle. If this 

difference is less than and absolute value of 180 degrees, the ship can rotate based on whether angle 

is smaller or larger. However if the difference is bigger than 180, then we have to reverse this 

situation as the target has gone full circle. This took a while to discover, but it is fairly effective. 

if((rotationangle)>180) 

{ 

if((rotationangle)>0) 

rotation+=(70.0*TIMER); 

} 

if((rotationangle)


David Hopkins 

} 

Fig 2.4 – Both ships will always be aiming to look at each other. 

The ships can carry different speeds, and potentially different rotational speeds aswell. I have tried 

to demonstrate this in the demo by having two types of enemy ships, fighters and scouts. The 

scouts are three times faster, but do less damage. 

Using the STL this allowed a better organization of the objects in the scene. All the objects the 

player can target (ships, navpoints and planets) are in one list. Each one of these objects are 

inherited from the base class c_spaceObject, and by using the method of casting down, all the 

objects could easily be pushed into a standard list (which is effectively a linked list for c++). 

This list is then accessed several times through the program. Once for drawing the objects, 

updating them and filtering for a target. The Player defines the target to aim towards through 

filtering through this list. 

The damage to the ship is calculated through a random number roll(between 0100) against the pilot 

workrate statistic(calculated in the crewAI). Damage against other ships uses the gunner rating 

verses a roll. 

The Heads up Display 

“ I find the interface is one of the hardest aspects of game design. It should be intuitive and icons 

should be kept to a minimum. I have never got an interface right (the) first time. It'sone of those 

things that should be tested and tested until everyone is happy with it.” Peter Molyneux. P47 

[Molyneux00] 

Page 17 of 22


David Hopkins 

Fig 2.5 – an experiment with Qt working with OpenGL. 

Learning QT 

The game required quite a complex HUD, originally the method for this was going to be through 

creating textures for each ASCII character. However, further research into the QT software 

revealed another potential solution. QT offers a host of functions for creating some simple looking 

but effective HUD tools, including push buttons, radio buttons and tick boxes. It works quite 

simply through a slot and signal algorithm [macey01]. Whenever a message needs to be sent from 

an item, like a push button, it calls its signal function which is sent to one or more slots of other 

objects. The most useful element is that it can display opengl scenes in a window, with a frame of 

buttons on the outside. The only setback is that it does slow down the opengl program, but it would 

be a useful for small programs so would have worked quite nicely with the demo. 

In the end I decided to use the glText to display the information, though it is still my intention to 

use qt for a HUD which the player can interact with. 

Problems Encountered 

I originally setup the game to be able to switch between levels easily based on a selected global 

levelNumber using the following code: 

Switch(levelNumber) 

{ 

case (1): 

{ 

draw all objects level_1; 

} 

break; 

} 

The program had a strange bug when I attempted to start on a different level number and attempted 

to switch to the current level. The enemy ship speed seem to rocket for some unknown reason. I 

originally thought it could be to do with the timer, but as I disabled this at the beginning of the level 

Page 18 of 22


David Hopkins 

loading, this was ruled out. 

When I switched machine I realized that all the starships were moving at a much faster speed. I 

realized later on that this was due to the ship update function not incorporating a timer amount when 

calculating the velocity. This was easily fixed by editing the speed values and multiplying the 

velocity by the timer to get the new ship position. 

Once I had discovered about casting down inherited objects into a global list of the base class, I had 

an issue with occasionally needing to be able to access items only in the inherited classes. By 

including a function called getType, which returns the name of the object type, I could cast a new 

pointer of the inherited type to the same data as the base class pointer. I have Leigh Mcloughlin to 

thank for this! 

if(gunman>getType() == "crewAI") 

{ 

crewAI *NPC = (crewAI*) gunman; 

... 

} 

The main problem involved with this project was purely the time limit. I ended up being so 

distracted by the space combat side of the program, and left only a small amount of time on the 

crew AI. This is a huge shame as I had done a lot of research into this, but have little to show for it. 

Further Development 

On a personal note on this project, there is so much more that I would like to achieve with this 

game, as the current demo does not do the concept justice and I intend to continue this work at a 

later stage. I have already mentioned that I would like to take this game into the third dimension at 

some point (properly! not just pseudo 3d), but for the moment I'mlooking to continue developing 

the twodimensional version. 

Space Combat 

• Develop FSM for ships, give the enemy better AI. Have different styles of attack runs for the 

enemy ships and evasion manoeuvres (eg. 3 point turn, barrel rolls, ship banking) 

• Have specific areas to target, allowing ships to be disabled through damaging specific areas, 

rather than simply being destroyed. Shields could also be implemented 

• Capital ships. Having giant sized ships would be quite an interesting feature, although this is 

more of a chrome feature at the moment (ie. It would be nice, but not necessary) 

• Group AI tactics for enemies and allies alike. This would involve having formations, and 

enemies can judge on attacking and retreating based on a group strength. 

• Radar. Either having a small radar on the screen, or an option to switch to an overview of all the 

ships in the area (similar to “ Homeworld” ) 

The Crew 

• Allow movement for the crew, using the A* path finding system. They would then be able to 

move and switch between jobs and in the case of the engineer, he would be able to move to 

repair the damage around the ship. 

• Create more emotions for the characters. Currently only a few are implemented, more emotional 

Page 19 of 22


David Hopkins 

states leads to a less predictable game and it would be far more interesting. 

• Develop more orders to interact with the characters. The player should have more freedom in 

the gameplay and not feel too restrained. 

• Look into the psychology behind human emotions to allow more realistic reasoning behind 

changes in character states. 

Story and Missions 

• The first part of the game needs a little work, I hope to have a good background story for the 

main character and subsidiary characters. 

Conclusion 

This project has been ideal as a revision for programming, and I have learned several useful 

techniques for developing games through the use of object orientation. The final piece however was 

a disappointment, as I did not achieve what I set out to reach. The hope was that there would have 

been a playable game at the end of the project. Restarting the project on no more than three 

occasions certainly did not help the situation, although i did learn from my mistakes on the previous 

attempts. 

In the end though, I really only ended up with a combat system that had only a few small features. 

The combat lacks the interactive element due to a lack of controls. With more time to expand on 

this project, there is a lot more that could easily be done and I am convinced that this could blossom 

into an innovative game. 

Page 20 of 22


David Hopkins 

Acknowledgements 

Phil Allen – for encouraging me to concentrate on story and design issues. 

Stephen Bell – for all his advice during tutorials. 

Eike Anderson – help with researching AI. 

Leigh Mcloughlin – general programming advice. 

References 

[Uren00] UREN, L., 2003. Computer and Video Game Design Issue. 

[macey00] MACEY, J. 2004. BA computer visualization and animation, computer programming 3 

lecture notes 

[macey01] MACEY, J. 2003. QT and OpenGL. 

[bateman00] BATEMAN, R. 2004. Programming with the Standard Template Library. 

[Rollings00] – p13 ROLLINGS, A. AND MORRIS, D., 2004. Game Architecture and Design: A 

New Edition 

[Rollings01] – p561563 ROLLINGS, A. AND MORRIS, D., 2004. Game Architecture and 

Design: A New Edition 

[Houlette00] – p284 FU, D. AND HOULETTE, R.2003. The Ultimate Guide to FSMs in Games 

[Molyneux00] – quoted in p47 ROLLINGS, A. AND MORRIS, D., 2004. Game Architecture and 

Design: A New Edition 

Bibliography 

CRAWFORD, C. 1982 The Art of Computer Game Design 

PEABODY, S. 1997. The Art of Computer Game Design [online], Washington State University. 

Available from: 

http://www.vancouver.wsu.edu/fac/peabody/gamebook/Coverpage.html 

[accessed 26 th February] 

UREN, L., 2003. Computer and Video Game Design Issues 

J. VINCE. ed. Handbook of Computer Animation 

Cromwell Press, Trowbridge, Wiltshire: Springer, p127 

ROLLINGS, A. AND MORRIS, D., 2004. Game Architecture and Design: A New Edition 

United States of America: New Riders Publishing 

BATEMAN, R. 2004. Programming with the Standard Template Library, Bournemouth. 

Available from: 

http://www.robthebloke.org 


MACEY, J. 2004. BA computer visualization and animation, computer programming 3 lecture 

notes 

Bournemouth University, Poole. 

Page 21 of 22


David Hopkins 

MACEY, J. 2003. QT and OpenGL, Bournemouth University, Poole. Available from: 

http://dec.bournemouth.ac.uk/staff/jmacey/QT/index.html 


UNKNOWN AUTHOR & DATE. Genetic Algorithms in Plain English and Neural Networks in 

Plain English 

www.aijunkie.com 

[accessed 3 rd March] 

FU, D. AND HOULETTE, R.2003. The Ultimate Guide to FSMs in Games 

S. RABIN. ed. AI Game Programming Wisdom 2 

p283301 

http://www.worldvillage.com/wv/gamezone/html/reviews/inspace.htm 

image of Operation Inner Space 

http://www.captainz.net/evn_omega/sol1.jpg 

image of EV Nova 

Page 22 of 22

Game Design and Artificial Intelligence - Bournemouth University

Create successful ePaper yourself

Delete template?

Save as template?