Friday 11 June 2010

Engine start-up and event system

David posted up some more CH47 pics around SimHQ and Facebook and possibly elsewhere. Lot of detail work has gone into the engines, rotor head and trying to get the smoothing correct at the rear of the aircraft.

Looking forward to getting those blades turning, the sound thumping and the dust is flying.

I've been doing a lot of logic work in the Apache in the past day or so. Also full of a head cold which tends to make me cranky.

Sat in the cockpit, the APU sounds like a vacuum cleaner in the next room. Adding moving cockpit parts such as power levers, flashing lamp indicators and other one shot elements that require animation in a periodic update function suggests that maybe it would be better to place all of these things in something more general purpose.

Rather than having a spider-web of update calls, updateCockpit, updateUnitWaypoints, updateEventTrigger etc. popping a function onto a stack when it's needed seems like the thing to do.

I'm proposing to add a simple event system that can take an entity and perform a chain of moves, rotations, material or colour changes, and remove from the stack when the sequence is completed or removed. Then augment this to perform function calls for mission events, to be fired as offsets from mission start time or absolute world time.

Initial thoughts suggest something like the following would cover most needed cases:
  • eventID = EntityID,  action, blend, userdata (e.g material, colour, vector) as csv
  • eventSequence = ID, eventID[], deltatime_ms, cycle_ms, repeat_count, start-time_ms (absolute world time or zero for mission start time)
Where a sequence to cycle a material between two states would need two eventID entries, one for each material and the entity to apply this to. And the eventSequence would contain the reference to both eventIDs. It's then up to the eventProcessor to handle the action. Which could also be SetKey() or SendMessage() but it should be generic enough to handle a lot of common situations.

Event is performed [repeat_count] times, a value of zero implies loop. [cycle_ms]  is time between each repeat cycle in milliseconds.

Some checks may be required before injecting an even into the eventSequence. To prevent duplication, for example, hitting reload to trigger a reload animation repeatedly would have the effect of triggering the animation to play before the previous playback has ended. Therefore a parameter to test the uniqueness of the eventSequenceID before pushing it onto the stack should suffice.

**edit: some of this doesn't make sense, seems it got screwed up in posting. Text has been mistaken for tags.**

3 comments:

  1. I have to say the model of that Chinook looks fantastic.

    Its a shame that most people will comment on the eye candy and not your programming skills flex but nonetheless I understand almost half of what your saying and it sounds impressive.

    How many lines of code are you up to now?

    ReplyDelete
  2. Couldn't say what the code count is. The asm source is close to 425k lines which the British Computer Society would still consider "trivial".

    Eye candy inspires me too, certainly it will encourage me to drop what I was doing just to play with the new model, and I think David likes to see his creations come to life. He's also good to bounce ideas off. 3D art is a highly technical process often involving lots of beer and OCD qualities.

    We'll discuss the technical limits of the engine, exporters, how our game software can interact with 3D shapes and with that understanding he builds as required. And that makes the job of programming that much easier.

    The breakthrough in getting a lot of this work work has been how each object (helicopter for example) can send and receive messages. It doesn't care where they are from, network, the cockpit interface, a character on the outside of the helicopter interacting with weapons. The messages go through the helicopter entity and sent onwards to an appropriate class to deal with.

    So if you press the pilots MPD button #1, the helicopter you are currently mounted will recieve a "SWITCH_MPD_01" message with an additional struct about that button. The helicopter can pass that same message to other clients over the network and also on to the MPD class which knows how to handle switches.

    Much of it is generic too, the same system will work for cars, tanks, sat dishes which can share some of the base classes.

    There's a danger we might make some things look a bit too good as that raises the expectations across the whole game. Our intent was to make something like Longbow 2 but with better models and lighting (and trees). I think we've overstepped that line a bit.

    The only other important goal was that we had to do it all in the space of one year. Just to see if it could be done. We can do that but the quality will suffer. Terrain and map building has proved to be the biggest pain in the ass, ever. Incredibly frustrating experience. It's never as good as we want it to be but next to a 1996 game it looks pretty good. But it has trees that block line of sight.



    I think the Chinook is looking brilliant too.

    ReplyDelete
  3. I was discussing this with Rob last night (over far too many beers). You've definately overstepped the LB2 update path with the amount of detail and work you are packing in. That's all the better for everyone else. Fantastic effort!

    I've been looking at the various game engines you've mentioned and I can see the limitations you are working with i.e. Leadwerks. But as Arnold Palmer once said "The most rewarding things you do in life are often the ones that look like they cannot be done".

    Just think though, all the work you've put in now will make the development of the next version (you've started the ball rolling now) with a better engine all the better. Just don't go too far now, lol.

    ReplyDelete