In this Art Asset Overview, I demonstrate some experiments with 2D/3D art: assets that are painted by hand, but have some 3D structure to support layering and parallax effects. We were thinking this might be an appropriate style for the Overgrowth “metagame”, where the player makes higher-level decisions, compared to the concrete moment-to-moment decisions of stealth and combat.

I’m experimenting with bringing some hand-painted assets into the background of the arena scenes, to visually distinguish important gameplay areas from cosmetic background elements, and to bridge the gap between the metagame and the combat. You can judge for yourself how well the idea is working by checking out the video:

document.getElementById('hs-youtube-b461IZwi0B4').outerHTML = "\x3Ciframe width='520' height='381' allowtransparency scrolling='no' frameBorder='0' style='border:none;' src='http://www.humblebundle.com/store/video/overgrowth?youtubeid=b461IZwi0B4'\x3E\x3C/iframe\x3E"
Be sure to watch it in HD!

Next time I will show more work on the metagame UI screens! Follow our Twitter feed at @wolfire for realtime updates!

Receiver was finally released on Steam today -- check it out here! There is a one-week launch sale bringing the price down to $3.99. If you already have Receiver or Overgrowth, then you can claim your Steam key on your Humble Store download page (linked from your purchase email).

Whenever a game is greenlit, there are always two questions that come up over and over: "How did it take THIS LONG for this game to get greenlit?", and "How did THIS game get greenlit?" In this post I will try to answer both questions about Receiver!

We put Receiver up on Greenlight the day it was announced, because … why not? There was no fee yet, and we had no luck getting it on Steam via the traditional method. Receiver already had a pretty significant following thanks to our supportive and vocal community, and great ‘Let’s Play’ videos like this one from Robbaz. So, when we got set up on Greenlight, it didn’t take too long to reach the top 20!

Our first thought was that once we’re in the top 20, it’s just a matter of time until we get picked. But that’s not necessarily true! There are great new games joining Greenlight every day, and some of them shoot straight to the top. So, when we were #11, and the top 10 got greenlit, we were briefly in first place! But sure enough, along came 10 super-hot games that pushed us right back to #11 right before the next batch was picked. This happened over and over, until it seemed like Receiver might never get on Steam.

Finally, we got a surge in votes following an Idle Thumbs podcast about Receiver, and that kept us solidly in the top 10, and we got greenlit in the fifth batch! It’s tempting to say that this final surge is what got Receiver greenlit, just like a tie-breaking point wins a sports game, but ultimately every vote is just as important as any other when the total is what matters. In the end, Receiver got Greenlit by accumulating 54,266 "Yes" votes. Let’s consider this graph of daily votes over time for Receiver:

The first thing we see is a massive spike at the very beginning. I suspect this is partly because we got on Greenlight so early, when there were so many users rating games. If you look up Steam Greenlight on Google Trends, you can see that there was a big spike in interest when it was first announced in September 2012, followed by a steep decline. Since only "yes" votes matter, it was a big win to be there for that rush of voters! For the remaining traffic, I don’t have access to any extra analytics data for the Greenlight votes themselves, but I do have access to the stats for "wolfire.com/receiver"! That traffic seems to correlate fairly well with the Greenlight traffic, so I marked some corresponding spikes in the picture above.

There is a pretty significant noise floor of apparently random spikes, from small threads on Reddit, Tigsource, and even TVTropes. However, the first large spike came from a Penny Arcade article about a different game jam, mentioning Receiver as a notable example of what can be done in seven days. Our next significant spike came when we announced Linux support, which got us a lot of traffic from sites like Ubuntu Vibes, and made us a useful example in discussions of the Unity game engine’s Linux support. When we released Desperate Gods, that brought some traffic back to Receiver, because whenever anyone mentioned that game, it made sense to mention our previous work as well.

Finally, the case of the Idle Thumbs podcast is the most interesting, because as an audio stream, it could not drive any direct traffic. However, it did seem to kick off a lot of discussion of the game across the Internet, which manifested as a large spike in traffic from seemingly unrelated viral sources. First there was a spike in Twitter links (blue), then a spike from the SomethingAwful forums (green), and finally, a spike in Google searches (red) along with a video by Giant Bomb. I don’t really know how all these events are related, but they all happened very close together!

To answer the first question we started with, Receiver took so long to get Greenlit because there’s very stiff competition on Greenlight. There are serious contenders joining every day, and only a handful make it through each month, so you can be accumulating thousands of votes, and still see your rank decrease.

To answer the second question, Receiver got Greenlit for several reasons, including help from the faithful Wolfire community that has gathered over the years! Another important factor is that Greenlight voters are starving for novelty, and satiated with polish. Why else would they be spending their time voting on Greenlight instead of playing the latest AAA games? We put a lot of novel ideas in Receiver, and while it wasn’t the most polished game on Greenlight, apparently it was what voters were looking for! Here is the design overview video, for anyone who hasn’t seen it yet:

document.getElementById('hs-youtube-GCThInmzjXw').outerHTML = "\x3Ciframe width='520' height='381' allowtransparency scrolling='no' frameBorder='0' style='border:none;' src='http://www.humblebundle.com/store/video/receiver?youtubeid=GCThInmzjXw'\x3E\x3C/iframe\x3E"
Be sure to watch it in HD!

Thank you everyone who voted for Receiver on Greenlight, and I hope you enjoy adding it to your Steam library!

This talk was really ambitious, attempting to discuss the entire context of animation and story, rather than the mechanics of animation itself. I didn’t take many notes at this point because my phone ran out of batteries, so this is largely from memory. I hope the speakers forgive me if I mixed or left out anything important!

Designing a Performance

Ed Hooks, Acting for Animators Mike Jungbluth, Senior Animator, Zenimax Online

Ed Hooks is an actor who has appeared on screen in over 100 different roles, and is also a renowned acting teacher, famous for his “Acting for Animators” workshops and book of the same name. Mike Jungbluth is a senior animator at Zenimax Online, and organized the whole animation bootcamp. He has worked on a number of games including Elder Scrolls: Online and Call of Duty: Black Ops, and co-hosts the Reanimators podcast.

What is the point of animation? One of the most important goals of animation is to create performances that elicit empathy from the audience towards the character. It’s certainly necessary to succeed at the illusion of life, but that’s only the first ingredient for an effective performance by this metric. A second ingredient is distance.

To evoke empathy, the player must have a certain amount of distance from the character -- it’s not possible to empathize with yourself! The speakers brought up one of the first scenes in Wall-E, when he watches a movie of two lovers having fun and holding hands. He wants to experience the same feeling himself, and looks for someone to hold his hand, but there is nobody else, so he tries to hold his own hand. It’s sad, because it doesn’t work: he can’t connect with himself in that way. However, we, the audience, empathize with him, because we have the distance needed to establish that kind of connection. Additionally, we see him empathizing with the human characters he sees in the screen, and his own empathy opens the door for our own.

Games have a special challenge because we are often controlling the character that the writers want us to empathize with, and like Wall-E holding his own hand, it just doesn’t work. We don’t have distance. They try to establish this distance through cutscenes, but that is usually clumsy, and not very effective -- we need more real-time and in-game tools to enable empathy.

So how do we create an empathetic NPC? We need them to have goals and personality and all of the other characteristics of an actual character, no matter how simple. In Skyward Sword, there is a shopkeeper that bounces excitedly and claps his hands as you approach, eager to make a sale. If you walk away, he slumps down, defeated, and slowly trudges back to his bench. Two animations, and a state change, and we have a more empathetic NPC than most!

Similarly, the Big Daddies in Bioshock are usually peaceful, but they become enraged if you mess with the little sisters, and that is enough to make them somewhat successful as empathetic NPCs. A common misunderstanding is that we have to understand why an emotion is being felt in order to empathize with it. That is irrelevant! It’s the emotion itself that we respond to, and the transitions between them. If someone is happy and then receives a phone call, and suddenly breaks down in tears -- we can empathize. The words themselves are not important. Characters, emotions, and transitions are the keys to empathy, not plot details.

Instead of focusing on plot points, we should focus on showing character through transitions. If a character is going from A to B, the interesting part is how they move -- not necessarily where they are going or where they are coming from. Do they go in a straight line at a uniform speed? Do they zigzag around, and get lost? Do they stop at each point to take in the sights?

So we’ve discussed NPCs a bit, but what about the player character itself? How do we achieve the distance we need for empathy? One technique is to restrict the choices of the player so that they match the choices of the character. In Metal Gear Solid 4, there are key moments where Snake (and the player) has no choice, such as this scene where he must move through a microwave hallway, while being slowly cooked alive. The plot itself might be ridiculous (why would anyone ever build a microwave hallway, let alone enter one?), but we can empathize with his pain, and with the act of sacrifice for a greater cause.

This confusion about the importance of plot results in games that have far too many words. In games, characters tend to have conversations, where they exchange facts. In good stories, conversation is rare, instead there are negotiations: exchanges of power. The words themselves are not important for good acting. Dialogue itself is very often redundant, unnecessary, and unneeded. Again, Wall-E very effectively established empathetic characters and dramatic scenes without any words at all for the most part. Shadow of the Colossus wordlessly created a strong relationship between the player and his horse just through time and cooperation.

Games tend to rely heavily on the techniques of film, and ignore the tools that are unique to their own medium. One such tool is “adrenaline moments”, putting the player in a situation that is important to their future. This is not possible in games that rely heavily on authored moments, because the experience is not unique, and there is only one possible outcome. However, mechanics and systems can allow for adrenaline moments that are unique to each player, like if you spy a creeper in your carefully-built Minecraft house, or a swarm of zombies in Day Z. We need to start crafting better scenarios that are appopriate for games if we want to achieve meaningful, empathetic performances -- it doesn’t matter how skillfully we craft animations if they are undermined by the context.

There was a lot more, but that’s the best I can do from memory of this talk. Sorry to Ed Hook and Mike Jungbluth if I misrepresented your content! This was the last talk of the animation bootcamp, but I’m really looking forward to the next one. If the stars align, I might even be able to participate myself somehow, maybe discussing practical uses for procedural and physics-based animation techniques.

Giving Purpose to 1st Person Animation

Ryan Duffin, Senior Animator, EA/Danger Close

Ryan has animated games since 2001, including first-person weapon animation for Battlefield 3, Killzone 2, and Medal of Honor: Warfighter.

He began by demonstrating how first-person animations look in third-person, showing footage from games like Mirror’s Edge and Dead Island. They look bizarre, with very little center-of-mass movement, and cartoony, spider-like arm movements. However, that is perfectly acceptable, because it looks great in first person, and that’s what the player sees! Animations that look good in third-person typically do not work in first-person. They are heavily distorted by perspective, low detail, and poorly staged. We almost always need very different animations for first person and for third person.

The first-person view is all about giving the player feedback -- communicating which weapon is equipped, which weapons are more or less powerful, what you are doing with them, whether they are ready to fire. Like the rest of the HUD, the first-person animations are the window through which the player views the world. They must be communicative as well as visually pleasing. You can think of the different first-person elements as actors on a stage, and figure out how to block them to be most visible and communicative to the player, while occluding as little of the game world as possible.

When experimenting with gun placement for Medal of Honor: Warfighter, and surveying gun placement in other games, he found that the most pleasing weapon location corresponded to the spiral formed by the Golden Ratio as applied to the screen. By lining up all the game’s weapons according to this rule, he achieved a consistent and intentional look, instead of just placing them arbitrarily on the screen.

The first person view can be used to convey feelings as well, such as pain, strain, exertion and weight. For example, the scene in Bioshock where the player character first encounters plasmids is conveyed mostly through the first-person hand animations. Similarly, the pain animations in Far Cry 2 and 3 really emphasize the damage that the player is receiving, and discourage the player from getting injured. The faces in Wolfenstein and Doom are early examples of this idea.

Modern shooters often tweak the timing details of first-person animations to convey subtle differences between the weight and handling of different weapons. They have different “aim down sights” timing, reload timing, weapon switch timing, and movement speed multipliers. Different weapon quality can also affect timing, so an old rusty gun might be more difficult to reload than a new, well-maintained one. A skilled marine might also reload in one fluid motion, while an untrained civilian might fumble and take longer.

Reference is key for believability and accuracy -- you should never make something unrealistic by accident! Know the rules so that you break them with intention. How does a gun work? Keep track of when a bullet is already in the gun’s chamber, whether your character is using good trigger discipline, where your magazines are coming from. In Battlefield 3 they tried to increase the realism of reloading by adding vest foley sound effects when the player retrieves new magazines.

Sometimes you really do have to break the rules though. The highest priority is to show the player what is happening, so everything has to be in front of the camera. Nobody would really reload right in front of their face like that, and the first-person camera FOV would not be able to see a weapon that is fired from the hip, but we have to compromise on realism to keep all the important action on screen.

There are special technical challenges when creating a rig for first-person animation, because objects are switching ‘spaces’ so often. They are frequently attached and detached from hands, guns, and the player’s body. The rig must be set up so this can happen smoothly and freely, so a pin can start out attached to a grenade, then be pulled out by the left hand, and finally discarded into world space as a physics object. Similarly, world-space objects must have the ability to interact with the first-person view, like if a dog jumps out and latches onto your arm for a QTE, or an enemy player stabs you in the face with an assassination animation.

It is also possible to animate the camera itself as part of first-person animations. You must be careful with these effects so you don’t induce motion sickness, but it can be really useful as punctuation for forceful animations. You can jar the screen to the slide slightly as you ram a magazine home, or shake and roll it around to simulate the massive recoil of a .50 cal rifle shot. Camera movement interferes with aiming, so it’s best to save disruptive effects for when the player can’t aim anyway, such as when reloading, striking with a melee weapon, or sprinting.

What about first-person body awareness, so you can look down and see your legs? There are several approaches to this, but usually you will need a special system that works similarly to the third-person character animation, but has special animations adapted to first-person. It’s possible to avoid this issue by only showing the legs when needed, such as the kick in Duke Nukem 3D, or the Strogg transformation in Quake 4. There are also special details to watch out for, such as shadows. You don’t want to use the actual first-person animations for shadows, because they look weird in third-person, but you also need the shadows to line up nicely with the first-person legs.

I hoped you liked this summary! The last one is all about the big picture, how to create context that allows for meaningful animations.

In this series of posts, I summarize my takeaways from some of the GDC 2013 sessions for anyone who couldn’t be there, starting with the animation bootcamp sessions on the first day. These are reconstructed from notes and memory, and may not exactly match what the speakers said.

Animating the 3rd Assassin

Jonathan Cooper, Animation Director, Ubisoft Montreal

Jonathan has been animating games for 13 years, including lead roles on Mass Effect 1 & 2, Deus Ex: Human Revolution, and Assassin’s Creed 3, and recently won the DICE award for “Outstanding Achievement in Animation”.

What is Assassin’s Creed? It was originally going to be a new Prince of Persia game, but ended up becoming its own IP, focusing on efficient parkour movements through realistic environments instead of flashy freerunning stunts through designed puzzles. The movement of the assassin is meant to be practical and smooth, with no interruptions from backflips or other tricks.

Every Ubisoft game is pitched to the executives using a 7-minute “target video” showing how the game would look in action, so they put together a video demonstrating the key features they wanted in Assassin’s Creed 3 -- such as tree navigation, rope darts, and deep snow. It ended up being greenlit, but the executives said the assassin in the video was too light and airy. They wanted him to feel heavier and tougher, so that was one of the major animation challenges this time around.

They created many thumbnails and character concepts to figure out how this stronger assassin should look. They decided to remove a lot of the armor and other extra clothing that the old assassins wore, and replace it with muscle mass, giving him a broader, but more streamlined look. He has new animations to make his movements look like they use more effort -- in particular, he has a “sprint propulsion” animation at the beginning of every run which emphasizes how much effort he puts into overcoming his significant inertia.

His attacks and assassinations have more follow-through to show how powerful they are, which at first made them seem less responsive. The team solved this problem with a brute force approach, by animating every possible transition in advance. For example, there is one assassination that starts with a jump off a box, and then ends with a run to the right. Or another that starts with a walking approach from behind, and ends with a walk to the left. It all added up to hundreds of animations just for the wrist-blade assassination move, in a detailed matrix including all the possible start and end states.

Many of the animation problems were solved with similar parametric matrices to blend between a large set of animations. For example, there were many jump animations for different heights and distances, and the system would interpolate between the closest ones for any particular jump. They even used pneumatic jump pad to physically launch stuntmen into the air for various heights and distances, and used those performances as mocap foundations to add more believability to the jump animations.

The technical animation team experimented with many different physics-based and procedural animation techniques, but most of them were rejected -- they created this odd effect in which the characters mindlessly react to the environment, and never anticipate anything. They ended up only using a few procedural effects. Here are two examples: First, there is a detailed lean and foot-placement system for turning while running, which was created procedurally, and then fine-tuned by comparing it to real motion capture data. Second, Assassin’s Creed games have always used IK for the detailed hand and foot placement in climbing, but now there is an additional procedural layer for overall body movement, used for reacting to jumps and landings.

One of the most important secrets of assassin’s creed animation has always been the secondary animation -- such as the cloth simulation on the cape, and the spring physics on the bits of equipment attached to the character. Since these items are driven by the physics system instead of directly keyframed in the animations, they really help smooth out animation transitions and increase the perceived fidelity of the game’s animation. That is why the animation in the assassin levels looks smoother and more detailed than the animation in the Desmond levels.

The force of the new assassin’s attacks is also communicated through the camera: each finishing move has an associated camera animation, which is applied when defeating the last enemy in a group. This allows for close-ups on enemy faces as they die, and impacts reinforced with camera movements. The combat camera is much closer in general, dynamically zooming in and out to be as close as it can possibly be without leaving important enemies out of the frame.

He demonstrated the combat animation process in detail, showing how the actors act out the basic movements, but the curves are all wrong because they don’t actually want to hit each other or move at a dangerous speed. The mocap data is then heavily modified by hand to emphasize impacts, ensure that blows actually connect, and generally increase the speed and energy level.

The non-interactive cinematics were recorded using full performance capture -- that is, simultaneous face, body and voice recording, as popularized by Avatar. As Simon mentioned, mocap is just a starting point for the animation team, but the simultaneous recording is really valuable for getting a natural performance from the actors. With the face cameras, the actors are more confident that details of their facial expressions and body language will be conveyed, so they don’t feel the need to exaggerate as much, or use cartoonish voice inflection.

The talk ended with a demo reel of animation from Assassin’s Creed 3, along with text conveying the sheer quantity of animations of each type. The assassin has 330 jump animations, 220 basic locomotion animations, 280 climbing animations, 210 new assassinations, and 3200 fight animations. There are 3400 crowd animations, and 3000 animal animations! Each animal had its own set of parkour moves so it could follow the player around in the environment, including bears, wolves, foxes, deer, and so on. There were 50 animators and animation coders on the project.

I hoped you liked this summary! The next one will be all about first-person animation.

In this series of posts, I summarize my takeaways from some of the GDC 2013 sessions for anyone who couldn’t be there, starting with the animation bootcamp sessions on the first day. These are reconstructed from notes and memory, and may not exactly match what the speakers said.

How to Get the Most Out of Your Mocap

Simon Unger, Animation Director, Hitman:Absolution

Simon was animation director for the latest Hitman game, which won several prestigious animation awards. Before that role, he spent nine years animating various titles at Electronic Arts, including MVP Baseball 2005.

He started by pointing out that motion capture is often perceived as a completely automated process -- a notion reinforced by public figures like James Cameron and Andy Serkis who emphasize the primacy of the actor’s performance, and describe performance capture as just a form of “digital makeup”. This is completely inaccurate! Mocap is just a starting point for animators to work from. Avatar credits twice as many animators as Toy Story, so there was clearly a lot of keyframing going on.

Motion capture has a long history in animation -- it used to be known as ‘rotoscoping’, and was performed by tracing performances from physical movie frames for realistic characters, such as Snow White in Disney’s 1937 film. Animators have traditionally frowned upon this practice because it looks cheap and lacks appeal. It lacks the punch and intentionality of good keyframe animation, and lacks the subtlety of live action, so it is the worst of both worlds. Even in 2D it runs into the “uncanny valley” problem, where it looks almost real, but a little bit “off” in a zombie-like way.

What we want in animation is a believable performance, which is not the same thing as a realistic performance. Animated films like Wreck-it Ralph and Finding Nemo both deliver much more believable performances than many photorealistic mocap scenes, or even live-action films for that matter.

So, why use mocap at all if it has all these problems? It’s a great productivity tool! If used as a starting point, instead of an endpoint, we can achieve the same quality as keyframing in half the time. Without this valuable productivity tool, the quantity of animations seen in many modern games would just not be possible. He then summarized some best practices and common mistakes for setting up mocap shoots.

1: Preparation

You need a very detailed shot list in advance, specifying the output filenames, detailed description of the action, number of actors, approximate duration, in/out movement direction, and so on. It should be so detailed that the shot could theoretically take place even without the director present. Storyboards and animatics can also help a lot, so that the actors know where the camera will be, and what the context is for the scene. Also, make sure to handle all of the practical details in advance, like catering, suit sizing, and so on -- stage time is expensive, don’t waste it!

2: Breaking down a script

Dividing a script into individual shots can be challenging, especially if the actors can’t all make it to the shoot at the same time. In this case, it’s really helpful to have one or two “utility” actors who can stand-in for anyone who is missing, so that the cast actors have someone to act against. With this trick, you can record the same scene multiple times with different parts of the cast, and then combine the best performances later.

3: Have an experienced director

A lot of studios use an arbitrary team member as a director, who may or may not have experience working with actors. Don’t do this! Mocap studios will usually have a decent director on call, or you could even use a voiceover director -- just get someone who has worked with actors before and knows how to get the best performance out of them.

4: Combat and stunts

Hire professional stunt people and choreographers, and have a detailed list of movements and references so you can communicate exactly what you want. This is mocap, not film or tv, so avoid the bad habits that might come from those media. Don’t pull punches! Wear armor instead, or hit padded props -- contacts can easily be fixed in post, but you need to capture the real movement and transfer of force.

5: Casting

Don’t just use random members of the development team! You can hire actors from acting guilds, and voice actors also work surprisingly well. You can even get people from local theatre or dance groups. They actually work better than film and tv actors in some cases: they don’t have those habits that are helpful for live-action but harmful for mocap. Celebrities are expensive, and extra-expensive if you want to include their likeness as well as their performance.

6: Rehearsals

Rehearse! This seems obvious, but is actually surprisingly rare. You are paying a lot of money just to be on the mocap stage, so don’t waste time and money and quality by rehearsing on stage. So, rehearse ahead of time! Do script readings, build chemistry between the actors, help the cast get in character. This can greatly increase the quality of the performance.

7: Context

Mark out the sets ahead of time: mark the dimensions of different game spaces using tape, and bring in physical sets for anything the actors need to interact with, like ledges, stairs, or walls. Make sure the actors know what kind of space they are in, so they can react to it, and use the appropriate speaking voice for the room size, and so on. Create appropriate props as needed for physical objects like guns, focusing on accurate weight -- it’s relatively easy to correct sizes in post, but it’s difficult to make a sword or gun look heavy if the actor was just carrying a cardboard tube.

8: PPP - Punctuality, Positivity, Professionalism

These are basics for shooting any scene in any medium. Always show up on time! If critical people are missing, then you’re burning up time, money and morale. Make sure to maintain a positive atmosphere on the stage: never make the the talent feel like they screwed up, make them feel like you are just looking for ways to make their performance even more awesome. Show that you are taking the whole endeavour seriously, so that the talent and mocap crew take it seriously as well.

Finally, he emphasized once again that mocap is a productivity tool, and not an endpoint. The performance you capture always starts out looking flat and weightless, with no animation appeal -- you need another pass to apply proper animation principles, worrying about silhouettes, arcs, speed, and so on. Mocap also tends to miss subtle movements, such as raising or lowering of the collarbone, so that needs to be added in by hand as well. Sometimes you have to go in deeper, and redo a whole arm movement or even a whole animation by hand.

However, overall it can double your animation productivity if you follow all these best practices, which is a huge win. Just don’t go in thinking it’s a magic bullet!

Someone asked about outsourcing animation, and the answer was that it’s entirely possible to outsource cinematics, but it’s not really possible to outsource gameplay animation, since it requires so much iteration. There is a very slow feedback loop when iterating with an outsourcing company, so it’s much more practical to do gameplay animation in house.

I hoped you liked this summary! Most of the Hitman mocap images in this blog post are from this related video. The next summary will be about animation in Assassin’s Creed 3!

In this series of posts, I summarize my takeaways from some of the GDC 2013 sessions for anyone who couldn’t be there, starting with the animation bootcamp sessions on the first day. These are reconstructed from notes and memory, and may not exactly match what the speakers said.

Developing Animal/Creature Movement

Amy Drobeck, Senior Animator, WB Seattle

Amy worked on creature animation for many years, including 9 years at Disney, and 6 years at Snowblind Studios. She loves animals and loves animation, so this is her dream job! Here is a summary of the advice that she gave about animating creatures.

First, start by watching animals in real life at zoos or wildlife rescue centers -- draw them, animate them, be nearby to them and see what it feels like, so you can emphasize that feeling in your work. Try sketching them and simplifying them to the most important shapes, and capture their movements, expressions and attitude.

If you spend a lot of time with domestic animals like dogs, cats, and horses, you can start to read and understand their body language, and know how they act and react to different situations. You can also try to understand animal perspectives by entering non-human worlds by sky diving or scuba diving.

Comparative anatomy is critical as well -- understanding how animals are different from humans and how they are similar. Most mammals are constructed very similarly. People think dog legs bend backwards, but really they just walk on their toes. Hooves are nothing too different either, they are essentially just fused toes. There are a couple important differences, though: quadrupeds tend to have more vertical rib cages while humans have more horizontal, and most of them don’t have collarbones. She showed a video of a horse that had its skeleton drawn on its side to demonstrate its anatomy:

In practice, you want to have a much simpler rig, both for technical performance and for ease of use. For example, the torso of a horse is actually quite solid -- instead of a bendy spine, just use one bone for the ribcage and one bone for the hips. It’s a much better use of resources to put those bones in the neck, which is much more expressive.

Her recent work was focused on animating the giant eagles in a LOTR game, which was a special challenge. Wings tend to look strange when they fold up in a game, so they added a mass of feathers at the “shoulder blade” to cover up any unattractive compression of the wing itself, while revealing the detailed individual flight feathers. With a rigid beak, she also had to find new ways to show facial expressions, focusing on the cheeks, eyes, and mouth corners.

It is also important to study the different kinds of animal gaits, such as walks, trots, and gallops. Gallops come in two varieties: transverse and rotary. A transverse gallop only leaves the ground at one point, while a rotary gallop leaves the ground twice (this looks like a decent site to learn more about gaits).

Normal character animation principles still apply, of course. In many cases you can take the body posture and silhouette of a human pose, and try to map it to the animal silhouette to achieve the same effect. She didn’t mention it explicitly, but showed some sketches that appeared to be from the Disney Sword in the Stone movie, which has a lot of scenes starring Merlin and Arthur in animal form, such as fish and squirrels:

For facial expressions, you can also focus on emulating human-like expressions with whatever tools you have in the animal face, even if there are difficult constraints like a beak or muzzle. She pointed out that with animal characters there is a lot more leeway for animating them with a realistic rendering style without running into the “uncanny valley” issue, especially with facial expressions and lipsync. We don’t usually see talking animals, so we’re not as sensitive if something is not quite right!

I hoped you liked this summary! The next one is all about performance capture, and how to do it right.

In this series of posts, I will summarize my takeaways from some of the GDC 2013 sessions for anyone who couldn’t be there, starting with the animation bootcamp sessions on the first day. These are reconstructed from notes and memory, and may not exactly match what the speakers said.

Making an audience believe

Jalil Sadool, Senior Animator, Dreamworks

Jalil has a long and impressive history in animation and visual effects -- some of his recent work includes working as a senior animator at WETA on Avatar, and animating the lead character (Jack Frost) in Dreamworks’ Rise of the Guardians.

He started by pointing out that the most important principle of animation is appeal. Does the performance look good? Does it inspire empathy in the audience? He outlined two paths to studying appeal:

A. Study great actors in their greatest performances. How do they move? How do they convey what they are thinking and feeling? Their performances are not just believable, but also communicative, and appealing. He gave an example from The Godfather, showing Marlon Brando’s character making a decision to deny a request. We can see him reach his decision long before he says it. He also gave an example from Tinker Tailor Soldier Spy, showing the importance of eye contact and avoidance, physical postures and leaning, pauses for thought and building up the courage to say something. A final example from Anatomy of a Murder shows confidence, comfort, power -- how the body and face show dialogue BEFORE it is said, as sure as lightning comes before thunder.

B. Study how people move in real life. Film them candidly, but try not to be creepy about it. He demonstrated some examples of interesting references that he filmed, including a lady in an animated conversation who performed more than twenty distinct hand gestures, and a man who looked like he was sleeping on a bench, except for his hand movements which showed that he was thinking carefully about something important. He came to a decision, brushed off his pants, stood up and walked briskly away. By taking novel films of candid movement, you can accumulate a collection of interesting motions that nobody has ever animated before.

The first step in animation is often acting out the scene yourself, and using that video as reference for keyframing. Why not mocap? Dreamworks does have a mocap stage that they use in previz to help block out ensemble scenes and camera moves, but since mocap is so much work to clean up and tweak anyway, it really comes down to a stylistic decision. At WETA they used a lot of mocap, but at Dreamworks they prefer to use keyframes.

He emphasized that when you act out your scene for reference, it’s the expression and movement of the body and face that is important -- the words in the script are irrelevant. In fact, he prefers to NOT play the recorded voiceover in the background when he acts out the scene, because that encourages reacting to the audio, instead of proactively performing the thoughts and intent of the character. He also tries to put the camera at roughly the same angle it will be in the final shot, because staging is really critical. A great performance is useless if it doesn’t read from the angle that the audience sees it from!

By recording lots and lots of takes this way, he can mix and match the best parts of each take, even using a nice hand movement from one take with a thoughtful head movement from another. Then he tweaks and refines and emphasizes the movement, until it is up to the quality that he wants, or has time for. The keyframe/reference process also makes it easier to take feedback from the directors -- he showed some shots through several iterations, such as a shot where Jack Frost is tumbling through the air, which he emphasized by integrating some reference footage of him waving his arms while balancing on a small box.

Questions!

Q: How do they get reference for actions that they can’t perform themselves, like acrobatic moves or martial arts?

A: Youtube! One of the characters had a shot where he spun a sword around in a dramatic flourish, and they just based that on a movement from the Batman Begins trailer.

Q: How do you handle shots with two characters in the same scene, if each character is animated by a specific animator?

A: One animator blocks out the scene, and then they keep sending the scene files back and forth and collaborating on the performance. It’s useful to have different animators for each character because it helps make their movements more distinct.

Q: How do you handle lipsync reference?

A: Record it from two perspectives: one from the front, and one from the camera angle. The front is useful for getting the basic movement, and the camera angle ensures that it reads for the audience.

I hope you all liked this summary; I will aim to post a new one every day until I've covered all of the animation sessions. The next one is about animating animals and other non-human creatures!

This is a guest post from Aaron Jacobs, one of the masterminds behind the essential SUMLauncher!

Hello! I’m Aaron Jacobs, the programmer for SUMLauncher, which is a tool designed to make management of an Overgrowth preorder as easy as possible. A few days ago we put out an update to SUMLauncher that we’ve been working on for a few months now.

Watch it in HD here

I’ve wanted to get into games programming ever since I started playing around with Halo PC mods in middle school. Sometime around 2008, a friend of mine introduced me to Lugaru, and its then in-development sequel, Lugaru 2. The game that eventually became Overgrowth caught my attention with its open development process. After I began pursuing a computer science degree, I found myself wanting to contribute to the Overgrowth community. A programming project seemed like a natural choice.

Anton Riehl had developed a mod for the main menu that could be used to run community made maps, but using it required downloading and copying in files manually. I wrote a tool that would recursively download all the files and automatically set up Anton’s Menu Mod.

The Custom Map Auto Downloader was extremely simplistic in its design, but it was a good first project for me. It was satisfying to make a tool that people found useful, and I wanted to work on another project. I figured that a tool to automatically download and install updates to the Overgrowth alphas would be a good way to go. While I was working on the initial version of the program, Anton discussed ideas for a more comprehensive set of content tools with several other people (including prominent community member, Johannes). We decided to work together on this idea, now called the SUM OG Utilities (Settings, Updates, and Mods Overgrowth Utilities), which would start with version 1 of what is now called SUMLauncher.

SUMLauncher was also well received, though it had many bugs initially. The positive feedback I received was a huge motivation to work on it though, and I found myself dedicating a lot of free time to improving it. Through this process I gained valuable programming experience and found myself dissatisfied with the quality of my old code. For this reason I did a massive rewrite, which became SUMLauncher version 2. I continued iterating and updating SUMLauncher, working on responding to feedback from the Overgrowth community about changes to implement.

During this time Anton had been continually adding content to the Menu Mod. It began to grow quite large, and the flaws of the simple design of the Custom Map Auto Downloader were increasingly apparent. We decided to build a much more robust system to replace the Menu Mod, and I eagerly got to work implementing it, using an interface Johannes mocked up. The project proved to be more complex than I was anticipating, and once my college classes started up I had little time to work on it. Migrating all the content over to the new system was a bit of a daunting task, as each item had to be modified to fit the new system and manually added to our content database. Luckily, Anton had a vast knowledge of all the community content present in the Menu Mod, and was able to guide the conversion process as he, my brother Joshua, and I worked to prepare the new system.

At this point SUMLauncher is a fairly mature and robust tool for managing an Overgrowth installation, with many useful features for preorderers, including:

• Updating Overgrowth alphas
• Performing clean Overgrowth installations
• A graphical tool for modifying Overgrowth’s configuration file
• A Twitter-based news feed
• Clearing the cache and other game files
• Installing community content
• Cross-platform support

SUMLauncher can be downloaded from the Secret Preorder Forum, which can be accessed by Overgrowth preorderers after their accounts have been linked.

We have put significant time and thought into SUMLauncher, but there is always room to improve - we would love to hear your feedback! What changes or additions would you like to see in SUMLauncher?

Here is the new Overgrowth video!

Don't forget that you can help support us, try out our alphas, and chat with other preorderers in the Secret Preorder Forum by preordering Overgrowth. If you'd like to see real-time news about Overgrowth, you can follow me on Twitter at @wolfire.

document.getElementById('hs-youtube-jZK_O1M8PQY').outerHTML = "\x3Ciframe width='520' height='381' allowtransparency scrolling='no' frameBorder='0' style='border:none;' src='http://www.humblebundle.com/store/video/overgrowth?youtubeid=jZK_O1M8PQY'\x3E\x3C/iframe\x3E"
Be sure to watch it in HD!

Thanks as always for all the support! See you guys in IRC and the forums.

If you liked this video, be sure to subscribe to our YouTube channel.

Also, feel free to support us by preordering Overgrowth!

This is a blog post adaption of my GDC 2013 Indie Soapbox talk, I hope you like it! I will link to the GDC vault video of it if it becomes publicly available.

Working with technology can be intimidating as an indie developer. Isn’t tech the domain of AAA? How can we compete with their large teams of experienced and talented engineers? Any one of them is probably at least as skilled at programming as we are, and there are so many of them working together!

The secret is that we don’t have to compete with them, because their process adds so much inertia. With such large teams and budgets they have to avoid bottlenecks that might stall the content pipeline, and need to minimize uncertainty about meeting development milestones. The most efficient way to accomplish that is to make sure that the departments can all work perfectly in parallel, with minimal need for communication, so design doesn’t stall tech, and tech doesn’t stall content. This works well from a scheduling and budgeting perspective, but restricts engineers to side-effect-free technology like optimization and iteration.

This approach encourages technical innovation at the periphery of the game design, instead of at the center where it would make the most difference. For example, there has been a lot of brilliant technical innovation in the Halo series that set new benchmarks for visual fidelity. However, the design of Halo is all about shooting aliens in 30-second skirmishes. It’s not about taking in the sights! All of this iteration on rendering technology and art asset creation certainly improves the experience slightly, but not nearly as much as if the technical innovations were closer to the heart of the game design.

On the other hand, indie games don’t usually have large teams or hard deadlines. We can work more serially, allowing design and technology to inform one another very closely. Antichamber has really clever technical sleight-of-hand to give the impression of non-Euclidean space, and the design is all about exploring that space. Spelunky has solid procedural level creation technology that makes sure that the game is fun to play over and over, and the design is all about mastering the rules of each environment by repeatedly failing and trying again. In both games, the technology is at the very heart of the design, and greatly elevates the player experience.

That’s not to say that graphics technology is worthless, it’s just most effective when the design takes advantage of it. In Journey, the sense of awe, beauty, and immersion is critical to the game design, and it would have been difficult to achieve that without their unique sand and cloth rendering technology (one of the programmers explains their sand tech here and here). If you remove those technologies, the game would not just have a quantitative decrease in visual fidelity, but a major qualitative change as well -- it would not be the same experience at all.

Gamers are always excited to see new technology that is central to design. When Alex Austin posted this video demonstrating physics-based infantry movement in A New Zero, people didn’t really care that it didn’t have very high visual fidelity; they were just excited to see a more embodied approach to movement in a first-person shooter! That’s how it achieved almost 500,000 views on Youtube without any promotion at all.

I sometimes encounter the idea that technology is a natural enemy of design -- that the purest form of design is found in board games, using cards, dice and tokens. This doesn’t make sense to me, because those tools are all technology themselves, and they clearly expand the design space instead of restricting it! The dice enable randomness, the tokens enable stored information outside the players’ heads, and the cards enable hidden information. Why shouldn’t digital technology expand the design space in the same way?

Consider this visualization of the design space, where distance from the center represents use of new technology. At the center is a dense cluster of games that do not rely on much new technology at all -- they focus on design and content using mostly existing technology. It’s certainly possible to create excellent games this way, and there are many examples, but most of them are by design specialists: developers who have created dozens and dozens of games over the years, often in game jams or prototypes.

The AAA teams take a different approach. They more or less use an existing design (or, rarely, start a new franchise with a novel design) and then use sequels to compete with one other in a technological arms race, moving outwards from the low-tech cluster in straight lines. There’s one line for third-person cover shooters with regenerating health, one line for open-world games with linear quests, and one line for third-person brawlers with quick time events.

The part of this diagram that I’m interested in is the space between these lines, where there is just emptiness. If you follow these lines partway out, and then take a sharp turn to the left or right, you end up with a game like Amnesia, or Overgrowth, or Natural Selection 2. These games sort of look like a AAA game, but have major differences in their design, so they really have no direct competition. There aren’t really any other asymmetric FPS/RTS hybrids, or any other physics-based tactical martial arts games.

If you take this idea farther, you can end up with something like Minecraft, or Flower, or Proteus: games that are so far from any existing genres that people debate if they are even games at all. It really doesn’t matter though, because gamers love them, and they are very successful by any measure!

I would like to encourage indie developers to consider using technology to explore all of this unmapped design space. The AAA guys are likely to continue iterating outwards on their straight lines, and there’s really nobody else to turn to: if we don’t explore this space ourselves, it will simply never be explored.

In this Overgrowth Art Asset Overview, I show off the new arena I'm working on and talk a bit about the process of making it. I'm pretty excited with where we're at with Overgrowth, and I'm especially happy that there are no major hurdles in sight for us getting the game to beta.

The Game Developer Conference is happening this week here in San Francisco, so there are a lot of cool people and indie friends in town showing off their latest projects. I'm going to be giving a talk at Lost Levels, which I think is going to be one of the most interesting parts of GDC this year. It's free, so come check it out if you get a chance! If you have an IGS pass, you can also check out David's talk as part of the Indie Soapbox.

Be sure to watch it in HD!

Next time I will talk a bit about 2d/3d integration, and why I think it will be useful for Overgrowth. Follow our Twitter feed at @wolfire for realtime updates!

Here is the new Overgrowth alpha video!

Don't forget that you can help support us, try out our alphas (such as the one in the video), and chat with other preorderers in the Secret Preorder Forum by preordering Overgrowth. If you'd like to see real-time news about Overgrowth, you can follow me on Twitter at @wolfire.

document.getElementById('hs-youtube-ZoWa3Z_w99s').outerHTML = "\x3Ciframe width='520' height='381' allowtransparency scrolling='no' frameBorder='0' style='border:none;' src='http://www.humblebundle.com/store/video/overgrowth?youtubeid=ZoWa3Z_w99s'\x3E\x3C/iframe\x3E"
Be sure to watch it in HD!

The features highlighted in the above video are as follows (as well as some that didn't make it into the video):

• Added audience excitement system based on combat events
• Added combat event system so level script can query what is happening
• Added crowd sound that changes based on excitement
• Added script support for looping sounds, and pitch/gain shifting
• Added Elo-inspired player skill ranking and win-probability system
• Added initial intro and outro text for arena career matches
• Added new scriptable Freetype text rendering
• Scroll wheel selection for objects under mouse wheel
• Whoosh sound for missed or dodged attacks
• Fixed problem with weapon sheathing on Linux
• Tweaked jump animation
• Improved camera rotation at level start
• Fixed level editor decal-only or object-only selection
• Improved performance and accuracy of decal projection
• Fixed problem with splitscreen mode persisting in editor mode

Thanks as always for all the support! See you guys in IRC and the forums.

If you liked this video, be sure to subscribe to our YouTube channel.

Also, feel free to support us by preordering Overgrowth!

I was just working on some text rendering for the arena intro and outro (which should be in tomorrow’s alpha video), and thought I would share how we handle that problem in Overgrowth. Almost every game uses text of some kind, but since most indie game programmers are not typography experts, there are a number of pitfalls that we run into. Here’s an example of some text in Lugaru which demonstrates almost all of them!

The most obvious problem here is that character spacing does not line up with character size. This is because it uses a text atlas (an image that contains every character that the game might use) that doesn’t contain any information about how wide each character should be. The text atlas also stores each character at a fixed size, so it becomes blurry when scaled. Here’s a scaled-up version of this bitmap text (above), compared to how the text ought to look (below).

In the years since releasing Lugaru, many free bitmap text atlas tools have appeared, which make it a lot easier to solve the character spacing issue. However, any text atlas will still result in fuzzy text if we scale it (even just reducing size by 1%), rotate it, or translate it (except if it is clamped to the nearest pixel). In Overgrowth, we solve these problems by avoiding text atlases entirely, and rasterizing text directly to a 1:1 image using the Freetype library, or using Awesomium (an embedded web browser).

The key to rendering high quality text is to rasterize it (convert it to pixels) as late as possible. Internally, fonts contain a combination of bitmaps, complex vector graphics and ‘hinting’ rules, which form an intricate system that determines how the font can be rendered to screen pixels in the best possible way, at a given size, scale, and style. When we rasterize fonts to a bitmap, all of this information is removed, and all that remains is a mindless array of pixels. This is perfect if we just want to copy these pixels directly to the screen somewhere, but any other kind of manipulation at this point will significantly degrade quality. Here’s a picture of text rotated after rasterizing (left), compared to text rotated before rasterizing (right).

One aspect of text rendering is really counter-intuitive to graphics programmers. Normally if we draw an image at a huge size, and then scale it down to fit the screen, it will have much higher quality because of all the sub-pixel information that we have added. This is not true for fonts! This is because the font hinting rules are specifically designed to render to particular pixels for maximum sharpness, and supersampling loses all of this information. Here is a comparison between Photoshop’s supersampled text (above) and Overgrowth’s text rasterized with Freetype (below). The difference is subtle, but look at the vertical components of the ‘d’ and ‘u’ characters.

So, if you would like the highest quality text in a game, I think the best solution is to use the Freetype library to directly render the text to a bitmap when needed, and then cache that bitmap to a texture for display. That is essentially how every other application and operating system does it, and I don’t see any reason why games should be the exception. Do you have any other ideas about how to improve text rendering, or any problems with this method? Please let me know in the comments!

Update 1: Signed distance fields are a really cool idea for preserving sharp edges when up-scaling fonts, but it still loses information, so it's better to just use the font itself if performance allows. Here is a demonstration of the distortion that we can get using a signed distance field: image link. We can reduce the problem by using multiple fields, but it can never look quite as nice as just rasterizing the font normally. However, if it's really necessary to up-scale a low-res vector bitmap, this is definitely the way to go!

Update 2: Text atlases can still be a useful optimization, if text rasterization turns out to be a bottleneck. It's probably wise to try the simple solution and profile, though, before assuming that an atlas is needed. When using an atlas, we just have to make sure that the atlas itself is rasterized properly, and for maximum quality, have to make sure it's copied to the screen at 1:1 scale, and clamped to the nearest pixel. We might also want to create the atlas on demand for whatever characters and character sizes we will have on the screen, instead of loading a premade texture.

We recently made a charity jam game called Low-Light Combat. In this jam, I wanted to try cutting out the most time-consuming steps of the traditional art asset workflow, to see if it would make any real difference in the final product.

Because there were a lot of textured 3D models, I spent the majority of my time editing UV texture coordinates. This allowed me to discover which UV techniques are most efficient for different models, or even parts of a model, and become comfortable switching fluently between them.

Be sure to watch it in HD!

It was a lot of fun to execute these assets because they were so typical -- usually I actively avoid making anything I've seen before in games. However, on some level, it's hard not to enjoy making spaceships, laser-guns and cyberninjas! Even time-honored cliché game fixtures like barrels and crates are gratifying to make because it's so easy, and they can be used to fill up large sections of a level.

A lot of people have asked why we spent that week on this charity game jam instead of Overgrowth. I had not planned to do any jam projects this year, but Mojam was an amazing experience last year, and it was an honor to be one of the few helping Mojang raise money for charity, so we could not really pass up the opportunity to do it again. I would like to thank everyone who watched my Mojam stream; hopefully we will get to play a match together in LLC soon!

If you've preordered Overgrowth, or donated to Mojam 2, then you already have access to the game on your purchase page. If you don't have your purchase email anymore, you can retrieve it using the key resender. Otherwise, for a $5 donation to charity here, you can get Low Light Combat and a couple extra keys so you can play with your friends.

Last week we participated in the Mojam 2 charity drive, and created a stealth deathmatch game called "Low Light Combat". Thanks to everyone who donated, and everyone who cheered us on in the live streams! Here's a video showing the results:

Be sure to watch it in HD!

If you've preordered Overgrowth, or donated to Mojam 2, then you already have access to the game on your purchase page. If you don't have your purchase email anymore, you can retrieve it using the key resender. Otherwise, you can get it for a $5 donation to charity here, along with a couple extra keys so you can play with your friends.

We had even more ambitious plans for the game, with extra levels, narrative, and graphical effects, but netcode ended up taking most of my time. You can expect to see those other plans realized in an update within a few months! For now though, it will be great to get back to Overgrowth arena gameplay.

It's that time of year again and David and Aubrey are live-streaming for charity in the second Mojam game jam for the next 70 hours. Tune in below or on the Humble Bundle Mojam website!

Watch live video from wolfiredavid on www.twitch.tv

Watch live video from wolfireaubrey on www.twitch.tv

To access the games when they are done, all you have to do is pay what you want to the Electronic Frontier Foundation and / or the Block by Block UN-Habitat initiative on the Humble Bundle Mojam website.

Here is the new Overgrowth alpha video!

Don't forget that you can help support us, try out our alphas (such as the one in the video), and chat with other preorderers in the Secret Preorder Forum by preordering Overgrowth. If you'd like to see real-time news about Overgrowth, you can follow me on Twitter at @wolfire.

document.getElementById('hs-youtube-qo_LTa9j2Z4').outerHTML = "\x3Ciframe width='520' height='381' allowtransparency scrolling='no' frameBorder='0' style='border:none;' src='http://www.humblebundle.com/store/video/overgrowth?youtubeid=qo_LTa9j2Z4'\x3E\x3C/iframe\x3E"
Be sure to watch it in HD!

The features highlighted in the above video are as follows (as well as some that didn't make it into the video):

• Added arena level with progressive difficulty
• Added arena level to campaign menu
• Added GPU character skinning
• Scripts can attach items to characters
• Split challenge level and versus mode scripts off from level script
• Level scripts can use string message passing instead of function calls
• Added transparent placeholder objects
• Added placeholder and pathpoint objects to spawner utility tab
• Added alt-drag copy support to connectable objects
• Fixed Mac crash when loading levels with groups
• Fixed Windows zlib.dll issue (error 0xc0150002)
• Fixed Linux SSE memory alignment issue
• Fixed deleting characters during combat
• Fixed shader live update
• Fixed object parameter saving and loading

Thanks as always for all the support! See you guys in IRC and the forums.

If you liked this video, be sure to subscribe to our YouTube channel.

Also, feel free to support us by preordering Overgrowth!

Here are the major changes for Overgrowth alpha 196:

• Removed MSVC 2005 dependencies to fix "side by side configuration" errors
• Fixed all known unicode errors and removed unicode warning
• Fixed Angelscript caches not updating when include files are changed
• Fixed Awesomium keyboard input
• Removed last remaining ODE dependency
• Fixed shader preprocesser issue with baked imposters
• Fixed crash when loading a level that has no script
• Added main menu toggle to config file
• Added mouse sensitivity value to config file
• Progress on placeholder object spawn points and previews
• Completing a challenge level triggers level-end screen again

As you can see this update was mostly about fixing long-standing compatibility issues, as well as any bugs that might have been introduced during the extensive refactoring for alpha 195. This should clear the way for further gameplay progress!

Don't forget that you can help support us, try out our alphas, and chat with other preorderers in the Secret Preorder Forum by preordering Overgrowth. If you'd like to see real-time news about Overgrowth, you can follow me on Twitter at @wolfire.

Here are the major changes for Overgrowth alpha 195:

• Switched build system to use CMake for all platforms
• Made sure all libraries and platforms are compiled with high compiler optimization settings
• Updated Boost, Awesomium, Bullet, TinyXML libraries to the latest version
• Updated build script to use latest compilers for each platform
• Added script bytecode caching (for fast Angelscript loading)
• Fixed morph target caching (for fast character loading)
• New undo system (more maintainable but not optimized yet)
• Wrote new GLSL preprocessor to replace Boost::Wave
• All decals use the 3D manipulation interface
• Added shader for tangent-space normal maps combined with detail maps
• All objects properly free memory when deleted in the editor
• Levels can have their own specific scripts
• Added ‘placeholder’ objects that can be used as reference points for level scripts
• Capped main menu at 60 fps even if VBL sync is disabled
• Fixed problem with character LOD cache
• Fixed problem with slow-motion toggle key

There is no video because these are mostly refactoring and build system changes, but they will make it a lot easier to proceed with new gameplay features!

Don't forget that you can help support us, try out our alphas, and chat with other preorderers in the Secret Preorder Forum by preordering Overgrowth. If you'd like to see real-time news about Overgrowth, you can follow me on Twitter at @wolfire.