Lorem ipsum dolor sit amet

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...

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).

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.

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.

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.

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.

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. :)