Hexgrids

Hexes are often considered better than squares for turn-based combat games, since hexes are the same distance from each of their neighbours. My code for building these starts from a seed position, which is manually set at a walkable location, and then it searches in all 6 directions using raycasts to see which ways can be walked from this location (i.e. which directions are clear of obstacles). This adds more hexes which are then also searched – we “flood” outwards until all reachable hexes within our predefined region have been added, along with their connectivity to their neighbours.

This produces a graph of connected nodes, which is perfect for the A* algorithm. We also need to be able to quickly gather hexes within an arbitrary region of space (without the inefficiency of having to search outwards from the seed location to find them), so hexes are also inserted into buckets which are configured as a sparse 3D array based on 1m x 1m x 1m size. The overworld has 70,000 connected hexes, and each interior/underground location has its own hexgrid. All A* grid loading and pathfinding is performed by multiple threads.

Less Need for Invisible Walls

The player has several options for how to control movement, including mouse-clicking (which uses A* pathfinding to figure out a route around obstacles) and direct WASD or joystick-based control (which does not).

Direct movement (WASD/joystick, where movement is constrained only by collisions) has a problem whereby players might wander away from where you want them to go, and off into the empty wilderness. By cross-referencing the player’s position with the hexgrid, I constrain the player to stay close to the nearest hex – this means there’s less need for invisible walls to stop them wandering off into the wilderness where there is no game content, or from walking inside solid objects when Unity’s rather suspect physics mesh-collisions fail.

Nice things you can do with the G (‘cost’) component of A*

A* is a pretty elegant algorithm for efficiently finding the shortest path between two locations. At its core is a calculation F = G + H, which estimates the distance that a possible solution might take through a given node. The G part of this is interesting: it’s the cost of getting from a node to a neighbour. Often this is simply chosen as the Euclydean distance between the nodes, but it doesn’t have to be.

We can make the G cost higher, for example, when crossing difficult terrain. This discourages the algorithm from picking a route without actually forbidding it. In TNT, I quickly found that the townsfolk loved taking a shortcut through a graveyard, which was often a slightly shorter way of crossing the river between the north and south of the city. This didn’t feel right: the cemetery path is visibly narrow and not well-worn, and crosses a narrow bridge, while the ‘standard’ route is a wider stone bridge leading through the marketplace.

So I added penalty areas – regions of space for which the G cost between hexes is artificially inflated. The cemetery is an obvious place where this works well, but this approach let me fix other areas too, for example narrow gaps between pairs of houses. I also add a per-terrain-texture penalty, so that NPCs tend to walk on cobblestones in preference to grass or sand. This stopped them from taking shortcuts all the time, and kept them to routes that they visibly ‘should’ be using.

By the way, if you’re wondering about all those white and blue boxes, they are named location markers – NPCs often move between specific locations so this was a good way to lay them out. These markers are also used in the cutscene system, allowing ‘stage directions’ to control character movements synchronised to a conversation or scene. [I wrote a bit about the cutscene system here.]

Believable Pedestrian Movement in Crowded Environments

Once I had a town full of wandering villagers, I needed to make them aware of each other so that they weren’t colliding all the time. Over the several years I was working on this, l had written various last-minute avoidance approaches (basically, over-riding their current A* path trajectory when they were about to collide) so that characters didn’t walk right through each other. It worked okay, but not great: avoidance tended to look very unaware and last-minute.

Here in debug mode they’re telling me about random path modifications they make when there’s other pedestrians nearby:

But then I discovered the RVO (Reciprocal Velocity Obstacles) algorithm: see discussion [here] and [here].

This provides a more elegant simulation of all moving characters, each of whom registers their intended trajectory. The paths taken by characters are then modified to avoid collisions several seconds into the future.

One Size Does Not Fit All

I had put a lot of effort (3+ years) into massaging my code and its parameters so that it worked well in all circumstances while overcoming recurring problems such as NPCs falling into holes or getting stuck on stairs (are stairs a hole when you’re going down? Are they a cliff when you’re going up?) Given the different sizes and speeds of characters, and the different steepnesses of terrain and stairs, this was a difficult task and perhaps ill-posed, i.e. lacking any single correct answer given the constraints.

My breakthrough came in a very simple form: I started to demarcate areas where the rules behaved differently. When walking on stairs, a character could turn off its hole-avoidance and steep ground avoidance. When going through busy narrow archways, characters could temporarily make their RVO objects thinner, so they don’t get in a muddle all trying to avoid each other. These are simply done as Triggers in Unity. When a character is inside a certain type of trigger, it runs alternative code for specific sections of its movement function.

Other Things I Have Written about Pathfinding

I’ve done some other interesting things with the A* algorithm over the years. [Here’s one from 15 years ago] with [an academic paper I wrote]. I captured data from players in order to make computer-controlled vehicles take ‘sensible’ routes.

Godkin is an in-development multiplayer co-op combat RPG, with a maximum of 4-5 players per session, and with high numbers of moving entities (4-5 players each with several AI-controlled followers; several villagers; and potentially 100s of monsters and 10s of defensive towers, missiles and spells active at a time). In order to handle the high amount of network traffic, I have developed an infrastructure involving, at its core, a direct peer-peer connection between each pair of players in a game session.

Peer-Peer Direct Connections

The main motivations behind a peer-peer approach are (i) low latency, and (ii) low server costs. Using peer-peer means that a hosted server is not needed apart from initial handshaking and NAT punchthrough. With 5-10 movement packets per second, per entity, per connected client, the amount of network traffic (and potential server CPU load) can grow alarmingly.

In my ‘web of direct connections’ approach, the player who starts up a game session listens for incoming connections. The second player to join connects to the 1st player and then itself listens for incoming connections. This procedure continues: each player who joins connects to each existing player’s connections, and then opens its own connection for use by subsequent players. This model means that each player can send and receive data directly with each other player (a traditional client-server setup would of course mean data between players would have to be relayed via the server, i.e. 2 hops rather than 1). Latency is minimised.

In Godkin, we’re using WebRTC data channels for both unreliable data (i.e. entity movement updates) and reliable data (i.e. game/entity states and event data).

Client-Server Fallback

The trickiest thing about peer-peer networking on the public internet is the fact that each client will be sitting behind a router which will probably not allow unsolicited incoming traffic, and in any case without manual configuration will not know where to route that traffic to, in its private network. The solution is NAT punchthrough which involves both clients connecting to a publicly-addressable server, and then (via data from the server) negotiating connections directly to each other through the same port that the other client just opened to the server. It’s a somewhat messy process and a small fraction of routers pretty much refuse to do it. Therefore, a fallback is needed whereby clients who have failed to achieve peer-peer connection will relay data to each other via a traditional server. In Godkin, we use UDP (for unreliable data) and Websockets (for reliable data) as a fallback. The exception is the game’s public hub where there can be larger numbers of clients, with players joining/leaving at a high rate: here, we use server-relaying all the time.

Scoping

The idea behind scoping is that certain data is less relevant to a player if it related to a game entity that is far away from their camera. The main data that can be culled through scoping is position updates (which are also overwhelmingly the most frequently sent types of data). Since Godkin is a 2D topdown/isometric game, it’s easy to decide whether a particular world position is visible to other players or not, assuming you know where their camera is located. If a packet is defined as ‘scopeable’, the sending client will typically only send it to other clients for whom it is in-scope. Every 25th packet is sent to everyone, regardless of scope. The exception is data related to Player characters, which is sent without scoping, since everyone needs to accurately know where everyone else’s camera is.

Distributed Control

One further system in Godkin which I have implemented for efficiency reasons is distributed control, by which I pass control of AI entities between clients based on whoever is closest to them. This means that both CPU and network loads are balanced between clients, rather than the game having a heavy reliance on the power and connectivity of the 1st player. In fact, distributed control is also a requirement in order to support scoping: we need to make sure that each client is controlling interactions between entities that are ‘in scope’ for it, i.e. it knows their positions accurately. Since Godkin is a co-op game, we’re not overly concerned about security (although, I have implemented some anti-cheating measures).

Unity3D Implementation

Godkin is being developed using the Unity3D engine, and I was initially developing the networking infrastructure using the excellent Bolt plug-in. Last year, however, the company Photon bought Bolt, and implemented a punitive per-seat cost which is the same as the per-seat cost of their client-server solution, despite the fact that server overhead in a peer-peer situation is a tiny fraction of that in a client-server situation. Unhappy with this, I explored other possibilities and eventually picked a really nice, bare-bones WebRTC plug-in. One of the benefits of moving to a simpler, low-level solution was also that I was able to fairly easily construct the ‘web of connections’ approach as described above, rather than treating the 1st player as a server (which is what Bolt does).

A couple of years ago, agar.io was released as a browser game, and caused quite a sensation. It has subsequently spawned an entire genre of games — lightweight, massively multiplayer browser games with simple graphics and gameplay. This type of no-nonsense, easy-access multiplayer game appeals to many people, and naturally suits lone developers (especially when their art skills are not great).

So late last year, and early this year, I developed orbs.it

Orbs is a simple to play game, yet is very skillful. It’s about fast and accurate control of your “guns”. Eight players start the game, and each initially control a single orb which is part of a set of 24 orbs encircling a central “sun”. You shoot from your orbs, and when you hit another orb you take control of it. The winner is whoever is left last in the game. It’s a very satisfying mechanic, especially when you get in the flow and claim orb after orb in rapid succession.

Lots of users

In May I released orbs.it on iogames.space which is the main portal for “agario-style” games. I was pleasantly surprised with the amount of players that clearly seek out this type of game — within a couple of days, my server was starting up 5-10 game sessions per minute, each with typically 4 or 5 humans in (the rest being bots). As of right now, there are nearly 90,000 player accounts in the game’s database.

Server architecture

Orbs proved to be a nice test-bed for the nodejs-based gameserver cluster I had developed. The central masterserver looks after player logins and communicates with gameservers which run the actual game sessions. It monitors the number of games running on each server, and dynamically starts/stops server instances as required, to deal with varying loads. There’s also some interesting requirements around things like gameserver hot-patching, so again this has involved developing useful techniques which I’m sure I will use again. I have done this sort of thing before in Darkwind of course, but the system in Orbs is generally much slicker and didn’t suffer from the horrible nightmares of blocked sockets which afflicted Darkwind on its opening weekend on Steam.

Networking

High-speed networked gaming is always a challenge to develop, and a particular challenge for “agario-style” games is that they are generally limited to using websockets for their communications. Websockets provide really handy bidirectional communication between browser and webserver, so are far better than plain-old Ajax.. however, they are still based on TCP, and that means guaranteed, ordered delivery of packets. This is the main cause of sudden spikes in latency which most Websocket games suffer from. The latency is basically unavoidable – it happens when a packet fails to deliver and has to be re-delivered, and all subsequent packets are cached on the receiver until such time as the missing packet arrives, so that they can be delivered to the receiving application in the correct order. This makes TCP fundamentally unsuitable for fast-moving data, especially when the nature of the data is that late packets are irrelevant. If your application knows where a player’s orb is at time 20 in a game, it really doesn’t care to know where it was at time 19, yet TCP doesn’t allow your application to see the data from time 20 until the data from time 19 is received.

Deterministic positioning of orbs

I wanted orbs.it to be, as far as possible, immune to the latency problems caused by TCP. I didn’t want the field of orbs to jump around and glitch on the screen, like the player-controlled entities in most agario-style game do. The solution was to remove player-control of the orbs altogether – this also fitted the design requirement of simplicity. The orbs move around in orbits, based on elliptical paths with continually changing parameters (and ultimately controlled by Sin and Cos, of course). The real trick is that these paths, although interesting and varied (leading to a continually-shifting playfield) are entirely deterministic. At any specific time after the game has started, the game server and game clients can all calculate and precisely agree on where each orb is. This vastly simplifies things and gets rid of many of the difficulties associated with everything a game client knowing about everyone else being out of date by the time they know it.

If you’re interested to read more about fast-paced multiplayer networking, this is an excellent overview.

You can play orbs straight from your browser here: orbs.it and it’s also available on the Android and iOS app-stores, although has not seen much traction there.

Godkin takes a “faked 3D” view (this style is often referred to as isometric, although actually we’re not adhering correctly to the strict viewpoint that would make the game isometric.) Getting the lighting and shadows looking good in this style is somewhat challenging, since there’s no real 3D geometry for the game engine to work with. I’m having a lot of fun programming this game in Unity (it’s my first Unity game) and figured a blog post about shadows and lights was in order!

At the core of my shadowing system are the FakeShadowCaster and LightAnimator components.

LightAnimator

A LightAnimator component is attached to any objects that have lights – camp fires, torches, explosions, etc. These search for nearby objects which have FakeShadowCaster components, and register with them. They also notify the FakeShadowCaster objects whenever changes happen (e.g. the light moving, flickering, brightening, dimming, turning off).

FakeShadowCaster

A FakeShadowCaster component is attached to any objects that we need to cast shadows – basically, anything that should appear to have some 3D ‘height’ – characters, monsters, rocks, trees. This component maintains a list of nearby light sources, and creates a fake shadow sprite to associate with each of them. Whenever a light notifies a change, or if the FakeShadowCaster itself moves, its list of shadows are re-calculated. Each shadow is rotated to face away from the associated light source, and its opacity is set based on distance from the light (plus other variables). I also wrote a ‘shadow skew’ shader which spreads apart the vertices of the shadow sprite which are further away from the light source – with a stronger effect the closer it is to the light; this adds quite well to the overall feeling of 3D. Another nice touch is that we can use whatever sprites we like for the shadows – so trees, for example, can have their shape baked into their file.

‘3D’ Object Shader

The standard Unity sprite shaders look great for terrain, and sprites which don’t have much ‘height’ – however, since the amount that each of their pixels is lit is simply based on the distance they are from light sources, this starts to look strange for objects that are supposed to be tall. The problem is that the top pixels and bottom pixels of the object will be at quite a different distance from the light – but to look like a proper object with height, the vertical position of all pixels should be considered the same, for lighting purposes. So here we have a shader that attentuates light to all pixels based on the position of the vertically lowest ones. This shader also reduces the brightness of any object which is in front of lights (since in this case the majority of the light should be cast on the non-visible ‘back’ of the objects).

If you’d like to follow the progress of Godkin’s development, here’s our blog. Or why not join us for a chat in Discord?

Goblin Portal have created a clean pixel style for the game, and I’m the programmer (of course). It’s working out well under control of a 2D physics engine: we have spent a lot of time getting the core animations and interactions with the environment as good as possible; the goblin runs, jumps and climbs walls, swings from chains as he attempts to escape the numbskull adventurers .. who in turn have no respect for the goblin, seeing him only as a quick kill for 10xp which brings them along the road to their next level and unlocking their next skill.

I’m using the same core set of technologies as I have for several recent projects: it’s written using HTML5/Javascript packaged into a desktop executable using nodewebkit and with pixijs for pretty efficient WebGL rendering. Nodewebkit gives access to things such as local file reading/writing, which isn’t normally possible from a browser. I’m using the matterjs javascript physics engine to move stuff around, but other than that there’s no actual game engine to be seen. I have found this suits me well for the 2D games I have been making lately – I can construct my own architecture rather than having to learn someone else’s; and the lightweight nature of Javascript suits me.

The near-term plan for Goblins & Grottos is to make a playable one-level demo, and to engage with players while expanding this into a complete multi-level adventure, starting with the goblin’s parents being hacked down by a merciless bunch of greedy adventurers, and ending with an unexpected and heart-wrenching moral dilemma. Or something.

We’re also planning on releasing the map editor as a core part of the game, and on making an on-line repository for player-made levels. There’s plenty of creative freedom in the map editor I have been creating, including customising the skills and chat text of the adventurers.

You can sign up as a tester over at goblinsandgrottos.com, or follow us on Facebook. A playable demo should be available within the next few weeks.

The game runs using HTML5/Canvas, with a node.js websockets server. The ‘render client’ ran on my laptop and players ran the ‘controller client’ on their phones.. this seems like a really nice way to do casual LAN-style multiplayer games, and it’s a configuration I have been thinking about for a few weeks. I just need to figure out a killer party game idea to use it with!

In “Hittin’ Worlds” Each player plays as a planet, in orbit around a sun. Asteroids are flying about, and players have to use their forcefield to deflect them. By using a virtual joystick-style controller on their phone, they orient the forcefield in specific directions.. incoming asteroids get deflected in that direction. The idea is that players fling the rocks at each other while defending themselves.

We also had a really nice piece of custom music written by a guy called Ian, from Athlone/Reading.

The basic idea with raycast cars is that you cast a ray from each wheel hub, and calculate the distance at which a surface is met (if at all). This defines the suspension’s extension, and then you simulate spring behaviour by applying increasingly strong forces as the suspension gets more compressed. There’s also some subtleties such as anti-roll and varying spring strength depending on whether its compressing or extending; but these are mostly tweaks applied to the core idea.

I also found that at high speed the default Shiva ‘spherical wheels’ car would suffer from occasional glitches and speed wobbles, rendering it fairly useless for most games. Sometimes it seemed to stagger sideways at high speed, presumably due to errors on the axis constraints allowing the spheres to role sideways. I assume these problems are caused by over-relying on the accuracy of the underlying physical simulation in order to obtain the required behaviour.

In the video clips shown here, the behaviour of the car in all ways other than spring response has been results-driven, i.e. the desired behaviour (skidding, drifting, tendency to roll, etc.) has been considered and this is used as a starting point for programming the calculations – rather than starting from an accurate physical simulation and expecting realistic/fun results as an emergent behaviour.

This represents very good progress towards what I’d like to have for a major new Darkwind project (Darkwind 2?) that I have started thinking about. Really the ineffective default Shiva car is what had stopped me considering this before now.

Last year I also wrote Musclecar Online. In this the car was entirely results-based, having no accurate underlying physical simulation from which the behaviour emerged. Musclecar Online is actually a 2D driving simulation with 3D models (hence, no hills or bridges) – and it was therefore entirely possible to define the behaviour I wanted first and then to write code to directly produce that behaviour.

After some research I have settled on node.js as a good solution. It’s very well regarded, largely due to its non-blocking, asynchronous model. This essentially means that anytime a resource is required (such as a database recordset) the request goes into a queue, to be called back when the resource is retrieved. In Apache, the model is blocking – the process sits and waits for the resource, thereby stopping any other activity.. this is why Apache needs all those independent processes, so that it can serve multiple clients simultaneously.

The game I have been working on is ‘Musclecar Online’ – a top-down racer in which players build their own tracks, vote on them, and then everyone in the world races on the same track-of-the-day. Rather than being real-time, you race against the ‘ghost lap’ recordings of other players; kinda like Speed Racer

Cache stuff in RAM

Linux has a server’s approach to the file system, of course, which means it uses all available RAM for caching disk files and such, but I figured it would be even better to make liberal use of Javascript arrays (which are really hash tables.. excellent for key-based lookups). So the server packs up canned responses into strings, as much as possible, ready for delivering over the interweb with no fuss or processing. This includes:

a 5-day pack of track layouts, allowing the players to see what’s coming up over the next few days;

per-cartype, per-second frequency bins, succinctly providing the data needed by the client to display a histogram of worldwide laptimes and point out where the player stands versus these;

a temporary array of ghost lap recordings, hashed by user ID for easy over-writing when they improve. This is only used up until 40 players have recorded laps for that car type on that day’s track, and allows random ‘unclassified’ packs of ghost laps to be delivered to players without the need to bother MySql about it;

more long-term packs of ghost lap recordings, separated into 6 divisions (F thru A) – the idea is that the player starts off racing against poor ghosts, labelled as division F, and if they beat these they are allowed to progress to division E, and so on. These longer-term packs are re-generated periodically, but not for the first time until 40 recordings are available for the car type.

Don’t fall into the ORDER BY RAND() trap

I have done some pretty naive stuff in MySql in the past, but running Darkwind for the past 7 years has helped me understand efficient database design and querying. With the characters, vehicles and weapons tables running into the millions, I was forced to. One of the newbie gotchas in MySql is to avoid doing a massive SELECT statement with ORDER BY RAND() LIMIT 1 in order to get a random record. If you do this, you’re basically asking the database server to load an entire table into memory, apply a random number to each record, sort the whole damn thing, and return one row. There’s a few obvious solutions, depending on how well distributed the data in your index fields is. One simple way is just to find your data range (e.g. laptimes min and max), generate a random number in this range, and then SELECT the first row greater than or equal to this laptime, LIMIT 1. Assuming laptimes is an index field, and also assuming there are enough records to make a reasonably even distribution across the data range, this works nicely.

Interesting asynchronous design solutions

Now, I love callbacks as much as the next man, but it can be an old-fashioned PITA sometimes trying to work with asynchronous coding. In a nutshell, anytime you want a resource that may be delayed (database query, file read etc.) you can’t use a traditional flow of control, can’t use loops for multiple accesses, etc. One of the things I have to do in the ‘Musclecar Online’ server is build packs of typical ghost lap recordings, in order to pack them into strings ready for dispatch to the clients. This means querying for each row with a separate SELECT statement, and therefore means 11 car types x 6 divisions x 5 different packs x 4 ghosts per pack = 1320 queries. Embedding each query inside the callback of the previous one certainly isn’t an option, but with a little thought I settled on recursion; a perfect way to unravel the asynchronous tangle. This works nice and efficiently, while still operating in serial (and therefore not choking up any server resources) and allowing nice tidy code. It’s kind of strange I didn’t see recursion mentioned as a solution anywhere on the web while researching node.js. Well, maybe I didn’t look for too long.

I have put together a nice workflow for this, so I thought it might be useful for other people too..

Step 1: Create your texture atlas. I use a program called Texture Packer for this, which combines your textures into a single PNG and also exports an XML description of it (which we’ll need later; we could of course manually write the XML but it’s a bit more work that way..)

Step 2: Write or export your XML. My Shiva code a bit later will assume the following format, which is what Texture Packer gives us. It simply encodes the names of the images (sprites), along with their positions and sizes in the atlas.

<TextureAtlas imagePath="ZS_icons.png" width="512" height="512">
<sprite n="backpack" x="204" y="2" w="160" h="186"/>
<sprite n="rotate_left" x="366" y="51" w="48" h="47"/>
<sprite n="rotate_right" x="416" y="2" w="48" h="47"/>
<sprite n="search" x="366" y="2" w="48" h="47"/>
<sprite n="shotgun" x="2" y="2" w="200" h="86"/>
</TextureAtlas>

Step 3: Import the xml file and texture atlas in to Shiva

Step 4: Create your HUD. Anywhere you want a texture out of the atlas, just set that HUD component to the Atlas texture (it looks a bit weird at design-time..)

Step 5: Add an XML variable to an AI, and set it initialised from the imported xml. (I call my xml variable xmlZS_icons, and hard-code that in the code below)

Step 6: Add the following function to your AI:

--------------------------------------------------------------------------------
function MyAI.SetUvsFromTextureAtlas ( sComp,sIcon )
--------------------------------------------------------------------------------

local r = xml.getRootElement ( this.xmlZS_icons ( ) )

local imgWid = string.toNumber ( xml.getAttributeValue ( xml.getElementAttributeWithName ( r, "width" ) ) )
local imgHgt = string.toNumber ( xml.getAttributeValue ( xml.getElementAttributeWithName ( r, "height" ) ) )

local c = xml.getElementChildCount ( r )

for i=0, c-1 do


local e = xml.getElementChildAt ( r,i )
if ( sIcon==xml.getAttributeValue ( xml.getElementAttributeWithName ( e, "n" ) ) ) then


local uscale = string.toNumber ( xml.getAttributeValue ( xml.getElementAttributeWithName ( e, "w" ) ) ) / imgWid
local vscale = string.toNumber ( xml.getAttributeValue ( xml.getElementAttributeWithName ( e, "h" ) ) ) / imgHgt
local u = string.toNumber ( xml.getAttributeValue ( xml.getElementAttributeWithName ( e, "x" ) ) ) / imgWid
local v = 1-( string.toNumber ( xml.getAttributeValue ( xml.getElementAttributeWithName ( e, "y" ) ) ) / imgHgt )-vscale
local comp = hud.getComponent ( application.getCurrentUser ( ),sComp )
hud.setComponentBackgroundImageUVOffset ( comp, u, v )
hud.setComponentBackgroundImageUVScale ( comp, uscale, vscale )
return


end

end

log.message ( "Unable to find icon '"..sIcon.."' in texture atlas!" )

--------------------------------------------------------------------------------
end
--------------------------------------------------------------------------------

Step 7: And finally, whenever you instantiate your HUD, call the following for each HUD component that’s included in the texture atlas:

this.SetUvsFromTextureAtlas ( "MyHUD.MyComponent", "sprite_name" )

WEEK 1 – intro, IDE, API overview
Lecture 1 – Introduction
Lab 1 – Setup Shiva + Mars Rotator
Mars model (Collada .dae and .jpg) (for use in lab session 1)

WEEK 2 – key game entities, automatic flow of control, AIs, keyboard, accelerometer
Lectures 2&3 – Concepts, the Shiva SDK etc.
Lab 2 – Mars and its moons!
Phobos/Deimos models (Collada .dae and .jpg) and skyboxes (.jpg) (for use in lab session 2)

WEEK 3 – programmed flow of control, messages, key game entities, data handling
Lectures 2&3 – Added to since last week!
Lab 3 – Mars with collidable asteroids
Asteroid model (Collada .dae and .jpg) (for use in lab session 3)

WEEK 4 – physics, direct movement, the camera
Lecture 4 – physics, movement, camera
Labwork: start on your game projects; complete lab 3 if you haven’t done so yet.

WEEK 5 – HUDs, runtime object management, coordinate systems, vectors and angles, ray casting, the math object
Sample solution to lab 3 (Mars with Moons and Asteroids)
Lecture 5 – HUDs, raycasting, runtime object management

WEEK 6 – sensors & colliders, tables, hash tables, xml, game deployment
Lecture 6 notes

WEEK 7/8 – particle emitters, multiplayer, multitouch, efficiency, Shiva script and OpenGLES, materials & lighting, pathfinding
Lecture 7/8 notes

Demo Games that we will be discussing in class:
The Shiva webplayer plugin will automatically install..
[Afterburn 2150]
[Mars Defender]
[Block Rockin]