Animation woes

For the last two weeks, I started every day working on Xenos with the resolution: “Today, I’m going to finish working on robot animations and write a post about it!” As you can see, this didn’t work out exactly as planned.


Alien scout close-up

We got the first robot – we call it a “scout” – modeled and textured some time in september. However, animating it proved a really tough undertaking. At first, the animations just didn’t look right. It turns out that making robotic motions is hard, especially when the robot is not a giant multi-ton vaguely-humanoid mecha, as everyone is used to. Alien scouts in Xenos are relatively small and have thin legs; when animated they mostly looked like an insect of a little bird, not a mechanism. It took us a week of heated discussions and constant reworking to arrive at something nice (and even now I’m not entirely satisfied… maybe there’s something we’ve overlooked?) Add to this another problem that appeared as soon as I added first robot to the game: speed.

The player in Xenos should be able to move at a quite brisk pace: otherwise it’s just too frustrating to spend several second on crossing the road. Animation-wise, this translates to running, which is (probably) fine for humans, but robots are usually associated with slow, deliberate movements. (Yes, I’ve heard about Cheetah. But the thing is, its movements are not very robotic.) While we have a running animation for the scout, it’s not super-convincing.

When you have walk and run animations, next thing you want is blend them together, so that  the robot can move at any speed (between walk and run). Which brings me to the next problem: Mecanim. It’s a hyped addition to Unity game engine, that is supposed to greatly simplify setting up animations. Well, to put it short, it does not. I’ve had some problems with Mecanim before, but this time I’ve decided to really give it a chance… and after spending 3 days wrangling with the system, I am certain that it is horrible, broken and nearly unusable. Or, well, to be completely honest, it’s probably nice – provided you agree to do everything the Mecanim way. It is made with a very specific development process and architecture in mind, and does not really work otherwise… and, of course, Xenos does not adhere to Mecanim ideas.

After stripping the whole Mecanim nonsense and reimplementing blending with code, I finally had a working robot in-game… but that does not mean that work is finished! To be actually interesting, the robot has to do something besides walking around. I’m working on it right now: adding some AI to the robots and making them interact with the player.

This is how it should work, when it’s finished. First, I have an Alien Spawn System, that handles spawning and removing robots. The idea behind this is, I don’t want to simulate all the individual robots in the game world – there would be hundreds of them, and this has no immediate benefit. The player would probably never notice this, especially since all robots (of the same type) are exactly alike. But I still want to simulate alien activities on some level. So, the Spawn System is tasked with keeping track of general “danger level” of all places. Whenever a player is in a dangerous place (that is, almost all the time), the System spawns a number of robots depending on danger level, somewhere relatively close, but far enough to be off-screen.

The robots have an AI that causes them to approach the player. But not directly – I want the player to feel that robots don’t care about him at all, not that they’re all out to hunt him. So, the AI actually selects a target nearby the player – for example, the scout would select some environment object, approach it and play “scanning” animation. This would show that aliens really do some stuff here, and ensure that the player is actually around to see it.

After spending some time near player, the robot AI then selects some destination  far away, and goes there. The Spawn System checks all robots, and removes the ones that went far enough away from the game: the player is not there to see them, so they’re not needed.

Or that’s how it goes if the player does not interfere. If the robot sees the player, it becomes alerted: it stops and looks directly at the player. A couple of seconds later, if the player does not run away, the robot attacks. The idea behind this is to make robot’s intentions crystal clear: at first, it pays no heed to the player. Then, it becomes interested. Then, aggressive. The “alerted” state also gives a chance to run: robot’s shot are quite deadly and hard to dodge (or they will be, once I actually implement them properly.)

This system, however, requires adding more animations – scanning objects, turning around looking for the player, etc. Which is why I’m not showing videos just yet – there’s still a lot to do until it’s finished, even though every day it seems that we’re almost there.

To make up for this post’s lack of pictures, though, I can show a couple of screens of the environment. We’re slowly but surely adding more and more stuff to the city, and it’s starting to look nice. It’s way easier when stuff is not animated (-8

A robot takes a stroll in the park

A drugstore

Street corner with a billboard

Fuel station.

Fuel station.

Leave a Reply

Your email address will not be published. Required fields are marked *