Massive Content Generation Techniques In A Valley Without Wind

So!  It’s been less than a week, and a lot has changed.  I’ll start by showing the latest footage of the game:

The reaction to last week’s video and screens was mostly positive, particularly when folks saw shots reflecting the actual in-game resolution, but there were common concerns about the buildings, the character’s running animation, the white borders around some graphics, etc. Well, all those have changed drastically this week, as you can see in the video above.  There are also a whole new batch of screenshots on the AVWW page, replacing the old ones. 

The screenshots have a very slight bit of JPEG distortion — they look crisper in-game — but it’s very near what you’d see. 

Plants, Ground, Sky, Etc
As you can see from the video, the game looks its very best in motion, with all the plants moving around, clouds moving, and so on and so forth — you really get a sense of being outdoors in the wild woods and fields like what I grew up hiking through in North Carolina. That’s not something I’ve seen represented in any other game I’ve played, so that’s exciting to me.

In terms of these aspects, the game is probably about finalized on its style, which I’m excited about.  Now it’s time to really crank out more content and more variety for the plants, to give variety.  Right now it looks cool, but there’s only about 8 different trees and maybe 12 kinds of smaller grasses and bushes, so there’s a limit to how many different scenes we can do. 

By alpha, I hope to quadruple those numbers at the very minimum, and ideally it will be even more than that.  A lot of the planets will of course be somewhat special-case-y: desert scenes, fully snowbound scenes, etc.  But hopefully at least 2/3 of them will be versatile enough to be combined and reused in all sorts of different and interesting ways to provide lots of interesting compound effects.  So far so good.

Buildings
The way that we’re going about creating buildings is really different from what I’d previously thought we would do.  I experimented with many different things, but at the high resolution and level of painterly realism that we’re supporting, it’s just not possible to do buildings piecemeal, built up from smaller component parts that are fully interchangeable.

That’s a hallmark of building interiors, of course — everything from Diablo to Demon Stalkers on up all use that technique for interiors, and we definitely will be, too.  Being able to have customer, user-definable, quasi-dynamic floorplans is a key feature of this game. 

I’d hoped that I’d be able to do the exteriors with a similar level of flexibility, as I had previously done with Alden Ridge back in 2008, but moving from 28px tiles to 64px tiles and going from a retro pixelart look to a unique painterly look has included a lot of adjustments for me for creating believable exteriors.  Since that was to be the greatest artistic challenge for the game, that was my first focus — no sense putting off the hard stuff.

When it comes to buildings, therefore, what I’ve settled on is doing each building more or less from whole cloth — it’s a unified image that can’t really be tiled or combined in most cases.  This allows for the awesome painterly HD look you see there, but it comes with a loss of flexibility in the art for building exteriors.  That’s okay, in the end, because it’s just eye candy rather than functional, anyway.  And I’d rather have less art that looks really good, rather than a ton of art that looks like the office building did last week (that was never more than a super early prototype, by the way).

This in turn adds a really immense load to the artwork, however.  I’ve been doing building modeling for my art for years, but doing just a single model even at fairly low resolution can take me 1-4 hours depending on the type of model.  There’s just no way that I’d be able to meet my goal of having hundreds of different buildings if I tried to build every last component myself from scratch, as fun as that is.

The solution?  I’m now using purchased 3D models for a lot of the detail stuff.  These are not custom-built for this game, which means that they come very inexpensively.  But the end result is very unique, because by the time I’ve scaled, positioned, lit, (often) re-textured, (sometimes) chopped up and rearranged, (occasionally) animated, and (always) heavily postprocessed each building, I get a really unique look that fits for this specific game and this game alone.  That cuts my time per building down to between around ten to sixty minutes per building, which is a massive improvement.  And it lets me get a really awesome result like you see here, without spending much or delaying or derailing the project.

Characters
I had hoped to do a second playable character for this week, but all I wound up with was the new robot (an enemy that looks kind of like a nightmare C3PO), and fixing the first character’s animation.  That required just rendering another 5 frames per side in Poser, and then I also improved the saturation and vibrancy of him, too. 

In terms of the robot, I also did him in Poser, and gave him his freaky skittering walk in that program directly, too — I didn’t know I’d be able to get such an unusual movement style in Poser, I thought I’d have to resort to Mudbox for that in more cases than apparently I’m going to.  So that’s pretty cool!  I used Poser 4 a lot back in the day, but Poser Pro 2010 is new to me and the UI is a bit daunting.  I’m getting way faster with the characters, though, which is a good thing — hopefully next week I’ll have even more to show in that category.

Spells And Particle Effects
So we have our first two spells in the game now — thanks to Keith!  While I’ve been working on the art and a little bit of programming, Keith has been really going at the code.  This week is the first week where this game is actually a game in a literal sense, in that you can do more than walk around in the woods.  That alone is pretty cool. 🙂

Particle systems are something we’ve done a bit with in AI War, and more with in Tidalis.  However, because of the scale of the former, and the genre of the latter, we only did so much.  Well, with AVWW, that all changes — this game is going to be whiz-bang fancy with the particle effects, and in the last couple of days we’ve taken the first few steps on that road. 

Particle Illusion is my go-to for rendering individual particles (animated or still), and then we’re using procedural animation techniques in-game to create more interesting and dynamic compound effects.  This is all stuff we’ve done in our other games, but here we’re just going to be having a lot more particles and a lot more complex effects.  Given the genre at hand here, and the closeness of the zoom, that’s something we can really do to our hearts’ content, unlike in the middle of a massive space battle or a puzzle game where the player is trying to concentrate.

Character Animations?
Here’s a secret: one of the reasons that particle effects are so important to us for this game is that they will let us have a spectacular high-res display that dazzles and is fun, but without doing much in the way of character or minor monster animations.

As I noted above, our work with the particle effects is just beginning — those are going to be a lot more prominent with spells, but also with even things like melee effects. It’s a trick a lot of Anime TV shows use to save on animation time, and it’s something we can put to use for ourselves, too, we decided. Funnily enough, the result actually looks better in a lot of cases thanks to the flashy effects.

In return, this lets us have a vastly greater diversity of playable characters. This is important for a game like this, in which any NPC can be a fully-playable character. In your average RPG, you have maybe 6 to — at absolutely most — 12 player characters to animate. In your average adventure game, in the Japanese flavor anyway, you have usually one. Then all those NPCs that you meet are just having very small animations for standing, walking around, and maybe talking if it’s a AAA budgeted game.

That sort of concentration of animations just wouldn’t work here, though — all of our NPCs have to have just as many animations as a player character, because they are all player characters.  That could quickly get ridiculous in terms of the production time, and would make adding more characters prohibitively expensive to do.  Since I don’t want to have a massive adventure game with only four or five characters running around, that’s a big problem, no?  How is an indie to solve this problem?

Particle effects is what we settled on, drawing inspiration from the likes of Dragon Ball Z on television.  All those cool particle effects?  Well, they draw the eye for one thing, and for another they actually obscure the world a bit, too.  In Tidalis or AI War that was a bad thing — you have to see to play.  Actually, that’s true here, too — you have to see the field and what you’re doing. 

However, what you don’t need to see, at the instant the spell is cast or the melee attack is launched, is your character.  In a brief poof of particles, your character takes some action that is clearly conveyed on screen without being directly shown. 

Thus we can get away with rendering “only” 39 frames and 1 portrait for each NPC, and a similar amount for most of the smaller monsters, instead of 10x or 12x that for having swiping/hit/grab/open/etc animations that you’d normally have.  And you know what?  This is critical, because even with just those 39 frames, the Darrell character is half a megabyte on disk, and the robot is about 750 kilobytes. 

If we have sixty plus characters, as I’d ideally like to by 1.0, and a few dozen monsters, then that’s a very nontrivial amount of disk space.  If we multiplied that by 10x or 12… that wouldn’t work at all, because not only would it take too long for us to create, but nobody would be able to download it.  It’s even worse in terms of RAM, because for things like characters we can’t compress the in-memory textures due to quality degradation.  So that half meg for one character suddenly becomes two megs of system and video RAM.

As with most large games with a lot of content, we’ll be loading and unloading content as needed to keep RAM in check while balancing the least amount of loading times, but the particle effects help us there, too.  By keeping the number of unique-per-monster-or-character frames to about 39, this makes loading times throughout the game vastly shorter (under ten seconds in all cases, if that, ideally — right now it’s one or two seconds max). 

It also lets us cache certain commonly-used particles permanently in RAM, while just loading and unloading the more specific-case ones, which saves on loading times even further.  Because our particle system is half-prerendered and half-pocedural, this gives us an enormous amount of flexibility while retaining that awesome look.

One thing you’ll notice in the video is that the character actually isn’t masked by the fireball at present — that’s because we don’t yet have a “casting” animation in place to go along with the fireball itself.  That’s on the list for this next week.  But the death poofs for objects and the robots do a pretty good job of illustrating the concept.  Actually, the death-poof technique is widely used in even AAA games — the 3D Zelda games spring immediately to mind.

Closing Remarks
Every game has to work within some form of constraints.  For most big-budget games, the  constraints boil down to “we can only fit this much content in RAM, and we can only afford to make this much content in the first place.”  That leads to things like worlds only being able to be so large, etc.  The really clever game studios are able to twist that formula around and do more with less.

Look at the earlier versions of World of Warcraft: they had very low-polygon models with incredibly textures on them, and not only did that help with their minimum system requirements, it also helped with making a convincingly massive MMO.

Look at all the SNES-era RPGs.  Final Fantasy 6 had a system whereby the individual player characters had walking and standing poses, as well as striking poses (side view only), and a few facial expression poses (front view only), along with a very few others.  In the context of a 32bit SNES cartridge, that was still a lot of memory capacity used to create 12 main characters and several equally-animated NPCs (like Kefka).  For doing the actual attacks, they then had various weapon or magic effects that would appear in space in front of the character, while the character struck their striking pose. 

The result with FF6 wasn’t what FF13 has with fully-rendered 3D, but to me it was a much more compelling game (and longer and more varied, I might add).  That’s what we’re going for here, too: a ridiculously compelling experience with as much immersion as we can give you under the constraints we have.  It all comes down to being tricky with how we create and use all of our assets, rather than just throwing a hundred artists at the job.

If you think the bump in quality between last week’s video and this week’s video was crazy, I can promise that the difference between even this week’s video and alpha will be pretty staggering.  When we have more of the content in there, along with more particle effects and more of — well, everything in general — I think the result is going to be something really attractive and unique, and something that people can be really excited about. 

Perhaps I shouldn’t be revealing the tricks of the trade as we’re using them (it’s a bit “how the hotdog is made,” perhaps), but I wanted to explain how we are going to achieve what we’re setting out to do.  With one artist on staff (me) working about half-time on art (the rest on programming, design, business stuff, etc), we’re going to make one of the bigger and more varied action-adventure games around.  This post explained a lot of how we’re able to do that, and why we aren’t crazy to even attempt it!

Stay tuned!