"Gondorian" and "Uruk-Hai" characters inspired by the work of WETA Workshop, Ltd.

What is Mayhem? It's an experimental work - a suite of maxscripts that work with Character Studio and let you generate characters with programmable behaviors for use in crowd scenarios. This experiment came about initially because I got it into my head to try and recreate a bit from one of the battle scenes in the movie Braveheart. Then I got interested in the work WETA Digital was doing with Massive, and other crowd software such as Softimage|Behavior and AI.Implant... Well, I guess my experiment got a little bit out of hand :-)

Why is Mayhem Necessary? ( the *really* techie bit )

To put it in a nutshell, because crowd currently can't create type of crowd simulations that I (and I suspect other people), expect to be able to produce with it.

In the latest release of Character Studio (4), crowd stability issues got fixed but no new functionality got added. To me, this was a bit frustrating. Crowd has some great tools such as cognitive controllers, per frame functions, and motion flow graphs. These are all things that should make generating your own "battle-bipeds" pretty easy. So why is it so difficult to make crowds do anything other than vague “wander about and don't bump into things” type of activities?

There are a couple of reasons that I can see. One issue is in how crowd solves bipeds. Bipeds work best with the “back tracking” and “use priorities” features turned on. However for simulations that are dynamic (biped interactions are necessary), any biped can affect or be affected by any other biped over time. Each biped must get solved simultaneously frame-by-frame for the simulation to work.

Unfortunately motion flow graphs are optimized to use back tracking and use priorities. If you turn those features off and try to solve all your bipeds simultaneously, your pretty motion flow graph becomes pretty useless. Not a good situation.

Another issue is in how motion clips are assigned to bipeds during a solve. Under the ‘back tracking’ and maxscript ‘biped.addPrefClip’ methods of motion clip assignment it’s impossible to make bipeds perform actions of a “stop-on-a-dime” variety (hit someone, react to explosion, etc). Unfortunately these stop-on-a-dime actions are *exactly* what you’re after. Hmm … not a good situation at all.

After hitting brick walls with these and a couple of other things, I had to drop the whole notion of using the biped and motion flow components of Crowd, and just built my own tools and geometry / bone bipeds instead. And thus Mayhem was born.

How Does Mayhem Work?

It works inside 3ds Max and alongside Character Studio. There are three stages to the crowd generation process:

Crowd Setup and Configuration - "Crowd Builder" This script initializes / assigns all the crowd delegate behaviors and their behavior targets. Delegate data variables for the characters are assigned or reset too. It's basically doing stuff that could be done by hand, but when you've got a couple of thousand orcs to setup, this script is really, really necessary.
Solve The Crowd - "Master Control Program" This is the character behavior engine bit (and yes, it is named after you know what). Run as a "per frame fn," this script manages what the delegates do and associated character actions. Behavior rules can be dropped into this script (range of vision, mugging on/off), as well as values like hit-points, weapon damage, etc. Solve time depends on the number of characters. For this animation (1000+ chars) it took a couple of hours.
Build Character Animations – "Choreographer" After the solve is complete, this script assigns the character animations for all activities that played out during the simulation. I originally used crowd’s motion clip synthesis but it was very slow. Eventually I realized that the characters knew what they were doing far better than the motion clip synthesizer did. So I wrote a maxscript to handle the results, and now a each characters animations get assigned in seconds instead of hours. Sweeet.

After all these maxscripts are done, you’re left with a huge bunch of animated characters, ready and raring to be rendered!

What Are These "A.I. Behaviors" All About?

Sounds super techie, but essentially it's just video-game-style logic to determine how the characters behave, wrapped up as buckets of code. The type of behaviors include generic character functions (e.g. mobility), character specific functions (e.g. class), and task specific functions (march, fight). Here's some examples of the ones I've been using so far, together with pics so you can spot where they're used in my little demo movie.

Fighting Behavior This works broadly along the lines of an AD&D-style fight: Find an opponent Decide who attacks first Decide whether attack is successful Yes - Roll Dice for moves and hit points damage No - Roll Dice for bad attack or blocking moves When an opponent is killed / dies from mugging Search for a new opponent (using “threat asses”) If no opponent then help allies (“mugging” behavior) If no enemy within range of sight, then proceed to assigned “goal” (e.g. enemy line of defense)
Mugging Behavior If another enemy opponent isn’t available, then the guy can assist his nearest ally by mugging that guys’ opponent. Mugging attacks do a huge amount of hit-point damage since they’re usually not defended against. Also I generally stipulate that an enemy can only have one mugger a time. Otherwise characters start running around in groups, mobbing a single guy at a time. (looks damned funny though :-)
Mobility Behavior Various behaviors used for assigning movement animations to characters (walking, running, stopping, etc.), together with a adjustments for random gait.
March Behavior Uses a "follow-the-delegate-in-front" rule to get people to walk in nice loooong lines.
Charge Behavior Uses the same follow-the-delegate approach as "March" but allows for a speed variation
Class Behaviors Behavior Yeah, I know it’s a rip-off of the LOTR shot. But it’s also what happens when a "Defender" class character meets a "Kamikaze" class character. Defenders will hold their line no matter what, and Kamikazes try to break through no matter what. Result = Carnage!

Mayhem - The Next Stage?

So what’s up next for this project? Well, there’s a many improvements, additions and half-baked ideas I've got in mind (time allowing!). Some of these are:

Wardrobe – a script to add randomization to character appearance and materials.

Animations v2 – currently the character animations I'm using are pretty basic - they weren’t really intended for anything else but testing the code. Plus what I know about sword fighting has been learnt either from movies, or fave games of mine like Blade of Darkness and Neverwinter Nights. Ideally I’d like to chuck mocap anims in there, and increase the number and complexity of moves.

Master Control Program fixes – I’m sure my maxscript could be so much more efficient! I think it spends cycles worrying about character actions when they’ve already been assigned. Also behaviors could be more modular – I should be able to drop in behavior rules in the top of the MCP and not worry about consequences. I’ve also been pondering whether this script could actually run as a bunch of cognitive controllers. Haven’t had time to test this yet, though.

Plugin for Character Studio? – It might be possible to embed some of my maxscript stuff as a new behavior under crowd. Under investigation!

New Characters – Ooopsie, I’ve just been watching Gladiator again. It’d be awesome to recreate the Felix Legions vs. the Goths, especially some of those marching formations that the Romans use. It’d be incredibly cool to have catapults flinging Afterburn fireballs and wreaking havoc on the barbarian horde… muwahahaha

Character Classes – I realized this the other day while playing WarCraft - characters with distinct classes (archers, pike men, sappers) should also have distinct associated behaviors, fighting animations, and different interactions with other classes (e.g. archers attack swordsmen, but panic and break ranks when the swordsmen get too close). Doh! Why didn't I think of that before?!? (note: I ended up experimenting with this a bit with the "Defender" and "Kamikaze" classes - see above).

FX – Okay, this idea is a little bit out there even for me but I’d like to be able to change materials in response to how much damage a guy has picked up, plus be able to track points for where effects could occur in relation to a character (dust from footsteps, blood spatter from a hit on the arm, etc).

That's all off in the future still. A broader goal is to start adapting this stuff to scenarios other than the medieval hand-to-hand-combat variety (actually a lot easier than it sounds since it's not close quarter combat). I'd especially like to try doing some WW2 stuff since I'm a huge Battlefield 1942 fan (Omaha beach here I come), but hey - we'll see how it goes.

Stay tuned for developments!

Thanks and Acknowledgements

Stephen Regelous and WETA – LOTR and Massive are just awesome - they've been a huge inspiration for this project!
Unreal Pictures – Character Studio is great! But can you please, please, please upgrade crowd just a l-e-e-tle?
Frank DeLise - who gave me the initial inspiration for all this stuff at a CS3(!) demo way, way, way back
Brandon Davis - whose description of his own crowd projects made me de-mothball this one, after I'd hit one brick wall too many. I figured if someone else was doing out-there crowd stuff, then I couldn't be that crazy :-)
Glenn Cotter - who’s always patiently listened to what I’ve been up to and never, ever said, “Dude - you’re mad”
Ste – I sincerely look forward to receiving the crate of beer that you now owe me!