When the motion of game actors is driven by a physics engine, we need a reliable method to control their motion. A governor uses negative feedback to adjust forces given a target velocity.

Principle

When a body of mass M is at rest, applying a force F will result in a speed S = F / m.

This formula can be used to write a simple governor – given the current velocity V0 and a target velocity V1, we have:

F = ( V1 – V0 ) * M

Units:

• F – force applied (Newtons)
• V1, V0 – velocity (meters per second)
• M – mass (kilograms)

Given the above we can write a very simple function that will calculate the force F required to update the velocity of an actor at every frame.

It may be working better than you’d expect – notably, given motion conservation, even a trivial governor (based on the above principle) will quickly achieve target velocity.

Scaling the output

The above formula can be modified by introducing a scale parameter:

F = ( V1 – V0 ) * M * S

The scale parameter may have uses – for example you can use it to increase the governor’s output when friction/air resistance become significant.

Note that scaling the output in this way may break time invariance – the simulation will behave somewhat differently depending on the size of time steps.

Implementation notes

Impulses vs continuous forces

A simple way to implement the above consists in delivering the governor’s output as impulses. An impulse is a discrete force applied to a physical body. A priori it may appear that continuous forces would be a better choice. However, depending on the way continuous forces are implemented by the physics engine, an impulse governor may be preferable:

• When applying a continuous force, the force is usually given in newtons per second. Therefore additional calculations are needed to precisely determine the total force delivered by the governor.
• With impulses applied at every frame, the ‘stop and start’ effect that one should expect is not visible.

Issues

Sharp changes in orientation

In some games, sharp changes in orientation are not a problem, especially when the actor need to be responsive (e.g. controlled by the player). For large actors and some other games however, sharp changes in orientation look ugly. A low value for S ( ~0.1 or less ) will reduce artifacts but this solution is not ideal.

A simple way to solve this problem is to interpolate between the current orientation and the target velocity before passing the target velocity to the governor.

Note: I removed the ‘motion aliasing’ section referred here previously; the artifacts I observed in my simulations were not related to the governor itself.

Going further: adaptive governors

Compared to the solution described above an adaptive governor can handle various situations by automatically correcting the scale factor S. This is done by measuring the bias between the expected output (target velocity at frame t0) and the actual output (real velocity at frame t1 = t0+1).

It is wiser to start with a simple governor - whether adaptive or not, the governor needs to be initialized with a base value for S; additionally when encountering obstructions, adaptive governors tend to ‘overheat’ – increasing S to a very high value. While it is possible to clamp the scale factor to a specific range, this is probably just the first in a series of adjustments – adaptive governors are smarter, they are also harder to design.

We know how to use instruments to fine tune the performance of our games: we have a quick run (maybe one minute) check the heaviest stack traces, and do some surgery here and there, right.

How about cases when…

• There’s just a couple of frames hanging every once in a while.
• The game slows down for a short period of time
• …

Here’s how I did it. I had a short span in my game where the frame rate dropped dramatically. While this typically lasts for less than 5 seconds, you may have noticed than the best games rarely slow down at all, if ever. Besides, what’s an isolated incident in a game may signal a problem in the game engine. Let’s get to work.

Here’s what I did:

1. I create a new file in Instruments, choosing CPU sampler.
2. I record a 2 to 5 minutes session, making sure I record the part of the game where the frame rate drops (!)
3. After the run, spikes (higher spikes…) would show, matching the time when the frame drop occured. I tried to get to this sample by sample, but I couldn’t extract any useful information.
4. Now, checking the inspection range button group at the top of the instruments UI, I noticed that I could restrict the span considered for profiling.
5. I then compared overheads within and without the frame drop time-span.

I took a couple of screenshots so I could compare easily. Here’s what we see:

• In the first case, CPU usage is very low. The game spends about 80% of the time waiting for the frame callback (note we’re running on an iPhone4, and this is a universal app also available on iPod 2nd gen.)
• In the second case, 85% of machine time is used up. There will be other things happening in the background etc… but more importantly, we can identify several activities that are, otherwise, simply insignificant (too fast for the sampler to pickup):
  • Drawing actors. This occupies 50% of the run loop
  • Evaluating decorations

Oh well. I happen to have 4 actors in there. Incidentally the model is the heaviest I’ve got. The actors aren’t showing on-screen when the frame drop occurs, they’re just nearby. But as a general rule, it’s much better to send more than less than there is to view(!).

The next obvious step was to go back to the game script and see what happens when the actors are removed. The frame rate recovered completely – all that was needed was optimizing the geometry for these actors.

Conclusion

This quick case study shows how CPU sampler can be used to identify overheads within a specific time-span. No traces, no manual profiling. It’s a very simple technique, and it can avoid heading in the wrong direction based on vague intuitions of where the overheads should lie.

In this case, the scene considered actually cumulated several candidates:

• The scene is complex. In fact I had to break up the scenery into several components because the max vertex count (owing to number format in my files) is ~8000.
• Procedurally generated decorations add to the rendering overhead for static elements.
• But the actor model, duplicated 4 times, is also heavy.

When I started off, I was so convinced that the complex scene was responsible for my overhead that I was about to do the artwork all over again, even though scene rendering uses VBOs. Bothering with firing up the profiler and running a 15 minutes session total pointed me in the right direction.

Originally developed under the codename ‘Hairlock’, Antistar 3D: Rising. is a universal game (iPhone, iPad, iPod Touch) published on the 1st of August 2010. Artwork in the game is a mix of Blender art and procedurally generated elements.

A Key Decision…

It was decided very early that all the details in the game would be modeled – no textures! There are several reasons why Antistar was created this way:

1 – I have never been very fond of textured games. This is isn’t because I think textures are bad, but because usually, I find that textures are abused, becoming an easy substitute for shading and high quality visual content.

2 – I trained myself in blender around 2000-2002; I always focused on modeling.

3 – Supporting textures would have added a load on the engine, taking longer to develop, leaving much less time to produce the actual content, making it potentially harder to run at frame rate and increasing loading times.

4 – Although it is now available on iPhone 4 and iPad, the game was originally developed to run nicely on an iPod Touch. On a small screen, the need to crowd scenes with tiny flatland decorations isn’t obvious – even if some games (e.g. Samurai: Way of the Warrior) use textures very ingenuously.

Blender’s good

Edit mode rocks!

Back in 2000 when I discovered Blender, I was still looking for software that could help me make my models. I am not a professional artist, so I need to try again and again until I see what I have in mind in the 2D view. Blender’s edit mode, with one hand on the keyboard and another securely cuddling the mouse, lets you change things over and over again at the speed of thought.

While the game doesn’t use textures, Blender has a nifty ‘retopo’ mode allowing to project geometry onto a surface while editing. This was used to add effects that make some players think that the game supports textures, but more importantly, offer an OK substitute to textures in situations where they’re really needed.

Free and comprehensive

It just turns out that Blender is completely free, open source and comprehensive. I didn’t use many features, but these are key to creating a game:

1 – Support for bone animation, with a little of a learning curve, but the same ergonomics found in edit mode, allowing to quickly define and adjust areas of influence for bones, add constraints, etc…

2 – Python scripting. I looked around for an export plugin for ages before getting into it, only to realise that python scripting isn’t hard, and there are key advantages to writing your own file format for 3D. In Antistar, geometry is loaded on the fly, in a format that Open GL understands, as exported directly from Blender, in just a couple of clicks.

Technical data

How much geometry in there?

As this was my first 3D engine, and my first experience on a mobile platform, I was fairly cautious when I started modeling, as I was worried I would run out of GPU time fairly quickly. Over time I realised that (a) rendering is pretty fast, even on an iPod Touch 2nd gen, and (b) once we do away with mapped images, we have a lot of polygons to play with (it’s also good to know that smaller poylgons render much faster than large ones). Here are some examples:

- Humanoids and other creatures: 650 to 2500 vertices/quads(*)
- Small decorations: ~40 vertices/quads or less. These can get duplicated a few dozen times in the same scene.
- Terrain (e.g. the ‘incubator’ scene displayed at the top): up to 10,000 vertices/quads.

(*) In most cases, the number of vertices is roughly equal to the number of quads.

Rendering

For rendering, I used a mix of just-in-time calculated and real time lighting (for actors and props). Evaluating simple illumination on the fly while loading models has advantages, but I haven’t implemented a method to refresh lighting following the day/night cycle in the game; instead, fog is used to affect the rendering of the environment according to the day/night cycle.

I’m still considering whether to use LOD (level of detail) nodes (aka, lighter models when viewed from far away) or not. In the first version of the game, I used depth of field balancing to avoid dropping the frame rate too much. depth of field balancing works quite well, although it seems a little difficult to make it perfect :). in the meantime, artefacts aren’t usually disturbing and may even bring a little life to the game, with soft oscillations in depth of field and fog level.

Cheats ?

At times 3D can get a little intense. To create the dark forest near Klinnburg, I flattened the trees, only leaving 2D geometry. This allowed keeping patches of procedural grass that I kinda like, and adding walkable stones here and there. I don’t like doing that too much, because it always does show a little.

Future work

materials

In the first release, the exporter only processed RGBA colors for materials. The engine is a little more powerful though, as it can take parameters for shading, ambient… well, the basic kit.

I probably want to get better at python scripting, so I can explore ways of generating geometry using plugins, and better balance what’s generated on the fly versus what gets loaded.

level editor

Currently, my export plugin handles objects and bone animations quite well, but it works more like a library export plugin, with any blender file containing a generous mix of actors, items and terrain. I want to take the time to turn this into a level editor. This would help streamlining the workflow, as for now the ‘level editing’ process consists in walking around the world and writing down coordinates (**)

forward raytracing?

And finally, I’ve been working on ‘rough and ready’ procedures for self illumination (!). This can be used part in real time, part by pre-calculating contributions. Initial results are promising and the results may ship with the game within a couple of months!

————-

Antistar 3D: Rising – is a realtime 3D adenture taking advantage of 3D capabilities on the iPod Touch, iPhone 3G/3GS, iPhone 4 and iPad. (app store link)

Update: Antistar 3D: Rising is now available on the app store!

Why is a 13 year old dreaming of metal cities?
What lies in the dark forest beyond Klinnburg?

Anticipating the success of the Twin Star Saga,
Antistar 3D offers stylish anime action and adventure.

>> Watch the video
>> More screenshots

Join the buzz or check discussions on Touch-Arcade forums.

With an exciting title putting experienced and new players on fair ground, we’ve just proven that mobile entertainment owes nothing to game-boxes:

• Realtime, fullscreen interactive 3D
• Unique mix of adventure and arcade
• Unexpected allies and opponents
• innovative ‘no grind’ gameplay
• An original cast of haunting, magic creatures.

From the quaint emptiness of a marooned village to a mice gang’s lair, become a child without memories,
armed with only courage and a forward attitude to solving life’s little annoyances – not having a clue what’s going on, not having a chance against oversize wildlife and getting captured by really bad guys.

With procedural landscapes, three dimensional growth and beautifully detailed models,
Antistar 3D: Rising pushes the limits of 3D on mobile platforms and will seamlessly adapt to your device’s capabilities.

Main Contributors: T.E.A de Souza, Chan Zhang, Karen Xu; Music: Matt Hansen (Calpomatt), Justin R. Durban (Edgen), Mark. SFX: Mark E Buckland, Robert Gacek (FXProSound), Joel Carli, Sith Master, Starmanltd, The_lone1, T$_Technologies.

Antistar 3D: Rising will be distributed as a universal app taking advantage of all device’s capabilities:

• Basic rendering optimized to run smoothly on iTouch
• Antialiasing (iPhone 3GS)
• Retina Display (x1.5 iTouch definition 3D view)
• 1004×768 full-screen on iPad

Visit the product homepage for a quick description.

I’m going away for a short week break. Chances that I submit before leaving are… …marginally small.
This is a picture from Hairlock’s first stage. Can you spot the teddy bear at the back?

Changing the artwork did introduce a few bugs. And I haven’t done much about sound yet.

Hairlock is an action/adventure game compatible with iTouch and iPhone devices. Hairlock will be available on the app store in July 2010.

I hit a low this weekend, feeling exhausted and dispirited (is that a word?). Finishing a game is exactly what you’d expect. A b**ch to get done with, never mind fixing bugs.

The fact is, the later stages in my game didn’t receive the attention they deserve. Now they do, and that’s good.

I’m putting together a little advice about game graphics. Maybe little use to you if your budget exceeds 10 000$. Otherwise we’re probably on the same boat.

What makes game graphics look rich?

Our perception of game graphics seems largely based on three simple dimensions:

• usability. Graphics are part of a game’s user interface. Poor ergonomics when producing graphics can mean any number of annoyances that can ruin the fun of playing, including, but non limited to:
  • user can’t differentiate walls from the ground
  • user can’t find their way our 3D world
  • user can’t distinguish items from decorations
  • user can’t see gaps between platforms
  • …
• countability. A detail isn’t a detail if it can’t be counted. Twisting a curve this way that way isn’t terribly useful. Adding a couple of spikes on a flat landscape is.
• nameability. Anything that a player can name ‘counts double’. A scene full of details is ‘just full of details’. A village with a horsecar, a well and a church has 4 countable elements. If the well has a roof, you can make it 5. Tiles on the roof? 6.

The bottom line is that being a great artist isn’t necessary, and might in fact work against producing rich game graphics. Graphics for gaming is craft first, art second.

The above rules don’t invalidate whatever we hold to be principles of design. In fact I would rather assume that basic design principles (this blog’s not the place) have been assimilated before considering the above.

Drawing on a piece of paper, I like to express an idea quickly, with as few strokes as I can. But I don’t really think a game scene ever has enough details. Even if you can afford throwing in enough details to crowd a scene, getting everything in (and visually tuning your stuff to avoid the crowded look) is just what you want to do.

What will cost you dearly?

Before I started making graphics for a game, I mostly cared about organic modeling. Fair and square, I concentrated on trying to make human faces. I still don’t think it’s a bad idea and, in fact I would maintain that’s exactly the first thing to worry about. However…

• Making game graphics that interact nicely with a game engine, especially an immature game engine, can be difficult or just frustrating. Making an engine that can support just whatever graphics are brought in can be… …a nightmare. The best approach is to keep it simple (consider squares for a start… don’t underestimate all that can be done with just flat, square terrains).
• Every type of object you might want to model brings it’s own challenges. If you’re new to this, then like me you’ll have something surprising to learn about why natural landscapes are hard to make; why even square buildings with square doors and window frames can be a nag… …and so forth.

What’s not a problem (anymore)

Face and vertex count. I don’t know about textured games. All I know is that the amount of faces and vertices you throw at an iPod touch 8gb isn’t a major issue. Overlaps are an issue. So you can make a smooth, detailed model, but not stack huge faces behind each other. In 2010, even mobile 3D needn’t be rough and blocky.

Save your time and your buck?

Given the above, here are two golden rules that can help producing rich graphics in reasonable time:

*Use simple shapes*
Literally. Use cubes. ball, cylinders, circles. Simple extrusions. It’s not just saving you time; it’s making graphics easier to read for your players.

One argument against simple shapes is that simple shapes don’t amount to anything recognizable. Well they surely do. A plane means nothing. A ball means nothing. A ball above a plane means a whole world, viz. the sun, earth and sky.

*Don’t work against your 3D tool*
As a 3D artist, my 3D tool doesn’t interest me very much. Especially not the features. Every other feature seems to be doing some other stupid thing that doesn’t help creating great models.
As a game creator, I love my 3D tool. Every little feature and function can be used to achieve a slightly different feel. So instead of just using simple shapes, or spending hours fighting with meshes and bezier curves, I can make my graphics more fun and engaging in a few clicks.

While my iPad is waiting to get a programmer’s attention, I ordered a Diga pen to try out drawing software. I doubt whether that’s gonna be much use but… …Just using this thing as a testing device or a reader would be a little limiting, right?

Terraforming?

I feel I’ve been muddling through tediously all the past week, with many artwork related bugs and time spent fixing the terrain

Although terrains are large, and ideally geometry for terrain should remain simple, the player is navigating the terrain, not looking at it from afar… I tend to get the scale of terrain elements wrong at first, and it takes testing the terrain and correcting it here and there to get it right. This can get horribly time consuming.

Planning

1. For the end of this week, I should finish getting the terrain right. All terrain should look OK and be walkable from Monday onward. My guess is the cabinet and icons could also be done this week still.
   • Stone bridge
   • Rope bridge
   • Spacecraft wing (to cross to field)
   • Correct river
   • Make ground/walls readable (cliffs)
   • Specify walkable areas (walkable/non walkable objects. Ideally there should be only walk test and NPC collisions, no terrain collisions.
2. March 28 – April 4: Make the game beautiful while running at frame rate (March 28t – April 4). On the Monday after I want to send a preview to selected game sites.
   • Integrate new NPC models. Each NPC can slow down the game a little so this needs to be done before optimizing.
   • Make and add decorations
   • Optimize until frame rate and frame rate variation are acceptable.

   At this stage it should be OK to walk around easily and stuff will look good. The game is already somehow playable, but is lacking in several areas: stability, persistence, story and plot, animation and user experience.

3. April 5 – April 11: Get the story and plot right
   
4. April 12 – April 18: Resolve stability and persistence issues; start testing.
5. April 19 – April 25: Finish animation and user experience
6. April 26 – April 30: Wrap up and submission

In space, nobody will hear you geek

There you are. I’ve just completed core gameplay programming for the first episode of… well… let me think up a name for it.

This looks like a small adventure/action game in real time 3D. Core gameplay can be summarized as follows:

• 4 player actions
• 9 different NPCs
• 6 items to collect
• 5 stages
• dialogues, here and there, to orient the player towards the right solution

There’s a lot to get the game done, but I still hope this won’t spread over more than another month (part-time). What do I leave out from ‘core gameplay’?

• Bugs. Many bugs.
• Non-committal gameplay elements – more dialogues here and there, minor NPCs without complex behavior and so forth. Non-commital gameplay elements are important. That’s added value on my game. But one needs something they can add value to, right?
• Game tuning – mostly timing / measurements related.
• Prettier rendering
• Production level artwork
• Decent Sound

Technical Design, Methodology

Given the above, you bet I didn’t bother with either of the following:

1. Getting stories ‘done done‘
2. Unit tests
3. … other nice things

Why? Is the nice, agile stuff not nice more? Why is missing the ‘done done’ over and over so irritating while doing team work, but somehow left out when geeking in a small studio? Do unit tests not warrant code quality and so forth? Or is it just that it’s faster to do without all this stuff?

Here are a few things I surely didn’t leave out:

1. Story driven. Even though I had to build an engine before I could even get to thinking of a game, I’ve kept a steady emphasis on getting valuable items done.
2. Separation. Didn’t write big classes, usually separated state from behaviors in the core model, defined a pseudo scripting interface (short of a scripting language integration) atop my game engine. Did write a small engine versus just a game, and so forth…
3. Integrated workflow. I arranged that I could update my assets in one click. No muddling through with cumbersome export procedures. The same goes with poor code and documentation. Poor code might be OK for a while. Poor undocumented code is worth nothing. Good, undocumented code doesn’t generate integrated workflow – not knowing how the code works doesn’t flow much faster than no code, or code that doesn’t run to spec.
4. Optimization. I did follow the time honored (ignored?) command: do not optimize your code… …unless you have to. So I always wrote first the simplest code that did a job, and faithfully relied on a profiler to help me frame-rate on a powerful, yet mobile platform.

Where is Attitude?

In a well funded team project (as in, bucks per hour), earning money needn’t be the primary motivator, but in the long run, there is no clear ‘finish line’ for your staff. They will work on and on, and get happy to get stories done done – work well done completed every one two three weeks.

In a solo project such as this one, or a small, non funded team project, getting the product done is the primary goal for the team, or the ghost out the machine. Psychologically, having half of the product done done half-way through feels much tougher (at least to me) than having the product about half-done half-way through.

So I what felt like was, OK, if I just sit and polish every detail one by one, I’ll be overwhelmed by the task at some point, whereas by attacking frontally every sizable, unavoidable task, I’d get to a point where it would be such a horrible shame not to finish that I’ll definitely manage.

Poor code, OK design

Do you remember your first game engine? Nothing to be proud of except getting a job done, right? Same here. Dead code, flawed code, even deep flaws in the design here and there, but it sort of works, and I would argue that’s enough.

This is what refactoring is for, and to some extent this is the (maybe illusory) benefit of strong ownership and solo programming. It’s much easier to get the product done and defer refactoring if you’re soloing. After all, if you don’t get any benefits from the product, you might just as well give up the code. I felt it was OK. On the other hand, really badly design code with large classes, no separation of responsibilities and no usable game development API, that didn’t seem tractable. Not only it could be impossible to refactor, it would have made finishing the product draft prohibitively hard.

I look forward to refactoring this stuff. In particular, I look forward to doing it while fixing the bugs. If a bug is impossible to fix with my current code, then there’s a case for redesign.

Docs are up

There’s been a point where I felt this stuff was so messy I’d never get out of it. Then I managed to delete a lot of dead code, crossing fingers every time that the code was really dead since I didn’t fancy getting it back from the attic, not even the recycle bin. That I mostly threw away whole classes rather than code fragments brings the point home regarding separation.

Then there was a point when I started designing the game, and I felt like throwing half of the working code away, because the code didn’t seem to support the design. So I did the unholy thing that you can only do if you control both the technical and artistic design – Instead of throwing my stuff away, I documented it, putting on top what seemed to actually work, and tried to redesign my game around the highest confidence bits of functionality. Finally this helped improving stuff that could be used in a design empathic to the engine, and throw stuff that was neither necessary, nor stable.

Looking at my docs, I’m reminded of a harsh, fun comment about docs masking poor code. But actually, even docs over poor code can be better than good. If code is bad enough that it can only be used in one or two well documented ways, that’s still functionality I can flow with, never mind indexing essential behaviors that should be maintained and improved, versus stuff that needs to be forgotten and deleted.

Spaghettis, Meatballs and a Haircut

In the next days, I’ll try to tend this blog more often. Because I’m gonna fix this mess, and hope to find design insights worth sharing along the way.

Until then, let’s write dirty code. Or if you can’t, get help from above.

Yea I know… screenshots… another time.

In my previous article, I drafted/debugged basic combat behavior in a game prototype. A simple combat system probably needs to account for the following – if only to get animations to sync correctly if character actions are independent.

• Impact Frame – unless you have fine grained collision detection, the impact frame determines when the opponent actually gets hit.
  I am adding per action impact frames – each action can define it’s own frame/time offset. I’ll probably use a time offset instead later, but that will be part of a general effort on my part to move from frame based to time based modelling.
• Passive reaction – When an actor gets hit, they cannot enforce their decisions.
• Impact condition. A simple model can take into account the orientation relative to, and distance from, the target. My model already has this but that seems a little buggy.

Writing a class to hold impact frames is nothing, although you might legitimately want to store your impact frame information anywhere else:

#import “ImpactFrames.h”

#import “Definitions.h” // used for the ‘act’ typedef which is just a NSString*

@implementation ImpactFrames

static NSMutableDictionary* map;

+(void)putFrameOffset:(int)frameOffset forAction:(act)action{

if (map==nil)map=[[NSMutableDictionary alloc]init];

[map setObject:[NSNumber numberWithInt:frameOffset] forKey:action];

}

+(int)getFrameOffset:(act)forAction{

return [((NSNumber*)[map objectForKey:forAction]) intValue];

}

+(void)clear{

[map release];

map=nil;

}

@end

Passive reactions can be implemented using three tags: action, affect and activity

• Activity represents the current action.
• Affect represents a passive reaction to an external action
• Action represents the actor’s decision.

Then each evaluation can be structured as follows:

1. If an affect is defined, override action with affect
2. If the current activity matches the current action, continue.
   1. If we have not reached the last frame for this action, continue to the next frame.
   2. If we have reached the last frame, clear the affect and action labels.
3. If the current activity is the ‘rip state’ return immediately.
4. If the current action is different from the current activity, initialize this action.

I had to patch my actions a little because I manage motion and activity independently, so I need to replicate some of the logic.