Extremely Moderate

It has come to my attention that Extreme Programming is the subject of some religious coding wars. Apparently, there are extreme Extreme programmers. Anyway, I've been using XP for a couple of years now and there a re some rules of thumb we've developed:

When you write a test, it should fail.
There are proponents for 100% test coverage, but that's not where we aim. Tests are there to drive development, so each new test when written should be trying to do something the system can't currently do - hence it should always fail, you write the code, it should succeed.

Test the behaviour, not the implementation
I'm using Google Test & Google Mock as my testing setup. It has a very odd syntax which the documentation encourages, where you can specify how many times you expect a given function to be called. Duh huh? Why would you give a monkeys about that, as long as the overall function gives the desired result? Using this will result in highly implementation dependent tests, and that means highly brittle tests that will fall over when you change your design in the slightest. Better to write a test along the lines of 'If you ask a unit to move to a given location, the unit moves to that location', rather than something in terms of function calls.

Make code general the second time you use it
An extension of the normal XP principle of not doing something until you need to. Don't waste time refactoring your code to be re-usable until you definitely find you're about to re-use it.

Pairing is not always necessary
Let's face it, a lot of coding is pretty straightforward. There are times you do by hand what a macro could accomplish, but it's not worth writing the macro for the time you'd save. In cases like this, you don't need to pair because you're not doing any thinking. Save the effort and let someone do it on their own. Minor refactorings and tidying up the appearance of the code also come into this category. It's often handy to keep a pile of these 'single programmer' tasks handy, as you don't always have an even number of people available, and that odd-man can't make tea all day.


There are more, but that'll do for now. The

Why people still don't use the STL

...because it is arbitrary, cryptic and seriously difficult to read.

Let's take a quick example, using std::map< filename,sample> m_samples:

 const BOOL AUDIO::is_playing(const FILENAME sound_file)
 {
  return (m_samples[sound_file].is_playing());
  }

works, but this doesn't:

 const BOOL AUDIO::is_playing(const FILENAME sound_file) const
 {
  return (m_samples[sound_file].is_playing());
 }

Why?

Well, std::map doesn't have an operator[] that returns constant references, of course. Gnngh.

No, you have to use this gem instead:

 const BOOL AUDIO::is_playing(const FILENAME sound_file) const
 {
  return (m_samples.find(sound_file)->second.is_playing();
 }

This forces you to use two major usability criminals, obfuscator-in-chief std::pair, which throws in a less-than-clear 'second', and partner-in-crime iterator, or in this case the snappily titled

 std::map< filename,sample>::iterator

Honestly. And oh noes! Heaven forbid you should want to use an STL container for storing resource classes as it unavoidably makes copies of things on insertion, so you'd better be using smart pointers or it'll be throwing things away left and right.

And another thing. Do you think it would be useful if a container class had a function called, oh I don't know, contains()? Nope. you have to cryptically look for something, and then compare it to an element off the end of the (not necessarily linear) container.

Good code:
 if (samples.contains(sound_file))
STL code:
 if (samples.find(sound_file) == samples.end())

Well, we could write our own contains() function by just extending the std::map, surely? But no! You can't inherit from STL objects.

And this is why STL is still widely ignored. It's useful, but that comes at the cost of code that will seriously slow down your reading if you ever want to come back to it.

Action!

Well, phew! Lots of actual work going on right now, so no time to talk.

Also, mildly deafened by Brian Blessed shouting loudly in my ears yesterday.

Testing Times

I'm an Extreme Programmer, no make that a Goddam EXTREEEEEEEME Programmer. Yee haw. etc.

'Extreme Programming', for those of you who don't know seems to stand for, 'Extreme-ly sensible combination of the last thirty years lessons in software development. Programming'. Fortunately, it's got a catchy and GODDAM EXTREEEEEME marketing name, otherwise y'know it might sound a little dull.

What it boils down to are a few sensible principles designed for building software, rather than trying to crowbar software into a system used to make bridges or circuits (ie Software Engineering).

The principles are:

Test First, Code Second - AKA Test Driven Development. Simple one this, all programmers want to get stuff working as the first thing they do. And the second. And the third. Pretty soon you've got a very complex system going, at which point it starts to break. And you fix it. And it breaks somewhere else. Bums. If only you'd written some tests to check the code was working. You can't do it now, where would you start? So you fall back on a combination of manual testing, and crossing fingers.

Test driven development demands that you write the tests a little at a time, for a bit of code before you code it. This makes you nicely disciplined into doing it, and gives you a great batch of tests that'll tell you if your new changes have broken anything. Believe me, this is a great relief. As a nice side effect, structuring code to be testable generally forces you to have a clean design.

Keep it simple - Only write the code you need to pass the tests. If you need more code, write more tests. This saves you writing code to solve problems you might never come across.

50% now is better than 100% never - Get something working as quickly as possible. Use placeholders, simplification, whatever, just get it playing. This way you can see if it's any good as quickly as possible, and you haven't wasted effort over-desiging something you're about to ditch.

The design is wrong and the customer is right - And if you've got something working, get players to play it, see if it's what they want, and if not, change it. Do not have a fixed plan for your destination or you may end up building a lovely white-elelephant that nobody wants to play.

Two heads are better - Get two people to work together on everything. This not only reduces bugs by about 60-odd percent, it also stops you wandering off down pointless paths and lets you bounce ideas off your partner. Ideally, one of you writes a test and the other implements the code (then vice versa) so you don't prejudice the implementation. I'm obviously not going to do this, because there's only me.

Stand by for Action!

Confirmation received that my own spare time work does not clash with my day job...

Anything can happen in the next half-hour!

A nice cup of tea, for example.

Take Art

You'll notice I haven't said anything about pictures (or music) yet. Well, I'm not going to do these myself and I shall be throwing myself onto the mercy of some artist and musician friends later, but how do we get by for now? We use placeholders, and there are two traditional ways to get them.

1) Theft
2) Programmers

Both have the advantage of speed, so we don't waste too much effort on something we aren't ultimately going to use.

Theft
Well, piracy. Simply use somebody else's graphics (sounds, fonts) from someone else's game, or the Internet. Very quick, and you get good quality results straight away. You can get away with it, as nobody will ever see (hear, read) these 'borrowed' assets. There is one major drawback, however.

You will forget.

You will forget to remove something from the final game, and then you can be in hilarious* legal trouble with your finished game. Not good. For this reason, I'm completely going to avoid this route and go with...

Programmers
Programmer art! It's great! Or not! Yes, programmers can do pretty much anything as long as all you want are some correctly formatted data files. We're spending no time here, so doubly bad. Programmer assets do have a big advantage though: they're noticeable. You aren't going to accidentally leave your enemy marines as bright pink rectangles. With any luck, they'll be so bad that artists will replace them on sight. Bonus.

*Not hilarious.

And The Bodies of Your Enemies Will Float By

The annoying thing about the Internet is that whenever you try and do something, a quick Google search shows that you might as well not bother, as it's already been done.

The great thing about the Internet is that whenever you want to do something, a quick Google search shows that you don't need to worry, as someone's already done it for you.

I've been practicing the great art of achieving lots while doing nothing. If you remember, I can't write any code until some contractual issues are resolved, but that doesn't stop me making progress.

I've sorted out the map editor, and all my developmental foundations: the low-level graphics and sprite system, the memory and string handling, and a maths library, and all without doing a single thing. These are all things I've had to write from scratch in the past, often slowly and painfully, but which can now be had for the price of a little research due to the generosity of programmers, and easy communication over the Internet.

First off, I've downloaded and compiled the Allegro SDK. This provides all the basic functions I should need, and being a venerable framework will have many years of nice bug testing behind it. It's free and it has no restrictive licence at all. As there's source code, if I find any problems I can fix them and pass the fix back to the main development community too. Although it supports 3D, it was originally 2D based which will be perfect. 2D is very much the poor cousin to 3D these days. DirectX 8 for example did away with it almost completely, making you use a sort of odd, flat 3D, but the outcry was so bad (and people stuck to DirectX 7) that they had to bring it back for DX9. Nobody, of course, will touch DX10 unless forced, as you can merrily wave good bye to any customers using Windows XP or earlier. A quick glance at the Steam hardware survey shows that as of today less than 30% of systems can run DX10, and that's gamers not just general users. Still, looks like it's up 4% since last August, so it'll be viable real soon now! Honest!

Anyway, backing me up in the tools department is respected tile map editor Mappy. There are several tile map editing programs around, but at a quick glance it looks like is the one for me. It covers both top-down and isometric views, as I haven't decided which to use yet, and joy-of-joys it even has source code for integrating it with Allegro applications. Ace.

All this means that I don't have to faff around builing the structure to let me make a game, and that I can get on to actually making one.