The P Project

Lorem ipsum dolor sit amet

2011-06-23T01:01:00.000-07:00

What's been happening? Not much. My PC has been in boxes for a couple of weeks whilst I've been moving house, this coupled with a heavy workload (but learning Android development, fun!), doing French, Russian and Ju Jitsu in the evenings (not at the same class) and attempting to draw again and remixing some tracks for a friend is making dev time somewhat scarce.

However, a commenter asks (thanks "WebSurfinMurf") whether the source will be available. Yes, absolutely. In fact, it may even be necessary to see certain portions of the game finished that I'm not terribly interested in. My plan is to do a decent tidy of the source code and then put it on a free account at GitHub, despite the fact I've been using SVN so far and have no real experience with Git... though I'm told it's easy enough.

Videos... videos! No apologies for the quality of this one, I'm using a USB2.0 video capture dongle with good old NTSC. So it looks like a lot of the US TV shows that got shown over here in the 80s. ;-)

Currently things are based on context. Click on an area of land, Captain moves there. Click on a Settlement banner, he'll recruit if it's friendly, attack if it's hostile. Likewise for entities. I'll set it so that clicking on buildings and agents goes up the heirarchy if appropriate. For buildings, clicking the workshop will initiate a workshop process, etc. No need for icons.

The resources for the project aren't too bad, but I need to strip everything out of the default Ogre media folder that isn't directly related to the project.

Instancing

A problem that's come up lately (particularly on a couple of low-end machines) is that OGRE slows down massively with multiple entities. (in Ogre, an Entity is a mesh, with material and animations, and attached to a positional node in the 3D scene). With about 50 units in a large army, and 50 units in large towns, often about 300-400 geometry batches are being sent to the graphics card. It's not really the 'amount' of triangles, it's more the fact that it's being sent in many batches, as apposed to sending a few batches with tons of triangles which is much more efficient.

OGRE has support for Instancing ( http://www.ogre3d.org/docs/api/html/classOgre_1_1InstancedGeometry.html ) , but the changes required in the code to support this are pretty horrendous and kinda break the paradigm that links game entities with their OGRE entities.

We may have to just see how it plays on people's machines to see if it's going to be an issue. Also, I'd like to keep individual entities as it makes selection much easier.

But before I go...

2011-04-18T06:08:00.000-07:00

I didn't want to leave the blog for a while without posting a video of the current build in Ogre3D. So I didn't. So there. Annotated for maximum annoyance. ;o)

Code

I've started getting into Boost recently. It's a dependency of Ogre, so it makes sense to use it. In particular, it's filter_iterator is immensely useful.

Also, some of the new features of C++0x are proving useful as well. I love the new auto keyword, where the compiler automatically works out what type the variable should be based upon the assignment it gets.

Unfortunately... the version of GCC that comes with XCode doesn't support these yet, so much time was spent changing things like:

auto filterIt;

back to...

boost::filter_iterator<std::const_mem_fun<bool, Agent*>, // continued...
vector<Agent*>::iterator> filterIt; // ... on a new line.

which was fun...

Music

Also, a quick note to awesome composer Tim Wright. I was curious about the synths and sounds used in the original Powermonger themetune. I dropped an email to Tim ( www.coldstorage.org.uk ) who did the original. He very kindly sent me an email with all sorts of interesting stuff about the original theme (some sounds were from the KAWAI K1 and others from actual orchestral recordings), which was awesome. He also did the music for the (acoustically and visually amazing) ST/Amiga games "Shadow Of the Beast II" and "III" which are well worth a listen if you have something that plays .mod files. He's still very much the top composer, so I heartily recommend dropping by his website and having a listen. Thanks Tim!

Big long post (and then a break).

2011-03-31T06:23:00.000-07:00

Hi guys, I want to wait until I have something playable before posting again, so there's going to be a long break.

I'm having a "dark night of the soul" about a few things, and wanted some feedback.

I think a lot of people are expecting an exact replica of Powermonger's interface, with the stone table, map on the left, captains at the back, etc.

To be honest, one of the things I hated about Powermonger was the usability aspects:
- The table buttons were (for me) hard to click, and find quickly.
- The isometric view made things terrible to select, find at certain angles, the rotation was useless (and screwed up move direction).
- The extra Captains didn't really 'work' properly enough to be worth utilising (unless you sent them to fight a Captain with an archer army where your Captain would get killed very quickly).

If I end up just remaking the existing game, I can't help feeling I will have:
- Made a poor-man's imitation of something the original PowerMonger on DOSBox did better.
- Possibly be asked to take it down by EA. (who have mused recently about resurrecting old IPs)

Q: At what point does a Powermonger clone stop being Powermonger?

For me, at least, Powermonger is the game. No micromanagement-nonsense that ruined Black and White. Not the horrible restricted view and table interface that ruined Powermonger (for me, at least). An immediately accessible game where you start out with a small rabble and impose your will on a very pretty map of nasties, with all the fun of building weapons, eating sheep and watching little people go about their business.

My own dream about Powermonger is the full 3D interface of "Black and White 2", where you were free to roam and spin the map in a very usable (imho) way. But 'in world' everything is like the original Powermonger. I want the user to be able to move around the game map freely, easily and efficiently, setting up the view camera anywhere. However, if you zoom out fully, you see the whole world, it's settlements, flags and troops... and the whole war room and table, with captains standing around.

So... if you have the time to spare:-

What aspects of the game actually made it Powermonger to you? (and without which it's not the same)

Advice needed on plug&play GameWorlds.

2011-03-25T05:04:00.000-07:00

At the moment, my BaseGameEntity classes (inside my main GameWorld class) have a virtual Draw() function which derived classes use to call some OpenGL commands.

Ideally, I would like to make my main GameWorld class completely locked up and independant of any rendering engine.

i.e., GameWorld can create a world, populate it, accept input messages and take a time value (delta time) to update the GameWorld. Completely on it's own without any 3rd party, OpenGL, DirectX, OGRE3D etc. proprietry engine.

For those in the know, what is the best (or most common sense) way to 'interface' such a closed system? The renderering engine (which I'll call AssociatedRenderer) basically needs to have knowledge of each entity it renders. For all intents and purposes, it's needs a "BaseGameEntity" pointer handed to it for each entity in the game, updated each loop cycle.

Should I add an AssociatedRenderer 'interface' class to each BaseGameEntity that has the following properties?


class AssociatedRenderer {
- void Attach(BaseGameEntity *); // i.e., ->Attach(this);
 called in BaseGameEntity constructor
- void Update(void); // i.e., in OpenGL this draws, in OGRE
 this updates entity positions.
}

... and leave it to each project that uses GameWorld how to implement AssociatedRenderer?

The downside is that I end up with different versions of AssociatedRenderer in each project that implements it differently. Could get confusing very quickly.

Go with the (state) flow.

2011-03-19T05:31:00.000-07:00

Been very busy with job and stuff since the last update, but work on the game has still been going on in the meantime. Mostly annoyances with a screwed-up state flow that was causing some very wierd behaviour from agents. Mostly in the message phases where agents, settlements and captains respond to messages from other entities. Also delayed messages were occasionally being repeated resulting in huge stacks of delayed messages.

But since last update:
- Properly implemented Retreat states for Captains and Agents. (similarly to the original, if a Captain dies, then his troops disband and run off back home. If their home has changed allegiance, they'll join that settlement's new allegiance.)
- Added Aggression (Min, Med, Max) similar to the original. (i.e., auto Max if attacked by another agent, or defending a settlement).
- Added Captains to anything larger than a medium settlement.
- Captains have 'Marauder' status, which determines whether they stay at home or go on conquests.
- Visual C++, XCode and Codeblocks projects. (I jump between them as occasionally something comes up I wouldn't have spotted on another platform. In particular, on OSX a 3rd party font library I was using was pulling a struct pointer value from a file { it must've dumped the pointer doing an fwrite of a struct with a pointer member } ... and on OSX it was pulling a 64bit pointer instead of a 32bit one, so the graphics were all garbled.)

I could be tempted to move into the graphical phase now, adding a Terrain class, etc. I think I will probably end up using Ogre to do the 3D part as it makes selection of 3D objects very easy, and also handles a lot of tasks that have very little bearing on the game itself. Also, I don't really want to waste time bogged down in certain areas. Ideally, the Game class will run in it's encapsulated form so that it can be plugged in with Ogre or anything else.

Texture testing.

2011-01-09T06:21:00.001-08:00

As lovely as OGRE is, I think I'll probably stick with OpenGL/SDL for now. There's always the possibility of porting later. Kinda ties in with the next bit.

In order to picque my interest, I started playing around ideas for the terrain engine.

A few years back, a sequel to Populous was released, called "Populous: The Beginning". I remember seeing the preview screenshots in a magazine (PC Gamer, possibly) and in particular I liked the way they did the terrain. (Image courtesy of MobyGames)

Whilst you couldn't arbitrarily raise and lower the land, you could use your shaman to build bridges across the terrain. The effect was very funky. Land would rise out of the ocean and the textures for sand and grass came through a kind of textured 'stencil'.

So, I started playing around this weekend with something similar. The screenshot is just a single tile where each corner has a height value.

The process I went for is roughly this:
1. Do a bilinear interpolation between the corner terrain height values to get a smooth heightmap (just greyscale).
2. Apply a displacement map loaded from a texture (greyscale as well).
3. Use this heightmap as the basis for mixing pixels between 2 different textures (e.g., grass, sand, ocean, mountain etc.). If your range is (0-255) and the current height is 63, then you would take (63/256.f)*TextureOne + (1 - (63/256.f))*TextureTwo for each RGB bit.
4. At each point on the heightmap, do a cheeky (heightmap(x, z) - heightmap(x+1, z)) to get a cheap 'gradient' value which you can add to the colour fragments to obtain a cheap bump effect.

For performance I'll probably have to use one 256x256 map over a group of vertices... rather than one per quad!

Re-inventing the wheel.

2010-12-30T07:11:00.000-08:00

As it transpired, the font rendering code (gltexfont) I used for the console didn't seem to work on the Mac versions (just got garbled output). Not sure whether it was a difference in the way files are read, etc. Anyway, I realised at this point I should probably start working on Texture loading/utilising code and Font code etc. which didn't take too long.

Basically, there are some tasks that just bore me. Texture loaders, managers, font rendering, image loading, object loading, etc. Basically, anything that stands in the way of actually putting a game together.

About a week before Christmas I started looking into game engine frameworks that could be used to save a lot of time. I tested out a few before looking into OGRE3D ( www.ogre3d.org ) , which seems to be implemented in a straightforward way (in fact, even basic classes like Vector3, etc. are implemented almost identically to the ones I've been using already... their coders must have a copy of the same book.).

After an immensely frustrating week battling with CMake, XCode, building from source, fixing dependencies, installing boost, uninstalling boost... I was beginning to get the impression that I had wasted a lot of time. However, a week later (and thanks to some very kind and helpful people on the OGRE forums), I'm working with Ogre3D and really enjoying it. It handles things in a very intelligent way, meshes are loaded into the scene and attached to nodes and everything works on a heirarchical basis.

It also has a nifty Terrain engine with LOD and texture paging which is kinda cool...

It's cross platform, so now I'm hoping to just plug in the GameWorld class I've been using so far and pretty much stop using the GameEngine class that's been wrapping it so far.

Also, OGRE supports lots of different object and texture formats so there's no tedious MDL loading routines etc. to write.

Perhaps I can start putting the 'game' into this now. :)

"Do Not Adjust Your Set"

2010-12-07T08:28:00.001-08:00

Holiday. Yay!

A lot of code thrashed at the moment. I realised that Settlements should have their own FSMs and message handling so they can respond to attacks, organise their settlers for different seasons, etc. So now armies can target and attack settlements and then recruit their settlers.

However, all this mindless code hacking has produced some unexpected results.

Well... that's not right. Alas, a lot of this sort of thing happens when you spend a morning just hacking away without scribbling ideas first down on paper. Trying to figure out why soldiers are following settlers even after they've been tagged as retreating. No doubt hidden somewhere between the states and the soldier's methods being called by said states. I'll find it.

On the plus side though, Captains now have a method "ConsiderOptions" in which they decide whether to find recruitable settlements, take on other Captains, take over enemy settlements (not currently implemented due to problem shown in video above), or just wander about. At the moment they only do this in the idle state. Ideally, a timer will allow polling of certain AI decisions so that they aren't run every cycle, but often enough to stop doing stupid things like chasing an army across the map that's getting bigger and bigger or heading to a village that's been emptied since the original decision to recruit it was made.

There's so much still to do...
- Implement Settler States (based on occupation)
- Add Inventory Items (boats, pikes, bows, swords, food)
- Add Inventory Handling (Agents, Captains and Settlements can all have items)
- Add Buildings (and makes them assignable to agents)
- SHEEP.

And that's even before putting the terrain back in, adding states for terrain edge collision detection, selection, sound, etc. etc. Oh well. It's still fun.

I'm also quite behind on my mail, so apologies to anyone that hasn't had a response yet.

Come back, I want to give you a thrashing...

2010-11-11T02:47:00.001-08:00

Hmm, I've implemented fighting in a rather silly way. Hence, I could use some advice from those who've written these kinds of games before.

Basically, when 1 Captain/Army attacks another Captain/Army, a function is called from the attacker's state which compares the sizes of the armies and then assigns each entity their target entity and then changes their State to Attack and all is well until one is defeated and then the entity asks their Captain who to go for next (if he/she is still alive, if they ain't, go home and make some tea...).

This was working quite nicely, until one army (A) attacked another (B) whilst it was already in combat with another army (C). After Army (B) defeated Army (C), Army (B) wandered off into the sunset with Army (A) walking along behind them, oblivious to the fact they were being poked in the back with pointy sticks, oblivious to their comrades shouting "ooh, my spleen" before collapsing face down in the daisies.

So... this simple Attack/Defend system doesn't work too well. (and, I seem to recall this happened in the original Powermonger as well... as it was a rare occurance in reality.)

I had an idea to maybe create a new Singleton class called "BattleMatrix" which contains ordered pairs of IDs (Defender ID, Attacker ID) and through which every entity in the game knows who is coming after it and who is still on it's "hit list" after other distractions (like pathfinding etc.).

Is this a good route to go down (before I end up writing masses of redundant code), or am I missing some obvious game logic somewhere?

In other news, I've been plowing my way through the Scott Meyer series of books (Effective C++, More Effective C++, Effective STL) whilst learning French and Russian at the same time, so brain may explode like that chess player. (don't worry, it turned out to be a hoax, but was a fantastic urban myth for a while)

"Ergonomically tewwific"

2010-09-07T04:06:00.000-07:00

Well, we're getting there... I haven't had much time to work on things lately as I'm trying to finish up my workload before going on hols for a bit.

Nothing very exciting here (and framerate/quality decimated by Youtube). Captains recruit their villages and go for a wander. White captain takes a dislike to Red captain, fight ensues [without the sprites, you have to take my word for it...] ;-) White captain wins the battle. Then takes on Yellow while his army has low hitpoints and loses. Then the two remaining armies have their captains removed to show what happens when the armies disband and the soldiers return home. Very basic, but I'm pleased with how clean the state machine runs at the moment.

I don't want to start doing the fancy graphical stuff for quite a while. I'd rather have the actual game mechanics working and the gameplay completed in this rather dull-looking 2D world than start adding fancy stuff just to justify nice screenshots. So you might want to switch off your RSS feed for a while if you want pretty screenies. :)

I'm particularly looking forward to having arrows, cannonballs that actually follow a trajectory. Originally, they flew across hugging the landscape like low-flying cruise missiles.

Very glad I picked up a copy of Effective STL by Scott Meyers. Didn't answer a question I had about STL so I'll throw it out here (and Google isn't helping either, maybe it's my search query).

Q: If your class has a property (bool IsAlive() is a good example), what is the best way to retrieve an item from a container based on a boolean method that the class contains?

At the moment, a very dull:
container<Agent*>::iterator i=ctr.begin();
while(i!=ctr.end()) {
if(*i->IsAlive()) // do something...
++i;
}

does the trick, but I was hoping that I could do this via the <algorithm> functions like find_if() which (from my own testing with large amounts of loops) perform much better than standard loops.

Globalisation, what think ye?

2010-08-11T05:05:00.001-07:00

Work continues in the background and 'fraid there isn't really much exciting stuff to show at the moment (or for a while as game logic, etc. gets added in).

However, I have a question for those in the know.

Q: How often do you use Global variables?

I noticed recently that every entity in the game has a member GameWorld *m_pGameWorld which is the resource an entity uses to obtain various bits of information about the overall game world.

This seems to be quite a redundant use of identical pointers, so I'm inclined to think that a global "g_pGameWorld" would be more useful, safer (as only one initialisation required) and be more efficient.

I was taught that, for the most part, global variables are to always be avoided as they lead to bad coding practices, badly connected hard-to-understand code, etc. and that objects should only take what they need via arguments and via object-specific methods/members. But it seems silly... really, for something like this.

OT: Got hold of RetroGAMER 47 on eBay. Cool articles on the development of Magic Carpet (was interested to note Glenn Corpes used the 'leave dead entities and re-use later rather than dynamic allocation' method discussed in the Scanners blog entry a few days ago) and also a big section on Elite. I wish I'd subscribed to this mag before many back-issues dissapeared... :[

Retro of the retro remake.

2010-08-02T03:47:00.000-07:00

Thanks to fellow blogger Steve Butterworth for reminding me of Google's (in)famous reputation for data collection and seemingly eternal retention policy. :-P

It appears that the old blog entries still exist on Google Reader, so I plan to add them into this blog (there aren't too many of them) and adjust the dates on them so they fit in order (if Blogger is smart about this and actually moves the entry as apposed to just changing the post date).

So anyone on an RSS feed beware, there'll be some wierdness whilst I put some posts back into the blog. :)

Scanners

2010-07-29T06:52:00.000-07:00

nyyYYYYYAAAAAAAARGH! *head explodes*

I'm beginning to regret the shift to STL vector containers for managing groups of Agents. In fact, I should've just created a static array[MAX_AGENTS] than go down this route.

At the moment, the base class constructor registers an ID with an Entity Manager that is unique to that (often inherited) class. This ID is used for sending and receiving messages.

Today has been a major crash-fest as I see what happens when you try deleting random agents from the game.

1. The MessageDispatcher continues to process messages from IDs that are no longer in existance in the game and attempt to send messages to them.

2. Delete an element from a vector, all the other elements afterwards get shifted along one to close the gap. This means that constructors and copy constructors get called for all those elements. All of them end up with new IDs that are no longer aligned with those waiting in the Message Stack.

3. Regarding 2) Even if I set the copy constructor to re-assign the ID from the (soon to be deleted) Agent, the actual memory location that EntityManager points to is still the old one that is going to be deleted.

Time for (yet another) implementation rethink of the basics.

[UPDATE - these problems are now fixed. :) ]

And now... the Prologue.

2010-07-25T03:39:00.000-07:00

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.

Old ways not always the best

2008-07-01T15:29:00.000-07:00

Powermonger had a novel way of texturing the landscape. It wasn't conventional texture mapping at all. Basically, each triangle was a cut-out of a repeating 2D pattern. Imagine cutting a triangle out of a piece of paper and then putting it on a wallpaper pattern and seeing the pattern come through. This meant that instead of flat shaded polygons, you could actually have something meaningful like grass, beach etc. without having to do the perspective and distortion calculations that are used in conventional 3D texture mapping (and would have been impossible on 16bit hardware, though I have seen a good Wolfenstein Atari ST demo).

Being a nerd when it comes to nostalgia, I implemented a function to draw the map in the old-fashioned way. In a way it's kinda nice because, now that the textures are facing you directly, you don't need mipmaps.

However... it's darn confusing when you rotate the map! The polygons rotate around an origin, but the patterns on the triangles remain static (as in the original Powermonger). You could kinda see this in the original, but because everything was so pixelated (320x200), it didn't really matter much. When you're running this at 4 times the resolution, it looks like a magic-eye picture as you rotate the landscape. :D

Hehe, I'll probably keep it as an *.cfg file option, but it's quite a wierd effect when you see it in action rotating (like a cinefilm projector showing a film on a white rotating teapot).

Here's a small clip from the original:

White Christmas

2008-06-26T15:41:00.000-07:00

One of the fun things about Powermonger was that the weather changed throughout the game. Green grass gave way to autumn ochre and then onto the snowy white of winter.

Seems a simple enough affair of using glTexSubImage() to replace bits of the current terrain texture with pixels from the next season's texture (from our Paris collection...).

Only 2 problems:
1. This has to be done not just for the original texture but also the mipmaps as well.
2. You can see a pattern emerging as the same alterations are used across each tile. I may use a large terrain texture and stretch it across several tiles at a time to solve this.

Anyway, even with a couple of minutes coding, I'm getting rather nostalgic about it. :d

2008-06-24T21:45:00.000-07:00

Sprites are now aligned correctly depending on their direction and the rotation of the 3D map... which is nice. You can currently send the captain around on the map and the soldiers will follow him and try to stay in formation. There's no ocean detection yet, so they walk straight over it. :) That'll require a little more thought as they need path-finding algorithms. In powermonger, if they couldn't get to their destination, they seemed to pick another destination near them and then try again.

You know, the more I work on this game, the more admiration I have, not just for the original programmers, but all the early programmers who had to cram so much information into what was back then quite a restricted runtime environment. I dread to think what my version would've run like on Atari ST... =P

Interface

2008-06-16T14:40:00.000-07:00

I've recently discovered that there were several Console versions of Powermonger which did away with the table buttons completely.

I'm wanting to keep the game as close to the ST/Amiga/DOS version as possible, but there's a lot to be said for a more intuitive interface. I think having the buttons along the bottom works quite well. I'll leave it for now, but I'll probably add the option of having buttons along the bottom at some point as I think it's a good idea, if a little abstracted from the interface.

( both screenshots from the Powermonger screenshots page @ MobyGames - www.mobygames.com )

Updated graphics

2008-06-12T13:08:00.000-07:00

Click image for a larger version.
(compass, scale etc. implemented as 3D in-game)

(any ideas what the symbol on the left shield was supposed to be?)

Test cases for test cases...

2008-06-10T23:46:00.000-07:00

One of the frustrating things about tile-based games is working out which tiles should have which texture depending on which properties certain map points have. There are 2 textures per tile in Powermonger and 2 possible ways the triangles can be drawn for each quad. What you end up with is a horrendous if(h1==BLAH && h2==BLAH && h3==BLAH...), etc. etc. affair which means at some point you'll probably find yourself looking at a wrongly matched tile somewhere down the line. Anyway, I've had enough of playing around with map tiles for now.

Annoyingly, Powermonger used a 320x200 screen resolution on PC, Amiga & ST. The observant among you will recognise this as 1.6 aspect ratio as apposed to 1.3 which is what most modern resolutions conform to (e.g., 800x600, 1024x768, 1600x1200). When you try and scale 320x200 to, say, 800x600, you get a noticeable vertical stretching. So basically fixing that means that there's a big black gap between the map and the navigation controls (which work now). Maybe I'll design a new graphic that fits the space.

Neat little trick for rendering a scene on top of another scene:-

Because the 3D perspective map and the table were both 3D, I was getting z-buffer clipping when the map was rotated (i.e., the ocean tiles would go through the buttons which were higher than 0 on the Y axis).

Rather than do 2 different rendering passes (draw the table in one pass, render, then the perspective map, render, etc.) you can do this:-

glDepthRange (0.1, 1.0);

... model your background scene here ...

glDepthRange (0.0, 0.9); // Bring the depth buffer range forward a bit.

... model your foreground scene here ...

This way, you can draw one scene on top of another but keep depth testing working for both scenes individually. Nice.

Powermonger terrain algorithm

2008-06-05T18:19:00.000-07:00

Having looked into the MAPDATA.DAT I'm pleased to find that Powermonger is definately using the same Fractal Brownian Motion algorithm that I've already implemented in the remake.

Here's the algorithm. Some notes first:
* IX(a, b) is a cheap pre-processor #define that takes 2 values (coordinates) and turns them into a single value used for indexing a 1D array. It also does some power-of-two checking to make sure that you don't get an index outside the range of the array.
* IX2(a) is similar, though it only makes sure that 'a' is kept within the range of the array.

Click here to open the algorithm in a new window. (sorry, the blog page isn't large enough to embed it here on it's own.)

Viridian Games

2008-06-05T11:37:00.000-07:00

A big thankyou to Anthony @ Viridian Games for posting an article on Powermonger's original map data format. This has saved me a lot of time with a hex editor changing values to see what changes in the maps when Powermonger is loaded.

Anthony has been working on similar Bullfrog-esque games and is currently at work on his own game "Planitia" coded in Direct3D. It borrows many of the best things about Populous and Powermonger. His blog is also very extensive covering topics on programming to all sort of things, well worth adding to your reading list. ( http://www.viridiangames.com/blog/ )

Object import added

2008-06-02T04:38:00.000-07:00

One of the things I love about programming is those moments where you find something isn't working and you do every possible thing imaginable (outputting entire data arrays to logfiles, etc.) only to find you'd been thinking about things in the wrong way to begin with. I'd been importing objects with texture mapping and wondering why the texture UV mapping was screwy on some faces, but perfectly fine on other ones. Turns out I'd forgotten that every texture coordinate on a face is unique and not always shared by adjacent faces as you would find with vertices which always have the same x/y/z values regardless of which face is referring to them. DURRRRRrrrr. Anyway, now that it's fixed I can populate the world with villages, etc.

Tiling code

2008-05-26T18:37:00.000-07:00

I'm wanting to keep this remake as close graphically as possible, whilst still enjoying the little tweaks that modern 3D APIs give you. So I've analysed the tiling in the original Powermonger and tried to copy or emulate that. Each tile on the landscape is either TRBL or TLBR ("Top Right Bottom Left" and "Top Left Bottom Right" respectively). This controls which way the 2 triangles that make up a quad are drawn. Each triangle has it's own texture. Basic method is to look at the 4 heightfield points that make up a tile. If all 4 of them are zero, then it's an ocean tile. If 3 of them are zero, then one triangle is ocean, the other beach. If 2 of them are zero, then the tile is all beach. If only 1 of them is zero, then one triangle is beach, the other grass. In each instance you work out which corner is unique and then assign the tile TRBL or TLBR status. For some tiles (i.e., all ocean, all beach etc.) it doesn't really matter if it is TRBL or TLBR as both triangles will have the same texture. There are some special cases for the land tiles though, as the hills seem to be prettier if you get the right alignment, so you can check the heights again and select some criterea from that.

Now, I fancy sticking some houses, trees, roads in... etc.

Book List + Development Tools

2008-05-19T06:02:00.001-07:00

Well, let's have a look at the book list that I'll be browsing over:

[EDIT - I've added some books since this original post in 2008]

"Programming Game AI by Example"
Mat Buckland, ISBN-10: 1-55622-078-2
"Visual C++ 2008"
Ivor Horton, ISBN-13: 978-0-470-22590-5
"Game Coding complete"
Mike McShaffry, ISBN-13: 978-1932111910
"Practical C++ Programming"
Steve Oualline, ISBN-13: 978-0596004194
"Mathematics for 3D Game Programming and Computer Graphics"
Eric Lengyel, ISBN-13: 978-1584502777
"3D Math Primer for Graphics and Game Development"
Fletcher Dunn and Ian Parberry, ISBN-13: 978-1556229114

Also the OpenGL "Red Book" and "Blue Book" which are available online at www.opengl.org

I tend to write lots of little programs that test out different ideas so I'll try and post these from time to time.

Here's what I'll be using:-

Compiler: Mingw32 (GNU C++) *
IDE: CodeBlocks (I prefer it to Bloodshed Dev-C++)**
Adobe Photoshop CS1
Cakewalk Sonar 7
Blender3D***

* I'd use Visual C++ Express 2008, but it has an annoying problem with MSVCP90D.DLL not being found and this can happen randomly due to corruption of project files and I don't have time to mess around with that.

** Mostly the implementation of the Project View and Code Completion seems to be a bit more robust.

*** I use Newtek Lightwave3D at work, but I don't have a home licence for it.

Intro

2008-05-19T06:02:00.000-07:00

It's hard to believe that there was a time when games used to be made by perhaps a handful of people. A programmer (or two), someone to do the graphics, someone to do the sound effects, someone to do music, someone to do the intro and finally someone to make the tea and occasionally wheel in a silver tray with a cake selection.

Why am I remaking Powermonger? (photo from MobyGames, contributed by John Scott, scan of original box art by Electronic Arts)

Well, working in Academia, I've become more and more distant from the things I used to (and still do!) love. Namely ART, MUSIC and CODING (i.e., excercising the grey cells). If you don't use it... you lose it. Writing this game seems to be a way of accomplishing these things without feeling that it has to become a day job, doing these things for money or under direction.

Also, I just loved the game. It was a simple little game of conquest with a nice 3D world, little people that go about their business (farming, shepherding, soldiering, fishing etc.), and most importantly that quirky Brit humour that summed up lots of those early games.

What's the plan?

I'm planning to create a remake that is portable (Win32/OSX/Linux, OpenGL, OpenAL - maybe Fmod) and free for anyone to download and play. I'd like to make the source code available as well, but I've been burned in the past (i.e., saw my own stuff appear on FlipCode with another name, slight graphics change and no credit whatsoever). However, I'm a nice chap and will probably drop the source at some point.

And after that?

Using the basic engine, AI, etc., I'd like to implement the game ideas into a nice big expansive 3D engine, pretty much Powermonger in a "Black and White 2" flavour, just without all the tedious micro-management that annoyed me about B&W2.

Many of us have become addicts to other development blogs. I myself can't help looking at Martin Bell's "Carrier Command" remake, but likewise, please understand that these things take a lot of time. A LOT of time, full of mistakes, wrong code, frustrating bugs, outside life (yes, I have one thankyou... ;-P ) etc., so be prepared for those long periods with no updates that are so common to the basement game dev scene.