Michael Goldborough, Game Programmer

For the past 10 weeks I have been part of a project team whose aim to develop a multiplayer XBOX 360 game. Here I give some reflection on the game development process and my role within it.

18th – 24th April 2011 (7)

I’ve done some beginer XNA tutorials to get a feel for project structure and XNA game development. This help to further determine what kind of work I can contribute to the project. I have been looking into menu systems and methods for saving player profiles and file structures for saving maps. This is something I will come back to later once the immediate work is done as it is something I’m just starting to understand. I also created a logo for the game using Adobe Photoshop.

25th – 1st May 2011 (8)

I started work on sound effects and music. I spent hours looking around for sound libraries that could be picked apart. Allot of the professional ones weren’t free as I was a bit naive to expect that there would be free ones of sufficient size and relevance. I was fairly overwhelmed by other distractions to make sound movement towards completion on sound. This week has brought realization about overzealous commitments which have had their effect on the progress of our project. This is also somewhat applies case for the others in the team. Due to this, I haven’t been able to pick up unforeseen work, particually on modelling and interface programming which I thought I could pick up and allow the other programmers to crunch for our Prototype milestone which is in June. I hope to make up this in the next week or two.

The game is sitting a point of having a player move around a sparsely populated space but still requiring some serious hours to resolve heavy slow code and lack of gameplay. Our eyes have been opened to the complexities of the tasks which even I thought were amply planned for but were still not achievable in our envisioned timeframe. Physics has subsumed far more attention then what I had hoped. The code efficiency on the XBOX 360 platform is also still sub-par. Both of these can be rectified by lots of crunching and extra allocation in this aspect. We should definently seek help with this aspect. These tasks will feature heavily in our development schedule for the next 10 weeks. This indicates that programming lies closely apon the critical path of our game and should be relieved of impediment, delays and distractions. For me, I will be taking graphic work for our game. It is quite an easy task but will still take some 2 weeks to make what we need for our early June prototype.

We have delayed a number of our games aspects such as the second character set modeling, gameplay complexity and test plans. We have been reluctant to reduce the scope of the project but the first things to go would be additional game modes, network programming and enemy AI and a number of maps. These would be a real loss to the game and would make our game less unique or attract an audience that is interested in only split screen games in only the Deathmatch format but would allow use to produce our core gameplay ideas to their full potential which is our number one goal.

2nd – 8th May 2011 (9)

I spent some time on game developer forums continuing to seek appropiate sound libraries and meanwhile found some tutorials and utilities to help create my own sound effects. I followed some links to some utilities and audio engineering software that fits our effects needs, that being: free and in stylistically consistent.

Allot of royalty free music I liked had the wrong kind of license which made it more difficult to find the diamonds in the rough as it was. While I decided not to make original music for the game in favor of sourcing it online (despite tips from the team that they may have friends that could help), I considered it.

9th – 15th May 2011 (10)

As our programming is behind schedule, we haven’t got to the point where we can test our sounds within a game environment. I created a sound set regardless informed by what I’ve learnt from other games. The advantages of going down this road of using a utility is that it’s free and somewhat unique, they also provided a method of saving my settings so I can make modifications to them later. I make a couple and left it for a later date and went searching the online free license. Allot of the sites were not that good and it took some time to learn how to use each site before even being able to filter through the music. where I found a mere one track that I found appropriate.

The project at this stage is generally lagging behind our expectations we have achieved an environment but without enough models to fill it and give the environment a game dynamic. We have a physics system, but one which isn’t meeting our expectations. We have an overall application, but one that runs slowly over its humps that we are yet to iron out with enough time and commitment. All these issues are affecting our ability to proceed on schedule and will also result in an unpolished prototype which I initially allocated three weeks to do.

16 – 22nd May 9 (11)

This week I completed a set of sounds for the prototype. Despite the utilities being free and requires little ‘capturing’. The disadvantages is that they sound a bit cheap because they sound a bit on the electronic side like they would fit well into an 80s synth pop music. Perfecting the sounds to minimize this feel took some time and I still left if a bit rough around the edges as we are kind of stretched and needed to move on. It would also be a waste if I spent too much time before we start testing the sounds I created for our sound library and left the full set of sound design until after our first prototype.

While finding music was quite an enjoyable part of the project, I was a little guilty about that enjoyment so I moved onto graphics work.

As with any artistic endeavor, I knew what I wanted to do before I knew how to do it. Space games usually have a cold sterile and technological feel. Nothing else seems to fit the genre so I stuck to what I knew and found out how to emulate different aspects of ‘space art’ that I liked. The first aspect was circuit like lines to frame the menus and the in game HUD. There was also lots of background space in the menus that I felt I had to fill so I looked for space art (ie Google images) and there were some brilliant illustrations of weird and wonderful space scenes. Some were planets with rings and moons, others featured different shaped galaxies, others had multi-colored dust clouds that resemble nebulas. I focused mainly on the later and with some lens flares to boot. I found some Photoshop tutorials that helped me get all these effects and used a color wheel to fashion a few scenes that would become the different backgrounds that appear in the menus.  I also chucked in a few shadows of some spacecraft (yet left their shape vague as we have yet to have our model scenes shared on our Dropbox.

Allot of these techniques can also be used for skybox creation which we also require. I’m going to be in contact with our lead artist more as this develops as we need to keep a well-defined art style.

23rd – 29th May (12)

By this point, it is clear that our ability to crunch for our already scaled back prototype in time for our early June milestone is slipping once again. Our prototype seems more to be one that demonstrates the art and physics of our game rather then a basic representation of our game idea. While there is still some two weeks before we finish our prototype, this is not what we hoped for.

To be continued.

Give Up, Robot: Nice little platform gem in an unexpected place.

In the development of network games, considerations of the different factors that affect players experience are a necessary part of design of computer games. The network which multiplayer computer games utilise is an important part factor effecting end user experience.

I seek to trace the development of TCP and UDP in relation of the Internet and then analyse current practices and issues in the utilisation of the Transmission Control Protocol and the User Datagram Protocol in online game design.

Introduction

TCP and the underlying IP were developed concurrently to the establishment of the Internet and the experience gained through use and experimentation on networks during the early days of the internet.

In the early days of the Internet’s precursor ARPAnet, it was originally a protocol named IP (Internet Protocol) that performed functions equivalent to those of both the network and transport layer in the OSI reference model. IP provided reliability at the transport layer while providing addressing at the Network Layer.

With an ARPAnet growing towards its technical boundaries in terms of capacity, the waste that IP implemented in terms of reliability of the transport layer came to be realised. IP was later separated in the implementation of the Transmission Control Program (RFC675) in the mid 70s and then became separated to TCP (RFC761) and IP (RFC760) at the start of the 1980s by DARPA. [1]

In the early 1980s internetworking of computers were not limited to the ARPAnet. Numbers of disparate networks such for commercial, research and academic purposes were in existence. Some of the earlier truly networked games grew as pet and research projects. A number of simple computer games were created as academic projects throughout the 1950s, 1960s and became more available in the 1970s with coin-operated machines and games installed onto mainframes at universities. [3] It took until the early 1980s until networks were beginning to be used to run video games.

With the installation of BITNET, an academic network became “the most widely used research communications network in the world for email, mailing lists, file transfer, and real-time messaging” towards the start of the 1990s. [4] BITNET did used the NJE (Network Job Entry) protocol (somewhat of an implementation of IBMs network [2]), and most users accessed it at their universities via a terminal of a connected mainframe which was time shared. Around 1982 the introduction of Text based persistent role playing games which operated via telnet such as MUD1 (‘multi user dungeon’) and MAD (‘multi access dungeon’) ran on these university mainframes, the latter widely credited as the first network game utilising BITNET while the former was licensed to CompuServe and run on their network after it’s initial life on a mainframe accessed via telnet. Others such games followed on the various disparate networks. [5]

ARPAnet was transferred to TCP/IP on Janurary 1st, 1983.[2] This opened the door to the implementation of UDP (RFC768), a transport layer protocol that worked over IP but was simple and fast because it dropped the reliability of TCP.

In 1986 academic networks like BITNET become integrated into CSNET (computer science research network). TCP/IP was used[2]. Around this time Commercial groups such as Prodigy, CompuServe, America Online, GEnie and Delphi begin to operate their own subscriber networks based on X.25 packet switched WANs. [6] Many of these networks provided subscription game services. A typical service was Quantum Link which connected Commodore 64 systems via a 1200bit/s dial-up modem, provided by Quantum Computer services [7][8].

In the early 1990s The ARPAnet which became increasingly known as the internet began to become more open, particularly with ISPs being allowed to connect to it and provide services to the public, connections numbered in the millions. Most commercially sold games such as Doom (1993) however only supported LAN connection between a few computers using the IPX protocol [9].

The release of the game Quake (1996) was an early on-line game including the use of the Internet Protocol[7], demonstrating client/server online games in practice on the IP protocol. In practice however, user experience while playing Quake proved to be variable based on network conditions and other issues still relevant today and are worthy of further study. [10]

TCP and UDP Side by Side

Since the implementation of ‘TCP/IP’, it has remained the main protocols used for communications across different forms of networks. While traffic unique to games and entertainment applications using TCP and UDP is common on the internet, IP, TCP and UDP have given rise many of the staple protocols in today such as: HTTP and FTP over TCP and DNS and DHCP and various streaming over UDP to name a few.

TCP:
• Connection based
• Ordered reception of packets
• Fragments packets based frame and network parameters
• Flow control
• Error control

Note the larger header size to implement these functions.

UDP :
• Connectionless
• Unordered packets
• No fragmentation
• No flow control
• No error control

Note the slimmer and simpler header size to implement UDP simple function.

Though the basic usage and structure of TCP and UDP have remained the same (as above), it can be stated that opposed to the UDP standard which has not be made obsolete since 1981, changes and additions to TCP and IP were common during the 80s as noted in the prefaces of the specifications of ‘IPv4’ and ‘TCP’ in 1981 (RFC791 and RFC793 respectfully). The introduction of IPv6, Differentiated Services and ECN to TCP and IP serve as recent examples of this continuing change.

Practical considerations for use of TCP and UDP in game design

Multiplayer games are complex applications that require the accurate and timely aggregation of the game state among clients. Determining how accurate and how timely a game is only one factor in deciding which network protocol to use in implementing network capabilities.

Consider these two arguments:

• As games with fast pace require players to receive real-time data, clients cannot stop and wait for packets to be received as TCP would allow.

• Important data representing the state of the game cannot be dropped, as UDP would allow, without resulting in a loss of synchronicity between client and server and between individual clients – until the application can restore synchronicity resulting in a skewed game outcome.

Although the choice is more then a reliability or speed binary as many factors that influence the end result of different implementations and should be considered, even in application design.

• Reliability can be maintained in applications using UDP by implementing reliability at the application level or at other higher layers thereby allowing games to maintain acceptable reliability while lowering the overhead by using UDP packet streams.

• Either short periods latency and other loss of synchronicity is usually tolerable by players and can be accounted for by creating more complex best-guess behaviour at the application level to fill in these gaps.

• Uncritical game state outside of client domain can be omitted from data being sent to the client such as events out of the players field of view.

• Applications can control the behaviour of the protocols below. For example TCP can be forced not to queue data before being sent with the TCP_NODELAY option, overriding its standard behaviour of implementing Nagle’s Algorithm to determine when to send a packet.

However at the lower levels, there are still issues that effect the choice of protocol in game design:

• Network factors such as frame size, bandwidth and latency can limit when and how frequently a packet can be sent, and how reliable it is in transporting the packet to the destination.

The protocols and systems themselves can serve as bottlenecks depending on the amount of traffic:

• Using TCP and UDP simultaneously can effect the performance of IP. Apparently TCP tends to induce packet loss in UDP packets. [11]

Current and future technological changes could impact on the use of TCP and UDP.

• Certain network configurations in games may require port forwarding to be set up on routers and may potentially limit game usability as many will be unsure about how to implement port forwarding.

Case studies

In an effort to learn more about current practices, I’ve conducted packet capture on four different games and will present some information and insights from the results.

These games are:
Starsiege: Tribes (1998)
World of Warcraft (2004)
Enemy Territory: Quake Wars (2007)
Farmtown (2009)

A. Starsiege: Tribes

This game was released when most players used 56kbps dialup connections however that started to change a few years into the game. The games is typically played in servers with about 15-20 players and is a fast-paced FPS game in which player sprites move quickly and is similar in nature to the aforementioned Quake. It has LAN functionality as well.

Observations:

100% of packets were UDP.

The server sent frames that were uniformly 79 bytes (37 bytes data) with about 1 in 40 packets being 93 bytes (51 bytes data).

The Client sent packets that were mostly 63 bytes (21 bytes data) and a few packets one or two bytes little more or less

20 frames were transferred in both directions on average during the test; 12 from the server and nine from the client.

B. World of Warcraft

This is a 2004 MMORPG in which thousand of player connect to servers with different areas, RPGs are typically no as fast paced as other genres of games.

Observations:

95% Were TCP packets, which was surprising.

About half of the TCP frames implemented WOW above TCP which were (88 bytes in total) had about 22 bytes of data in the WOW data segment.

30% were (54bytes) with ACK in them and no data
The other 20% were data (between 100bytes and 300bytes sizes were quite various).

About 12 frames per second were sent on average during the test.

Most of the WOW over TCP packets were not recognisable by Wireshark however, some of them contained fields such as ‘Realm List’ indicating structure at that level.

C. Enemy Territory: Quake Wars

This game is a fast paced FPS game, about 10 years after the original Quake game.

Observations:

The game uses almost 100% UDP

95% of UDP packets were pretty standard
The client sent packets mostly 60 byte frames (18 bytes data). The client received packets from multiple IPs during the games. They varied from 100 to 1000 bytes

260 frames were transferred per second on average during the test.

5% of the packets had Quake III Arena Network Protocol over UDP which had a structure similar to this:

(Client to server type)
Type (Game)
• Game
o Current Sequence
? Sequence Number: 32767
? Reliable: True
o Acknowledge Sequence
? Sequence Number: 25959
? Reliable: False
o QPort: 18804
o Client Commands
? Data (12 Bytes)

D. Farmtown

Farmtown is a basic Flash game in which game persistence is maintained via a server database. It is accessible via Facebook.

Flash is known to work closely with HTTP as Flash applications are most commonly found imbedded on web pages. Flash applications are known to not be able to transport data through UDP as yet and many implementations of flash games that have real time requirements have quite poor results when used on connections with low bandwidth or high latency.

5 frames were transferred per second on averageduring the test.

The game used a combination of TCP and HTTP (over TCP) communications at a quite intermittent rate.

SIN ACK and FIN messages were around 54 bytes which made up 70% of packets

The other 30% of packets were a combination of HTTP 1.1/ 200 OK, get and post commands (100-400 bytes) about 2 per second

Tools

Wireshark http://www.wireshark.org

Starsiege: Tribes (1998)
World of Warcraft (2004)
Enemy Territory: Quake Wars (2007)
Farmtown (2009)

References

[1] Postel, J. (November 1981) NCP/TCP Transition Plan (RFC801); On-line resource. (last accessed October 15, 2009).
http://www.ietf.org/rfc/rfc801.txt

[2] Koh, JK. (1997) Internet Timeline; On-line resource. (last accessed October 15, 2009).
http://wwwmcc.murdoch.edu.au/ReadingRoom/VID/jfk/timeline.htm

[3] Wikipedia (2009) History of Video Games; On-line resource (last accessed October 16, 2009).
http://en.wikipedia.org/w/index.php?title=History_of_video_games&oldid=3…

[4] Living Internet (2009) BITNET history; On-line resource (last accessed October 16, 2009).
http://www.livinginternet.com/u/ui_bitnet.htm

[5] Lextrait, V. MAD – Multi Access Dungeon; On-line resource (last accessed October 16, 2009).
http://www.lextrait.com/Vincent/mad.html

[6] Mulligan, J. (1999) History of Online Games Part I; On-line resource (last accessed October 17, 2009).
http://www.tharsis-gate.org/articles/imaginary/HISTOR~1.HTM

[7] Mulligan, J. (1999) History of Online Games Part II; On-line resource (last accessed October 17, 2009).
http://www.tharsis-gate.org/articles/imaginary/HISTOR~3.HTM

[8] Wikipedia (2009) Quantum Link; On-line resource (last accessed October 17, 2009).
http://en.wikipedia.org/w/index.php?title=Quantum_Link&oldid=294694207

[9] Wikia (2008) Doom Networking Component; On-line resource (last accessed October 18, 2009)
http://doom.wikia.com/index.php?title=Doom_networking_component&oldid=44…

[10] Mulligan, J. (1999) History of Online Games Part III; On-line resource (last accessed October 17, 2009).
http://www.tharsis-gate.org/articles/imaginary/HISTOR~2.HTM

[11] Fiedler, G. (October 1, 2008) UDP Vs. TCP; On-line resource; (last accessed October 18, 2009).
http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/

Ideas and a rather messy collection of notes from the friday presentations at Freeplay 2009

iPhone game dev
Kynan Woodman (Firemint), Neil Rennison (Tinman), Paul Motion (Iron Monkey)

Selling at 99c on the App market to get people interested. Then bumping to $2.99 when game becomes visible.

Home developers can potentially develop faster then EA. When new platforms come out, indies can take advantage of it faster. Six month development time becoming more prevalent in industry for iPhone apps.

Polys one of the only advantages of the PSP over the iPhone.

Where 3D is difficult to do well on DS at its ’32×32′ res – iPhone is easier.

iPhone artists moving from DS dev to iPhone get confronted by a 1024×1024 blank photoshop file to work with.

Flight Control took a week to develop by Firemint’s CEO. Makes use of line drawing methods. Was worth making extra maps for.

Issue of Mobile dev is no D-PAD an issue that ported games often ignore. When it comes to using a new platform well, new innovation ‘tends to be the cream that rises to the top’.

Firemint has moved well from Work for hire to publishing – with royalties and massive critical acclaim as the reward (eg Mirror’s Edge) though the process was a difficult learning experience.

Useful to look at in relation to the AppStores ‘delayed rating’ system where
Flight control sells – ratings slow to move until sales continue – then rating increases – dips a bit – and the dip in ratings lags behind it.

There is a PDF of the sales of Flight Control floating around somewhere.To illustrate this

Agile Development in Practice
Focus on Scrum development

Scrum methodology comes from Research and Development industries such as pharmaceuticals where time, money and labor is difficult to allocate upfront.

The starting point of deciding on work is based apon the decision of whether ‘this will give the client what they want’.

It works by going though cycles, each producing robust code. These cycles are known as sprints.

This allows for a situation where a product is always close to a point where it can be released quickly.

Scrum mantras
‘don’t do anything that wont make money’ (ie. code commenting doesnt make money)
‘focus on individuals and actions over processes and tools’

Working software over comprehensive sofware and documentation

Customer contact key (through a single point of contact, in games this is often a publisher rep). Publisher rep plays role of “product owner” in scrum methodology.

Scrum related to the ‘kaizen process’ (‘kaizen’ japanese for improvement (wow how groundbreaking!!) idea from japanese car manufacturing): ‘look around everyday and decide how customers product can be improved’. ie Feature driven development. Eg: engine programmers don’t include features until they are needed/requested.

Artists often can’t wrap their minds around scrum ‘often dont know what you guys are talking about’ ‘cant i just go back to making some icons now’

‘Scrumm zealot’ bible: “The pragmatic programmer” (not necessarily scrumm related) has a mantra of ‘you are a tradesperson, this is how to make quality code’

Agile methods: Others like the crystal method exist
Game development has tighter deadlines and publisher requirements compared to other projects.

(A question: Can team members maintain a consistent vision of the design docs [given such design methodology 'extra work'])

’5-8 Optimal number for scrumms (ie teams)’

“Getting to the end of a scrumm you find your self putting on the hat of researcher for the next cycle.”

Scrum helps organises tasks (or modules of work).

Multitasking distracts from work. The idea of radio silence (No disruption or communication until a task is done; focus) assists this ban on multitasking.

“Scrums tend to stop when bugs occur which they need to be stopped”
“Allocation of staff outside of the cycle to fix bugs”

“The advantage of Scrum in our small studio is having the tasks up on the wall to help focus, even though there aren’t 2-3 week cycles”

A Burndown Chart: a line that descends to zero (indicating progress to cycle completion).

This can be included in a information radiator. IE a plasma TV – highly visible. Shows progress. Marquees indicate measures of progress.

ScrumWorks: a software tool to help create a burn down chart.

After a sprint planning meeting, someone is allocated a task of punching in and ticking boxes on ScrumWorks. A web server could be set up to disseminate scrum information.

When turbulent requirements arise, changing to 2 week cycle – clear goals change cycle back to 4 weeks.

“Scrum helps to produce optimisation early: ie good algorithms”

“Last minute hacks often save your ass, how can this be reconciled with this methodology?”

Given a monthly cycle, customer demands a delayed until the start of the cycle in three weeks (ie sometimes they will forget) either way you dont have to drop tools to do their request.

Selling scrum methodology to clients: You get something for free (working display of code at end of each cycle).

Planning is usually three days at the start of the cycle. This can be considered as too onerous compared to mega planning and develop stage. Especially if it’s a 3 day planning for a 2 week cycle. It’s a fair question to ask if the flexibility worth the overhead. (Though it often is)

Small to medium teams – type and size of scrum utility.

Have a good definition of done.

Damian Scott (Primal Clarity’s Imperial League)
Small niches and specialisations exist and are worth filling

Playing in someone else’s sandpit
Spongebob: Light Camera Pants
Lucky because were able to write own story

gameplay and design are main avenues for creative influence

No fire, characters can’t die etc

Try to build a good relationship with IP owner

Cameron Lee Visceral, EA

Get the licencees to define the essence of the licence “give us three important pillars of your IP”
Pixar’s Cars three pillars:
* Racing
* Characters
*Environment

THQ publisher came in and asks for features
Take off tyres
Boost nitros

Torus Blake Mizzi: Scooby Doo
We wrote up our own description and gave it to them.

Create a document of guidelines from IP owner, all changes require you to refer back to doc.

Warner Bros wanted combat game “Like lego star wars + more”
This doesn’t fit well with passive seeming characters traditionally in tv show as investigators.
Was a push to get Daffney holding a big hammer.

Ed Sharlton was sent to assist who is a original story writer for TV series, though not a good games writer. He wanted lots of dialogue and cutscenes. There ended up being over 60 minutes of tem.

JAWs IP:
Original idea to go around in the water in boat and complete challenges

Studio conception of IP “targeted to older audiences” ie JAWs was a horror story
- didn’t really suite holders publisher came back and said:”The game should be: What parents think their kids would like”

(Monster Jam
Pub: Activision
IP: livenation(?)
No notes on this..)

DS homebrew:
Tools: DevKitPro, PALib
(DS Game Maker, MicroLua ‘are crap’)
presenter website:multiple-option.com

Emulators:
DeSmuME
NO$GBA

Getting things done (manager ideas)
google “The Cult of done manefesto”
find out source of problems; ask five why questions “go back 5 whys”
“Gofer”-ing is bad

Bug trackers bugzilla

basecamp.com

revision control
*subversion
*Git

Sources: “Making things happen” by Scott Berkun
“Lessons Learned” startuplessonslearned.blogspot.com
steveblank.com
2dboy.com – (getting things done by David Ellen(?))
7 habits of highly effective people (“bs self improvement book”)
Wolfire games – wolfire.com

Petri Purho (that guy from Finland: Hyyvaa Paiva!!)
his game: Crayon Physics Deluxe (We were invited by Petri to download his game on ‘the bay of pirates’ website)

Play: Enviro-bear 2000 Operation: Hibernation (funny game, driving with mouse)

Play: Spelunky by Derek Yu (randomly generated adventure)

Read: Lost Garden -read articles on “Paint box games” eg of making creative games.

Read: “Click Nothing” (Improvisation) presentation material (a game design blog)

Prototyping rocks. “Prototyping is the foreplay of game development. The reason I call it foreplay is because most of you guys want to skip it”

Try making a game in 7 days. Read: “How to prototype in 7 days” (Probably the article Petri was talking about)

Read: “The scarlet letters – notes on making art”

“Put your shit prototypes on the net” because “some things are only awesome on the internet” (ie Rick Ashtley)

(Scribble Naughts game on DS mentioned to be similar to Crayon Physics deluxe.)

SPD aimed halfway between Sand Box Games and Hardcore Puzzle Games.

(His windows file explorer program “Nexus File V”)

If you were misquoted or mis-attributed in theses notes, please email me.

Introduction

What interests me about AI in sports games such as this is that given the presence of full behavioural independency of player controllable entities, the limitations of the programmed AI provides a space for players to adopt weakly dominant strategies based upon learning the predictable behaviour of the entities that the AI controls. We can also consider that NPC AI characters can also play a role in teaching players the rules of the game. I will start below by analysing the higher level manifestations of AI in Bot Arena 3 and then proceed to those at lower levels.

Heuristics and Learning

In consideration of the ‘evade’ challenge level in which the only dominant tactic is to run away along the limits of the polygonal map, someone without access to source-code can conclude that the AI entities have no functions for learning which would enable them to adopt a tactic clear to sentient beings of the human variety, that intercepting the path of the player by moving diagonally is possible when the player adopts the previously mentioned tactic. Once the player determines this evasive strategy, the only ongoing challenge becomes one of reflex.

Behaviour States

The AI always adopts one of a subset of behaviours and switches behaviour automatically based upon the state of the game and the in match objectives. For reference, those behaviours are:
• Follow (player assignable)
• Close-in
• Regular
• and Wander
Given the above list, it must be stated that the list above is only a list of behaviours that the player is made aware of and there may possibly be others. Player notification of AI behaviour and the ability for players to not only delineate between behaviours but also to understand the consequences and characteristics each behaviour presents is well applied in this game.

Full Spatial Awareness

Given this game is based upon a real world concept “Robotwars” (TV) in which humans have full spatial awareness over the domain of play which is a small flat 2 dimensional plane, I don’t particularly consider full spatial awareness a design flaw.

Simple Pathfinding and Interaction

Bots under AI control show the function of strait line motion in which when their aim is to approach an objective by setting a target and following a path to the target location at which point they reassess. Low level AI that controls the bots understanding and response to spatial limits such as walls, other bots and NPC husks also exist and interrupt path finding which is I consider pretty fundamental to suspending disbelief in respect to the relation of AI to the physical rules of the space represented in this game.

Another point of interest is the methodology with wich bots peform their main function. Target selection and preference (or lack of) for healing or destroying are quite simple but yet play an important part in making this game challenging and enjoyable.