And now... the Prologue.

A while back I started work on a remake of Powermonger which was abandoned for various reasons (mostly due to an increased workload and general recession-related crapiness). However, there were other reasons, worth mentioning if they contain but a glint of gold for the would-be hobbiest programmer, for why the project failed.

(I also don't know where the blog went, I don't recall deleting it! Maybe I did post-pub one night, who knows. Shame though, had some nice pictures...)

1. There was no 'Game'
There was an 'Engine', but no 'Game'. Engines are easy (and fun) to write. However, when it came to making little people move around the world, interact with each other, interact with the world, communicate with each other etc., etc., I ended up with huge switch statements containing vast numbers of conditionals and ended up getting completely lost.

Even if it looks crap, BUILD THE GAME first. Maybe just different colored pixels for the game agents, a console overlayed which outputs properties for different selected items, etc. Cut out a dimension if you must and view things top-down without ever going 3D.



I recently acquired a copy of Programming Game AI by Example, by Mat Buckland. In it, he lays down the groundwork for a Finate State Machine with Enter/Execute/Exit points and also a proper Messaging System so different classes can communicate with each other via a proper Entity Manager. It's a lot of ground work to put in, but worth it in the long run. I should have done this at the beginning.

Now, everything from static objects to people are descended from a base class which is capable of sending/receiving messages. (things like trees are a level down, contain position, and capable of receiving messages, whereas people, captains etc. have also a finite state machine, velocity etc.).

2. Writing games is not easy
Perhaps for some, it is. But for me, it isn't. Some days I look at a section of code as though I'm looking at a Haynes manual for a Reliant Robin. But part of the thrill is the challenge of pushing one's self to accomplishing difficult tasks and extending one's knowledge.

Perhaps in retrospect, Powermonger was a bit ambitious a project for a first ever game. Perhaps it would've been better to start out just doing a simple platformer 0r puzzle game.

Anyway, all the AI doesn't have to be in there for now. Can just be captains wandering to towns, recruiting, then when they are confident, taking on other captains before they can rouse a similar rabble!

3. C++
"In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg." — Bjarne Stroustrup.

Despite learning C++ at university, I managed to get by with a sort of 'vanilla C' and only recently bothered to learn about STL containers.

So I gladly plowed through my code, replacing arrays and pointers with vectors, maps, sets, lists etc. with their own iterators where appropriate. For small projects, everything was fine, until I started getting SIGSEV messages with very cryptic output.


If you have a class:

class MyClass {
public:
MyClass() { data = new int[100]; }
~MyClass() { delete [] data; }
private:
int *data;
}

and call the following:

vector<MyClass> vClassContainer;

for(int i=0; i<100; i++) {
MyClass c;
vClassContainer.push_back(c);
}

... then what happens is that the Copy Constructor actually gets called, C++ does it's best and performs a shallow copy which causes various problems. "data" is not allocated for the copy, and delete gets called on an un-allocated pointer.

So remember your copy constructors and (though I suspect you don't need it) assignment constructors.

i.e.

MyClass(const MyClass& a) { data = new int[100];
/* ... whatever method you like for copying 'a' data ... */ }
MyClass& operator=(const MyClass& a) { data = new int[100];
/* ... whatever method you like for copying 'a' data ... */ }

// However, if you call the following, you won't get this issue.

MyClass c[100];
vector<MyClass> vClassContainer(c);

A silly example here, but an idea of where not fully understanding how something works can actually cause a lot of confusion in the long run. Often in the interests of 'saving time'. ;)


4. # I'm free, to do what I waaant, any old ti-iime...
When a project becomes publicised, you are exposed to a large collection of opinions, ideas, suggestions, criticisms, compliments and pretty much the whole spectrum of public debate. It's wonderful to have people interested in your project, any many of them offer invaluable support (and my thanks here to Viridian Games for invaluble help with a large number of things for the original remake). But there can also be a pressure to conform to different ideas about how your game should be. If you're not careful, you end up turning your project into something you never wanted it to be, and as such, your inspiration to keep working on it dries up as it resembles and less and less what you had hoped it would be. Sometimes you just have to plow ahead with your own idea of how things should be.

5. Patience.
Much of it required.