I've written before, in depth, on my process for iterative game design and why I use it. That blog post was a year and a half ago, however, when it was just Pablo, Phil, and myself and we hadn't even started working on the first expansion to AI War yet. I was the only game designer on the staff at that point, and the only programmer, and none of us did this fulltime. Then our game came out on Steam and Direct2Drive and changed all that.
So! Seems like it's time for an update about iterative design, especially in light of our major design shift for AVWW last week. After all, now I've had the pleasure of working with a Lars as lead designer on the Tidalis project (while taking the role of producer), and with Keith as my co-designer on the AVWW project. And we've put out three expansions for AI War, the second two of which were co-designed with Keith as well.
What's Changed Since The Last Blog Post?
Despite all the changes to the company, to my life, and to what projects we're working on, the process actually hasn't changed one iota. This is surprising even to me, honestly. But it's the nature of why we were able to make the shift to side view in AVWW, and why it wasn't as ballsy a move as some people seemed to think it was (though we appreciate the kind words on that score). Our Process, In Brief
If you want the hugely detailed post, check out Iterative Game Design The Right Way, my original post that I linked to above. But the short of it is that we decide, at the start of the project, what our "immutable design goals" are, and then start chipping away at the 'ol block of marble.
As the joke goes, you just have to "chip away everything that doesn't look like an elephant" to carve an elephant out of a block of marble. That's really an apt description of what we do. We start with a collection of ideas, things that the project absolutely must accomplish in some manner, and then we start brainstorming designs until we have something that seems likely.
Once we have a strong-enough-seeming design, and the time and manpower lined up, we start on the project. That's when the iteration begins. The first designs are always flawed and rarely fun, but they are illuminating. They teach us why other game designers probably did this or that, and what mechanic X or why means to the player. They help us build a technical prototype, and form both an art style and a musical/sound style.
Nothing is sacred except those immutable design goals, so we wind up having a very free discussion of ideas that actually works best with multiple designers. Keith and I both freely suggest things that are outlandish and half-thought-out, and just get the others' first reaction to it. If it seems like something worth pursuing, we do, but it's also perfectly natural to let such trains of thought just fade once they've shown they aren't worth it.
I always like to say that if a design was so obvious that we could have thought of it right from the start of the project, then everybody would be doing it. You can set a direction for a project at the start, and you can and should set immutable design goals, but if you try to create a massive design document that is set in stone, you're not going to make a very original game. All the best stuff comes out of the iterative process, and that takes time and iterations. To me, this is what it means to be an indie: this freedom to experiment.
An Experienced-Focus Way Of Looking At Immutable Design Goals
Another way of looking at immutable design goals is based on the player experience. In my other post, I said that my immutable design goals for AI War: Fleet Command were:
1. AI War must support co-op play in a way that is fun and painless.
2. AI War games must be long -- 8-12 hours perhaps -- and must continuously evolve as they progress.
3. There must be a huge number of viable options available to the player at any given time, or every game will start to feel the same.
4. The game must be designed in such a way that it does not reward fast-clicking over real thought, or my dad (and players like him) will not really enjoy it.
5. There must never be a "best path" for players to learn, or the game has just died. There must be enough variability and randomness in each game that players must somehow have to make different decisions based on the current situation.
And those are all true. Those were the parameters of how I wanted to play the game. But that's also like describing how an elephant is posed, not what an elephant actually looks like (awkwardly returning to the carving-an-elephant analogy from above). These sort of immutable design goals are important, but there's an even higher order of goal that I pay even more attention to: how does this game make me feel.
Imitative Feel
I think that any indie developer, when setting out to make a game, has an idea of what they want it to feel like to play that game. Often it's imitative: "I want to recapture that feeling I first got when I played Ocarina of Time." That's a specific goal, and so long as the actual mechanics of how your game works are sufficiently different, it's not to say that the final game will have much in common with OoT. We're talking about the impact of OoT, not its literal design.
Of course, that can result in games where designers simply try to imitate the form of the original game in hopes that the feel will follow; it never does, so that's a waste of time. But that's a whole other discussion that I won't get into here.
Art Imitating Life
Another way to establish the primary-immutable-goal for a game is to think about things outside of gaming. For instance, people that design golf video games are presumably trying to make something that feels increasingly like the real game of golf , not something that gives them the feel of the Tiger Woods games. These people presumably like playing golf, and want to capture what that means in the form of a digital game.
In the case of AI War, once the decision was made to set the game in space, I knew exactly what I wanted the game to feel like: I wanted to feel like Ender Wiggin. I wanted to feel clever and outnumbered and to win against all odds. It's surprising, perhaps, that the idea of an asymmetrical AI didn't occur to me until halfway through the project, but there you go -- it wasn't something any other multiplayer RTS game had ever done.
Setting Yourself Up For Epiphanies
At some point as I was chipping away at the game of AI War, I realized that a lot of my smaller goals were being met, but that I still didn't feel like Ender for some reason. And that's when the epiphany hits. That's the big benefit of iterative design, is that you set yourself a goal that nobody else has ever accomplished, and then you keep working closer and closer to it until you have all the epiphanies you need in order to make it happen.
Another analogy I like to use is that of walking down a long and twisty corridor. You know where you are, and where you want to end up, but you don't know all the intermediate steps. You can see around a corner or two as you go, and can make decisions that should take you closer to your goal, but you can't know absolutely for sure. Since you can only see around so many corners at once, that means you have to put in the time and do the walking to really find the right path; and sometimes that leads to backtracking.
Backtracking, in this sense, isn't a tragedy or even a surprise, it's just part of the process. I'm not one of those people who thinks that the first idea I have on a subject is the best I'll ever have. I rather think that the more I know about a subject, and the longer I think about it, the better my ideas about it will become. That's what the iterative design process takes advantage of.
Conclusion
You might be wondering what the overarching immutable design goal was for AVWW -- after all, it started out as a post-apocalyptic top-down game and is now a purely-fantasy side-view game. The core idea of that game is and always has been "I want to go adventuring in an exciting, dangerous-feeling, infinite world."
This is an elephant that we're still very much chipping away at, but I think you can probably see via our regular videos and developer journals how this sort of process evolves: we mention most of what we're working on, so you see some features appear and then later disappear. That's the process of walking down these corridors and finding out which ones really lead us to the end destination we're striving for.
Anyway, it's a process that I very much believe in and that I think others should use. So far it's worked every time for us!
This is the detailed diary that was promised in our big side view reveal post. It's assumed that you've already read the post on the other end of that link; if not, a lot of this post isn't going to make much sense, so make sure you do!
Obviously the biggest news this week is the switch to side view, and that's what the other post focused on, but that's not remotely close to being all that's changed. Here's a rundown of new stuff since last time:
Revised Control Options
Since the first previews, we've been saying that this game would be just a keyboard-only game or a gamepad-only game. You could choose which you want, but there would be no mouse involvement at all. This is something we've reconsidered based on playtesting and on feedback on our diaries and videos: now there will be three control options: keyboard, keyboard+mouse, and gamepad.
The new mouse-related control scheme is only partly in place now, but it will allow for precision aiming. The keyboard will also include options for angle-based aiming as well as the lock-on methods that we've been showing so far. Both of these control schemes will be interchangeable, so that you can mix and match these controls as makes sense to you. And of course all the keys are remappable.
The same thing goes for the gamepad, but actually that's becoming less the preferred way to play, now. We decided to increase the number of ability slots from 6 to 9, to make full use of the keyboard, and that means that most gamepads now don't have enough buttons to really handle the maximum number of abilities that can be used in the game. That's not crippling, and gamepads can be used in conjunction with the keyboard or on their own, but it's no longer the ideal control mechanism.
The control mechanism that we're going to be most emphasizing as the default will be the keyboard + mouse option, which is what we feel like will feel most natural to computer gamers, and which gives the most precise control over your character. But we're having options for everyone. And gamepad support is actually coded in now, for the first time in one of Arcen's released titles, so you don't have to worry about that going anywhere!
"What's My Motivation Here?"
Before I continue on with the list of what's new, I want to take a quick break and answer a question that a lot of players have been asking. We've addressed this in various interviews, but never very concisely or (apparently) clearly. If the goal in Zelda is to rescue the princess, and in Castlevania it is to defeat Dracula, then what's the overarching goal in A Valley Without Wind?
The most basic answer is: to heal the broken world as best you can. The world is torn, troubled, and overrun by evil. People are scattered, disorganized, and civilization has fallen. You play as a series of individuals (permadeath, remember -- every time you die it's a new character), and collectively all your characters are trying to help improve the world in whatever ways you see fit.
Usually this means helping out NPCs, improving settlements, and defeating evil overlords that threaten huge tracts of the world. If this were Zelda, each of these overlords would be Gannon. If it were Castlevania, they'd each be Dracula. However, since this is AVWW, they are all Big Bad Guys with procedurally-generated names and backstories and lieutenants and strongholds, and there are an infinite number of them.
Beating one of them is a big accomplishment, like winning the game in another game. And once an overlord has been beaten, you've saved a substantial part of the world -- it won't have to be periodically re-saved. NPCs will rejoice, and then life goes on in those areas. You can still improve the settlements and such there, and there are other NPC-focused things to do even in an overlord-less area, but the threat of that overlord is forever gone.
Part of the whole "you can play in one world for as long as you like" means that there always needs to be more to do. So, to that end, if you go just over the mountains, there's another overlord, even worse than the last, and leveling up and gearing up to beat him is like going through an entire game's progression again. It's like starting a new campaign in AI War, against a fresh pair of AIs, but keeping all the history and backstory and planets from the galaxy you played right before it. You've killed Dracula, now go get Gannon. Okay, now Sauron needs a good whooping. And so on.
To get a hair more specific: you're going to have to play for 10-20+ hours to bring down one of those overlords. Doing so requires not only the fight with the overlord themselves, but also traversing their entire fortress of bad guys that they have on hand to protect themselves. Prior to defeating that bad guy, you'll have 10-20 hours of NPCs in a wide range of regions who are lamenting the crushing yoke of this overlord in various ways. And if you try to attack the overlord too early, after even finding their keep to begin with, expect to die. Once you finally do defeat the overlord, the game remembers that forever (that's part of the "deeds" system the game has). To NPCs that were affected by the overlord, this is a really big deal and they remember both the overlord and the specific character that defeated him/her.
It's kind of like the way AI War builds up to the final fights at the procedurally-generated AI homeworlds. There's a strategic component to even figuring out how to defeat each overlord, because each one is outfitted so differently. So you might have to do some recon and some refitting as you go, too, in order to even take them out.
I've written at length about the benefits of having a persistent world that keeps going infinitely before, so I won't go into it in depth here. But for me personally, it's a very exciting new thing.
A Focus On Magic, Traps, and "Scrolls" Instead Of Physical Weapons
You might recall that in past versions we've talked about swords and gatling guns and so forth. We've decided that this simply isn't our strength for a game like this, and those mechanics simply we're looking very good visually or feeling very good in terms of gameplay. Spells, on the other hand, were already looking good and felt really good to use. And with our slots system for combining spells to get custom effects, that made the spell system even more unique compared to the rest. So that's where we're focusing the bulk of our attention
Spell Crests And Augment Gems
My hope is to have at least a hundred distinct spells by the time we hit 1.0, many of which can be socketed into a "Crest" that allows you to charge up a more powerful form of the spell and can also take additional augment gems that add stronger and more varied effects (some of which have trade-off side effects). One simple example is shown at 0:48 in our latest video of the game, with a Ball Lightning spellgem plus a Splitter augment gem inside a two-slot spell crest that has an inherent charge ability modifier. So that lets the player charge up a lightning ball to be more powerful by holding down its key, and then it rockets out in multiple directions rather than just in one, for instance. That's just a pretty simple effect, and with two slots only (the maximum number of slots will be four).
Raw Gems Versus Gem Dust, Plus More On Scrolls And TrapsThe recipes for crafting spellgems and crests and things of that nature all have at least one "raw gem" included. When you find a vein of one of the six types of raw gem underground, smashing that vein gives you a raw gem item as well as multiple gem dust items. The raw gems all go to spells or crests, while the dust all goes to scrolls or traps.
Scrolls and traps are all consumable items, meaning that once you craft them you have only a limited number of them. This is in contrast to spell gems, which you get unlimited uses out of, but which require magic points for each time you use them. Traps and scrolls require no magic points, and in some cases are more powerful than an actual reusable spell, but you only get a limited number of them.
New Crafting System
We took a hard look at our crafting design and found it wasn't meeting our goals, so we came up with a new system that we think is much more compelling, and a streamlined interface we're pretty excited about. We'll be talking about this in detail in the next couple of weeks, but the resulting system is being polished up as I write this, and it's really very good.
The core ingredients are the raw gems and gem dust noted above, and each gem or bunch of dust has a tier. Regions level 1-5 tend to have Tier 1 gems/dust, level 6-10 have Tier 2 gems/dust, and so on. So you don't have to get all new inventory every time you level up, but you always have new stuff to look forward to as you progress. When you combine multiple tiered ingredients into a single recipe, the average tier is used for the finished product.
However, gems and gem dust aren't the only crafting materials: there are also "catalysts" that might range from anything like "iron" to "soft wood" to "plums" to "silk." These sorts of things can be found mostly above ground and inside, whereas the raw gem veins are mostly found underground. The most interesting and powerful spells, traps, and scrolls require catalysts that don't show up in the lower-level regions, so as you're playing the game you're finding both higher-tier raw gems, new kinds of raw gems (you start out with only red and white), and new kinds of catalysts. Of course, if you're an advanced player and don't want to go through the regular progression you can always jump into higher-level regions early.
But for average or new players, there's a progression of expanding options as you explore, and these form the backbone of how you outfit yourself for exploration, and how you are able to improve your settlements. There are actually other components to this as well, such as crafters needing a place to do their crafting in the settlements, and needing to be appropriately-skilled at crafting to make what you need. So you'll be finding things like memory crystals from which your civilization's crafters can learn to make new things or mix or catalyze them in new ways. We're also thinking about crafters needing certain improvements to their workshops and the player being able to help out with that, but we're still not sure if that would actually add fun to the system as it will be.
More on that in future diaries, but there's lots you can do with all this. It starts out slow and easy, and then gets more complex the higher the region levels go. Actually, that's a pretty good description of a lot of parts of the game: it eases you into things unless you skip to some higher region levels right at the start, so you can basically choose the sort of progression you want to have.
The New Magic Point SystemThis has been talked about in the forums some in past weeks, and it's only partly in place at the moment, but almost all spells will be requiring magic points for each use. This of course means that you can't just spam your best spell, but you have to use them a bit more tactically in terms of your long-term consumption.
There are a variety of ways that we're building RPG-style optimization tactics into this system. First is that enemies will often have small MP or HP drops that you can pick up and which increase either your health or your magic points immediately on contact. So if you can kill enemies while expending fewer MP than you gain in the drops, then you can adventure on indefinitely.
Another thing that provides tactical options for you the use of scrolls and traps, which do not require any MP at all, but of which you have limited quantities. So designing your loadout before an expedition (both at crafting-time and what-to-take-with-me time) takes on great importance, because you want to have enough of these to help offset your general MP use, but at the same time you want enough spellgems that are powerful that you can use for the bulk of your combat.
There are also some scrolls that actually give you more MP directly, kind of like an ether in Final Fantasy; but to get those scrolls requires the use of certain catalysts and gem dust that you could be using for other scrolls or traps... so it's always a tough economy of choice, and different players will have wildly different styles of play.
Lastly, there is also a whole category of "touch spells" that are basically the equivalent of melee weapons in other games. These spells don't require any MP, but they only work on enemies that are close enough for you to touch. With many enemies, that means you're going to take some health damage yourself if you're not skilled. But if you are very skilled, it provides yet another way to play. And another way to keep yourself steeped in magic points on lengthy excursions without having to use MP-granting scrolls too heavily.
What Is Meant By The "Depth" We Keep Referring To
When I talk about gameplay depth, the magic point system and system of choices it creates is one part of what I'm referring to. The other parts generally revolve around the macrogame and how you choose to change the world. And the other part refers to the mechanics of actual combat itself, particularly at the higher levels, where spell choice and spell combos will matter. Suffice it to say, this is a game that requires some planning on multiple levels if you really get into it; most similar games just hand-hold you down a linear gameplay path, and your involvement consists of executing that gameplay with skill.
Twitch skill can matter here if you want to play above your civ level, but even more important in all cases is the ability to make good plans and execute them. If you want to defeat an overlord or build up a specific settlement, then that's a complex undertaking that requires planning, multiple intermediate expeditions, and then skillful execution. I guess it's the strategy game developer in us: we just can't get away from that sort of thinking even when we make an action-adventure game!
Fire Touch Spell, And Environmental Interaction
This is the first of the "melee" spells mentioned in the magic points section above. So you can use and reuse this one for zero magic points, but it only hits things right in front of you and isn't overly strong. It's not the first choice for combat in most cases, but at the same time its class of spell is instrumental to bring along for every expedition. However, it also has a great value aside from direct combat:
One thing that you probably noticed in the video is that you can just walk right past trees, buildings, etc, now. This of course makes sense in a side view game, but one of the coolest things that we have been showing so far was the environmental interaction, right? Fear not: that hasn't been lost, it's just been changed around some. Most spells don't hit the background trees and such because that would be incredibly annoying.
However, when you want to knock down some trees for whatever reason, this fire touch just causes a burst of flame directly in front of you, which also hits the background. This is the easiest way to get wood from trees, or plums from plum trees, and so on. Excellent catalysts for various purposes.
Seize Spell And Combat Tactics
If you look at 0:29 in the latest video, you can see the new Seize spell in use. Basically what it does is grab a usually-non-colliding piece of destructible background or foreground (trees, plants, wire baskets, whatever) and makes it shining, spectral, and colliding. You can't get past it without destroying it, and neither can enemies. Enemies will start trying to hack their way past it if you trap them on the other side of it from you, buying you time to re-equip, heal, deal with a lone enemy that you've separated from the herd, or whatever else you need.
You can even, of course, create a whole line of seized objects for enemies to slam through, buying yourself even more time at the expense of the background objects and the MP required for the seize spell. In essence, this works kind of like a cover mechanic in an FPS game, but with destructible cover. It's actually a lot easier to use than just hiding behind stuff in the old top-down view was. And you can combine this with other abilities, such as using environmental objects to slow down enemies and then hitting them with area damage from the safety of the other side. Or it can buy you some time to lay down a line of traps.
When I talk about the depth of combat that we are going for, this is one example of what I mean: you use spells and environmental objects in various combinations, rather than just button-mashing the fireball spell into every enemy you meet. Developing out more ideas like this is something that we'll be doing over the next few months, and I'm sure players will also have many interesting ideas to contribute if AI War is any indication. We also have a cache of other ideas for tactical combat options, but since they haven't been playtested yet I'm reluctant to talk about them in case some of them don't work out.
Vertical Terrain Traversal, and the Ride The Lightning spell
The latest video shows a lot of walking around on the surface, but probably only a third of your playtime would take place there. The other two thirds take place either underground or in the interiors of buildings (more on interiors and undergrounds below).
Moving around underground or inside now has both a horizontal and a vertical component to it, of course. Gravity is your constant enemy, even though this isn't a platformer game in the sense that Mario games are platformers (aka, no precision jumps needed). To that end, you will have a variety of tools at your disposal for getting around.
The first is shown at numerous places in the latest video, and it's a spell called Ride The Lighting. It can be used at any time, even when you're falling or already having jumped into the air, and it boosts you up about 4x higher than you can normally jump on your own. Each time you do costs magic points and requires a recharge of 1.5s afterward. Higher-tier Ride The Lightning spellgems let you jump progressively higher.
The second method for traversing terrain, and the one that will be more commonly used by most players, is wooden platforms. These aren't implemented yet, but basically you'll be able to place wooden platforms from your inventory into the game world. This is in no way a construction game like Minecraft or Terraria, but you will be using wood for things like building platforms and so on. These platforms can be arranged like bridges or like ladders, so you can get through most of the game without having to have any particular skill at jumping if you want to really stock up on a lot of wood instead. Or you can get by with very little wood if you prefer the jumping.
These sorts of things also have combat benefits: you can use these sorts of spells and consumables to avoid enemies (thus carrying forward the minor stealth component we've been talking about in the top-down view), or to get a better tactical position that you can then attack from. We haven't done a whole lot with that yet, but as a longtime RTS developer it's the sort of thing I've always wanted to be able to do. In a top-down game every direction is functionally the same as the last -- if you attack from the north, south, east, or west, it doesn't matter. But from a side view, suddenly attacking from the side, bottom, and top of an enemy all have really different meanings. This is quite exciting to me to get to work with.
The wooden platforms are another way in which the game emphasizes expdition planning, too -- if you go into a really deep cave without enough wooden platforms to get back out, then you are going to die down in that cave! Unlike Minecraft and Terraria you can't just dig yourself a way out through the rock. This game is about exploring and traversing the hostile environments that you find, rather than being able bending every part of the world to your will -- this world is way too hostile for that. And in a lot of respects this makes the underground sections feel a lot more like real spelunking, even if it is still highly fantastical.
Enemy Generation
One thing that has really changed in how we're handling the game is how we're handling enemy generation and monster nests. Initially in the top down view we just had enemies seeded into each chunk, and you ran into them when you ran into them. They would respawn over a long period of time after you left the chunk. Then we added the concept of monster nests, which spawn monsters more rapidly, and which you could seek out and kill. That's when you started seeing incredibly huge swarms of bats in our tests builds (that was only ever a testing thing).
Now what we are doing is scrapping the directly-seeded monsters, and just having nests that are seeded around, but not letting those nests be touchable by players. They are essentially just visible spawn points for enemies. They also now spawn fewer enemies than the monster generators in preview #11 did.
The net effect is that there are now always monsters present (it gets pretty boring when there aren't), but they don't clump up too much, and you can enact strategies around where you can see them visibly spawning. Such as laying traps or whatever else to suppress them for a while. It offers a lot of future tactical options for us as game designers that simply wasn't there with something that is easily destructible.
You'll probably notice from the video how much better balanced the number of enemies is throughout compared to last time; you're never getting swarmed by 50 enemies, but there also aren't large periods of time where there's literally nothing going on.
Poison Water
One of the new things in the game is the ability to fall into water. When you do, you move more slowly and can't jump as high, but otherwise keep moving as normal (in other words, similar system as Cave Story and Metroid). While in water there is no air gauge, because the bigger threat comes from the toxins that are in all pools of water -- if you just stand there in the water, and are at full health, you'll be dead in 60 seconds.
That's actually not a very stiff penalty, which is great because this game has permadeath. Death in this game should not generally be because your finger slipped or because you missed a jump, but rather because you made a series of bad choices. In that way, it's much more Metroidvania than Zelda, even.
Anyway, so being in water for long is a bad idea, but falling briefly in isn't going to kill you unless you're already on the point of death. But for most enemies, being in water is much more quickly fatal: when they fall into water, they die within about 5 seconds instead of 60. This makes it so that the enemy nests can keep spawning more enemies as the older ones reach the lower limits of the level and die off in the water, which makes for constantly shifting "patrols" of enemies in many cases, which is pretty neat.
I should also go ahead and mention that you can't use water to farm enemy drops: when an enemy dies in water, they don't drop anything. While I'm at it, I'll also mention that when a loot drop or player item bag falls into water, it floats at the top instead of sinking. Thus you can build some wooden platforms to skim across the top of the water and get your stuff back without having to step in the water. This is also true for lava (see below), which is even more important).
Falling Damage, Lava, and Platformer Elements
One of the first things that we prototyped with the side view was the characters taking damage from falling too far. This is something that works in FPS games, but my experience has been that I don't really like it outside of that -- in Minecraft, for instance, I'm on the record as asking for there to be no falling damage.
So we took out falling damage for most of the regions, but one of the things that I'm really angling to do is make it so that regions are unique not just in look, not just in rewards, and not just in enemies, but also in larger gameplay mechanics. For the lava areas, that's always been something that has been intended to be very difficult as a region, but it's also a region that lends itself well to platformer-style elements.
Now, I'm an absolutely enormous fan of Mario games and Donkey Kong Country games and other things of that nature. Have been all my life. But the switch to side view for this game doesn't signal that it is in any way becoming a platformer -- it's action adventure, just rotated on its axis. But since it is side view and gravity does exist... well, there's no reason that the lava areas can't be a haven to stick all the platformer-type stuff that we might want to do.
So in the lava areas there is falling damage, and there are pits of molten lava that kill a full-health you in about 5 seconds instead of the 60 that water takes. There will also be timing-based lava waterfalls and things of that nature. If you don't like platforming elements you can stay out of the lava areas and not miss anything; and you won't be seeing anything like that in any other part of the game. But if you do like platforming elements, then this is a pretty interesting area to go into, and it contains rewards that are relevant to being able to do even more platforming.
Speaking more about the falling damage, that is all handled based on your velocity when you hit the ground. Normally in most areas your terminal velocity is capped such that you never take any damage. In the lava areas it's about 4x that, such that one a really long fall you will die on impact, an on more modest falls you will take 1/4, 1/2, or 3/4 damage respectively
This is the only region type in the game that will have any falling damage at all, and it's also the most blatanty-hostile type of region. The sort where you don't send a fully-equipped character, because the risk of death is astronomically higher than anywhere else. Don't worry, there will literally be signs posted at the entrances to the lava areas warning you of this, and to go back if you don't have a deathwish. My view is that it's fun to have a couple of rare pockets in the game that have this sort of unbridled hostility against the player -- it's the sort of place I'll enjoy going occasionally, myself -- but it can't be more than 1% of the areas in the game, if even that high of a percentage.
If everything in this section sounds like a horrible idea to you, then no worries -- you can simply always go around the lava flats and even the deep and pretend they don't exist. If that's how you feel, you won't be missing anything you would care about, anyway. Think of these as the rare and isolated "challenge areas" for players who like an insane challenge, and who like platformers at least some. For everyone else... there's a massive infinite world that doesn't have any mechanics remotely like this. This section should thus actually come as a comfort to players that don't like traditional platformers, because we're making a commitment to keep any and all such mechanics limited to just the lava areas.
Surface Chunks and Underground Caverns
So at this point there is a single "surface chunk" in each region, but we're actually going to be expanding that this week to being a long list of surface chunks in each region -- really expanding the amount of above-ground area that you can cover, so that there is enough to the surface that you can actually spend 33% of your time above ground doing interesting things, rather than spending all your time underground or inside. I like underground and inside as well as the next fella, but I also like seeing the sky!
At any rate, these surface chunks have the sky, and buildings on them, and you can go in all the buildings. Then most of the surface chunks also have one or more holes in the ground, as seen in the video (some chunks are just swiss cheese with holes, of course), and when you go down in these holes you can find underground doors like what you see at 1:53 in the video. These doors lead into completely-underground chunks that are filled with all sorts of interesting things, including sometimes underground buildings.
In most regions, these only go down so far -- you'll find chains of caverns that take you an interesting amount downwards but not infinitely so. This is where you find the raw gems and other cool stuff that you can use in crafting. Sometimes this is where enemy lairs or even overworld keeps are. All stuff is down there. In a few region types, there is literally an infinite downward progression of caverns taking you downward. Keith and I have been talking about various fast-travel mechanisms for making it back up and down for these infinite areas, but we haven't settled on anything definite yet.
Interiors
Exploring inside buildings is the other third of the action-adventure parts of game, and that has probably grown in importance even since preview #11. One of my big goals is to make the interiors really feel distinct from the undergrounds -- to that end, there will probably be a lot less darkness inside, and of course the actual interior construction in general is really different.
So what's inside that you're exploring for? Mostly it is catalysts for crafting, but it's also memory gems. Some of the most important spells will require components from interiors of certain regions, so there are some really substantial rewards to be found inside buildings.
I don't have as much to say about interiors this week because the switch to side view has invalidated most of the work I previously did on them. However, the new task is a much simpler one, so I'm hoping to have basic interiors up and going this week, and ready to be shown next video. Also, I will still be releasing the old top-down interior generator tool as an open source program for others to use, even though AVWW now won't be using it. I'll try to get to that this week, too.
Terrain Generation Techniques
The basic technique for cavern generation in AVWW is the one proposed by Noel Berry here. However, I've extended on that a fair bit to make various flavors of caves, and to make caves that can intersect with variable-height rolling surface hills like you see in the videos. It's a really cool system, and it's completely removed the need for the hand-crafted maps that I talked about at length in preview #10.
It's all procedural now, and it's providing really, really varied results including cliff overhangs, floating islands, and so on. All inescapable pits have some poison water somewhere down at their bottom, which is handy so that if you are being foolish and don't have enough wood platforms or spells to escape the pit, you won't have to suicide yourself -- the water will take care of that for you.
And of course, the water takes care of any enemies that fall into such pits as well, as noted above. Which means that you don't wind up with all the enemies just hanging out at the bottom of a pit, fruitlessly trapped. And you don't need enemies to avoid falling off ledges, because enemies falling off ledges adds so much to the gameplay -- you have to watch out for them coming at you from above!
New Objects And Buildings, Removal Of Broken Vehicles
As you can see in the latest video, there are tons and tons of new objects and buildings in the game, aside from all the existing ones being re-rendered from a side view perspective. I think the count of objects has roughly tripled since #11, up to something like 150 objects, and the number of buildingshas gone from about 20ish to about 50ish. Nowhere remotely near all of them are shown in the video.
One other change going along with the new objects is that I've taken out all of the various broken vehicles in the game. In a magic-using world, such vehicles would never have really been needed anyhow, and they were never going to be something you could actually drive. I simply had cars and similar because I wanted to have highways full of broken cars, like in The Stand.
From a side view, though, it's really impossible to do a highway that looks good, and the cars were one of the most boring parts of the art from #11 and before. So now highways and cars are gone, and in their place is an incredibly more varied and interesting selection of objects more fitting with the new theme of the game.
From now on I'm going to be dedicating one solid day per week to simply making more objects and buildings and other art elements, to make sure that this game really has a ton of content even by the start of beta. Last Monday was my first stab at having a day of that sort, and I was able to get 116 objects and buildings all done in one day, so that's a good sign. I should be able to kick that number up even higher as I get more practiced at it. Already these new buildings and objects are just giving an incredible amount more character to the various areas, though; my favorite at the moment is the telephone poles that are sometimes in the Small Town regions.
Streamlined Inventory System
Another thing that we've been working on in the last couple of weeks has been getting the inventory and crafting systems really working as smoothly as we can. The crafting interface we'll talk about in depth in a future week, but the inventory interface is done already. There are now two kinds of inventory: usable inventory, and crafting materials. Crafting materials that you pick up (such as raw gems, gem dust, and catalysts) all immediately go into "the vault," which is a central personal repository that you can access from anywhere. If your character dies, nothing happens to anything that's in the vault. If you go to any crafter or any workshop to do crafting yourself, you can access everything in your vault at that time. None of this stuff ever shows up in your main inventory, taking up space.
Usable inventory, on the other hand, is actually stored on your person. The ability bar at the bottom screen is now 9-wide instead of 6-wide, and each slot corresponds to the same number key on your keyboard. Your entire usable inventory is 9-wide, and up to about 10 rows tall, although it only shows as many bars as you are actually currently using. If you press the 0 key at any time while playing, then your active ability bar will switch between different rows of your usable inventory.
In this way, you can get at your entire usable inventory without ever having to open a menu. And in fact when you do press the I key, it brings up a very minimal interface that is just however many ability bars you actually have in use at the time in your inventory. You can drag items with the keyboard or mouse between the different bars, or onto a new bar. As you pick up new usable items, they go into any empty slot or onto a new bar, and you can then rearrange them as you will. Thus the entire usable inventory interface is for organizational convenience, not functional necessity, which is pretty cool.
When you die, your entire usable inventory gets dropped in a player item bag right where you fell. It never disappears, so if you remember where it is you can go back and get it at your leisure. It's planned that there will be no way to send usable items back to the vault while you're out in the field, or to get other usable items out of the vault. But the plan is that when you are in settlements you can access your vault and put usable items into and out of it. Your actual field inventory thus is no longer unlimited like we'd once planned, but it's still enormously, uncommonly large. Most players will likely never use even 50% of the available space of usable inventory in the field.
Other QuestionsQ: Will this affect multiplayer at all?
A: No, we've done all of this in a way that is fully compatible with the multiplayer code we already had.
Q: Is there a day/night cycle now that we can see some night areas in the video?A: Actually, there's not a day/night cycle. We do have regions that are clearly at night, but those regions are always at night while you are in them. It seems like a lot of games have a day/night cycle, and that's just not something that we saw as adding value in this game. Instead, what we have is the windstorm cycle, which is a lot more unique to this game and which has been discussed in the past. The basics being that every four moves you make on the overworld, you run into a windstorm, unless you're standing on a settlement or a wind shelter at the time. So it's kind of a musical chairs thing, and you can build "roads" for safe travel via the wind shelters, etc, etc.
Q: How does this affect the size of regions?
A: It doesn't particularly. Individual surface chunks are now a functionally smaller since large parts of them are now taken up with showing sky or ground that you can't interact with. However, to compensate for that we're making it so that regions are made up of multiple surface chunks rather than a single one, which actually lets each region become much larger and more interesting. And it makes the surfaces actually something that can go on infinitely like an interior or an underground area can, so we've actually bought ourselves a lot of flexibility there.
Q: Does this affect the overworld map at all?
A: Not one line of code has changed for the overworld map. I improved the graphics there, and that's it.
Q: Do you still get dumped mid region by windstorms?
A: Oh, yes. It's actually a lot more threatening now than it was before, because of the presence of pits and such. And also, once we have the linked surface chunks going, it will be even more threatening because of the fact that you might be multiple chunks away from the overworld -- this is quite exciting for me, actually, as I never felt that in the prior versions the windstorms were really notable enough.
Q: Was it not insanely hard to throw away so much hard work on the top down version to make the switch?
A: You'd think it would be, but I can honestly say that it was the easiest thing I've done on this project in a long time. Remember, I'd spent the last six months not really having things turn out the way I wanted, and listening to everyone complain about the camera perspective, eight-way sprites, etc. That was hard, and extremely frustrating, but ultimately fruitful. Once this idea had fully formed to the point that I knew it was something we needed to do, it came together really fast. I think I had all the side view code, up to and including physics, done within about three working days. Then it was just a matter of all the art rework, and introducing new mechanics, etc. And other content generation things like really getting the caverns feeling different between different areas, things like that. It felt really, really good to be making those changes, and consequently they just flew by.
In Conclusion
Whew, that was a really long one. But hopefully this goes a long way to reassuring folks that all is well in the valley without wind, and that the side view is in no way a dumbing-down or a reduction in tactical options. We thought this through in great detail before pulling the trigger, and I think that over just under 300 emails between Keith and myself have now been exchanged on the subject. Most of those 1,000+ words.
And you guys have seen the sort of games we make, right? Look at AI War, for goodness sake. If we'd felt that the game would be poorer for this, but only the art would be better, we'd have gone with the better game and worse art. It's been our very good fortune to realize that not only is the art better in this perspective, but so is the gameplay as well! In the coming weeks we'll focus more on the crafting mechanics and interface, as well as some of the macrogame stuff to do with NPCs, settlements, and so on. And of course the various new spells and enemies, interiors, and all that good stuff.
Thanks for taking the time to read, and here's the new video again in case you missed it. Enjoy!
There comes a point in every good game's life where it stops feeling like a prototype, and starts feeling downright fun. For AVWW, that time is now, and it came about because of a fundamental shift we made to the game: rather than being a top-down 2D game in a faux perspective that is common to SNES, DS, and pixelart games, it is now a side-view 2D game. It's still a sprawling adventure game in an infinite world with a top-down overworld map, but the perspective of the actual action-adventure bits has now flipped.
It's amazing how obvious this change seems in retrospect: it fits perfectly with the rest of the game's design, and in fact augments it. There was recently a three-page feature on AVWW in PC Power Play, and literally the only thing that's now outdated in that article is the screenshots. Settlements, crafting, hopes, deeds, NPCs, and so on have been completely unaffected by this shift.
The perspective change has been a unifying force for the art as well as the gameplay, while ditching the camera angle that was bothering so many people in the previews. All of the individual graphics in the last video diary were high-res and attractive, but the overall composition was never able to gel until now. I find it really telling that when our PR guy Erik saw an early side-view build, his first comment was to compliment me on the new art -- and that was before I'd changed any significant portion of the art he was seeing.
The traditional faux top-down perspective blends elements that are side view and elements that are top-down and elements that are partway between; this works with pixelart, which is more abstract, but really bothers people increasingly as you move into higher res stuff. So what Erik was seeing was all the side-view stuff that I hadn't even changed, just with the top-down stuff lifted out. Scene composition counts for a lot, as any photographer will tell you.
Keith and I originally talked about making a switch to side view on the day after Christmas. I felt like it would give an enormous boost to the art, but Keith worried that the game would feel more arcade-like in a bad way, and I was worried that I wouldn't be able to implement the sort of tactical combat that I was hoping for. Just when I had convinced Keith to do it, I flipflopped and we stuck with a top-down view. It's funny looking back at those emails now. On May 27th, after months of trying to make the top-down view work, I finally realized that the side view was what we needed to do. Blue's News has been calling it a side view game every time we do a dev diary, so I guess Blue has a pretty good crystal ball!
Part of what convinced me that this was the right direction to take the game in, and not just for art reasons, was the evolving design of the combat. I wanted a reasonably tactical gameplay experience, but in realtime that comes down to the choices that you make more than battlefield position. Location changes too rapidly in this sort of realtime game to be a substantial force for tactical maneuvering, so the bulk of the tactics come down to what abilities you use, and when, and in what combinations. And I realized that would be absolutely killer in a side view game -- as a kid I had a special love for side scrolling games such as Zelda II, Faxanadu, Ironsword, Metroid, and Castlevania II.
It's the sort of game design challenge I just absolutely salivate over, and I think we'll have something really fresh and exciting even by beta. The last few weeks have been euphoric for me, as this one simple change just solves so many problems that had previously seemed intractable. Even Keith, who really doesn't like twitch games or platformers, has been remarking on how much more fun the game is lately, which I take to be a very good sign.
Also in the time since the last developer diary, we've added over a hundred new objects to the game, a handful of new spells, several dozen new buildings, and several new animations. Oh, and we've added chains of underground caverns, which are a major new thing. This means we're getting started on vertical development in a major way. However, at the same time we managed to completely redo the inventory interface, get most of the work done on an all-new crafting system, redo the bulk of the art that we already had, do all the new physics for the side view mechanics, and in general convert over all the adventure-related and graphical-related code so that it is now side view instead of top view. That's exactly as much work as it sounds like.
So how were we able to get so much done on the vertical development front while we were still making so many structural changes to convert this to side view? Simple: it's incredibly faster to do work for a side view game. I don't have to spend hours fiddling with new pieces of art to get them in the exact right fake perspective that people will complain about anyway; I just render it from the front side, and that's that. I don't have to render front, back, and side perspectives for every character and monster (and even with that, people still complained about not getting front-angled and back-angled versions); instead I just render the side view, and that's that.
The result of this side view switch is something that looks incredibly better, that's orders of magnitude faster for us to create, and that's more fun to play. It also helps give a much stronger sense of place: partly it's seeing the sky when you're outside, but it's also the varied terrain height, long falls, poison water, and so on. There is more interesting stuff visible on the screen at all times now, but amusingly the new perspective is still about three times lighter on the graphics card thanks to not having to render quite so much grass; my average framerate is now about 250fps instead of 80fps.
Rest assured that we're committed to the same "easy to get into, but incredibly deep" gameplay that we've been talking about since the start on AVWW. The last few weeks we've been making huge strides along that very path. We look forward to sharing even more of our progress with you over the coming weeks, and we expect to hit beta in early August. Player feedback has been instrumental for us in helping to polish this game and particularly to make the perspective shift -- that's something I can't emphasize enough. People tried to help us improve the faux top-down perspective, and when that didn't work as well as anybody wanted we went another direction. I think people will be really pleased with the result. If you haven't already, be sure to check out the latest video and see for yourself!
Speaking of player feedback: we are hearing the requests for more concrete information and visual demonstration of what's going on with the NPCs and settlements and so on. In response we've been working on a dev diary that gets into some of those details. So rest assured that more info on that is coming (currently targeting one of the next two dev diaries, along with crafting, for the next few weeks), but it's going to take a bit longer to do well. A bit later today I'll have a more detailed developer diary talking about specific new elements that are already in the game in greater detail (UPDATE: here is the new post). Enjoy!
Please understand that my intent is not to tease, here -- a lot of game companies give the barest hints of information, and try to drive you nuts with speculation and extrapolation. Folks familiar with Arcen know that's not our style.
That said, what I do want to tell you is that there are several pretty major surprises coming for A Valley Without Wind in the next developer diary, but that I won't talk about specifically what until that dev diary arrives. That will be in a week or two, depending on how development goes during that time.
Why on earth would I make such an empty, teasing-style post? Frankly... because whenever Major Things Change without forewarning, certain people I know tend to get annoyed with me. So this is your forewarning: the next time you see AVWW, it's going to be pretty different in a lot of fundamental ways, although not the most fundamental stuff.
What's happened to cause this? We had the epiphany that this game didn't even know it was looking for. There was a similar point, about March of 2009, when suddenly I had the idea to make the AI asymmetrical in AI War. It had been a game about even contests of will, but suddenly it was to be a David and Goliath sort of situation. That changed everything, but also tied together all the best of what had been inwork on AI War since November 2008.
That's what's happened here: we've had our big ties-everything-together idea, and it changes a few very core things about the game, but does so in a way that keeps all the coolest stuff and in fact augments it. All that "macro game" stuff that Keith is working on (perma-death, settlements, NPCs, deeds, hopes... basically all that stuff that people are most excited about) is alive and well, just to set you at ease.
Again, sorry for the tease. We'll have videos and developer diaries as soon as we humanly can complete the work required to share them. I have never been so excited about this project, though, and I think others will share the sentiment when they see how all these changes come together.
The last thing I'll say is: thanks. The watershed moment came about while thinking about fan feedback on our existing developer diaries and videos. There have been various persistent complaints on the blog, the forums, and youtube, and thinking about how to solve all of those is what led to the epiphany. So thanks for that!
It's been a while since our last update -- we've been really busy, as you might expect. The game has now been in development for 17 weeks, but this week we don't have a new fully-produced video mainly because we're running short on time. However, a number of the new animation updates that are in this batch of changes really can't be described very well with words, so I've put together this animation test video that shows off each new thing for you:
Interior Generation
This is something that I posted a lengthy technical post about yesterday, but the short version is that procedurally-generating the interiors of buildings is coming along well. It's a problem that lots of other people have solved in various ways, but which nobody seemed to have solved in the specific way that I needed.
So I've come up with a moderately new approach to the problem, basing part of my work on what an indie working on roguelikes created, and that's leading to really interesting and varied interior floorplans at this stage. In a month or two, once that's all further polished I'll be releasing the C# source code for my interior generator as open source under the MIT license, so that others can make use of it.
Story And Setting
Perhaps the most shocking thing we've changed in the last three weeks is the story -- the broken-earth setting, former ice age, etc, all remains, but the real-world future setting has been replaced. Instead this is now a purely fantasy world called Environ. Rather than trying to explain all the differences, let me just give you the new intro story for the game:
It is the year 888. Wind-blasted snowfields have covered the world of Environ for centuries. Survivors in this ice age are few and isolated, caged by the bitter cold. If they travel, the world itself seeks to devour them. For most, only the enigmatic Ilari provide any shelter against extinction. Driven by desperation, others ventured into the forbidden lands to unearth and reclaim citadels of ancient and wonderful technology. Wary of the ill-understood machines, some have embraced the talents of magic and telekinesis that have emerged in recent generations despite fear of accepting those powers from the Ilari.
Now the glaciers have begun to recede, and a few brave souls venture forth. What they discover is something no one expected: Industrialized cities from the 5th century lie in just-abandoned ruin, next to far-flung bronze-age towns from the first century of the ancient era, near enclaves of skeletal robots from a time after people. Most people from those fragments of other times are dead, but some live on despite periodic scouring windstorms and roving monsters. These people are as lost and confused as the refugees from the ice age.
This is a deadly new world, and the scattered peoples of Environ must work together if they wish to stay alive. They must thwart the wind, the monsters, and the would-be tyrants popping up. They must explore and scavenge the time-shards to find the materials they need. And they may need to enlist the Ilari to help rebuild civilization. If the survivors can find out what happened to their world, that would seem a luxury. Such massive damage seems irreversible, but some may build what all now dream of: A home free of fear and death. A "valley without wind."
Why the change? Lots of reasons; this has been building for a while. I think that Keith always would have preferred a more fantasy-focused setting, but I was pushing for the broken earth setting because of lingering attachments to the setting from Alden Ridge. But as we've been doing the project, I keep coming to the realization that this or that thing would be more interesting if it was vaguely like the real world, but set in a fantasy world. I talk about that some relating to interiors in particular in the Interior Generator post.
So now we have a world called Environ instead of Earth, and all the peoples and nations are fictitious instead of historical, though some historical influences should be obvious as in many such fictions. Instead of the real timeline of civilization, we have something that goes roughly like this:
The Ancient Era (before year 0, encompassing many things such as the bronze age and so on)
The Major Event (year 0)
The Middle Ages (0-300 or so)
The Modern Era (300-500 or so, and very similar to our 1900-2010 period)
The Ice Age (500-888+)
The Future (not saying, but that's where the skelebots are from)
And actually there's a lot more detail to everything than that -- ancient Atlantis-style high technology civilizations, etc -- but I'm not going to go into more depth at this time for two reasons. First, I think that's spoiler-y enough just with the above, heh. And secondly, we actually would like to have some divergence in history timelines from world to world. Not saying that will definitely be something we do pre-1.0, but it's ultimately where we want to take this. So the "major event" might be some bad cataclysm, or it might be some major good event, depending on the world in question. We'll see.
There's never a shortage of ideas, though, and going with a more fantasy/sci-fi mixed setting, while keeping elements from the real world, gives us pretty well the ultimate in flexibility. That lets us tell all sorts of stories, which of course is the big goal here.
The Minimap Visually, the minimap looks the same as it did last time. But functionally, we've changed a lot with how that works.
The system we were using before was to have "points of interest" that were these little black doohickeys on the ground with a red glow that you had to walk near to. When you did, the red glow would go out, and you'd get some EXP, and the minimap would reveal a piece of itself that was tied to that POI.
In practice, this made exploration an enormously time-consuming and annoying activity. Finding a little tile-sized POI object in the middle of this giant overworld region was not fun, not fun at all. And the way that the EXP was gained actually had some problems with that as well, but I'll get into that more next time -- some general changes coming with EXP.
So what we did to solve this problem, anyway, was that we got rid of visible POIs but kept their sort of segmentation for the map. So as you walk around the map, whatever segment you happen to be into gets revealed as soon as you enter it. This makes exploration comparably straightforward, and prevents you from ever having to scour around an empty field looking for some tiny object, for instance.
The minimap is so insanely useful because it helps you efficiently navigate; and the new segmenting system still keeps the fun of exploration because on intricate twisty maps you still have to find your way around obstacles, etc. So this works out as a very nice balance, and best of all when we're playtesting now the exploration just feels right, and feels fun.
Also, as a convenience we've made it so that doors to buildings that you (or another player) have previously gone through now show up as green instead of red on the minimap. This is sort of an auto-breadcrumb feature, but we're also going to have manual breadcrumb features where you can magically mark places that are notable or that you want to come back to (or that you don't want to come back to, if you prefer).
Lastly, the entrances on the minimap are now actually drawn where the entrances are, rather than centered on the entity housing them. This makes the minimap yet another bit more informative (so you can tell when a building has two side entrances, etc).
Evil Outposts
These aren't 100% complete yet, but their structure is in there now. Essentially, these are dens of bad guys that harass your settlements or cause other trouble. These are less notable than an evil overlord lair, but still cause a lot of grief to whoever they are bothering. You can undertake to destroy these outposts, or you can actually use friendly NPCs to soften the outpost up before you go in. The mechanics of that we're keeping under wraps until you get to try it in beta, but we're very excited about it. Hey, we've got to leave some things for you to discover in-game right?
Explorer NPCs
The game now supports NPCs that are explorers, and which will go out looking for things. This is very useful, because a lot of important things in the game aren't apparent on the minimap until some player or NPC has found them. You can control where NPCs explore by where you place wind shelters, which adds a bit of a strategic layer to this part of the game.
If you're looking for an evil overlord outpost, or some new settlement to visit, you can have NPCs go and try to at least locate that stuff for you, rather than you having to search completely manually yourself. Or if you're one of the "kill everyone I meet" sort, you can of course do the exploring on your own time.
Settlement Changes
At one time I believe we were saying that the only survivors in the world would be scattered NPCs that were alone or in very tiny groups. And that any settlements that existed in the world would be ones that you'd create yourself. That's changed.
In practice, we found that this would just be too tedious. Creating your own settlement from scratch is fun and interesting, but not if it's something you have to do a lot of times in succession. So our goal is that you'll want to do that at least once in your playthrough, but that it won't be a regular thing.
Instead, you'll get to focus on the more fun mechanic, which is shepherding, customizing, and growing settlements. Getting them started is the boring part. Consequently, there are now smallish settlements (at the moment, about 5-10 NPCs starting out in most) scattered all around the map as you explore. As noted above in the Explorer section, these won't be obvious as you're moving about on the world map, so you can either explore deeper yourself to find them, or use the explorer NPCs to make that process quicker (trust me, there's no shortage of things for you to explore directly, so having the NPC take on some of the grunt work doesn't lose you anything but a grind!).
Visual Additions
* Many spells and such are now able to ripple grasses and other plants like that as they pass over them.
* When your character has died, a status message at the top of the screen now says "[Name of Character] has perished. Press confirm to choose another."
* Similar context-sensitive info messages at the top of the screen are now shown when you can pick up a player bag, talk to an NPC, or are standing in front of a door you can go in through.
* Monsters, NPCs, and player characters now have (usually single-frame) hit and magic animations that get played. The hit animations for players usually involve a ducking hand-motion as the player telekinetically thrusts or slashes a glowing weapon. For spells, the pose the character takes varies quite a bit more, which injects some more visual personality into each type of sprite.
** These animations are super fast, well under a second, which is why they only need to be one frame. That makes it so that they don't take up much time or cause you gameplay lag of any substance, but the positive impact on the feel of the game is really great. It's a lot more immersive this way. This was another big item that took a lot of code additions to get working.
* Bats now barrel-roll when they hit the player.
* Espers now have a spin visual effect when they are attacking the player.
* When entities die, they now collapse into the ground in a paper-like fashion, making for a much more satisfying effect when trees and other large objects are shot, in particular.
* Extensive, extensive work has been done on "cross chunk transitions," which basically makes all the objects on the screen collapse into the ground when you leave, and then all of the new ones shoot up out of the ground when you come back. The ground itself is fading in/out to black as it does so, so it's a very neat look that adds a unique flair that's only possible with the specific sort of visual style we have going on here. I'd say it looks sort of like a popup book as it does this, but that sounds childlike and un-cool. This is something that looks really fun and that I could just watch over and over again (and have, while getting all this working). This was another really big job, but it makes the game feel vastly more polished to play.
* Added in a new fancy visual effect for when new tiles are discovered on the world map, causing them to swirl around and then settle as they appear.
* The game now supports non-square textures (that are still powers of two on each side), which makes for some slight loading speed improvements as well as some render-speed improvements.
* When player characters pick up something like dropped loot, they now briefly stoop to do so (for a quarter second or so) and stop moving as they do so.
New Spells
* Teleport uses a tracer object that moves quickly for 0.25 seconds, and then teleports the character to the location of that tracer object. Thus teleportation through solid walls and such does not work, but teleportation across chasms and water does.
* Ball Lightning is basically a more powerful fireball that is a bit slower to use and also wider, which is worse for small areas but easier to hit moving targets with. It's also more expensive to make and has very different (and cool) visuals. It's not really that exciting compared to other spells I have planned, but the visual effect was something I stumbled across by accident while doing teleport, and I figured this would be a fun "minor variety" sort of spell.
And Lots Of Other Stuff
There were also lots of other bugfixes and internal tweaks and changes, but I won't bore you with that list. It has things such as accuracy of coming out of doors, not letting energy lances slide around objects, making light snakes not collide with entities, making object collisions multi-source for mob situations, and the list goes on.
I try to keep to the more interesting stuff here, but once we hit beta the lists of changes in each version will be all-inclusive as our AI War fans are used to. But so far there's just no point in doing that here, as that's only relevant notes for active players.
I'll have a full developer diary #11 (no video this week, though) posted in the next day or so. However, first I want to talk about interior floorplan generation. This is something that I'm going to release as an open source example program in a month or two, once it's fully polished.
This past week has been both the most productive and the most mind-numbing that I can remember in a long time, for me. That's a really odd combination, no? Well, there's a reason that I've been putting off the interior floorplans work for A Valley Without Wind since March.
Discarding The Map-With-Variances Approach
Initially I had thought I would do a map-with-variances approach for interior floorplans, basically a similar version to what we are doing for external overworld chunks. The problem is, while outside wilderness areas are nice and blobby and organic and lend themselves well to that sort of approach, interior floorplans really don't. The first time somebody sees the bathroom opening directly into the kitchen, or finds a conference room that can only be accessed by passing through a small storage closet, the jig is up.
Then there's the problem that I have to model building interiors based on exteriors that are pre-rendered. What I mean is, the vague shape of a building (ignoring windows) needs to be the same as the outer shape you're seeing in the overworld chunks. If the exterior walls are angled in the pre-rendered image for outside, they have to be angled inside, too. If the door is in the front center of the building, then it has to be there on the inside, too. If your building is rectangular or square, tall or short, and on and on. And that's before you get into function, even -- houses look one way inside, office buildings another, etc.
We've only got maybe three dozen building graphics so far, and lots more are planned, but already we have a staggering number of combinations of shapes, which was going to make that map-with-variances approach an incredibly intensive amount of content generation, as well as profoundly disappointing to players that expect something procedural. Externally, our map-with-variances approach works so well because it augments the procedural generation techniques, providing more variance through complex human-created inputs than a pure-procedural approach is likely to make. Internally, the variances would be too small because of the need to make the whole structure make some sort of human-constructed sense.
Examining Existing Fully-Procedural Approaches
So my next thought was to just go fully procedural for the interior of the buildings, after all. I started cooking up some ideas for how to do this, and then decided to do some research. And that quickly shot holes in pretty well all of my ideas. Turns out that this has been a much-studied problem, and there is even one guy who did his masters thesis on how to model 3d house interiors -- just houses, not any other kind of building. There were some other scholarly papers on other forms of building interiors, but most of those were behind paywalls and were likely to be full of examples in math, not code. I think in code, not math.
This was mostly stuff for 3D models, though, anyway -- much more complex than I wanted. I turned instead to roguelikes, which are a very well-understood form of interior generation, with a lot of different kind of algorithms. Last fall I got into procedural maze-generation algorithms for some of the latest AI War map types, and these roguelike algorithms were only somewhat more complex on the whole.
The problem is that the maps they create are full of holes. If you've ever seen a roguelike, you know what I mean: most dungeons have a room, with some hallways off of it connecting to other rooms, and all of this is floating in this big, empty blackness. The overall extents of the rouguelike dungeons tend to be unpredictable, there's all sorts of non-accounted-for holes all throughout the map, and it definitely doesn't conform to any sort of exterior building shape.
Perhaps the simplest example of these approaches was one by Jason LaPier. Here's his Javascript example that you can play with in your browser, and here's his blog post about it. I was attracted to his approach because it was very simple and was able to take in human-created data points in the form of room shapes, which would allow for a lot of flexibility even after the initial algorithm was complete. However, it still suffered from all the drawbacks (for my purposes) of any roguelike algorithm, in that it created a roguelike-looking dungeon. Which wasn't my goal.
Setting: Creating Unique Architecture
Before I continue on with my technical explanation, there's something else that I'd like to note: namely, that as I was looking at all these methods for making both fantastical and realistic building interiors, I realized how much more interesting the fantastical ones were. Houses and offices are actually kind of boring buildings, when you get right down to it.
That's why you see games like Left 4 Dead having all sorts of passages blocked off and destroyed, and parts of the buildings collapsed, etc. Normally most buildings are meant to be as easily-traversal and non-maze-like as possible, for the sake of usability. We want people who enter an office building to be able to get from point A to point B as quickly and simply as possible, in the real world. In the game world, it's far more interesting for players if the path from point A to point B is as convoluted and challenging as possible (well, within reason).
This is something I'd run into in the exterior areas, too. Normally, in real life, when you're in a big field of grass or in the woods... you can just pretty much walk any way you want. Sometimes there are bushes, but you can go through them if you really want to. And going around is rarely far. Most of a grassy field is going to be hugely boring to you, because it's all just the same grass, essentially. What made the exteriors in AVWW suddenly take on a life of their own is when I started to diverge from reality -- making lots of little streams, lots of chasms, and various other obstacles to get in your way.
Suddenly the exteriors felt mildly to majorly maze-like (depending on the area), and were a lot more fun and interesting to explore even without having more interesting points of interest yet. That was a really key thing for me to learn. And if you look at something like Minecraft, you can also see how effective the terrain-generation is there, too, even with very few types of terrain. This is also something that really adds to the attraction of roguelikes, I think -- because their dungeons are very abstract and unrealistic, they are also very maze-like and excitingly unpredictable. They feel like somewhere you'd be chasing after dwarves or orcs, not like someplace you'd be doing your taxes.
With all this running through my mind, the choice was easy -- this game needs to take a more fantastical turn when it comes to interiors. Instead of trying to model real house floorplans, let's model house interiors that are as interesting and crazy as possible. Floorplans that have all the parts you'd expect -- kitchens, bedrooms, bathrooms, etc -- but which are built to be intentionally game-like and thus maze-like.
A lot of games that are trying for realism just use the aformentioned techniques of building damage and rubble to accomplish the same effect, but to me that just wouldn't provide enough procedural variance. Players can tell when the floorplans are boring but rubble is just moving around. Of course it's still my upcoming of challenge to actually populate the buildings with interesting things, but right from the floorplans on up I wanted to have buildings that felt unique, unpredictable, and excitingly foreign. Like a roguelike, then, but without all that soupy blackness between rooms and halls.
Crafting My Own Approach
The things I really liked about LaPier's roguelike example was how he defined his room templates as char arrays that were easily human modifiable, and how he randomly mixed them up on a row-by-row basis to create random variances. Since he graciously released his Javascript code under the MIT license, I decided to start with those pieces as a core for my work, and go from there. Instead of doing halls and such in his fashion, I'd do something of my own.
The other challenge that I was going to have was that we use a faux-3D perspective in AVWW that is identical to most SNES RPGs but very divorced from anything roguelikes are doing. As with most maze-generation algorithms, they assume a flat grid and walls that take up exactly one tile each on the grid
What I had to do was somehow implement walls that had perspective, which meant that side walls would be one wide while top and bottom walls would be three high at minimum, but preferably not more than three high without converting into side walls or a big ceiling block above a certain point. What a challenge!
This was the other reason that I really liked LaPier's approach: I could build those elements of faux perspective into the room templates themselves, which would give me a good start on having a correct map once they were seeded in. Then I'd just have to figure out a new way to add doors and hallways, to make sure everything was connected, and to correct all of the literally hundreds or thousands of perspective errors that were likely to result from just plopping everything together in this fashion.
So that's what I sat down to do, a week ago.
The Process
This is the process that the interior generator goes through, in sequence:
1. The type of floorplan is based on an enum, and the size of the overall floorplan in width and height is encoded into the enum name for the sake of brevity. Note that these sizes are inflated compared to the actual size that the building appears to be on the outside -- common to most RPG games. That gives us much more interesting interiors, and exteriors that we can actually see the whole of.
2. A random seed is passed to the FillMap method, along with the InteriorGenerationStyle enum. Given those same two inputs, and the same desired floor (Z Index), the result will always give you the same map, which is helpful.
3. The first mapgen step is to set all of the InteriorGenerationStyle-related variables, which includes defining the broad profile of the building's outer walls to match the exterior. This also places the exterior doors or ladders. For side doors, since you can't see those in the exterior graphics in the game, those can be placed at any Y offset along each wall.
4. There are a couple of different room templates that I have defined in a similar style to what LaPier was doing. Which are used varies by InteriorGenerationStyle as well, and I have four different possible definition types. W is "provisional wall," C is "provisional blocking ceiling," b is "provisional non-blocking ceiling," period is "generic floor," and blank space is "hallway." At this stage in the process, that's all we need. I'm not defining room types, and I'm also not defining possible door-points.
5. For buildings that have more than one floor, it decides how many floors they will have between min/max values for both the upper and lower bounds. It then clamps the requested floor to the actual floor bounds -- so if you request floor 0 and the max floor is -1, you get floor -1 as your topmost floor (so, this would be an underground building, like the ice age hatch).
6. Now we actually cut staircases between the floors. Starting at Clamp(0) floor, it starts deciding where to place floors, and then it recursively moves toward the floor you actually requested, collision-detecting and stripping out two-floors-away staircases as it goes. The result is that you wind up with staircases that are always lined up perfectly and never sitting on top of one another. Beyond that it's a little hard to explain, so I'll leave the code to speak for itself on how exactly I made that work, when the code is released.
7. Now that we have the outer shape of the building in place, the doors or ladders to the outside, and the interior staircases, it's time to actually start filling in walls and rooms and hallways. To do this, I use LaPier's method with a few modifications: I don't intentionally leave space between each room, and when there is leftover space I distribute it completely randomly in the X and Y bounds of each row. I also randomize the list of rooms per row after all of them have been picked, so that there isn't a trend of having smaller rooms to the right of the building.
8. Step #7 happens in isolation, in a completely different code structure from the actual building I've been building so far. What I wind up with is an identically-sized LaPier-method overlay of rooms with no external shaping that I can plop down on the staircases, the doors, and the exterior walls that I've defined so far in steps 1-6. During this step, I never overwrite the actual existing building structure that we've defined in those first six steps. The staircases, the doors, and the exterior walls cause all sorts of disruptions to the LaPier-style rooms, and that's completely okay as that actually adds substantially to the variance once we combine the two.
9. Now I'm done with the LaPier method, and I have a perfect external shape, random staircases, doors to the outside, and some pretty interesting rooms layered about -- and filler hallways naturally develop based on how I designed the LaPier room templates, too. However, there are no internal doors between any of the rooms or hallways, and all sorts of things are inacessible and invalid. The perspective of the walls is munged up in many places, because the various room templates haven't been blended together, they've just been set next to one another. When working with rooms with perspective, that's deadly to the realism.
9.a. From here on out, we enter a master method called CleanUpInteriors, which is what I spent the bulk of this past week creating. It has 22 steps that it goes through with the "provisional" walls and floors and ceilings, and then it converts all the provisionals to actuals, and then it goes through a further 30 distinct cleanup steps.
9.b. The very first thing that we do in CleanUpInteriors is 8 cleanup steps that get rid of the most obvious problems: walls that are incredibly high or short, ceilings that are placed incorrectly, and so on.
9.c. Next, and optionally, the game looks at all of the defined rooms (any contiguous areas of GenericFloor), and it cuts random doorways between a room and anything that's not part of the room, in a random direction. Later we'll definitely be more precise about making sure everything is connected in a valid way, but this is a handy way to disrupt things early. Some InteriorGenerationStyles use it, others turn it off
9.d. Now we go through another 11 of those cleanup steps, some of them quite lengthy. The goal here is to get things prepped to the point that the overall structure of what is closed off and what is open is now pretty set. We need to know which tiles the player is allowed to traverse in some fashion in order for our next step to work right.
9.e. Having the data on traversable tiles in hand, now I use a pathfinding algorithm to find all the grouped traversable tiles that are unable to be traversed to one another. For buildings with two exterior doors, I actually use a pathfinding trick that allows for each door to have a separate set of rooms and hallways that does not connect to the other. That doesn't always happen, but it can, which is a neat variance. Sometimes one of the side doors just opens into what amounts to a coat closet, or sometimes it's just half the building, etc.
At any rate, once I have the data on where connections are missing, I add in randomly-sighted doors such that everything is connected. It makes sure that a valid connection will result from each door so that it doesn't put in excess doors, but where it places that door out of the pool of valid places per contiguous traversable tile set is completely randomized.
9.f. Now we have a fully-traversable interior floorplan, but there are still a lot of details that are messed up, and the cutting of the new doors (and in some cases, hallways) has caused some new minor disruptions. So it's time for one last cleanup step on the provisional tiles, then the conversion to the non-provisional tiles, and then the final 30 cleanup steps.
9.g. Some of these final 30 cleanup steps added in chasms (for rooms that are completely inaccessible by any means for some reason), and courtyards (for rooms that aren't directly accessible via an interior door or hallway, but instead require going under the edge of a ceiling to get into them. The chasms and courtyards are fanciful and just part of the AVWW theme; you could easily leave them as hallways or GenericFloor, at your preference, if you're using this algorithm in another game.
10. Now the game has a fully-defined, polished set of interior rooms, halls, chasms, and courtyards, inside an outer structure, with staircases up and down and exits to the outside on a single floor out of potentially many. FUTURE STEP: All of the rooms are now nicely defined, distinct from the hallways, based on being either GenericFloor groups or Hallway groups. These GenericFloor groups can instead be changed into more specific floor types, such as Bedroom, Kitchen, Bathroom, Office, etc, etc, etc.
This is actually a comparably straightforward step, although I'll have to be careful not to put bedrooms leading into the kitchen, or bathrooms without any doors. Anyway, I haven't don this step yet, which is one of the main reasons I'm not yet releasing the code (the other reason being that the numerous cleanup steps need more testing and tuning time, although at this stage they're looking pretty solid).
Post-Process
Once the above process is completed, you have a hard-won array of tiles that define an interior floorplan. It's devoid of any objects, but it lays out the rooms and doors and stairs and all that good stuff. It also doesn't really lay out anything specific about the walls or ceilings, etc.
So the game itself has to decide when to draw a front-left-corner ceiling tile, or things of that nature. These were already things I'd implemented in AVWW when I was creating floorplans by hand in xml, and it's a really straightforward bit of logic (if there is ceiling to your top and right, but not your bottom or left, draw the front-left-corner ceiling, etc).
Also, the game itself will have to go through and actually put in things like tables and beds, ovens and debris, and so on. But since the algorithm above (with the later addition of step 10) will determine the function of rooms (which tiles belong to the kitchen, etc), that makes for nicely encapsulated, relatively straightforward sub-algorithms.
This algorithm also doesn't do any setting of tilesets -- to choose what the walls, ceilings, or floors look like. That's yet another thing the game has to do, and something I'd already coded back in March. That stuff is trivial compared to actually making the floorplans, I can tell you. But the cool thing is that this represents nesting within nesting within nesting (actually deeper than that, in reality). So the floorplans are quite unique when just looked at on their own, but when you combine those with different entity-seeding logic in each room and hall, with different tilesets, with different enemy populations, and so on -- you get a pretty insane amount of variance.
Example Floorplans In My Ugly GDI+ Tester Program
Ice Age Hatch Examples 1-4
Little Shop Examples 1-4
Log Cabin Lodge Examples 1-4
Modern Ruins 3 Examples 1-4
In Conclusion
If you're absolutely desperate for an algorithm like this and this is the one you think you want, then shoot me a note and I'll send you the C# code now. But I'll be officially making the code public under the MIT license in a month or two, once I've got things completely ironed-out and step #10 in there.
The tedious part of all this was getting all the various cleanup steps tested, and tested, and tested. I had the working exteriors and interior walls put together after a day or two (most of that time spent on research of various interior wall methods), and I figured I was almost done then. What I didn't figure on was another 2,000 lines of code that would be required for cleanup alone.
In a lot of respects, this sort of cleanup very much reminds me of the sort of work I used to do whenever we had a business client with dirty data in Excel that we needed to scrub and get set up in a properly-validated database. What I didn't expect in this particular instance is that these cleanup steps add even more to the procedural variance in the floorplans. Based on everything that gets combined, scrubbed, cut, and so on, you get a ton of room shapes emerging that were never in the base room templates.
Oh, and the other thing that I should mention is that at any time I can add more room templates, and get even more variety without adding new code (same benefit as with the base LaPier method). Right now I did enough so that I could differentiate the various types of buildings, and so that I could really get a lot of starting variance, but there's lots of room for more later.
All right, that's it for now. Like I said at the top, I'll do an actual sans-video post on our overall progress on the game at this stage, but this was my big project for this period and it was pretty interesting, so I figured it was best as its own post.
