The Dead Walk | The Brick Dead Project

Things were going great for The Brick Dead Project, an ongoing series retelling one ignorant man-child’s quest to bash together a video game through excessive use of Google. With the core concepts created, everything from here on out should be a breeze, right?

Nothing is so painful to the human mind as a great and sudden change – Mary Shelley, Frankenstein

Things had, for lack of a better term, sucked for the past week.

I had left behind the decorated and polished environment of my Level-Home for new vistas. I needed to create a new, larger playground to build and test my ideas for the more advanced game mechanics. I bashed together a bare-bones boneyard without much thought. Experience had shown me that most of what I did at first would end up reworked, rewritten, or just flat-out removed. What I hadn’t experienced what how bad it would feel to end up back in an ugly, barren setting. It’s not one of those things that just pops into your head. It sneaks up on you. Grinding on you hour by hour, day by day.

Environment, such as it was, established, I had taken to rewriting the character controller. The original version used co-ordinates in the level to restrict player movement. From the onset, I had attempted to keep as much of my code portable and modular as possible so it would be easier to redeploy to other levels later. I wanted the movement limits restrained by invisible level geometry, like a bounding box, rather than hard numbers that needed to be tweaked every level. My first rewrite failed rather spectacularly, flinging the player to and fro at the whims of my hastily created raycasting move controller. I scrapped every bit of it and went back to the Internet. I re-researched and rewrote the whole thing again. The second time it worked. And it felt bad. There was a little ‘float’ or ‘slide’ in the original character controller that, while not intentional, made the character ‘flow’ even when pressing against the unseen border. This new raycast controller stopped you dead at the movement limits. It was exactly what I wanted. And it sucked. I scrapped it and went back to the original yet again.

After spending a so much time spinning my wheels on the character controller, I needed to make progress. Granted, a couple days may not sound like much when you think about the hundreds of people spending years to create your favorite store-bought games, but in comparison to my absurdly fast build time on Brick Dead thus far, it felt like I had wasted a lifetime. It was time to start work on what I expected to be the biggest feature I had yet tackled: Automated enemies; The Creeps.

So, first thing I needed was a model. I struck gold on the Unity Asset Store thanks to bisaniyehocam’s gift to the community of a pack of free skeletons. They were a little rough and low-poly for a PC game, but they’d certainly do to get me going. They fit the theme, they had removable weapons, they… didn’t have a walk animation. They could run, but I couldn’t use fast enemies in a game of this nature. I tried the running animation in slow motion, hoping for the best. As you’d expect, it looked terrible.

Oh, and they also did this:

So… Bonus, I guess.

Progress isn't made by early risers. It's made by lazy men trying to find easier ways to do something – Robert Heinlein, Time Enough For Love

In the old days I‘d have been pretty well boned at this point, destined to once more battle that b*tch Blender and handcraft a walk animation myself. These are not the old days, for both good and ill. The Unity 4 engine I had been working with featured a new animation system called Mecanim. Mecanim is… kinda weird. Much like most other modern technology, it provides a single, extraordinary feature you always dreamed of. Then it goes on to totally rewrite the rest of the book on everything that worked fine in an all new, usually asinine, way. The good part? “Retargetable animations.” This means that, after converting our little skelly buddy here to a Mecanim compatible format, I can pull any other humanoid walk animation for him to use. The asinine part? The thing to control the Mecanim animation system looks like this:


Now, I know what you’re thinking: “Isn’t this a whole lot easier to setup than a giant block of code?” Yes. Yes, it is. Ya know what it is absolutely horrible for? Troubleshooting! Good luck trying to sort through this mass of spaghetti in real-time. Throw in multi-level animation blending (An example of which would be in BDproto1 where the wizard’s legs move according to movement while the arms move according to spell casting) and you can’t even see what’s going on at all times, let alone track down an errant animation issue. Things get even weirder if you go all-out on Mecanim as it features a new way to move characters around based on the physical movements built into the animation, not actual code. Sometimes. Depending on how the animation was made. And how you set a mass of checkboxes on the model importer (The model for the animation, mind you, NOT the model you’re using).

Suicide inducing animation controller aside, the missing walk animation led me to one of my favorite experiences yet on this project: Clipping apart real motion capture data to bring a CG character to life. Honestly, if you had told me even yesterday that I’d be sitting at my desk doing stuff like this, I’d have alerted the funny farm. THIS is why we feature the GUO Crazy Projects! The functionality of million dollar studios is just lying around on the Internet waiting for you to play with it and the only cost is your time (and, in some cases, sanity). In this example, a free game creation engine where the publishers have provided a huge cache of free motion capture data. What a world!

As shiny the prospect of running my own little mocap studio was, the tedium of finding matching frames to get a pose to loop just right on half a dozen types of walking can wear a little thin. Add in the animation spaghetti monster controller, and it can be a bit much for a noob in the midst of an already frustrating week.

I elected to slow down and really learn the Mecanim system. Well, that was the plan anyway. Not two hours later, Unity yet again provided exactly what I needed. The Mecanim demo project contained an excellent animation controller complete with already chopped-up animation loops just waiting for anyone to use. It was perfect! I was off to the races once more. With a little copy/pasta magic, the Mecanim made locomotion engine was plugged into skelly. I tore out the chunk of code that processed player controls and soldered the skeleton's AI navigation controller in its place. Tweak some speed and movement restrictions and… Presto! It lives! Er, walks.

I did it! My first lil’ AI dude! I chuckled madly to myself and bounced my balls off the skeleton’s kneecaps for what felt like hours, delighting at the scene. It continued marching, unimpressed at my antics. Nothing happens without code, of course,  and I had not written a single line to determine skelly’s reaction to being hit. But I had plans! Big plans. Great Big Plans.

The grey skies parted. The sun shone. I was making progress again.

It was the eye of the storm.

No comments :

Post a Comment