Blog for Daniel Buckmaster at GarageGames.com

The Onager Engine

Daniel Buckmaster — 2008-05-07T18:50:07+00:00

[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.

No, still no crosshair...

Daniel Buckmaster — 2007-11-03T18:36:57+00:00

Sorry. Well, I can post the code changes to the crosshair I made, but I want to write a real resource with a full tutorial and usage. On second thoughts, I might just get it out there and do the scripting side of things later. Yeah, I'll do that. Okay, so I just invalidated the title of this blog entry. Meh.

Due to a week of holiday that is just coming to an end, I've had a lot more time to work on Torque than I usually do. As such, a Great Leap Forward has been made. Or several. To accompany the several Small Steps Back. Among the Great Leaps are AI coding and scripting. I added some functionality to AIPlayer so that when I tell a character to fire, it will wait for a random period of time before firing. Useless, you say? (Yes, useless, you say.) Well, not for my game. I want to, eventualy, have whole armies duking it out in a battle. As such, it's really notpossible to schedule an 'updateMe' routine on every I character with any sort of speed. So I hand out the AI to 'squad manager' entities that do all the thinking. So while I may have 150 bots a side, that's only maybe 12 squads, so only 24 (in total) objects doing any sort of complicated thinking.
Of course, there's problems with that approach. One of which is the firing. If a squad manager is running its 'tell the squad when to fire' routine every second, then every second, all the AIs in the squad fire a shot. They wait a second, then fire a shot. Uncanny. So the solution was pretty easy to find - simply add a random delay to when an AI character fires. Schedule would have been the easy way out, but I'm staying away from it as much as possible - even the squad manager thinking routines, I want to move into code, or at least partially. And anyway, you run into the same problem as before - you're scheduling for every individual character, which basically defeats the purpose of using a squad manager at all. So I decided to just move that functionality into code.
A little while later, and I had the AIPlayer::singleShot method. It takes two parameters, minimum and maximum values for the random delay. After that length of time in ticks, the AIPlayer triggers a script callback on itself, and in that script callback, I do stuff like set the character's image trigger, etc.
So that's how it'll work. Each time the squad manager runs through its 'tell people to shoot' routine, it does just tht - and the result is that you get a smattering of gunfire that looks nice and natural.

Second blog post!

Daniel Buckmaster — 2007-09-01T20:40:37+00:00

Yes, it worked this time.

In my last blog, I mentioned a few changes to GuiCrossHairHud. To sum it up, imagine the Advanced Crosshair resource but more of a blank canvas. The crosshair will remember GameBase-derived objects you look at, and fire off one of two script-side callbacks when you look away or look at a different object.
Basically, the changes I had made back then were roughly correct, but sharply messed up. The crosshair would shoot off 'object selected' callbacks as long as you kept your crosshair on the same object, and sometimes it missed out 'object deselected' ones. Tonight, I sat down with a piece of paper and a pen and went through what the code should do, and how I would make it do this.
This is something I can not reccoment highly enough for anyone beginning any sort of programming. You have a problem, so work it out on paper first. It's much easier to find errors in your own logic rather than errors in logic after translating it into code.
Anyway. Like I said, I cleaned up the code substantially, and as a bonus, I even made it work! So now I'm almost ready to release another resource based on this which I reckon could be pretty useful. There's just one problem, which has to do with object IDs. I made a forum post, so I won't derail the blog with it. But keep your head down, 'cause there's a storm coming... hah. Hah.

First blog entry...?

Daniel Buckmaster — 2007-08-07T09:50:24+00:00

This isn't actually my first blog entry. You see, I wrote one last night. It was the blog entry to end all blog entries, and it was so damn long that my eyes bled when I looked at it. Then I hit 'Submit', and it got eaten by the computer. Now my computer has taken responsibility for its actions and suffered duly, and I am revising my first-blog-to-end-all-blogs to something more short and less eye-straining.

So, this is my first submitted blog entry. Whoopdedoo. Hi, I'm Daniel, I'm a student in Antwerp and I use Torque in my spare time. Now enough of that. Let's get to the fun bit!

As some of you who frequent the forums here may have noticed, I just posted my first resource (whoopdedoo). It's a new class, BasicShape, that is what ShapeBase should have been. You see, when you want shapes in your world that are static, you have two options. You can use StaticShape, which carries around a huge amount of overhead inherited from ShapeBase, or you can use TSStatic, which can't use datablocks, can't process ticks, etc. I figured there has to be some half way, a measure between functionality and performance. Turns out there wasn't, so I created one.
As I'm just beginning to code in the engine, it was implemented pretty simply. I read through fxRenderObject (exceedingly useful), TSStatic (not so useful but still instructive), and figured out which elements were needed for each. BasicShape is the result of these efforts, incorporating code from both classes. So it inherits from GameBase, can display a simple shape, will collide with things, and uses a datablock. Awesome.
What's the downside? Well, it was coded by a noob, so it's not perfect. About five minutes after posting the resource, I had some help optimising it - which I appreciated, don't get me wrong. I want to learn all I can, and for other newbies like me, I highly reccomend diving in there and doing stuff.

In other news, I also hacked up the GuiCrossHairHud code. The default crosshair will, when pointed at a ShapeBase object, display a cute little readout showing you its precise health level. This is a bad thing. I'm all against hardcoded functionality, and this is hardcoded functionality at its worst. Especially since my current project (see below) is going for a 'realistic' feel - which does not include knowing the precise health of any object you care to look at.
So I cut out the bits that rendered the health, and then I had an idea. After looking over the advanced crosshair resource, I added in some of my own modifications - namely, a system that fires off script callbacks when different objects come under the crosshair. Think of Morrowind, when you point your crosshair at an object and you get a little message box telling you what it is. That's what I'll be using this for. Wrench your mind out of Morrowind and remember Halo's system for taking weapons - when you get close to one, you get a message at the top of your HUD saying 'Press E to take whatever'. Now picture a merge of the two systems. I want to do all interactions this way - taking weapons and ammo, opening doors, boarding vehicles, the list goes on. All wired through my handy crosshair system. Whoopdedoo.

Now, I mentioned above that I had a project going. Indeed I do. The long and short of it is that it's going to be a FPS based on the Warhammer 40,000 IP. Fire Warrior was lousy, IMO - not the game itself, but the way the IP was portrayed. I mean, come on, is it plausible that a single Fire Warrior, on his first day out no less, is able to take out hordes of Chaos Marines and Daemons? Please.
So we (myself and a few buddies doing artwork) are going for a more true-to-tabletop game. Battles will be just that - not a standard FPS romp where you shoot everything in sight except your legs (when they aren't invisible...), but an actual engagement between opposing armies. Scores of infantry, tanks, and monsters; artillery barrages and air strikes; psychic powers and special abilities. Wholesale destruction like nothing you've ever seen. Well, maybe you saw it in DoW, but that's another bone to pick. Is it plausible that, after being hit in the face with a Prism Cannon and tossed twenty feet through the air, a lowly Ork stands back up and keeps running?
The hell it is!

So, upon this concept we based a few gameplay features. I won't disclose them unless you ask really, really nicely, but they're awesome. Six playable races, six playable campaigns, create characters that gain experience and rank, take orders or command your own squad, pilot vehicles, become a powerful psyker, you name it and we want to include it!

Anyway, that's what's been going down. See youse all next blog. If you computer doesn't get hungry again.