Project Management Solution

This is my new Project Management Strategy:

1. Stop using the Feature Tracker on Sourceforge
2. Reduce Soureforge release upload frequency (~monthly)
3. Set Up a Subversion server on my desktop machine
4. Do periodic Subversion uploads to Sourceforge (once-weekly)
5. Use FreeMind software for project management
6. Export FreeMind HTML as a TODO list

Advantages:

• Total cost = nothing.
• Reliance on slow Internet = hugely reduced.
• Source code backup = much more efficient.
• Nice mind mapping tool - very dynamic (more suitable than Gantt charts)
• More informative TODO list
  

Disadvantages:

• Source backup slightly less reliable.
• Sourceforge 'activity' rating will drop, which will impact publicity

To supplement this, I might also look for some extra server space for hosting the 'data' (content) components of the engine, including user-contributed content and closed-source plug-ins. This might have a small cost. I could also use this for other projects, and hosting a proper wiki for this project.

Project Management Problems

I spend roughly 1/2 to 2/3 of my time on this project on administrative tasks. This is totally inefficient, as I am also the sole programmer.

This is a problem entirely due to the third-world Internet service provided in New Zealand, and the fact that the Sourceforge server, which has a great suite of tools, unfortunately lies on the other end of a very slow pipe (thank you monopolistic capitalists, and a feeble-minded government for not releasing the rest of it to the public) across the Tasman Sea. If I can not improve on this rate, then unfortunately Project Management is devouring far more time than it saves and I have to give it up, as I only have 4-5 hours per week for this project.

This is an interesting issue I think - especially that I have got to this point where Project Management fails due to poor technology provision. Unfortunately I'm trying to do the poor-man's mega-project. What I really need is to rent/buy/swindle my own local server space.

Another problem is that the project's complexity is ballooning - I need proper Project Management tools (i.e. dynamic, staggered Gantt charts). I can't do that with Sourceforge.

My options are:

1. Continue status quo
   
2. Abandon all digital project management and revert to paper
3. Rent US server space + domain
4. Rent NZ server space + domain
5. Try and get free local hosting
   

I could revert to paper - which would be much more time-efficient, but then I lose the ability to store and publish project info online easily. I would still have to put up with slow file release uploads, and wait until a free wiki service is available. Cost = nothing.

US server space is 40 times more cost-effective than NZ server space. I don't know how NZ servers can justify their exorbitant fees for 40MB of space and a sub-domain - net worth approximately nothing. What a joke. I think US server space would still have the slow-connection problem (may even be worse). Cost = small, with either marginal space or slow connection.

Another option is to set up my own server (expensive but ideal), perhaps using an old computer that somebody doesn't want and just buy a domain name. I would have to switch to a proper Internet connection and get a phone line, which would be a pain, but may be inevitable. Cost = expensive. The big advantage here is that I have total control over releases/source code availability/content and don't have to answer to anyone.

Another (perhaps best) option is to set up the project as an academic endevour, and use super-fast, free, university hosting. Cost = none, but project may have to change scope.

Unfortunately I don't have the budget to justify setting up my own server yet, so might revert to paper and off-line tools until then.

It might be more effective to do an off-line Gantt chart that I can publish on-line at intervals. I'll try that for now.

3D Audio Now Working

We have sound effects!

I have got a prototype 3D audio system working.
I would include a screenshot, but I don't think it would add anything.

Now it just needs a tidy-up with a revised structure, better camera 'listener' behaviour (for proper '3D' audio experience), and facilities for specifying which sounds to use in a tank's DEF File.

Fmod

Fmod seems to work right off the bat, however it is plagued by those annoying artsd problems - no properly closing the daemon, and refusing to open more than one daemon. This presents a real pain in the neck for testing. Although it would be OK for a final package, it is so much of a pain for testing that I'm going to look at OpenAl, and see if it has the same problem.

Wiki

I started a wiki on the Sourceforge page, but the connection is just far too slow - it's extremely painful just logging in. So I'm going to abandon that and look for something better. I really need to start documenting the details of this project before I forget how things work!

Some of the complex features happen very quickly and will be hard to convey to users in real time (armour penetration models for example), so it would be nice to document these. It would also be nice to explain how various model-loading features work (DEF files etc.) for modelers' reference.

Animated Vehicles now supported

I have upgraded the engine to support a variety of different types of animation. These will be included in the next release (0.51 "Vi").

You can now specify in a vehicle's DEF file (the text files stored in data/vehicledefs/) if it has an animation for:

• IDLE
• MOVE
• FIRE

You can also provide a custom name for an animation. So, if you already have a model you don't have to go back and change all the animation names to suite the engine standard.

You don't need to have all the animations either. You may want to skip having an idling animation, and just have a firing animation. No problems there.

The engine will also intuitively figure out if the firing animation should be played on an attached turret, and that the moving animation should be played only on a hull etc. etc.

A sample definition file (DEF File) segment looks like this:

SET_IDLE_ANIMATION Idle
SET_MOVE_ANIMATION Driving
SET_FIRE_ANIMATION BigGunFiring2

So far the moving/driving and idle animations are always set to 'looping' and the firing is set to 'not looping'.

I don't have any blending of animations yet, but I haven't incorporated the intelligent driving system yet so there's not much point interpolating left and right track speeds based on relative steering angle. It will happen later on in the picture.

No Comment Required

Sound Libraries

I'm looking at 3D audio libraries. There are several major free library options:

• irrKlang Linux, Win32, some Mac support. Closed source.
• OpenAl Linux, Win32, Mac OS X. Open source.
• Fmod Almost all O/S. Closed.

I have used OpenAl with Evo3. It worked - which is a good start. It is supposed to be designed after the OpenGl format, which means it's C (not C++). It uses some very odd vectors (they have normals) which is a big pain, because my 3D co-ords don't work like that, and it needs careful conversion. It also has some bugs, pieces that don't work properly, fiddly bits, and the newest version doesn't work properly. For some reason it needs to be 'installed' in Windows, which is a bit weird. It has been used by many of the most popular games however.

Fmod looks like it might be the latest and greatest, but it's closed source which is disappointing. This may also mean that it's easier to use, however.

Not sure about irrKlang.

What I might do is try out Fmod with a very abstract interface (as I've done with all my other handler classes), so I can replace it with something else if preferred. It looks like Fmod will be quite easy to use.

Working with complex models

I just had a revelation regarding how to deal with complex models.

When working on large models it can be easier to build/work on different components separately, including doing the animations separately. A problem arises when you want to merge them all back together as a finished product; animations can get mangled and the 3d editor can slow down as it has to deal with lots of vertices. You need to merge them because a MarkIV mesh can only hold one 'object'.

The revelation: there is no reason why you can't just leave the parts as separate meshes in the same way as separating the turret from the hull. I can just extend this code, so that you can do things like:

HAS_SEPARATE_TRACK_MESH 2

Which would mean it needs to load 2 separate meshes (one for each track).

TRACK_MESH left_meshfile (-2,0,0)
TRACK_MESH right_meshfile (2,0,0)

Which would load each track and adjust it's offset to the left and right of the tank by 2 meters, respectively.

You should also be able to make just one track object (containing both tracks):

HAS_SEPARATE_TRACK_MESH 1

Without too much problem.

You would also need to add the name of the track animation:

ANIMATION_DRIVE move.anim

The engine should be able to work out which object or objects to run the animation on. The engine should also be able to scale the animations depending on the current speed, and if there are two tracks and the tank is turning - the engine can then interpolate the speed of each track appropriately.

Other benefits of this approach - when checking to see where a tank has been hit (by a shell), it is a very simple matter to determine if it has hit a track, the turret, or the hull. This would have to be estimated if they were all one object.

Separate components may result in it being easier to paint/texture, which would be great.

I could even extend this idea further (if requested) to support any number of different components (not just tracks), so that fiddly little components like hatch cupolas can be worked on separately too.

Pros:

• Modelers have a lot of freedom, and a lot of options.
• Easy to work out where a shell has hit a vehicle
• Animation easier for modelers
• Modular approach easy for modeling
• Can have different track speeds for left and right tracks
• Big complex models don't slow down modeler
• Can reuse same approach as with separate turret
• Should be easier to paint
  

Cons:

• Lots of different approaches may be confusing
• Lots of different DEF file formats to support (not a big issue)
• Vehicle models may not be consistent in simulation
• Might be tricky for modeler to align different parts in 3D space (and scale)
  

Modelers do not have a single approach, which may result in confusion or a variety of different types of model (which may disrupt the consistency of the simulation).

The King of the Tigers

David's revised King Tiger model. These will be the most realistic and detailed vehicles in any game or simulation ever produced.

Turrets Now Track Targets

I've just finished version 0-5-0 (Thror). Here's the improvements:

* Target aquisition working over network in real time
* Vehicle Turret Rotate to target and tracks moving targets
* Unit Controller converts target to coords (at moments assumes can be seen) & Cancel Unit's Waypoints.
* Fix: so blank chat doesn't print anything
* User Interaction: able to order tank to target enemy tanks
* Selected Vehicle details panel
* Networking: block clients from connecting mid-game

The tanks' turrets will now actually rotate to track moving targets. They rotate at the authentic turret traversal speeds too.

I haven't uploaded a Windows-compiled version for a while because it's so time consuming. I might do that on the weekend.

The turret is only lining up based on 2D trigonometry so it doesn't quite get it right when the tanks are sitting on a slope. I'll need to some some 3D trig adjustments to fix that up.

I'm going to move towards more combat next. I've already built the infrastructure (while I was doing the turret thing). Here's what I'm going to build next:

* Improve Turret Rotation by adding 3D (pitch/roll calculations into theta)
* Leading shots - incorporate estimated vehicle relative speed and time to target
* Check if target in range
* Unit Controls: Enable engagment/combat model
* Design: ballistics model design
* System: Basic projectile class
* Angle of gun adjusting for range and height
* If not in range move towards target

In other news: The tanks and terrain you see in most of my screenshots are actually my scrappy quickie-jobs that I have roughed up for testing (with terrible borrowed or worse self-drawn textures). These are only temporary stand-ins for testing purposes.

David who is building (so far pretty much single-handedly) the WW2 Simulation that will use the engine) has been working on some ultra-high-detailed realistic scale models, and new texturing techniques that look like our little hobby project is going to blow the pants clean off even the best commercial products in this category. I'll have to do some extra work to make sure the engine can accommodate the new models properly!

Features that we'll build-in are:

• Improved Level-of-Detail support for super-high-detailed models.
• A really unique (and fantastic ) wheel animation and suspension scheme that we've come up with
• Animated tracks
• Proper hill-climbing, fording and other simulated physics
  

Latest Improvements: Nearly Ready for Combat

I've improved the networking system; now all the messages are totally synchronous. It should be very stable. Some improvements can still be made to smooth out jittering effects on clients, which are sometimes noticeable when the updates occur.

I've also finished the lobby. You can now choose a force by clicking on a shield and your name moves over to the correct force. It's all integrated properly with the server, and works on solo games too.

When you start the simulation, you can now only control those vehicles that are part of your force (none if you are on the Spectator force).

Furthermore; I have built a little (translucent) panel that displays details about the selected vehicle. These are colour-coded and customised to reflect which team the vehicle belongs to.

It's starting to look pretty good. I needed the force-separation and the panel to prepare for the combat model, which is the next thing to build.

My plan at the moment is to do a prototype of the combat model with only 1 new order: attack! When you have a vehicle selected and right click on another vehicle the engine will determine if it is an enemy (different force) and if so attack it.

Attacking is just going to consist of fire and reload phases at the moment, and then become more gradually complex. With the basic phases working (we should be able to monitor that from the new panels) I can then build some projectiles and see if we can build up our physics model.

Ballistics and Projectiles

OK - after I clean up the networking I'm going to start work on the number 1 request:

Ballistics and projectiles

And get some action happening! I'm going to attempt a completely new approach, which should be more realistic but introduces many more complexities.

Firing high-speed projectiles in 3D space means physics simulation, which can be reasonably CPU-consuming, and collision detection, which can extremely CPU-hungry. Physics simulation follows one of three approaches:

1. Pre-calculation of projectile paths
2. Real-time projectile motion
3. Simplified statistical simulation

Pre-calculation means computing the end points and some intermediate points of a dented parabola in 3D space (dented to adjust for air resistance). You can then even determine the amount of time it takes to reach the destination, and wait until this time passes before calculating anything else. This approach means only one calculation per projectile; a small one-off CPU spike. Real-world information such as actual maximum range can be incorporated to reduce the complexity of the calculation.

Real-time projectile motion means generation of actual projectile objects which have a velocity vector (with horizontal and vertical components), air resistance factor, current angle of orientation vector, and other details, which means it can be moved accurately in real time. This approach means that there is no need to compute the whole path beforehand, but continual, small motion calculations throughout its lifetime. The CPU-load is similar to having another moving vehicle in the simulation for every projectile. We will reduce the complexity by assuming that the movement in-between iterations is a straight path.

I used a statistical approach to where projectiles would land in my previous engine (Evo3). This meant that hardly any calculation was required, but nothing was really simulated accurately either. This approach is used by most computer games, and suited a very large number of vehicles firing projectiles, but I think we have enough CPU resources in modern machines to improve on this model for the Mk IV engine.

I'm going to try method 2; real-time motion of projectiles. Essentially this reduces the number of vehicles we can field at one time, but I think it would make for a more interesting simulation. This also means that if a vehicle moves in the path of motion of the projectile after it is launched that we know if we will hit it, which might sound unlikely, but in close-range heated engagement this would produce much more engaging simulation. We can also do some interesting things like adjust for wind change whilst the projectile is moving.

One of the main problems with the real-time motion is that we have to check if we hit something every time we update the movement of the projectile. Checking if we have hit something means drawing a line in 3D space between the new position and the old position of the projectile (Raytracing), and checking against every object in the scene to see if it was in the middle. The actual ray-trace can be a very costly procedure, and if we are checking against all 1000 objects in the scene, every 50th of a second, that is 50,000 raytraces per second, per projectile in motion. It gets worse, as every object is typically made up of 10,000 triangles, and each one is checked - so we are really doing about 500 million raytraces per second per projectile. This is a problem that clearly needs some optimisations.

I was at a conference all last week and I picked up a good idea from some researchers working on raytracing optimisation for graphics rendering. Whilst they were using raytracing to cast shadows on rendered objects, the idea is the same. They managed to massively reduce the amount of calculation required by only checking the bounding box of objects with each ray, and then only if that was a hit, checking the triangles of that object. This means that we would be doing only 60,000 raytraces per second per projectile, which is much better than 5 million.

I also need to check if the projectile has hit the terrain, but the optimised method isn't really going to work for that, because the terrain is massive and varied. In this case I might just use my height-above-terrain method, which means adding in only 100-1000 or so additional raytraces per projectile per second.

I could also divide the objects into 'zones', and only check against those objects that are in the same or neighboring zones to the projectile. This means a lot of irritating program structure design, but would reduce the raytracing to about 1/3. Not as much difference as the bounding-box check optimisation and a lot of work.

Thankfully projectiles will move quite quickly, so only need to be checked 3 or 4 times each. This means that there may only be 5 or 6 projectiles of this type in motion at any one time, so we are really only looking at an additional 120,000 additional raytraces per second. We could again reduce this by halving the number of iterations (meaning a less smooth path of motion) calculated if need be.

1 Raytrace is approximately 30 operations, meaning 30Hz of clock time. Worst case scenario, we are calculating 20 projectiles in motion at one time, which requires about 48MHz of CPU ticks. Modern CPUs have at least 2.8GHz to go around, so we are looking at using 2% of a modern desktop's CPU for this part of the simulation or up to 4% of a really slow one.

I think this approach is really only going to apply to direct-fire shells. Small arms ballistics and indirect fire can use different (less CPU intensive) models.

The other problem with the real-time approach is telling the vehicle what angle to fire the projectile on to hit a particular target. This means that we probably have to pre-calculate the path beforehand anyway (something an artilleryman would have to do in the real world by hand). We can introduce some error into this calculation to account for real-world sources of error, and possibly scale this according to the experience of the personnel. Even a very accurate calculation will not account for wind variation during projectile motion, so there could be some quite interesting stray shots.

This all sounds like a costly CPU calculation, but if we look at the Quake computer game from many years ago (when we didn't have a lot of CPU to use at all) the ogre characters must do something similar with the grenade firing, and there were often many of them in one scene with potentially tens of moving, bouncing projectiles, that probably needed even more calculation and ray tracing. So I don't want to write-off this approach just yet.

Lobby

This is what the lobby prototype looks like.

It has all the main components in place; forces (with badges), buttons, scenario details, start/ready functionality and chat.

At the moment the idea is that all players join and become members of the 'observers' force (i.e. not actively participating). They can then choose another force. I want to allow multiple players to command the same force as I think this could be an interesting engine feature, at least as an experiment in early versions.

The idea behind the lobby is to provide a 'waiting room' where players can wait for everyone to connect before starting the simulation (rather than having people connect half way through and all hell breaks loose with network synchronisation).

It needs a tidy-up, but I don't think I'll bother with that ahead of building other features (like improving the networking synchronisation model and getting some animations going on the vehicles).

I still haven't built the functionality to let the user choose a force (by forces I mean 'red' and 'blue' teams or particular divisional/brigade elements that are being simulated) by clicking on it (because there isn't any force infrastructure in the engine yet to support it). I may not even worry about this just yet, and will come back to it once the vehicles are actually identified as being on different forces.

The other major feature missing is the scenario chooser. This is for two reasons:

1. I haven't built any scenarios, and have nothing to put it them other than lists of vehicles.
2. I don't have any menu functionality or directory listing functionality in my GUI/loader.

Again, I might come back to this once I has some scenarios to work with (around the same time as I build the long-planned 3D scenario editor). I'm still refining exactly what the scenarios will contain, as I have almost completely changed the design since the original Evo3 scenario model.

The lobby is supposed to feed into a 'deployment mode'; which is really a 3D version of a lobby, where players can position their troops/vehicles prior to the engagement part of the simulation.

I want to have hooks in all these pre-simulation phases that allow them to be automated by the server with time limits, pre-loaded lists of scenarios, other conditions etc.

The other thing I have to do to the lobby is remove those buttons and features that are not needed by a particular mode. i.e. remove the 'ready' button from solo mode, and remove the choose scenario button from client mode etc.

Version 0-4-7 (Thrain) Released

See the downloads page. I have uploaded a Windows version + source and data for the latest version of the engine.

New Features Include:

server updates clients with total ready status
ready/notready text in lobby
button clicking on 'ready' and 'start' in lobby
server adds self to ready status
Added short sleeps into some engine loops to massively reduce CPU load
'Ready/notReady' count of players updated in GUIs
Force 'shields' loaded into GUI
New 'lobby' area GUI

Bits that have been left out include:

* Lobby GUI not cleaned up on lobby restart
* still can not select a scenario
* lobby GUI still not customised to solo/server/client
* can not yet select a force from lobby menu

The next major version will focus on an improved networking system, and probably some animations support for vehicles, and a 'deployment mode' + lots of little fixups.

I'm only making win32 releases of major releases because it's so time consuming. My Internet connection is still too slow to do regular updates, and too painful to do subversion, so I am just doing fortnightly-monthly releases.