I love this photo

Props to Guy Parsons

I discovered this website today, looks like it should contain some useful stuff for people developing game tools.

The Toolsmiths

These videos have been kicking around for a while, but if anyone hasn't seen the tools for Love - a game being developed seemingly solo by Eskil Steenberg - you should check out this video and the others on his site.

The Tools

Whilst personally, I'm not sure re-inventing the modelling package is something that artists are really looking for, you can't deny that he makes everything look pretty.

Source Control is not a delivery mechanism

How do you get your tools out to the team?

If your preferred method is to shout over to the artists: "New tools are ready, sync to Perforce now!", then you're a bad dog, no biscuit for you.

This is exactly what we used to do, but no longer. Here's why:

50% of our support questions went like this.

ARTIST: "Help! My tools are broken"

    "Have you tried syncing to the latest" :ME

ARTIST: No.

    "Let's try that first" :ME

[Sync, try again]

    "There you go, all fixed" :ME

ARTIST: "You're the greatest."

The other 50% went something like this.

ARTIST: "Help! My tools are broken"

    "Have you tried syncing to the latest" :ME

ARTIST: "No"

    "Let's try that first" :ME

[Sync, try again]

    "Hmmm, yeah, er, that's bust, I'll go and fix that" :ME

ARTIST: "I hate you!"

When we switched to giving out installers we literally cut our support queries in half. Not only that but it also allowed us to properly version our releases, which makes tracking bugs much easier too.

Other things

Once you start with the installer, other advantages become clear. The process of building an installer is a natural fit for continuous integration, every evening you can build a new installer which can be given out to the team in the morning. This can lead to problems though, because if you are building an installer every night then it is by definition work in progress code. WIP code can have instabilities and bugs, and that can mean your team losing faith in the tools, and once that happens it takes a long time to earn it back.

So ideally, you do a nightly build of your latest code. A small section of the team, perhaps the technical artists or one of the more friendly designers can take the installer and upgrade every morning, after few hours or days of testing the installer can be approved and then you can offer it out to the rest of the team.

To force or not

In my opinion the jury's still out on whether to force an update out or whether to allow users the options. I guess ideally you'd support both, but in general I think that unless you have a very robust testing framework or team, forcing updates onto people will only generate bad blood when you break someones tools hours before their art review or something.

To be honest it seems pretty silly saying all this, because it is so obvious and once you've made the switch you can't understand why anyone wouldn't set their tools up to be installed atomically straight away. However, I remember the old days when Perforce seemed like the obvious way to distribute the tools, but no more.

Notes

• Deliver your tools atomically
• An installer is a good way to do this
• Automate installer creation overnight for a daily build
• Make sure you test the installer before distribution

Some installer software you could try:

• InnoSetup - we've used this for a while now, it's pretty good. Nice and straightforward to get a typical installer set up. Main downside is any scripting you want to do has to be in Pascal!
• Wix Toolset - we're looking into using this in the future. Integrates nicely with Visual Studio, can be scripted in C#
• NSIS - the other one of the big three. I've no experience with this, but it's by the makers of WinAmp.

I came across this interesting piece from Paul Bakaus called Why I would hire game developers for my startup and I thought I'd try my hand at the opposite view point to stop all those web developers feeling put out.

Rapid Iteration

With multiple releases a week ( or even a day ) web developers have really been able to run with the deploy, measure, iterate, mind set. Put that in context with game development teams who create monolithic C++ monsters that require days to change even the most basic features, for example front-end menus that require a full-time C++ programmer to implement any changes that the designers require.

High level languages

To the metal C/C++ coding is going to be around for along to time to come yet in the games industry and rightly so. However, look to the web developers and their complete frameworks built in high level languages like Ruby and Python. Why is the gameplay written in a language that excels at talking talking the hardware. Why can't the designers have their own framework in Lua, or Python or Ruby, which allows them to create complete levels without any intervention from a coder?

Openness

Search Google for a blog on coding techniques for web development and then try the same with game development techniques. My quick google search reckons the numbers are about half, but to be honest, I doubt the relevance of many of the game development results. Where are the blogs from senior developers in big name game devs? I'd love to see coding techniques from Uncharted or the way the cover system was implemented by the Gears of War team. I'm not sure whether this is shyness on the part of the developers or it's the publishers keeping them locked up. Either way, I think it is a shame and only holds back the industry.

Disclaimer

I know that high level languages are making in-roads into game engines, but there use is usually very limited. And I know that a lot of teams are trying very hard to get rapid iteration working with in their team, but this is the exception rather than the norm.

So there you go web devs, it's not all bad, I think coders in the games industry could learn a lot from you guys.

Well these articles pretty much answer any theories I suggested about making money through blogging.

From slashdot, via the WSJ, to a few real blogs

A couple of nights ago I went to see Simon Singh announce whether or not he will be appealing in the libel case that has been brought against him by the British Chiropractic Association. I went to the event to show my support for science against pseudo-science, but came away with a new found loathing for the British libel laws, which seem to be fundamentally flawed and heavily in favour of the corporation and the rich.

However, almost in passing, Nick Cohen mentioned something that - combined with a TechCrunch post I'd read that day - sparked a few neurons and I thought I'd jot it down.

Nick mentioned that newspapers are in decline; blogging is on the rise but that no one is making blogging pay and so how do the journalists continue to exist. ( I'm paraphrasing that pretty heavily, but I think that was the general idea. )

On the way home, my girlfriend and I were thrashing out ways in which it could work and I came up with this comparison.

Today, the newspapers work like this: a bunch of writers create content which are then aggregated by a selected few editors into a handful of publications which are then distributed daily or weekly. The writers are paid by the publication and the publication costs money and charges for advertising space. At the moment it just about works but revenues from sales are falling as more and more people get their content online. Online advertising on their websites in not enough to fund the whole process.

Now how about this scenario: A bunch of writers create content which they post on their individual blogs. This content is aggregated by an computer program based on criteria set by the reader ( e.g. Google Reader ). There are no longer a handful of publications but millions, one for each reader. The writers place adverts in their work, which is included into the RSS reader. As they are a single individual with minimal hosting costs, the revenue from the ads on their work is enough to pay themselves.

This is not a new suggestion, it the basis behind the whole blogging movement. So why are journalists like Nick Cohen unable to make a living from his writing? Note, I realise that Nick doesn't have any adverts on his site, but I believe the point is still valid. TV channels like ITV have existed for years and years entirely funded by adverts. In these days of targeted advertising like Adsense shouldn't this all be possible?



It seems to me that the problem is targeted advertising doesn't really work for high level content like this. As a scientific sceptic and someone who isn't interested in suing anyone for libel, what adverts do you think I would see when I'm reading a blog post about Simon Singh being sued for libel by the British Chiropractic Association? The image on the left is the result of a Google search for "Simon Singh Chiropractic libel".

I suppose that some people reading a blog post about this subject would be interested in finding a Chiropractor, but I would have thought there are better advertising subjects like, for example, books by Nick or other Guardian journalists.

When I started writing this post I was going to that what we need are advertising services where I can sign up for a specific demographic. e.g. C# coders, Games Developers, etc. and then I would get targeted adverts with a higher level focus, not just focus on a couple of key words in the post. However, I've no doubt that this actually exists somewhere, I've not looked. So what is lacking? Probably that the advertisers still aren't twigged to the whole online thing. The people who read a Nick Cohen blog, or a blog about Game Tools development should be the easiest people to advertise to in the world. You know exactly what to advertise to them. Well, in fact you probably don't, but you should know what not to advertise to them, and I'm pretty sure Chiropratic services is one of those things.

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

When designing a tools pipeline for your game, you could do worse than to adopt The Unix Philosophy as stated about by Douglas McIlroy.

The way in which we interpreted this philosophy was to separate each step of the pipeline into a single command line application, with a input file ( or set of input files ) and an output file ( or set of output files ). Running your export pipeline then is just a case of defining a script which calls each executable in turn, passing the output of one as the input of the next. You write a GUI that is used to set up the initial options and provide an interface to the user, and as each executable will be writing out to a log file, your GUI can also display the status and any warnings or errors that are generated along the way.


full size

The alternative would be to create a application which does everything. Some sort of Excel for games development. This might sound attractive on the surface. The user has everything under one app, you can unify the UI, the codebase is just one application.

However, this approach is simply not as flexible as the single command line tool approach. Imagine this common situation: you change your export pipeline so now all the models in your game need to be re-exported to match the latest engine.

With the monolithic single application your users would either have to load up each model and hit the export button, one at a time. Or more likely you would have to implement a new feature to the tool, complete with GUI, to allow batch exporting of a set of models.

With the separate tool pipeline approach you can write a script in a couple of minutes that takes a list of models and runs them quickly through your pipeline as a batch process. If it becomes clear that this is a feature that will be used frequently by users then it is no problem to add the GUI part at a later date, which provides a front end to the batch script.

Taken as a whole, implementing that feature fully in both cases is basically the same work. Implement a GUI option, call your model export code multiple times for many model files. The difference is that in the second case, with the simple command line tools, we can get a batch export running in under 5 minutes, then if needed, we can add a GUI later on. With the monolithic app the GUI is a required part of the tool and the coder who writes the new feature must be familiar with codebase in order to implement the feature. When you're in a situation where none of your models work with your game engine and your whole development has ground to a halt, setting up a batch export in under 5 minutes is invaluable. ( Of course if you've managed to get into a situation where someone has changed the model format and brought your development to a halt then you should probably have a think about how your team operates, but still... )

In addition to this flexibility with individual tools you get a built in modularity to your code. If you've decided to re-write your texture processor, simply keep the input file, output file interface the same and you can drop in the replacement very quickly. Decided you need an extra step to your pipeline, after the collision export but before the final compile? Write your new tool and drop it in between those two. Best of all, none of these tasks requires touching the code relating to the other tasks, so your changes will be more stable.

Talking of stability having discrete executables has another advantage in that they are inherently testable. There is no need for complex unit testing frameworks to maintain ( though in another post I may argue that you should have a unit testing framework anyway ). You can automatically test your tools, by running them on a known asset and checking that the result is as expected ( e.g. with a binary diff ). You can then be sure that after making changes to one of your tools you haven't inadvertently broken them.

So to summarise, build your pipeline with the Unix Philosophy in mind and you get:
- flexibility
- modularity
- testability

This is going to be awesome

It's really cool to see people doing things in Home that no one could have predicted six months ago. The post says it's out today, so I'm excited to see what people will make of it.

One thing I've really grown to love over the years as a tools programmer is the command line tool and automating everything.

Pretty much every C# tool I write is written as a dll with a command line exe and, if needed, a GUI exe. That way I can simply string all the tools together in a script and be sure that I'm running the same code as when the users are going through the front end.

So when I started developing stuff for the iPhone, one of the first things I found myself needing was an automated build script to create our distribution builds. Ready to give out to the team members without access to XCode.

The one problem I encountered briefly was zipping up the app bundle which I then added to our Subversion repository. Previously I'd been right-clicking and selecting compress. It didn't take me long to find the answer.

Also my build script sets up the correct Entitlements.plist and restores the original one back. This is very important as it can effect your normal build and debugging if you aren't careful.

My folder structure looks like this:

# Output of build process
/trunk/MyApp/build/Distribution-iphoneos/MyApp.app
# Build script location
/trunk/Tools/Scripts/dist_build.sh
# Entitlements file which is used for distribution builds
/trunk/Tools/Scripts/Data/Entitlements.plist.DIST
# Zip file which is added to Subversion
/trunk/Build/MyApp.zip

And this is my super simple build script:

#Set working directory
cd ../../MyApp

# Backup existing Entitlements.plist
cp Entitlements.plist Entitlements.plist.BAK

# Copy Distribution Entitlements.plist
cp ../Tools/Scripts/Data/Entitlements.plist.DIST Entitlements.plist

# Build
xcodebuild -configuration Distribution -sdk iphoneos2.2 clean build

# Change to app directory
cd build/Distribution-iphoneos/
# Remove previous zip
rm MyApp.zip
# Zip up the app bundle
zip -r MyApp.zip MyApp.app/

# Copy to location for Subversion
cp MyApp.zip ../../../Build/MyApp.zip

# Restore from Backup
cd ../../
cp Entitlements.plist.BAK Entitlements.plist

When you're target is to write some AI behaviour that makes a game object move in a realistic, but determinate manner, you really can't beat the spline.

Path finding and steering code is all very well and good, and can provide excellent results, but if you simply want a fish ( say ) to swim over to a point and not look wobble, or stutter, or swim into rocks when the path finding fails, then a spline is the best way.

Some code:

class Hermite
{
public:
Hermite();
Hermite(Vector3_arg start, Vector3_arg end, Vector3_arg t0, Vector3_arg t1);

// Return the position at this point along the spline.
Vector3 PointAt(float t) const;

// Return the tangent at this point on the spline.
Vector3 TangentAt(float t ) const;

// Return an approximation of the length of the spline.
// Calculated by dividing the spline into 10 segments and working out straightline distances between them.
float GetLength();

// Return the distance left on the spline in the forwards direction ( towards m_end )
float GetDistanceForwards(float t);

// Return the distance left on the spline in the backwards direction ( towards m_start )
float GetDistanceBackwards(float t);

Vector3 m_start;
Vector3 m_end;
Vector3 m_t0;
Vector3 m_t1;

float m_length;
};

Note, I've made the contents of this class public and removed the getters and setters to keep the sample size down.

Here's one of the most straightforward splines to use. The Hermite. It's incredibly easy to create, just provide the start point and tangent, and the end point and tangent. And then you can get any point along the spline using the PointAt(t) method and any tangent along the spline using the derivative method TangentAt(t) where t=0 is the start of the spline, and t=1 is the end.

Vector3 Hermite::PointAt(float t) const
{
float t2 = t * t;
float t3 = t * t2;

float h1 = ( 2 * t3 ) - ( 3 * t2 ) + 1;
float h2 = ( -2 * t3 ) + ( 3 * t2 );
float h3 = t3 - ( 2 * t2 ) + t;
float h4 = t3 - t2;

return ( h1 * m_start ) + ( h2 * m_end ) + ( h3 * m_t0 ) + ( h4 * m_t1 );
}

Vector3 Hermite::TangentAt(float t ) const
{
float t2 = t * t;

float dh1 = ( 6 * t2 ) - ( 6 * t );
float dh2 = ( -6 * t2 ) + ( 6 * t );
float dh3 = ( 3 * t2 ) - ( 4 * t ) + 1;
float dh4 = (3 * t2 ) - ( 2 * t );

return ( dh1 * m_start ) + ( dh2 * m_end ) + ( dh3 * m_t0 ) + ( dh4 * m_t1 );
}

It's so easy, now if you need to get your fish smoothly from where it is to another point. You just create a spline.

void CreateFish()
{
m_pHermite = new Hermite( pFish->GetPosition(), pFish->GetHeading(), pTarget->GetPosition(), pTarget->GetHeading() );
}

void UpdateFishPosition(float deltaTime, Fish* pFish, Hermite* pHermite)
{
float newT = pFish->GetCurrentT() + ( deltaTime * pFish->GetSpeed() );
if( newT > 1.0f )
newT = 1.0f;

Vector3 position = pHermite->PointAt( newT );
pFish->SetPosition( position );
}

The sharp-eyed among you will note that increasing t by ( deltaTime * pFish->GetSpeed() ) is not right. t is not a measure of distance, it is a normalised distance along the spline so the units here don't match.

We should be converting the (deltaTime * speed ) to be unitless before we increment t. Giving us this:

void UpdateFishPosition(float deltaTime, Fish* pFish, Hermite* pHermite)
{
float newT = pFish->GetCurrentT() + ( deltaTime * pFish->GetSpeed() / pHermite->GetLength() );
if( newT > 1.0f )
newT = 1.0f;

Vector3 position = pHermite->PointAt( newT );
pFish->SetPosition( position );
}

The one problem remaining is that your point doesn't move along the spline at a constant speed. The interpolation is dependent on the curviness of the spline. There are ways around this, but to be honest, they are probably not worth worrying about. If you keep you splines relatively short and instead use multiple splines linked together, you should move along the total length of each spline in approximately the correct time, even if your movement along the spline is not constant speed.

So, demonstrated using rubbishy pseudo-code and skipping the constant speed issue, there you have it. Hermite splines are a simple and effective way of simulating smooth and natural motion for your in-game objects.

There are some pretty esoteric settings available in all compilers and IDEs, and I've never much cared to get involved in them. However, sometimes these things are forced upon you. Like when I've was programming for the iPhone and debugging just stopped working one day. For the life of me I couldn't work out what I was doing wrong and why it wasn't working. I tried resetting the phone, XCode and my machine, but it didn't seem to make any difference.

Eventually I worked it out. I'd switched profile to try out a distribution build so that I could test installing the app through iTunes. To do this you have to screw with your settings and create a file called Entitlements.plist which has one boolean property get-task-allow. I've no idea what this value is for, but there are a couple of very important rules to learn about when running your app.

1) If you are building using a development profile, then get-task-allow should be set to true.

2) If you are using a distribution profile then you must set get-task-allow to false.

Also, and this is the bit that got me stuck for hours. Even if you are building with the debug configuration in XCode; if you are using a distribution profile you will not be able to debug. The debugger will quit with one of the delightfully useless messages of:

putpkt: write failed: Broken pipe.

or perhaps:

invalid hex digit: 116

Just switch back to your developer profile and breakpoints should start to work again.

Now we can find the point on an ellipse, given the angle around the ellipse we are positioned. What if we want to orientate our object to face in the direction it is moving as we increase or decrease the angle? Or what if we want our object to leave the ellipse and smoothly move onto another path, like a spline?

What we need is the tangent to the ellipse at a given angle. I knew this should be straight forward, but it took a while for my brain to slip back to A-Level maths mode and remember how to do this. Too much time writing Tools code I guess. Anyway, Calculus to the rescue!

So if P is the point on the ellipse that we defined in the previous post, we are looking for T the tangent on the line.

P = m_h * cos(t) * m_up + m_l * sin(t) * m_along + m_centre;

To find the tangent we want the derivative of this equation, that is the rate of change of P with respect to t ( the angle around the ellipse ). So we can simply differentiate w.r.t. t which is simple if you know that the differential of sin(t) is cos(t) and the differential of cos(t) is -sin(t). Giving us

T = - m_h * sin(t) * m_up + m_l * cos(t) * m_along;

Note, that we've lost m_centre, because that is a constant.
And that is it, here is the full method

Vector3 TangentAt(float t) const
{
float c = cos(t);
float s = sin(t);

return - m_h * s * m_up + m_l * c * m_along;
}

So, let's say you are writing a game, and you want something ( an enemy, the player, whatever ) to move in an ellipse. This ellipse is a 2D shape but can exist in any orientation in a 3D space.

So first off, how do you represent the ellipse?

We can define the ellipse as a centre point, two orthogonal axes and two radii ( or a height and length if you prefer )

class Ellipse
{
Vector3 m_centre;
Vector3 m_up;
Vector3 m_along;
float m_h;
float m_l;
};

Ellipse e = Ellipse( Vector3(0,0,0), Vector3(0,1,0), Vector3(1,0,0), 1, 1);

is defining a circle of radius 1 at the origin, orientated with y up and x along.

Ellipse e = Ellipse( Vector3(0,0,0), Vector3(0, 1, 1), Vector3(1,0,0), 10, 20);

is defining an ellipse which is angled forward ( (0,1,1) is up ) and along the x axis.

In order to move your enemy/player around the ellipse you will need to be get a point on that ellipse, this is pretty straightforward:

Vector3 Ellipse::PointAt(float t)
{
float c = cos(t);
float s = sin(t);

return m_h * c * m_up + m_l * s * m_along + m_centre;
}

Here t is the angle around the ellipse where you want your point. You can see that if the angle is 0 then the c = 1, s = 0 so the returned point is just

(m_centre + m_h * m_up)

i.e. the top of the ellipse.

for t = π/2, c=0 and s=1 so the returned point is

(m_centre + m_l * m_along)

i.e. the right side of the ellipse.

There you go then, how to find a point on an ellipse. Next topic, getting the tangent to an ellipse.