The Onager Engine

[BEWARE - super long post!]

[EDIT: Name changed from Siege Engine to Onager Engine; see comments]

So, this is my current project. I would make a project page for it, but I don't have a company...


What is SiegeEngine? In short, it's Torque 1.5.2 with a bunch of resources and my own modifications.
What is it for? It's the engine that will be used in the U40kCG, my 'other' current project - U40kCG relies on SiegeEngine being finished, and SiegeEngine's raison d'etre is to make the U40kCG possible.
Why did you call it SiegeEngine? Well, it's a long story. To cut it short, I wanted something like The War Machine, but since that's sort of taken, I settled on the next best thing. Plus, it uses 'engine', which is quite appropriate.


Enough waffle. What makes SiegeEngine different from stock TGE? I'd love to hand you a final feature list, but I don't really know myself. Here's my current train of thought for version 1.0. If any feature looks like something you have written a resource for, I probably used it. I have compiled a (huge) list of every resource I've used, so don't worry - you're not going to go without credit.


-Hitboxes on ShapeBase objects, including vehicles, as well as the ability to dynamically activate/deactivate them. This combines perfectly with...


-Locational damage integrated into the standard ShapeBase damage system and ShapeBaseData. These are further enhanced by...


-Mesh hiding and multi-material skin swapping used both for limited character customisation and real-time amputation of appendages (and vehicle parts). These features are also implemented in the ShapeBaseImage class for dynamic altering of weapons and other items.


-Torque Modernisation Kit for DRL, bloom, water and interior rendering.


-Visceral first-person experience through the ability to see your own body (gasp...); the elimination of weapon offsets and muzzle correction; dynamically applied 'sniper-breathing'; a fear/fatigue ('stress') meter; and additional crouch/prone/swim stances.


-Advanced weapon effects including terrain deformation; a unique addition to ShapeBaseImage that works with the state system to allow never-before-seen freedom in creating weapon state sequences; material-based terrain/character/interior explosions and hit particles; and projectile penetration for exit wound effects and character/wall piercing.


-Fully-featured melee weapons using the existing ShapeBaseImage framework. Allows the in-game addition of bayonets to ranged weapons, as well as normal close-combat weapons, shields, etc.


-Powerful vehicle mounting system for creating arrangements of passenger seats, weapon control seats, pilot and copilot seats, seat swapping, compartments, and more.


-Datablock-based voice sets to easily create varied rules for a character's speech. Fully integrated with the Player class to allow characters to chatter, call for help, alert friends, etcetera.


-Radio/communications system that manages a radio and radar network, adds dynamic noise to played sound files, and handles jamming, encryption and signal strength.


-Fixed HoverVehicles including hover-on-water capability.


-Voice chat for enhanced in-game communication with other players, along with full options to limit its usage.


-Immersive environment effects such as clustering foliage and shape replication; huge dynamic forests; swarms; hostile flora and fauna; and skybox cycling for day/night transitions.


-Faked inverse kinematics for the Player class utilising a simple triangle solver to pose limbs in real-time given a target object or node, eliminating the need for multiple complex animations - for example, when holding and reloading different types of weapon. Interpolation with time targets and instant posing supported.


-AIPlayer upgrades to give a greater deal of autonomy to AIPlayers - they manage their own firing and have the equipment to make basic decisions about aim targets and move destinations. Optionally, they can utilise a the Player stress meter.


-Advanced AIMaster class implements RTS AI routines to direct a developing battle.


The idea is that the final game should be a game of large-scale battles that you would typically see in an RTS (a man's RTS, not Warcraft 3), but from FPS perspective. I want to do into detail about some features...


Hitboxes, locational damage, mesh hiding
Yes, this had to be in there. The U40kcg is based on a grim, gothic future where infantry fight with hugely powerful weapons. I'm deliberately being ambiguous here, by the way. But here's an example. Think of the Torque Bow from Gears of War. It hits you, then you explode. One faction in the U40kCG carries, as standard, a weapon that fires four-round bursts of projectiles that do basically what the Torque Bow does, except they explode on impact. Imagine the carnage.

So early in development, I decided that 'real-time amputation' would have to feature.
Basically, the idea is that hitboxes on a character (I used Davide Archetti's resource, with some heavy modifications) each are assigned to a location which is represented by one or more meshes. When that location is damaged above a 'critical damage' level, it is amputated (depending on the weapon that did it - obviously a pistol isn't going to do this). The mesh is hidden, and a 'stump' mesh shown.
Of course, this would be nothing without having characters react to their arm being severed. Basically, the character will die if this happens - a special, slow death. Unless they're super-tough, of course. In this case, they'll fight on, but with penalties such as not being able to reload their guns.


Character customisation
The mesh hiding resource (by Erik Madison) lets you do lots more than just express your sadistic tendencies. In this case, I'm putting it to work in a similar way to the node hiding resource's aim - you make a model with a bunch of meshes that represent variations of equipment, then hide the ones that a specific character doesn't have. In the context of a large-scale battle, the idea is to give each unit a variety of possible looks - different versions of the same armour, different personal additions, etc. At the same time, different skins will be applied - so some individuals will have a different skin colour, muscle tone, or scarredness.

Why not use a dynamic skin modifier resource to paint on scars and decals and stuff? I think it's overkill for my purposes. It should be enough to simply use one of a variety of skins.
Customisation of player characters is a slightly different issue, and specific to the U40kCG, so I won't discuss it right now, except to say that I may go down the route of adding dynamic skin modifiers.


The TMK
Ah, yes. Well, basically, the TMK is too good not to add. When you see some before/after shots, it's immediately apparent how beautiful the MK is. If Koushik releases DTS shader code, then I may add that as well - in a modern market (not that I'm aiming to sell the game - simply for people to enjoy it without having to transport their mind back to 1999), it's sort of standard to provide normal mapping, etcetera. But for now, the MK will do nicely.


Visceral FP experience?
That's marketing talk right there, that is. See? I can talk the talk, you betcha!

Ahem.

My objective of my Player-class modifications is to create an immersive experience when you're in first-person. (And no dicking about with third-person, either.) I always cringe when games touted for being 'realistic' fail to show your body in FP view, or have a floating gun with an arm attached. It's simply not the way things should go. To that end, I used Joe Maruschak's brilliant FP resource, so all animations are done all the time, and on the server (except eye orientation, which is kept in code). This means things like head bob are intrinsic - if the character is animated well. Combined with the additional Player positions resource, which gives crouch/prone/swim capabilities, I hope players will actually experience that sense of body that is missing in most games.


Weapons
ShapeBaseImage has seen ome big changes. My big brainwave was a 'watched field' system, which basically is a timer that the image maintains, and fires callbacks based on events (such as a maximum reached, a certain value reached, etc). When this is combined with manual image state changes, you have a powerful way to control image states. So for a four-round burst, you create a shotCounter field and increase it every time you fire. After firing, check the field - if it's less than 4, go straight back into the fire state.

Terrain deformation, again, was something that, considering the setting, couldn't be left out. A lot of battles in the U40kCG will feature heavy artillery, which is just laughable if it isn't leaving huge craters and sending geusers of dirt into the sky. The current resource is a starting point, but still things can be improved - notably relights and circular deformations. Boy, I'm looking forward to that...

Melee weapons are another setting eement. In my opinion, any self-respecting SF setting that includes melee combat as an efficient alternative to shooting is a rather good joke. However, the U40kCG's setting is rather special. And melee weapons are cool. So I'm planning on implementing them in the simplest way possible. When a melee weapon is in its 'active' state, it casts a ray every tick along its edge (defined by nodes in the model - I'm planning on allowing curved swords and stuff). Anything hit is damaged. The method of determining damage, I'm still deciding on. Either I'll add a field to ShapeBaseImage to track the image's velocity (including that added by animations), then when a hit is detected, do damage based on collision velocity. Or, I'll only trace in a special 'swing' image state, so you can only hurt people when you're swinging.


Vehicles and HoverVehicles
Everybody likes public transport. But it's not necessarily easy. The idea is to allow vehicles to be segregated into different 'compartments', each compartment containing a number of seats. Each seat is linked to a 'board point' represented by a node in the vehicle - when someone comes close to the board point, they can get in by pressing a key, Halo-style. When in a seat, characters either control something (the vehicle, the turret, a sponson gun), in which case any moves they generate are passed to that object, or they don't control something. In the latter case, they will be stuck in a seat, but able to twist their torso, so they can still look around and fire their gun.

Through some sort of GUI, players will be able to swap seats within the compartment they are in, but not between compartments.

Potentially, I'd like to leave corpses in their seat - so if you want to swap to that seat, you have to get the corpse out first. But maybe that'll just stuff things up.

I'm worrying about the problem of mounting - with the sheer variety of vehicles in the U40kCG's setting alone, and the different ways you can board them, it's impossible to have a unique animation for each. One option is to do Star Was Battlefront-style mounting, where you just get teleported to where you need to be. This, however, goes atgainst the whole 'visceral FP experience' thing. Another option is to implement some sort of 'mount vehicle and move about on it' resource. Then 1) seating can be accomplished by having an AI routine take over to seat the player and walk to where he needs to be 2) transport vehicles with standing room instead of seats can be created.
This is all a bit complicated, though.

HoverVehicles I added in there on impulse, really. The U40kCG should feature them, and I've heard how broken they are. I'm going to take a crack at doing something about it. And adding hovering on water, which should be less difficult.


Voice sets
This is one of the older features I've had in mind. Ever since I played Tribes, actually. The idea was for people to pick a 'set' of voices, which have different ways (accents, genders, etc.) of saying the same things.

This can be extended to AI characters, since the U40kCG is going to have a lot of dialogue (from squad chatter to sending and recieving orders). So characters will need to shout expletives, insults, and compliments, as well as being able to string together a sentence like 'squad 2, go to point A and kill the poor sods you find there'. Plus, it would be good to abstractify all this in some way.
So a voice set is basically a datablock that defines the way a character talks. It has a list of voice files for insults, a list for compliments. It stores the directory of a folder where all the other sounds can be found - voice clips like numbers and letters, and things like 'move out!' and 'retreat!'.
This is activated by calling a method on an AIPlayer. So you say %player.swear(); and the object relays that to its voice set. The voice set picks an appropriate file and plays it.

Still haven't decided on a method for sentences yet, but they'll have to be quite dynamically generated - in the above example, the fragments would be something like 'squad' 'two' -pause- 'go to point' 'a' 'and kill the poor sods you find there'. That last segment might be 'and dig yourselves in tight' or 'and await further instructions' depending on the order.


You FAKED inverse kinematics?
Well, it's getting there. The idea is to have, instead of a full IK solver, a triangle solver, designed to be used on three-segmented limbs (upper arm, lower arm, hand). It makes a triangle with the first two segments, then points the last one in the appropriate direction. The point of having it is to take the strain off the animations. Example - consider a sniper rifle and an assault rifle. When you hold them, your right arm is in basically the same place, whereas your left arm isn't. Same goes for reloading. So instead of having four different animations (assault hold, sniper hold, assault reload, sniper reload), just make two (rifle hold and rifle reload), and use IK for the rest. In this case, you'd put a 'hand' node in the weapon models in question. When you're holding the gun, you set the left arm IK target to the hand node, and it goes there. To reload, you just animate this node to do whatever the hand needs to do.




That all sounds fine and dandy, but why am I telling you?
Partly, because I feel like telling somebody. If everyone thinks these features are crap, then I'll have to rethink the design for the U40kCG quite a lot.
Partly, because I think you'll be interested. I intend to release my changes as a resource, so if you like the idea of Torque being able to do these things, all you have to do is wait!
And finally, partly because I have no idea how I should be going about some of these things. Well, that's a lie - I have some idea about every idea, but not enough know-how to put those ideas into reality, whether they are good ideas or too impractical, etcetera. If you are in the same boat, maybe we could put our heads together and work something out.

Well, that's that. I'll be back.