August 20, 2009

Emergent Game Design still emerging?

Almost a decade has passed since "emergent game design" showed up as a new buzzword in the game industry. Basically who could pull it off was pro, the rest was rubbish. Curiously, "emergence" in games in not ten-years old, it's actually something that's been around since the very early gaming days. It's basically something that occurs naturally, as long as you give the players diverse and natural tools to mix, match and discover new mechanics, be they intended by design or not. That last part doesn't really matter 'coz what gives players pleasure is the learning experience itself, not knowing if what just happened was intended or not. At least not primarily.

The thing is that Players are inventive by their own nature, the simplest challenge makes them think about ways to pull things off easier and faster - and that's where emergence is born from, not at the cold lines of code. So what's been missing is the "diverse and natural tools" part that I've mentioned before. By "natural" I actually mean stuff that work as expected. There's a sad trend of getting gameplay so meticulously under control and plastered that you see large boulders hitting soldiers right on top of their heads and not harming them, just to theoretically avoid "frustration" in a couple whining players that would just learn to place their units away from their catapults' target otherwise. But nah, let's waste them and spoon feed them a "fix" which will just make the game shallower and move it one step away from the much-needed suspension of disbelief. That is probably a dire result of game designers getting less and less secure about their own mechanical designs due to the complexity of modern games, where their ideas rarely get through to the final format as intended.

As for the "diverse" part, that is in fact the gravest point. It's easier and safer to have all enemies, for instance, share the same attributes and functionalities and tweak their values. Yet it'll sure-shot make the game incredibly boring. To add insult to injury, there's the darned massive multiplayer online (MMO) syndrome which has plagued the game industry. It's a suicidal, lemmings-like march of formerly solid companies heading towards self destruction - thinking they'll become Blizzard-mega-rich. Fact is, that MMO games has led more companies to the brink of bankruptcy and closure - and investors at the brink of insanity - than any other game genre in history. Obviously if you want to make massive content to provide for a semi-infinite amount of play time, you're bound to what I call "statistical boredom". How in heck has this contaminated regular games is hard to swallow though. I won't even get started on why on earth does a supposedly primarily multiplayer genre needs so much focus and effort on single player missions and content.

Back to the point, this lack of different functionalities or features for different units were well justified back when making 3D games was extremely hard and cumbersome. Nevertheless, nowadays the odds are completely reversed. Making high-end 3D art is way, way more expensive and time-costly than adding a few new functionalities to the same unit, made extremely trivial by modern and low-cost engines like Unity 3D. Yet spamming new 3D art with the same functionality of all else that the player has already seen results in a much shallower game, and less / short-lived fun factor.

When will designers get a clue and wake up to the new times? In large game studios that should probably start by the producers and game directors, since they're the ones deciding the directions. Since most of these large-format studios are obsolete, dinosaur beasts acting like slow-turning titanics heading to their respective icebergs, where's hope? Apparently in the smaller, agile studios that are popping up, empowered by a fresh vision and no strings attached.

Let them lead the way to better, deeper games, and shall emergence be rediscovered.

Recommended reading:

August 08, 2009

Lightwave to MotionBuilder

If you've ever done anything related to character animation for real time applications - most noticeably games - you already know that these real-time engines don't have any time to spare to "fix" our 3D characters bone influence weightmaps like in most non-realtime 3D applications rendering. That basically means you have to resort to "explicit" maps which have absolutely zero tolerance for things like vertices with over 100% or under 100%. So if you have, say, forearm and arm bones influencing the same elbow vertices, you'd better make sure that both sum up to 100% - eg. 60+40 or 50+50 - or else all sorts of weird distortions happen. In Lightwave 3D you can simulate the effect of explicit maps by toggling the "Use Weightmaps only" bone properties option and making sure "Normalize weights" is off.

Now, let's say you want to spare yourself from the troubles and complexities of setting up a full rig - which's a digital puppet armature with all the wiring, knobs and levers set up properly for ease of animation - yourself. The best standalone option out there is Motion Builder, owned by the giant Autodesk. Once you experiment its power, it's hard to look back. It's safe to say that Lightwave's powerful IK booster comes close in terms of posing power and might even surpass the market leader in terms of flexibility, but the fact is that for professional high-end animation, you need live IK, physics and ragdoll effects, and that Motion Builder delivers in spades.

The problem is, Motion Builder uses explicit weightmaps, just like most 3D applications, so trying to import your Lightwave models with bones directly into it will surely result in some of the weirdest deformations you'll ever see. So you go back to Lightwave and painstakingly have to set up the weight maps one by one, using the same naming conventions motion builder uses to make its "characterize" process seamless. Not to mention having to set up that complex hierarchy of about 90 bones and later tying it all up together. And why don't we have a mirror weights option, you don't mean I'll have to re-do everything finger part by finger part in the other hand do ya?? Ouch..

Fear not though, Lightwave's community to the rescue! First, since this is the most helpful 3D app community in existence, I want to give back I little so I'm giving away my meticulously setup rig model with all skelegons properly named and ready for joint conversion. It's in the bottom of this text just like all other links. To use it, open it in Modeler, then tweak the vertices to comply to your specific model, you can refer to any Motion Builder tutorial model to check where each joint is supposed to be. To convert the skelegons to joints in Layout (instead of regular z-bones, remember joints is what Maya and Motion Builder uses) I strongly recommend using Adam Redwood's script, to make sure the joints are named correctly in Layout.

So now the big problem is mapping those weights right? Okay, first let's explore our options. If you have the bucks, you can try using the default Lightwave bone options (strength and falloff type) to make sure no bones are affecting areas they shouldn't, then use Okino's Polytrans software to generate an explicitly-weighted model. Haven't tried it myself yet, but according to the company's info in their website it'll joyfully create all weight maps for you.

As for the second option, you can manually set up the weights using symmetry for things like the fingers, copying (duplicating) the map, rename it (say, left to right), then clean up the vertexes from the non-desired side in both maps. Zzzzzz. The apex of needless repetitiveness - read, tedium - in my book.

Third option is what I'm here to talk about. First set up parts for each weightmap you want for just the center and left side of your model, I suggest hiding each part as you create it to avoid overlapping regions. Then use Trueart's handy parts to weight plugin to convert these parts to weightmaps. Now, manually optimize your wmaps for best deformation - you know, things like lowering the shoulder influence under the arm - not bothering about compensating the adjoining bones as one regularly would. To smooth out large chunks automatically, use the wmapblur plugin.

Now you've got a full half of your character done and you want to mirror these weights to the other half. You may be tempted to use the ancient YO_mirrorweights plugin, in my tests it did work on LW 6.5 but it crashed on 7.5, actually it won't even show up on 9.6 as available after you install it. As hard as it is to find and run, if you have access to a 6.5 installation by all means use it, it's a great option. Kung Fu Tools is supposed to be even better, but I couldn't find it anywhere - if you still have it lurking in your hard drive, please share it in the Lightwave forums.

"MaDDoX, I don't have LW 6.5, am I doomed?". Not at all, because Sir Timothy Albee kindly shared with us one amazing tool called BG Morph-and-Weight Copy. What this little gem of a tool allows for is copying weightmaps from completely distinct shapes. Although its intended use is for just slightly different shapes, in fact all you have to do is create a morph map for the target character, tweak it to roughly conform to the original (properly weightmapped) character and apply the script with a sizeable threshold. What that technique allows for is that once you have a good-behaving model of a certain style, say, a biped, you should never have to spend time creating its weights again, just tweaking it to compensate for different proportions.

Anyways, the point here is mirroring the weightmaps, how can BG weight copy help us? Here's a technique that I figured out that solves just that:
1. Copy your object and paste it into a new object
2. Use FI's Move VMaps plugin to rename all your weight maps from "Left" to "Right"
3. You'll now stretch your object horizontally, set -100 to the X axis in the numeric window and apply. Flipping the normals after that is optional since we'll just use it to copy the vertex maps from
4. Delete the non-symmetrical weightmaps, like Spine and Neck
5. Copy the mirrored object and paste it into a background layer of your original object
6. Set the FG and BG properly and run Copy BG Weight.

Presto! After some moments you'll have your mirrored weights. If you run into any "overlapping vertices" error, simply select any of your model polygons, perform a 'select connected' and cut/paste it to another BG layer.

Finally, all that's left to do is to run normalize weights, using the other script by Timothy Albee, that'll adjust your weights proportionally to their original values but make sure all vertices weights sum to 100%. Done, you'll now have a complete motion builder compatible character ready to FBX export. So here's my little gift setup/mini-tutorial to you guys, I hope you put it to good - and profitable ;) - use. Have fun!

MB-compatible Skelegons Rig:
Skelegons to Joints:
Parts to Weight:
FI's Weightmap Blur:
TA BG Weight Copy and Normalize Weights:

Update: Two years after writing the original article, what a nice surprise I had when I found that multiple advancements were done in that area. Lightwave 10 has a much improved export/import FBX plugin now, and the rigging master, RebelHill, got some inspiration from my researches and has developed two absolutely brilliant video tutorials explaining the arcane details that I couldn't unveil back then. If you want to go down the LW->Mobu->LW workflow, by all means check these life-saving videos:

Understanding LW and FBX

  • (part 1)
  • (part 2)