[Warhammer Dark Omen Forum]

Warhammer Dark Omen Forum

Beginnings of a UI

[attachment=1]

The Dragon has two special moves, to fly and its breath weapon, these are controlled by a "dragoncharge" indicator, a kind of mana bar if you like that forms part of the portrait.  Of course those buttons don't actually work yet, that's for tomorrow .

Made good progress on the monsters tonight, but I'm taking a break. I feel the need to vegetablise myself infront of the telly for a few hours

Getting there

[attachment=1]
[attachment=2]
[attachment=3]
[attachment=4]

Figuring out the behaviour of flying units, here's the first implementation

Flying Units - Early Implementation	powered by Aeva

Off shopping soon, so will be a slow day.

Well the good news is I managed to get rid of the mutexes on the rendering thread, so the only mutexes now are in relation to mouse clicks and the unit processing logic.

And there's more good news, I am about to begin work on the mesh units and their special attacks   I just have to fix their navigation first as they seem to never march through their list of waypoints, and then it's time to get their special moves in .

Well that's typical, made the changes to my debugger code files, recompiled, then saw the problem and fixed it without needing the debugger.

*rolls eyes*

I think i'm going to go to bed before I find another bug!

Right, seems my problem debugging threads turns out to be a bug in my compiler.  Luckily it's open source and actually compiles itself (which is a brainfuck in itself), and people have posted various solutions so I'm trying them out and seeing what this new level of debug information turns up.

Well the rapid progress has been somewhere hindered by a memory access violation somewhere in the threading system, and seeing as you asked - let me go put the kettle on and I'll impart some weary wisdom from the world of multi-threading - which will probably suggest you spare your sanity and never try it.

Right coffee in hand...  Multi-threading is the devil.

And frustratingly this game needs it, because there's a lot of logic that needs processing to have lots of units.  The biggest issue with doing multi-threading on the Windows platform is that only the main thread can talk to the graphics.  So all the 3D stuff has to be done on the main thread.

This means the other threads are doing game logic, which in this game is the decision making engine that makes the soldiers run around in accordance with their orders.  The heaviest part of that calculation is when the soldier has to be positioned in 3D space, I do this entirely in maths from a memory bank that holds topography data for the map.  Because the topography data only has reference points every n units of space in the 3D world I have to do a calculation that works out the height at a given co-ordinate between the neighbouring reference points, rather than raycasting in 3D which is both slow and can only be done on the main thread.

There's also a lot of range calculations involved in the logic of the decision tree, and that involves some power of and square route maths, as well as some 2D movement over the terrain surface which involves some cosine and sine maths.

Basically, range = sqrt( (destination.x-source.x)^2 + (destination.z=source.z)^2 )
x = x + cos( facing ) * speed
z = z - sin( facing ) * speed

So basically there's a lot of maths to do which aren't direct 3D operations, which is why this game benefits a lot from threads.  I am toying with the idea of pre-caching some of those sums, ie: having a databank of cos results.

The problem with threads is that if one part of the software is writing some data whilst another thread reads it then the software crashes - and because this is parallel processing you have little control over when events happen.

To combat this there are a number of approaches, the first thing I did was create a working copy of the data in use, so that the render just works with a final output of a few key pieces of information, specifically:

A boolean true/false flag for each soldier that gets switched to true when it is time to render.
An x, y and z position
A bearing for the units direction
And the current animation sequence and frame

Basically the threads get all of this information ready and then set the boolean flag to true, the rendering thread then draws it and sets the flag to false.  Once the flag is false the thread processing that unit will then reconsider the logic for that soldier.

In addition - because of the current crashing problem - I do something called mutex locking on the threads which creates a "pause" for processing of a unit whilst that unit is in it's rendering cycle, so that the rendering cycle and the logic cycle for a given unit never occur at the same time.  I dislike mutex locks as they hinder the performance benefits of using threads, and in this case they don't seem to have fixed anything so they might not stay, but they're here for now.

Now somewhere in this flawless logic is a floor, and this is the bug I am trying to stomp right now

The difficult part is that when a crash occurs from within a thread you get absolutely no debug information at all, and when I run the software outside of a thread the crash never occurs.  So debugging is done by a process of trial and error.  Which is bloody painful.

-*-

As for tools, I am using the Xors 3D engine which is a DX9 engine.  I use this because it is very similar to engines with which I was already familiar from "back in the day" but has the addition of shader support and DX9 features, I have a shader which drives the landscape texture which I wrote myself ( technically: A 7 way splat shader that does not use alpha channel thus maintaining shadow support) - and a couple of shaders on the water which was public domain code.

I compile in BlitzMax/GCC which is a superb combination for rapid development, it'll compile multiple platforms and multiple languages but its own language constructs make for easy and rapid development and I use them almost exclusively.  However, because the 3D engine I am using is DirectX this particular game will be Windows only.

Thanks guys.

I'm having a bit of a mare today, I've been integrating multi-core support.  The speed boost is quite large and it was well worth doing but I spent the last 4 hours repeatedly rewriting the way I handle dead soldiers until I got it right!  I think i'm about coded out and am starting to make silly errors, and I had best get some Xmas shopping done so I'm taking a break.

Before I leave though, here is an epic battle of 700 Dwarves fighting 1000 Skeletons.  It does not take full advantage of my laptop because there are only 2 units in this battle, and each unit goes to its own thread with a third being used for graphics, if this was broken up in to units of 100 it would probably have run a lot faster, but it was still adequate given I was on full graphics.

I think in the final game units will be up to about 200 or so - although there may be the occasional exception.  Of course if you mod the game you can specify any size you like as long as your computer can handle it - but units over 200 start to become ungainly to operate in such a fast playing battlefield, especially if you have a low leadership score in your unit.

Epic Battle	powered by Aeva

Night Battle - Dwarves versus Skeletons	powered by Aeva

Well don't go to be yet, i'm uploading a night battle of Dwarves versus Skeletons!

EDIT: But in fairness, that will be 30 minutes uploading apparently...

Melee is done, just starting to work on the monsters.

Test Battle	powered by Aeva

The best hit so far is Tactics of War, although I think tactics is wrong.  I want something that makes it feel truly epic - I was thinking along the lines of "Epic Battles".  But "Epic War" might be better, although I like the sound of the "of War", maybe Epic Battles of War.

Although these are all generic, perhaps we need a story for the campaign that might give it a theme, and the name might derive from that.

EDIT: Legions of War ?

[attachment=1]

Still lots more to do, but the behaviour of the units is about 70% of the way there, for melee anyway.  I havn't started ranged or special attacks yet.

[attachment=1]
[attachment=2]
[attachment=3]
[attachment=4]