[Warhammer Dark Omen Forum]

Warhammer Dark Omen Forum

I just wanted to post to state that I am still alive and that the project is not forgotten or anything.  Having both a day job and 2 of my own businesses does sometimes take up a lot of my time and so I've not been able to get close to this in a month - but I will be back at it in a couple of weeks.

I've had the art for two new mesh units.

[attachment=1]
Canon

[attachment=2]
Mortar

I've been doing a lot of reading up on networking today, and note with some interest that in some countries UDP traffic is routinely blocked.  It sounds strange to me, but I guess the idea is to limit the web to just web pages and email.  Because of this I shall have a go at abstracting my network layer from the socket used - and provide the functionality to send gameplay data over either UDP or TCP.  UDP will be faster, but I would like not to exclude people in far off places like the United Arab Emirates and such from playing the game so if I can I will include a TCP option.

I did start listening to a 2 hour seminar by the lead network programmer on Halo 3 too, but after 40 minutes I was having to physically stop myself from emailing him optimisations to his own techniques.  So I have high hopes of the networking side of the game.

If only I was as good graphically !

He's made a start already.  Here is the canon before any textures have been applied.

[attachment=1]

I've jut commissioned some artillery pieces to be made especially for the project.  I'm making use of the superb skills of Nick Igoe who is extremely talented, and he's cut me a good deal because I did not ask for exclusivity so he can sell the assets on to other games programmers.

Here is one he already had made, a trebuchet.  It's rigged for animation but I need to sort out the sprung rope so that it animates and flexes properly, as he had never made animation for the model.  He's making me 3 new pieces, a canon, a mortar, and a catapult.  So we'll be well stocked for artillery pieces!

[attachment=1]

Currently there is no flanking bonus because skirmishing doesn't really warrant it, but it is something I'm astutely aware of and will do if I can get the solid formations in.

Thanks for the control summary, what I've got at the moment isn't the same but it feels okay. We'll see if it stands up to play testing when we get that far .

I've got half a mind to make the server a separate non-graphical app, if it isn't too much refactoring, as this approach will allow me to compile the server app under Linux which means it could be run on a web server - which would be awesome for campaigns online - it could effectively result in an inbuilt ladder or mini campaigns with persistent campaign maps or something like that, with direct output to an SQL database for integration into websites.

No promises on that though, we shall have to see if I can decouple the graphics easily enough.

I started work on the multiplayer tonight.

Firstly, when I compile a copy is automatically sent from my laptop (which I prefer to code on at the moment) to my desktop, if the application is running on the desktop then it detects the update, closes and relaunches itself - that's kinda neat and makes developing much easier It means I can code in the comfort of my games room, whilst the desktop is in the lounge - and I know it hasnt crashed because I see the network connection hitting

I've got a TCP connection established between the server and the client and that all works fine. I auto-detect which computer is the server or client at the moment because that makes dev easier, simply by looking for a file that is only on the desktop - but at some point there will need to be a lobby)

The next step is to get a UDP connection established too.  The reason there are two distinct network protocols (TCP and UDP) and that i'm using them both is because whilst TCP is very reliable - packets always arrive in order and any missing packets are resent, it's very robust and stable - The disadvantage is that the packets are larger by somewhere around 30 odd bytes each.  So game state changes will be sent over TCP, and non-critical realtime packets will be sent over UDP.

For some reason I am struggling to get the UDP connection to establish a link tonight, but I am sure some time away from the keyboard will fix it - so Big Bang Theory and a cup of coffee is on the menu for the rest of the night

I'd love to see an interface identical to Dark Omen's in terms of Map/Camera/Troop navigation

I don't really recall the specifics of Dark Omens controls, but I do intend to include rotation as a command that can be issued as that annoyed the hell out of me in Rome Total War, it just didn't work as nicely as DO.  The changes I made today are quite nice to work with.

Select a unit with the left mouse button, if a unit is selected you give it move orders with the right.  Shift to issue a chain of orders.  If no unit is selected the the right mouse button allows you to rotate the camera.  Arrow keys allow you to move the camera, and + and - allow you to change the number of ranks in a unit.

and instead of 3D animating the portraits perhaps you could make them 2d animated like in Shadow of the Horned Rat, where just the eyes and mouths move.

For me this just isn't a major part of the game.  DO was telling a story so having an animated leader in a game where units all had their own storyline was part of that, but that isn't the case for my game - it's very definitely multiplayer, so I don't see it as necessary - and it is an aweful lot of work just to create stills for all the units let alone animated in 2D or 3D (in point of fact, I typically generate 2D graphics from a 3D source, and have done for years).

Glad to hear Archers will be able to target fixed points, like Dark Omen for those critical intercept shots and unlike Rome Total War series where they can only target the enemy in their current position and generally miss.

It's one of those DO inspired gameplay features I would consider to be essential.  It's not currently in the game, but it will be.

Does Dark Omen work out the arrow hit calculation when it hits the ground or like most games that the arrows get calculated if a hit or miss as they fire and before they actually hit, which is bad.

I don't know how DO does it, but I do it by calculating where the shot will land and then firing the arrow down that path.  It would be much faster to check for collissions just once before the shot is fired - which when dealing with large numbers of troops will save a lot of calculations - but I havn't done that.  I check for collisions on each arrow on each move.  I think I still have work to do here which I will sort out when I do the targeting of an area.

I really like the idea of the first two ranks of archers moving to the back etc..

Yeah I think it would look good, but I still have to work out whether the second rank should move forward, otherwise the unit will move backwards on the battlefield as it fires - but if the second rank moves forwards then it precludes the point of the maneuver.
 

and would much prefer solid formations like Dark Omen, rather than the current kind of skirmish melee (sorry for my obvious bias and can wait for the future mod, hehe)

Solid formations are very warhammery, the skirmish battle are much more cinematic in style.  Ideally I would like a mix, and it will be interesting to see what effect that has on the combat.  Anything which can add a tactical element to the game is welcome - as I want to avoid it being a zerg rush.

Excited over the forthcoming Mulitplayer developments, is it more than 2 player? Would be cool even if it meant smaller amounts of troops each etc.

I plan to support lots of players.

The intended music sounds great and will look forward to hearing more and perfect that you know re-enactors for battle sounds.

I just hope they say yes!

Please let me know if we can help with anything, especially designing new maps!

Well if you fancy designing the campaign map we could talk about that.  I was thinking something parchmenty, and stylised.  Would this fall into your skill set?

Loving the latest screen shot and seeing them fighting in between the buildings. I will dream of playing.

If only it was actually playable with that many soldiers!

I thought you might enjoy this, although unplayable due to a woeful fps of 3 - it served the purpose of testing to make sure there are no crashes and the memory management is all under control.

Here, a maximum graphics settings battle of well over 10000 men, somewhere around 12000-14000.

[attachment=1]

So looking at the stuff coming up, I've got some interface work to do which I really am not looking forward to!  At the moment the controls are kinda horrible, sorting that wont be so bad but part of the interface overhaul will be portraits for the units.  I'm not going to animate them like in DO - but doing all the art is a task and a half!

Some units will need control icons, like archers.  Currently they only fight in skirmish mode so they'll need some controls for shooting at fixed points, and I was thinking of a more ordered attack mode where the front rank fires and then moves to the back so that the next rank can fire, and so on.

The same could also be done for melee units, the way they fight at the moment is a kind of skirmish, but they could have an option for solid formations too, although it's a bit of work to code that the results could be worth it.

Then there is the multiplayer code, I think it makes sense to code this before any new unit AI is written because I may have to jiggle things around a bit in the unit control logic to get the multiplayer in, so I may as well do that first.

Also there is the problem of sound effects.  Music is covered, I don't know if I mentioned this before but I have gotten hold of some music from hollywood film score artists and it's absolutely bleeding epic, featuring full orchestras with french horns - the works, but I need to hook up with some re-enactors to get the battle sounds recorded.

I was thinking earlier "Hey, i'm on the home stretch" - but then I stopped and realised how much there is to do still! Because after all this is done I need to work on the campaign side of the game and make about 100 or so maps!

That's actually a really cool idea.

It does pose some quite probematical technical challenges though.

Firstly, flying creatures can clear buildings already (although I have it disabled because it makes the game take longer to setup until I put in saving/loading of the level instead of regenerating the needed height data each time I run it - but it will be making a come back).

Climbing would be technically very difficult because I would need to do not just animations for it, and extra logic, but more importantly it would require detection of wall edges which currently is not very precise.  I am using very fast "vague" maths in a lot of places to speed things up in order to have as many units as possible, so the precision for the wall edges is not very accurate because it doesnt need to be - unless I were to include wall climbing in which case it'd have to be very precise indeed!

Actually, it would necessitate reading off the 3D geometry data, or a lo-resolution version of it.  Rather than just looking up an indexed memory bank of 1's and 0's that states whether an area is enterable on the ground.  The maths for that just isn't fast enough at all for this game, sadly.

Pathing done

Now, sleep.

This is stage 1 of getting the units pathing around buildings and other mesh-based terrain obstructions.  I have integrated the mesh data into the ground height algorithm, so currently they fight over roof tops!

[attachment=1]

The next step is to integrate the terrain height data as part of the actual movement code and get soldiers to move around the obstructions when they cannot "climb" the area infront of them.

I think my earlier reticence was more the illness talking, I am actually fiddling with the code now for half hour or so before bed - I'm about to attempt to get the soldiers pathing around buildings and other mesh based terrain obstructions.

To my mind the OSRIC is more about flavour than rules, the internals of the system already take a seperate to hit / damage approach - picking stats consistent with OSRIC is no biggy, the internal number base is 120 - which divides neatly into all the dice sizes which is why I chose it.

The fact that OSRIC does not have an official battle rules set is actually an advantage because it gives me some artistic license - although there are some rules by a third party which I may look at.

I had a little tinker in the code, I fixed the archery logic in a couple of minutes but the speed problem is not a thread issue.  What it is is a limitation of the animation system.

Basically the way animation is normally done in 3D is simply a selection of rotations and movements of pivot points and the effected vertices - it isnt much data and so is usually just part of the 3D object.  With sprites, usually you have a sprite sheet and you just view a different window of the sheet.

Because of a side-effect of the sprite shadow system which I got working essentially by hacking, and of packing as much into memory as possible, the way I have done my animations is technically wrong.  I send an entirely new image down the bus every time the animation cell changes - so the limitation on performance is more due to bus speed than anything else. Which is the same on both machines.

In theory the textures should be getting loaded to the video memory on both machines which should speed things up for me but could effect users who dont have as much graphics ram, meaning that performance could be more of an issue for other users than it is for me.  I am wondering if there is a problem with the textures loading in to video ram but I've checked the docs of the 3D engine and everything seems in order.

Basically, performance isnt great - and more specifically, it isnt sufficient.

I cannot help but wonder if I have tackled a few things incorrectly.  The structure isnt quite right for multiplayer (although not far off) and the way the world is built is very inefficient given what the final world has ended up looking like after I had to remove tonnes of stuff.

I think there is some merit to using modeled maps rather than the way I am generating them now and I am still really disappointed about the shaders on the mesh units.

So... I have been thinking about a re-write and I have been thinking about using very low polygon models instead of sprites.

I have also been wondering whether to base the games internal rules logic on OSRIC - I can't get a Warhammer license but for OSRIC I can (A: Because it is an open platform and although some of the licence does not bode well for computer games, however B: I know the author), and this would allow me to essentially make it the AD&D equivalent of Dark Omen.

EDIT: Without shadows the game still runs at 30-40+ fps depending upon the number of units - but shadows are soooo pretty.