Wednesday, March 30, 2011

First Public Version of A Valley Without Wind To Be Beta, Not Alpha

It pains me to say that we're delaying the first public version, but Keith and I spent a good while talking about it today, and we agree it's for the best.  We've decided to scrap the idea of a public alpha, and instead are going to start with a public beta. 

In practical terms, what does that mean?  It means that instead of having a version for preorder/demo in 3-4 weeks, our timetable is shifted to "we don't know."  It might be May or June, or it might be even further along.  We don't have a crystal ball, but things are proceeding well so far, and we'll know when we see it.  In the meantime we'll keep you as informed as possible about both our progress and plans.

The Obvious Question: Is The Project Behind Schedule?
Not in so many words, no.  It's simply lopsided.  We have an awesome engine at this point, but not a lot of actual game so far.  We've been focusing on the technical aspects, and the construction of this infinite world itself, and multiplayer, and the basic systems for gameplay such as crafting and item use and combat.  These were the bits we were most unsure about, and the bits that underlie everything else.

In many respects, we're a lot further along than I'd expected to be at this point.  It's also high quality work: the worldbuilding code that is there is practically final, and we just need a lot more layers on top to really make a truly varied world; the parts of combat implemented so far are also really solid, and work in multiplayer, and most importantly are fun.

But that's not an entire game yet.  To put it bluntly, what we have at the moment is this fairly repetitive world that is nevertheless infinite, and which has very repetitive gameplay due to simple lack of content.  Skelebots chase you, and you fire spells at them, and that's about it.  This tiny scrap of gameplay is fun, but most people would wear it out after 20 minutes or so

Why Didn't We Start With The Gameplay?
A few people have asked why we didn't start with the gameplay first, as they've heard game designers should.  The answer is that we did -- in terms of what we designed.  In terms of what actually gets implemented first, that differs from project to project, even in AAA games.  In order for us to prove out interesting gameplay for this specific game, we had to prove we were capable of making an interesting, dynamic world to house it.  So that's what we've done.

We also had to prove out that we -- I -- could do the art in a way that looked good, and that was reasonable in the amount of time it would take.  I've done the art for some space games so far -- Light of the Spire and AI War 5.0, mostly -- but doing all the art for a game of this sort was a new challenge that took a lot of figuring out.  Until we had that sorted, we couldn't be sure we could really make this game, given our very tight budget and staff constraints.  And I think that's been successfully demonstrated at this point, as well.

We also had to implement a whole new networking model -- this one fell entirely to Keith, to my great fortune -- and we weren't sure we could do that in any reasonable amount of time.  Or what sort of refactoring it would take if we waited until later.  So we hit that up early, too, and it's working quite well if not fully optimized (aka, no smoothing or prediction).

When starting out with a brand-new project, especially a large one, you want to start with the bits that are worrying you.  The bits you aren't sure you can pull off.  If you can reassure yourself that those bits are feasible, then you can proceed with confidence on the entire rest of the project.  If you leave those uncertain bits until the last, you might be in for a nasty surprise, and the whole project might fall apart.  As of a few days ago, we've now hit all the big points of uncertainty -- lighting was the last of the brand-new things that we weren't sure about.


All Projects Start Small, Then Accelerate
The description of the gameplay two sections back might sound lame, but at one point AI War was just a game with fighters, light starships, and engineers.  I guarantee you every other game started out the same way.  At some point Chrono Trigger must have been just some empty-ish fields and a couple of repetitive  battles with one or two playable characters.  Forget all that story stuff, time travel, variety, and interesting locales. 

I remember screenshots from what turned into Ocarina of Time when it was for the Nintendo "Ultra 64," and all it involved was Link fighting a single Stalfos.  They were soooo excited about the revolutionary new "Z targeting" system they'd invented, though they didn't call it that yet. 

And they were right!  Boy was that revolutionary.  They made some amazing engine strides, and were able to do something that no game had done before.  The entire game rest of the game was designed and built around what that one mechanic -- everything from camera angles to boss fights.

But it wasn't a game yet, or at least not a very fun one.  This is more or less where AVWW is at these days.  We have a working prototype in hand, it's all sorts of unprecedented, and we're super excited about it.  But this is the game-lifecycle stage of videos and screenshots for a reason, when it comes to larger companies.

Why Were We Promising A Public Alpha, Then?
This was my error.  See, we've been doing AI War expansions and engine upgrades for the last 9 months.  The last full game we did was Tidalis, and puzzle games are necessarily smaller in scope than most other kinds of games.  The last time I was this early in to a project the size of AVWW was about two years ago, with AI War's alpha versions.  Consistently, what I had at that stage was an overgrown prototype.  I should have remembered this!

But we've been doing all these expansions lately, and that was fresher in my mind.  When you do an expansion, a funny thing happens: you can do one day of work, make a new ship or something, and then put that out as a public beta on preorder/demo.  This is no problem, because the fans already have this huge game to play with, and they are happy to get that 1 extra ship added in and see what it does.  Then every day as we do more work, we release more betas quickly, and everyone stays happy.  Before you know it, a few months have passed, you're doing balance testing and polish, and you release.  Success!

I think that this led me down the wrong path, paired with thinking about how Minecraft spent so long in alpha (and I think I read it went into alpha after only one week of development, if I'm not mistaken).  Minecraft is another one of those special cases: it has an enormous creative component, so players could have fun in the sandbox of the game even when all you were doing is digging up dirt and rearranging it into houses or whatever other patterns.  Minecraft could start out extremely primitive in its first versions because of its very nature, but you can't build anything out of skelebot corpses; there has to be more of a game here right from the start.  It's not better or worse, it's just a different kind of game.

Why Not Release A Public Alpha For Those Who Really Want It?
We were criticized for releasing our first footage and screens of AVWW too early, in too raw a state, and I'm still on the fence about whether that criticism was entirely correct.  Some of our fans were really salivating for anything we could show them, and in the end it turned out we got some really useful feedback that helped us to improve our graphics in a way I might not have thought to on my own.

Regardless, I'm increasingly coming to feel that it would be a colossal, perhaps unrecoverable mistake to release any playable build of the game "too early," whatever that subjectively means.  The obvious reason is that the press, and people with a passing interest in the game, might download it and not like it in an early, unpolished state.  But even when it comes to the fans who are most excited about the game, there's this problem: an alpha could never live up to their expectations. 

The press would actually probably be more forgiving, because they at least are used to seeing early builds of game software -- they know how the hotdog is made, so to speak.  But when it comes to the hardcore fans, they want what we've been promising -- but it isn't done!  They want settlements and to see a big interesting world that you can explore around in, and they want NPCs that they care about, and intriguing bits of story, and goals that actually matter.  They want to be able to affect the world in ways that are lasting.

So... should we hand them a game with a few enemies, basic sketches of interiors and exteriors, no real overarching goals, and no memory-of-deeds system?  That's insanity.  Those fans that have been around us a long time, and have seen us develop games before, know the process and would probably give us the benefit of the doubt that we'd make a good game.  In their view, we've done it before.  But the excitement would be gone.  It wouldn't have done them or us any service.

So Is The Project On Schedule Or Not?
Oh, yes, it's very much on schedule.  Our goal is 1.0 in October, and that seems imminently hittable.  The engine is vastly further along than I thought it would be at this time, and we're finally getting into the vertical development phase of the game in several areas.  We have all the basics of the explore/craft/combat trio down, and those are fun and simple.  We even have the very basics of NPCs.

What we need before we start showing this around in a playable format, though:

1. A lot more content of all sorts.  We've already been planning that for the next 3-4 weeks, and those plans haven't changed.

2. For the game to set dynamic goals that the player actually cares about, in terms of them being able to help out other NPCs, or find the lairs of bad guys and kill them, or whatever.  We don't presently have this at all, and there's no way we cold do this in 3-4 weeks on top of #1.

3. For the game to remember past events in a meaningful way, so that the whole benefit of the perma-death system becomes clear.  This in turn feeds back into #2, and there's a cycle of complexity here that we need to sort through.  The engine is ready and waiting for this, as is most of the design, but we have to actually put this in place.

4. Ways that the players can strategically affect their world.  As of today we have the basics of the wind shelter system, which is a great stride forward, but that isn't enough (and it isn't even fully finished yet).  What we really need are settlements, as well as the more complex interactions with NPCs that are related to #2 and #3.  And that also requires more crafting and other forms of content from #1, to really make it so that the player has enough choices for there to be any strategy to it.  See how this all interrelates?

5. More ways for the game to set up obstacles for you, that you can then overcome.  Even simple things like locked doors provide a surprising amount of  interest, because those represent something you can't do until you solve whatever puzzle is associated with the door (find the key, or the lever, or whatever).  That's a superficial example, but a lot of this also comes back to having notable arch-foes and the hopes of characters that you can work toward solving... again, speaking to #2  and somewhat #4.

When all of those things are in place, what we will have is a "broadly feature complete" version of the game.  In other words, all the major points of horizontal development will be done.  We'll still have loads of work to do in terms of adding yet more content and fun stuff to do, plus plenty of polish, and I'm sure other subsystems and points of interest will come up if there's time.  But when we hit those milestones, that will be a game that is varied and interesting for at least a few hours, if not far more.

That's when we'll start needing player feedback and content.  Right now the code changes enough that we don't really want custom content that will all just have to be changed, anyway.  That stuff needs to stabilize before we invite in a ton of people.  If I was a player giving feedback on this current version of the game, my feedback would be summarized by the above blog post.  Those are the largest "problems" with the game, and they all are simply factors of it not being done yet, like with the Stalfos battle in the Zelda prototype.

Players can't give us meaningful feedback until we actually have things a bit further along, I'm realizing.  Otherwise the incompleteness of the current builds masks everything and adds way too much uncertainty.  That's a new thought for me.

Just Sum It Up, Please: How Is The Project Going?
It's actually going really, really well.  The engine works and is in excellent form, and we've got the beginnings of content development going on.  What's there is cool and fun, but it's not yet nearly enough for anyone to really have a good time with it yet.

It's going to be a while yet before we hit that critical mass.  There's always a tipping point when a game goes from "promising prototype" to "this is an non-final build of a really fun game, and it's already fun."  We'd be stupid to release something that wasn't in the second category; I don't know how the press would react, but I know our biggest fans would be really let down.

What Comes Next?
It's quick for me to do textual posts, and to some extent screenshots or at least sprite samples, and I'm going to try to do more progress reports along those lines.  Videos are vastly slower, and are something I don't think I'm going to try doing any more regularly than biweekly.  Erik, our PR guy, may start doing some videos before too long, to take some of that burden off me.

In terms of when we will hit public beta, the answer is that we don't know.  It's really up in the air.  I would be really surprised if it is in May, honestly, but you never know.  I also would be really surprised if it is in August or after.  My best guess is maybe sometime in June, but that's too far out to really have any degree of accuracy.  We'll know we're ready for beta when we see it; it will have to meet all the criteria on my list above, and then I'll be happy.  Right now we're just chipping away everything that doesn't look like an elephant.

I can't wait for folks to be able to see this game, but we do have to be sensible about these things.  If it makes anyone feel any better, I've been on the anxious-player side of things my whole life.  We're telling you now because we didn't want to string you along with "oh, it will be next month" every month.  As a player, I always found that supremely annoying.  I never quite understood the dynamics of what the developer was going through until lately.  Live and learn! 

A Valley Without Wind: What's The Deal With Perma-Death?

When it comes to the perma-death mechanic, the one thing I want to make most clear is that this has no bearing on the difficulty of the game, despite what some folks might expect.  In most games with perma-death, that means that the game is very hard.  How difficult or easy this game is depends more on how far you push out into the unknown, how many risks and such you take, etc.

No Do-Overs
Rather, the perma-death here is basically just taking away that convention of "oops, you messed up, time for a do-over!"  There are no do-overs in this game, except in the sense that there is in real life.  In real life if you lose your job, it's not like you can never get another job -- you can.  And you might even be able to get your old job back, under certain circumstances.  What you can't do in real life is say "oh, actually, I went back in time and now I never lost my job in the first place!"  So in real life you have the ability to try to correct past mistakes in various ways, but you can't erase them from existence.

That's very true also in AVWW, in terms of the general design of the game.  There is no way to save your game -- things just get persisted to disk as you play, and as you exit, etc.  So that's important because you can't just reload your last save if something happens that you don't like.  As with Minecraft, you can back up ALL your world files if you want to be able to save-scum, but it's really a lot of files and not something we make at all convenient.  That's counter to the idea of the game.

What Does Death Really Mean Here?
Going along with the above, death is the biggest mistake of all, of course.  You did something that wind up getting "you" killed, and now "you" are dead.  End of story for that character.  But you-the-player of course continue on, and so does the world around your character.

You aren't even particular punished for losing that character: their inventory is right where they died, so you can go get it if you want.  No rush, even.  It will sit there without disappearing for as long as the game world goes on.  In general, loot drops and other dropped items in this world never disappear unless someone picks them up.  Because of the fragmentary way we save the world, this is easily possible while still keeping memory requirements quite low.

That's what I mean by persistence: even that little scrap of wood that came out of a tree that you can use for crafting will sit there in the world forever, until somebody does something with it.  No fading-out of drops after a few seconds here.

Anyway, back to the death thing.  So you do lose your inventory, but it's really not lost, because you hopefully know where you died.  In terms of experience points you've gained, and the level of your character, however, none of that is lost.  All experience and levels are actually larger than your character, anyway -- in multiplayer, all players share experience and levels between them, it's a global thing not a per-character thing.  All the neutral-or-allied-to-you NPCs also share all this (monsters, obviously, do not).

So when you die, you choose a new character, and that's that.  They come back with some basic equipment appropriate to their level, as well as the same level as the character that died.  If your character was using some good equipment, you can go get it at your leisure.  If you have a stash of equally-good equipment closer by, you can just take that instead.  Equipment gets obsolete before too long anyway (since it has levels as well), so you're always building newer and better spells, weapons, traps, etc.  Losing some equipment in the middle of some bad guy's lair isn't a crisis by any stretch, if that's what happened to you.

This Is A Really Forgiving Game, But Death Is Everywhere
There is no way to lose in this game.  As in, there is no way that "the world ends and you can't play anymore."  You can lose -- and boy, will you -- when it comes to smaller and larger objectives you might find.  Attacking some bad guy's keep might lead to a real pile of graves in your graveyard, and a real depopulation of your NPCs as you take each one over, try to kill the bad guy, and die (probably you should get yourself stronger before going after that specific bad guy, apparently).

Most players will die as much as they level up, if not more.  It's a really tragic sort of scenario here, for a lot of the characters.  But it really depends completely on how you play, which brings us to...

The Difficulty Is Self-Tuning
The world of this game is normally a really dangerous place, but if you stick close to home, and stick to regions that are at or lower than your level, it's actually not that dangerous.  But the rewards are smaller there, and what's the fun in that!  Most players that are looking for challenge will go out... looking for challenge.   And they will find it!

But for those players that are cautious, or less skilled, or just want to have a more relaxed time, you can do that, too.  You can just hang out in Kokiri Village the whole time in Zelda if you want, and you hardly get attacked.  But that gets boring pretty quick, because there is not much to do there.

In AVWW, you can opt to level up without engaging in combat (based on exploring instead), and you can just stick to the relatively safe areas, which have all sorts of interesting nooks and crannies, if you like.  And as you level up, more of the world becomes "relatively safe" for you.  So to extend that Zelda example, it's like if you had a very large Kokiri Village that had some low-level monsters, and which got bigger the more you explored around.  You could play the whole game that way if you want, and it's a slower, more peaceful, less stressful way to play.  It's perfectly valid!

Then again, I think most hardcore players are just absolutely happy when they get out of Kokiri Village the first time.  I know I was itching to get out.  If "Kokiri Village" is large and ever-expanding in this game, that's absolutely dwarfed by the dangerous parts of the world.  And that's where all the really interesting rewards are, too.

Most players will, I think, strike some sort of balance between the safer regions and the more dangerous ones.  The specific balance will depend on the player and their preferences -- even how they are feeling on a particular day.  Sometimes I'm spoiling for a fight, other times I just want to explore around and find some useful smaller goodies, as well as do a bit of crafting or something.  You don't have to play the same way each time you sit down to the game.


The World Lives On
I've mentioned before that the goal here is that you can only play with one world for as long as you're in the game, if that's what you want to do.  Some players want to have multiple worlds, and that's perfectly fine and supported.

But there should never be a point where the world says "okay, that's it, you're done and you need to start a new world now."  There also should never be a point where the player says "okay, I want to play with feature X, but I need to start a new world to do that."  You can do anything in one world that you can do in another, no matter what the history of the respective worlds is.

The cool thing about having a world that is long-lived is that you build up a history there.  Not some random facts about the backstory of that world; that's not that interesting.  Instead, you build up a history of what you did in that world since you got there.  Players of AI War know pretty much what I'm talking about.  Know how some planets there take on a significance to you alone, because of one (or more) epic battles that were fought there?

In AI War, of course, all of that is in the player's mind.  The game doesn't really keep track of the history of each planet, because that's really just not the focus of that game as a military strategy title.  With AVWW, however, it's all about the world and the characters in it, and what those characters do.

If you have some character who was really accomplishing a lot and then died, the other characters will react to that.  We're thinking about adding funerals into the game, for several good reasons I won't go into here (you don't have to attend with your new character if you don't want to).

Similarly, if you've been going around murdering lots of good NPCs with your character, and that character is really hated, then there might be a celebration that the evil guy -- you -- is dead, rather than a funeral.  And your new character has their own past, and isn't really associated with those evil actions you took while in control of your prior character.  The slate is wiped clean.

In that sense, you really are sort of like a puppet master.  You're one character at a time only, and the only way to change characters is for your current character to die.  But while you are "in character" for one individual, you can do whatever you like.  Do bad deeds, do good ones, and the game will remember.  The narrative of the world gets built up through what happens in this sort of fashion.

Many Of These Features Are For Beta
Just one note of warning: a lot of the features having to do with the hopes of NPCs, the deeds of player characters, and basically the narrative of the world in general, are all what we're targeting for beta.  In early alpha, our focus is completely on the exploration and combat and crafting and all that sort of thing, which is a large enough topic by itself.

Perma-death is already there, and works as described except that there is no memory of what that character did (and no graves quite yet).  But this game is being built in layers, and the first layer is the physicality of the world and how you interact with it.  The second layer is the narratives that get told in that world.

Just so there's no confusion when it comes time for alpha!

Tuesday, March 29, 2011

A Valley Without Wind Pre-Alpha #8 -- New Lighting Test



This video is just a simple lighting test showing off our new way of handling light in AVWW. The older method, using the z buffer, is still available for lower-end graphics cards and computers, but this new model looks way better, and on most computers won't use that much more CPU/GPU!

What We Were Doing: The Z Buffer
The problem with the Z Buffer method is that it winds up with very pixelated edges.  That buffer doesn't support anything except binary write / don't write data, and that's not super conductive to having high quality lighting.  The plus side is that it's super compatible with older graphics cards, and it doesn't use much at all in the way of GPU power.

The #7 video was using the z buffer, but was also using a trick for the "eyesight" part of the view to make it look like a gradient when the z buffer doesn't really support that.  The trouble there is that you can't do that with anything that overlaps in the z buffer; so I could do that for eyesight, but not for lights.

What We Tried Before The Z Buffer
Why not just use the normal 3D lighting model that most 3D games use?  I tried it, but the problem is that this is a 2D game being rendered using 3D quads.  That just really didn't work out, because pixel lighting is incredibly expensive on the GPU, and not supported by every card, while vertex lighting is incredibly coarse and looks really bad.

To make matters worse, the way that we draw things in Unity 3D is by using their Graphics.DrawMeshNow method.  Supposedly that supports lighting, just not certain kinds of lighting, but my experience was that even vertex lighting was fraught with errors.  Based on the materials in use, I'd get random aspects of the lighting shutting on and off in various parts of the scene.

I tried using Graphics.DrawMesh instead, but that in turn doesn't support things that I need to do with uv animations and such for textures.  As I discovered with Tidalis and AI War, Graphics.DrawMeshNow is basically the only possible solution that has any substantial speed for the number of sprites that we need to draw, while also supporting all the functionality we need in terms of fancy texture mappings.

So that meant that a traditional lighting model was basically out.

The New Method
The new method is actually conceptually simpler than any of the others, and doesn't really do anything new technology-wise.  I thought of doing this from way back, but never thought it would look very good or perform very well.  After the #7 video, and some prompting from long-time Arcen community member eRe4s3r, I decided to at least give it a shot.

What I'm actually doing for perfect darkness is rendering an array of big black circles with fading-to-transparent radial gradient edges to them.  These circles are about 256 pixels in outer diameter, but on the pure-black internal diameter they are about 64 pixels.  Each one of these is rendered in a grid that is screen-aligned and 64 pixels per grid tile.

Talk about an inefficient way to draw blackness!  But the cool thing happens when you start "carving out" blackness where there is a light source.  Every frame, each light source writes into that big screen-aligned array if it is providing some light to it (in a framerate-independent manner, of course).  Also every frame, at about half that rate, each tile loses light.

The longer the light is in one location, the closer towards perfectly-invisible that black circle on all the tiles near it get, until they disappear and it seems perfectly bright.  Since the images drawn in each tile are so much larger than they need to be, their gradient edges "hang over" into the nearby tiles.  I also have each image pulsing by about 10% on a 4x speed sine wave, which makes the edge of the darkness seem to pulse in a living, threatening manner.

The other effect of all this is that when you turn move a light source, it takes a minute to fade.  About half the time it took to create the light source in the first place.  This means that things like the fireball, which flicker and sputter in a seizure-inducing fashion if there was no slowdown, instead look graceful and almost liquid.  This is darkness with substance, which is a pretty neat stylistic effect, and in keeping with the visual style and themes of the game.

How Does This Integrate Into The Game?
This new effect adds a lot of extra draw calls into the game, and so on some very old GPUs it might stutter some.  These would be the same computers that would need to turn shadows off in the game, and might even need to turn foliage down.  To make sure those sort of machines can still play the game, we now have a settings option where the lighting model can be chosen.

The z buffer method is functionally equivalent to this new one, it just looks worse, but it's more efficient.  For people with astronomically large screen resolutions, they may also prefer that, as the cost of this lighting model gets linearly higher with the number of pixels in the screen resolution.

On our test machines, we haven't found this new approach to be very heavy at all, though, so we suspect most people will leave this turned on by default, as they will shadows, foliage, and so on.  If you can comfortably run AI War, you can comfortably run this, too.  But in terms of netbooks and other smaller computers that can run Tidalis but not AI War, let's say, we also wanted to have options for them with AVWW.  So far it seems we do!

Friday, March 25, 2011

A Valley Without Wind Pre-Alpha #7 -- Lighting, Lava, Deserts, and Interiors

Here's the latest video:



The latest screens are collected on the A Valley Without Wind page.

What's New In This Video
This is the game after 10 weeks of development -- we missed a few weeks in there for videos because we were really tangled up with it!  Quite a number of the things in this video are worth pointing out, so read on below (note that the screenshots shown don't correspond to the actual video stills -- you'll need to watch the video itself to see that).

0:03 -- you can see the new lava flats region, although I'm thinking about adjusting some of those dead bushes so they're a bit nicer-looking.  You can also see the new Neutral Skelebot character, who works as an NPC or as a player-character (as all NPCs in this game do).  You might also notice that the enemies in this region are level 517, while the civ level is only 33, so it's pretty much instant-death if they catch me.  And my fireballs do approximately nothing, too -- this is an EXTREME example of playing at a higher region level than your character is supposed to be able to.

0:14 -- This is one of two tilesets for ice age interiors, but it's just a testing floorplan that I was using to verify all the ceiling stuff works well and is easily scriptable.  That was a huge amount of work in the last few weeks, but it's finally easy to define custom floorplans via our chunkscript system.  This makes it so that players can design their own floorplans which get randomized, too.  Unfortunately I never did have time to  actually start populating anything IN the buildings in terms of objects, furniture, etc, which is part of what delayed the videos; I really wanted to show that, but in the end other things were more pressing.  That's coming soon!

0:15 -- Notice the Neutral Skelebot standing there?  That's an NPC that I can talk to, and he'll say something to me as well as craft bear traps if I ask him (he's a Trapmaker profession character).  Still lots more to do with the crafting interface, which isn't shown, and obviously we need to be able to craft more than bear traps, but it's coming along!  A lot of the more involved NPC reactions (Hopes, Settlements, and Deeds are all based on that) will be our big focus of alpha; for now they're mostly about crafting, and you can take them over when your current character dies.

0:18 -- The reason the light faded to nothing is because the new "flash of light" spell had been cast right before this segment of the video, and so it was going back to the normal state of complete darkness after the flash.  Most buildings will be quite dark inside, and what you're seeing at this point of the video is the extremely dim "eyesight view" that you always have as a bare minimum inside.  Realistically, you won't want to play in that eyesight-only mode in dark places much, so you'll light up the darkness with actual lights of various kinds.

0:22 -- Case in point, here's a "moon lamp," which is an ice-age future lamp that never goes out and requires no power.  It creates a pulsing circle of full brightness that is fairly midsized as far as lights will go.  You can see that in my inventory I happened to have 10, and I was placing them like I would a bear trap or other deployable inventory item.

0:30 -- The world map has even more regions on it now, and the graphics for this we're now starting to do in a more vibrant, less-painterly style.  The conversion isn't complete for all tile types yet, but it is for the ones shown here, and the effect is much more dramatic and HD-looking. 

These little tiles are just too small and full of detail to have a painterly effect; we leave that to in-game areas, now.  You'll also notice that there are now numbers on each tile -- these are the new "region levels," which control how difficult the area is, and the level of all the monsters in that region. You'll also notice that movement between the different map tiles is now smooth.

0:33 -- This is the new desert tileset, at least in its current incarnation.  All of the tilesets will be getting more varied and detailed with more objects, plants, and other variety as more work is done on them.  The four new regions -- desert, lava flats, temperate deciduous forest, and temperate evergreen forest -- are all "hostile" environments, which means two things.  One, they are twice as large in terms of general space compared to normal non-hostile regions.

And two, every time your character steps into one of the hostile tiles on the world map, you get sucked into them even if the wind counter has not yet reached zero.  By building wind shelters, you can move across even these hostile spaces with impunity, so you can essentially build "roads" of a sort through the deserts and forests.  The lava flats are pretty much always small enough to easily go around them, but they will have valuable things you can find in them, so that's a good incentive to intentionally visit them from time to time, hostile or no.

0:47 -- This is showing one of the Small Town regions, which is not new, but which is much improved compared to past weeks.  A lot of work has gone into improving how buildings are populated near to one another and other objects, and so things tend not to jumble up like they once did.  You can also see some of the new vehicles here, such as the giant bulldozers and the smaller sportscars.  The old Jeep is now gone; that was the one object that I'd based on a photograph rather than a 3D model, but now everything is based on 3D models originally.

0:53 -- We're back to the world map, and you can see a bit more movement around here because I'm moving around as a "ghost," which doesn't get sucked into regions involuntarily.  Ghosts are mainly something we use for testing, and I don't think they'll be playable in the public versions of the game.  You might notice that the "thawing ice age" region tiles still have the painterly look rather than the newer crisp look.  I think those are the last ones I haven't yet updated.

Normally all those dark forest and desert tiles would be hostile, remember, so my movement would either be a lot more circuitous or would be a lot more fraught with peril and side-tracks.  You won't normally move so quickly and so far on the overworld until you've spent a bit of time building up a wind shelter network.  So in a more established world, of course, you'll be able to move around just precisely this quickly.

0:59 -- Back to the lava flats again, this time a bit of a different view.  I'd like to point out the lava effect in particular as being something that's really cool that I'm proud of.  It comes across even better when you're looking at it in full-quality in-game, especially if you're not also moving.  Very dynamic.

1:07 -- Back to the ice age building interior again, to show off a different lighting effect.  When you cast light-emitting spells, they have this crazy, slightly-cartoony lighting effect around them.  I'm using ZWrite to accomplish the faux-lighting effects for the game, so I can't do smooth gradients  that blend together; so hence the more cartoony look instead, which I think looks cooler anyhow.  It took a lot to get this working right!

That reminds me -- the "eyesight effect" is something that only applies for your direct character in multiplayer.  You don't get to see your friend's line of sight, so if you are both tromping around in the dark, it remains just as dark as it would in single player.  That said, of course true light sources (like the fireball or the moon lamps) are seen by everybody just the same.  As I mentioned before, running around in the total dark isn't something you're expected to do all that often.  And since the power is just about universally out, most buildings that have roofs are pretty dark to say the least.

1:12 -- Now we see the dark forest for the first time; this is the temperate version.  This isn't full darkness, you might notice, but instead is just very dim.  You can still see the eyesight view from my character, although he's running fast and it's only dim instead of completely dark, so it's less noticeable.

What is more noticeable is that there are a couple of damaged skelebots chasing after me, and the regen effect that they are using on themselves also glows like the fireball.  A new skelebot that suddenly joins the chase would have no such giveaway, though...

1:15 -- That's me using the "flash of light" spell, which is that second icon on the bar (I've toggled it to bar 2/3, which has that, the bear traps, the moon lamps, and the shrink spell, which I'll talk more about later).

1:19 -- It's only showing "Lvl 5" so obviously about that new skelebot because I specifically switched to targeting him, FYI.  If I hadn't seen him, he could have caught right up to me quickly there.

And that's what's new in this video -- it's a packed video this time!  But there were even more new things that weren't visually shown here.  Read on for details on those.

What's New, But Wasn't In The Video
These are in no particular order:



Process Improvements
There's been a ton of internal improvements, for one thing.  Previously, after the graphics were all done for a new building or object, it was taking me 20-30 minutes to get all the code values tuned and in place in the game, which was super annoying.  Now we've put in a new developer menu that can be opened with F7, and which lets me tune all of those things directly.  That often brings the process down to 30-90 seconds on average per object, I'm finding (though more on buildings, which needs doors placed, etc, but still not long.

The floorplans definitions have also been hugely improved so that the ceiling definitions (where corners, etc, are -- and what direction external doors far facing are) are now way more dynamic.  All that pretty much happens automatically now, and in most cases the chunk script simply needs to say "put a wall here" or "put a ceiling here, with little other info.  The first prototype I did had something like 20+ different definitions, so even I was making floorplan errors left and right, and it was a really tedious process.  If we want a lot of floorplans, this has to be easy to use!

Actually, that pretty much goes for all of the "process improvement" stuff that we put in place; the only way to get a large volume of stuff into the game is to make it easy to add said stuff.  A solid week of this last three week period has been working on process improvement stuff, so that will pay off big time next week and so on, but that's one of the reasons we didn't have more art content from these last three weeks themselves (though, looking back, there's more than I thought).

Actual Character Stats
Previously, we had only really temporary and non-properly-increasing stats for the characters for things like magical attack and defense, health, etc.  This has been internally completed now so that it's actually like it will be in the final game, although the stat balance will inevitably see a lot of tuning between now and 1.0.

Each individual character has their own unique "roll" however, as in a lot of RPGs, so every individual is unique in their stats.  Right now there are only two visual looks for them, but that will also be increasing in volume before alpha, and after.

Dynamic Character Names
Previously, characters didn't even have names in our working versions, but now they're pulling a first name and a last name from files that are per-graphic, and combining them at random.  So if you have 100 skelebot last names and 100 robot skelebot names, for instance, then that's 10,000 different unique skelebot names, and that's just for the skelebots. 

As the "planet names lists" have been really popular with players in AI War, hopefully these character name lists will also prove popular with AVWW, and we should have just ridiculous numbers of character names by the time we hit 1.0.

Many, Many Region Improvements
The generation scripts for all the regions in general have been improved, leading to more varied and interesting regions even with just the assets already in place, and faster generation times particularly on really densely-packed region types like the junkyards or the grassland shanty towns.

Crafting!
The crafting interface and base mechanics are now in place.  Right now you can just craft bear traps out of scrap iron (actually, at the moment an NPC has to do it for you), but a lot more on this is coming soon. 

Our system for crafting is really simple: in the crafting menu, you have a list of craftable materials, and you can select one to see all the possible recipes that involve that material, and whether or not you have all the scrap and any other craftable materials needed to make them. 

Scrap doesn't have levels, but craftable materials do, and are more rare.  When an item is created from a recipe, it has the average level of all the materials that went into it (often that's just one single material and a collection of level-less scrap). 

This will include a lot of variations so that you can really customize your loadout based on what sorts of craftable materials you find (that way your loadout is a bit more self-directed compared to games like Diablo or Borderlands where you just get what the game gives you), but it's not completely open-ended in the way that something like Magicka is.  And none of the recipes are secret or involve any fiddling with the interface, unlike Minecraft. 

All of those other crafting systems are really awesome and work well in the contexts of their games, but we want to keep the focus on the adventuring itself.  It's possible we might have a system for slightly customizing individual crafting recipes in the future, but we're not sure.  That would probably be an alpha or a beta thing at the earliest, though.

Inventory Is Now Icon-Based, And Items Have Names And Descriptions
Getting our inventory from being base functional to actually having good usability.  I'll show screens and/or video of it once I have time to make it pretty, but it works quite well and is very quick to work with, which is a big plus.

NPC Dialogue
Think of how it is to talk to NPCs in Final Fantasy 6, or Chrono Trigger, or Zelda 2.  This is basically like that.  Each NPC says one single thing, and that's it.  If you come back after time, they'll eventually have changed to say something else.  In some cases, they'll say different things to different characters based on the context.

There won't be actual dialogue interaction of a significant sort (nothing in the Western RPG tradition), but once we are into alpha and we're working on the Hopes system, you will be able to hear more about the desires of an NPC, and help them out with those if you so choose.  And of course later interactions involving inviting them to Settlements and all that sort of thing. 

Right now it's just the basic chat with them, and they can do some crafting for you, and that's probably what our end target for pre-alpha is going to be, as there's a lot of other more gameplay-centric content that needs development before we get into the more advanced NPC systems.

Perma-Death
Our system for perma-death is now fully in place -- when you lose one character, they are gone forever although their bag of inventory is dropped where they died.  Experience gain and civ level is global, and survives past any character.  After one character dies, or at the start of the game, you choose a new character and from then on are them (until they die). 

At the start of the game you just get a trio of random characters to start with, and at the moment that's what happens after death, too, but later you'll be able to assume the roles of actual NPCs you've interacted with.  You'll also get permanent graves and such later on, but to some extent that's the very first part of the Deeds system, which is going to be one of the three foci of our time in alpha.

Improved Particle Effects
All of our particle effects have been altered and improved, particularly when shown against light-colored backgrounds.  They now include under-layers that let them work additively, but without "whiting out" against backgrounds that are too light.  In snow areas and inside ice age buildings, the effect is quite dramatic.

New Music
As always, there's a bunch of new music.  The new track from the video is the lava flats theme.  It's really good stuff!

Shrink Spell
One thing that we want to allow players to do, if they are inclined, is to customize their world.  You can't reshape terrain or raze buildings, but there are a ton of destructible objects (trees, shipping containers, broken vehicles, lamps, etc) all over the place.  You can destroy these... but what if you want to rearrange them?

That's where the shrink spell (pictured right) comes in.  It doesn't work on enemies or on indestructible objects (like buildings), but for any smaller objects it lets you shrink them down and put them in your magic bag. 

They then show up in your inventory as "Grow Gems," which you can use to re-inflate the object at a place of your choosing -- another region, inside, whatever, so long as it follows the normal placement restrictions for that type of object (trees can't go on tile floors or on roads, straightforward things of that nature).

Right now the grow gems are a bit imprecise to use if the object can't be placed right in front of you based on those restrictions (it just moves to somewhere nearby in that case), and equipping a bunch of grow gems from your inventory would be a pain of a process to go through, but otherwise it's fully ready to go. 

Later on probably in alpha, we intend to make a specialized placement mode and streamlined interface specifically for the shrink/grow process that will make that easier to do.  Bear in mind that this is a completely optional, aesthetic sort of activity to undertake in the first place.  But we know some players will really like this (and we think it's cool, too), so we want to make sure it works as easily as possible.

Shadow Improvements
In past weeks, players have still been complaining about two things related to shadows: that shadows cross other buildings, and that shadows would protrude into the sky.  I had thought that the first problem couldn't be solved at all, and that the second one couldn't be solved except by keeping large shadows away from the sky.

As it turns out, in the process of figuring out a lighting engine (I'm using the Z Buffer instead of using actual lighting, for various reasons), I also figured out a way to make shadows not fall on buildings at all, and also not to fall on the sky at all. 

I'm not sure how well these specific screens show any such cases where that would happen, but I'm sure the video must.  I'm quite pleased how this unexpectedly turned out!  I didn't know anything quite like the Z Buffer existed -- well, I knew it existed, but not exactly how it could be used in the context of a 2D game like this.


Bunches Of Other Engine Improvements And Extensions
We have entrances to buildings, which is harder than you might think.  We have better scheduled saving of regions and "chunks" to disk, preserving performance and data.  We have a bunch of new shaders to support the faux lighting engine.  We support a bunch of new things that let us do the lava clouds.  The way that the world map is seeded is now quite a bit better.  We added preliminary support for having multiple floors in a building, but haven't finished coding that in yet.  A lot of collision stuff was extended or improved.

And so on.  I know I'm forgetting a bunch of things, but those are at the very least the highlights.  I've spent a lot more time than usual on programming this past three weeks,  but I'm going to be going into a bit of an art-creation kick for the next week or so, and then working tons more on the interiors.  There's still a lot I need to do there to really get that where I ultimately want it to be, with multi-floor buildings of various sorts with basements and all sorts of fun things.

What's Next?
I'm working on tons more art, as I just said, but also on the interiors still; those are the last big worldbuilding area where we have a significant chunk of "horizontal" development left to do. 

Keith, in turn, has some more inventory and crafting horizontal development to do, as well as adding support for a few new things like firearms and physical weapons (swords, etc), as well as adding passive "augment" gems that will function in place of armor, improving various stats while you wear them (we're cutting the former idea of armor in favor of this).

Beyond that, I think it's mostly into vertical development for us all the rest of the way from here until we hit alpha in another 3-4 weeks.  There are tons and tons of traps, enemies, characters, dialogues, floorplans, objects, tilesets, spells, consumables, weapons, and so forth that we want to get in place even before we hit the first public alpha release, so it's going to be a hugely busy few weeks.  We have some really cool and unusual enemy designs that I'm quite excited about, so it will be fun to share those as we're getting to them.  Stay tuned!

Horizontal vs Vertical Game Development Phases

This is going to be a three-post day, to hopefully. make up for having neglected the blog for three weeks.  In the last post, I talked about the design process for A Valley Without Wind, at least at a high level -- that's a complex topic, so I might write more on that in the future.

One particularly interesting concept that Keith and I have adopted in our design lingo is a delineation between "horizontal" and "vertical" types of game development.

Horizontal Game Development
When you're developing horizontally, you're adding new classes of features.  In Tidalis, a new horizontal feature was when we added the ability to have items, or to have an adventure map.  With AI War, a new horizontal feature was when we added the ability to have minor factions, or "event attacks," or campaign types.

In AVWW, examples of horizontal features we've done so far are having multiplayer, having enemies, having the world map, having building interiors, having regions and all the effects those on the character, having crafting at all, and so on.

Horizontal features are major game-changers, as they add whole groups of new functionality to the game that were not there before.  Another way to describe them is that they are scaffolding: in AVWW, we added "the ability to have enemies" weeks ago, but we only added a single enemy, the Skelebot.

Vertical Game Development
When you're developing vertically, you're still probably adding little bits of scaffolding here and there, but that's not the core focus.  To use AVWW as an example again, when we finally get to adding more than a single enemy, that will largely be vertical game development.

Horizontal game development can be the most exciting thing for some designers, and from looking at some indie games it always makes me wonder why there wasn't more vertical development (awesome ideas packaged in a really short game without a replay value is a bugbear of mine).  But vertical game development is just as critical to the game, overall -- AI War is fun and varied because there is so much to explore and to discover in the galaxy.

As an example of just how important vertical game development can feel to players: The Zenith Remnant is our best-selling expansion for AI War, and it's pretty much 80% vertically-developed.  It added a few horizontal things -- golems and minor factions, most notably -- but the bulk of that expansion is more content, more to explore, more to make each galaxy feel like a living and unique place.

Side Note: Indies Vs. The Big Boys
I don't want to name any names, but I think that if more indie developers focused on a vertical development phase after their excellent horizontal work, that they'd really be even more competitive.  There's something to be said for a highly polished, focused, finite experience, of course -- and I'm in no way advocating simply "padding out a game" with repetitive stuff.  But when you have an awesome new concept, it just seems to me like a waste not to explore it fully, in all its permutations and variations.

Truthfully, we never would have been able to make three expansions for AI War had we just been running on the strength of the ideas that I had, though.  I had enough ideas for part of one expansion, but not even for that full thing.  Players, though -- man are they a font of ideas, and that's what made the expansions to AI War possible.  It's something I'd be delighted to see more indie developers doing in general.

A Valley Without Wind's Pre-Alpha Horizontal Development
With AVWW, we've been doing a ton of horizontal development to get all the various subsystems in the game working and proven out in a broad sense.  That's why you see one enemy, and why we have multiplayer but not yet any prediction or smoothing, and why I had planned not to include shadows for a while (until I was overruled by players).

This mostly-horizontal period of development has taken up most of our time on the game so far, but thankfully we are nearing the end of that process -- my favorite part of game development is, as you might guess, actually the vertical.  We still have more to do with the general mechanics of crafting, NPCs, and the like, but in terms of what we're doing before alpha, the list is actually pretty short. 

Things like Settlements, "Hopes" (our version of "Quests"), and Deeds (the game remembering your past victories and losses in a meaningful way) are going to be our primary areas of horizontal expansion during the alpha phase, and having all three of those in place and fully the way we want will likely mark our transition to beta.

In the meantime, once we get our last push of horizontal development done here, we're going to really be pushing into the vertical, trying to get as many enemies, traps, spells, craftables, general objects, characters, weapons, consumables, buildings, floorplans, dialogues, and so forth into the game before we hit alpha in another 3-4 weeks.

By now we have this amazing skeleton, but we need to start focusing on getting some meat on them bones.  For those that have worried that the game is going to be about "kiting" enemies, for example, that's a fear based out of our simply having implemented one prototype entity, but the reality is even that one enemy won't continue functioning in that simple manner by the time we hit even alpha.  Lots to do, and for me this is the fun part -- we've built most of our toolkit, and part of a world, and now it's time to start really building a world using that toolkit.

The A Valley Without Wind Design Process (And "Where Have The Videos Been?")

Keith LaMothe and I are working together on the design and programming of A Valley Without Wind, him with the greater share of programming, me with the greater share of design, though we both do both.  This is a bit of a new process for me, despite the fact that I've worked with teams on software for a decade, and teams for games for the last two years.

Our Design Process For Tidalis
Lars Bull and I collaborated so much on Tidalis (and actually, Keith, Pablo Vega, and Phillipe Chabot were all in on the design discussions on Tidalis, too).

Anyway, the core design of Tidalis was a lot simpler, and at the early stages of that game I was doing all the programming, so we could just prototype the latest idea from whoever and see if it was fun.  And given that it's a puzzle game with a bunch of modes, plenty of the modes didn't impact other modes.

Our biggest design challenges on an ongoing basis all had to do with the intricacies of physics in the game and how they affected the advanced brainteasers -- and all that pretty much fell to Lars to calculate and tell us what to do to get it right, because personally I wasn't skilled enough at the brainteasers to do the advanced ones, anyway.  I preferred the action modes.

Our Design Process For Light of the Spire
Light of the Spire was our most recent expansion for AI War, and Keith and I both divided up the design and programming about equally here (and, as with AVWW, I did all the art for that expansion).  The thing about LotS was that it was a sprawling expansion adding new content and features onto an already-massive game.

Thus for the bulk of our working time, Keith was able to take the Fallen Spire campaign and a few other related components, and I was able to take pretty much everything else.  It was an even divide of work, and by the end of the development cycle we then both worked on bugfixes and balance for the expansion as a whole, though I also pretty much kept my nose out of Fallen Spire (as I kept my nose out of the Hybrid Hives from Children of Neinzul, which were also Keith's thing).  It worked out well.


Our Design Process for A Valley Without Wind
Coming into AVWW, there was a ton more to do design-wise than we'd had to cope with since I was working solo on the design for AI War.  Not only is AVWW as large as AI War or larger, depending on how you look at it, but it's also all quite interrelated.

For many months before we even started coding, Keith and I had been having these longwinded design emails and IM chat sessions back and forth, hashing out what the game might be like, and which ideas we liked and didn't that occurred to one or the other of us.  That worked out very well, because with one person it's hard to know if your ideas are any good until you try them (which led to a 6 month private alpha for AI War), but with two people you can eliminate a lot of mediocre ideas without even having to try them.

Of course, a lot of things that we were able to broadly design in advance, we still had to design the specifics of when it came time to implementation.  The leveling system is all very well and good in concept, but when you get right down to it, how many enemies should you need to kill to level up on average?  How many enemy kills correspond to finding one "point of interest" in terms of EXP gain?  And a million other little questions like that.

In the past with something like AI War, my process was to think it all out on my own, possibly talk to my wife about the really tricky ones and see what she thought, and then implement it into the prototype and see if it made any sense in practice.  Sometimes things did, sometimes things didn't, but it was a slow process.  AI War 1.0 was vastly smaller than AVWW 1.0 is going to be.

So... Where Have The Videos Been?
Working with Keith saves a ton of time of prototyping ideas that won't make it into the final product (not that we'll do none of that, but we'll at least do a lot less).  But at the same time, all those IM chats and emails are time consuming in and of themselves.  Hugely productive, but when we hit a major new set of things that are all interrelated and which need a lot of design all at once, this tends to suck up enough time that programming and art lag behind.

It's still a huge savings to the project timeline in general, but it means that we have less to visually show when we hit one of those stages.  That's pretty much the stage we were at before we showed any videos or screens for the game, because we had to design everything fresh then.

Then for four or five weeks we were showing screens and videos pretty consistently, because we were riding off that last round of design and the amount of major things in the game that we had to define all at once were pretty low, comparably speaking.  Even so, I was thinking about dropping the frequency of at least the videos to biweekly, because the press seemed to be getting less interested in weekly press releases, and each set of videos/screens/diary takes me about 4-6 hours out of my week to do, and that's quite a heavy "time tax" to incur weekly.

But suddenly it's been three weeks since our last video, and that was totally not something I'd intended to do.  The chief reason it's been so long is that we hit another one of those "major nests of design questions that need to be answered before proceeding," and that was paired with a huge amount of new non-visual programming work that we did in that same period.

The net result is that the game is incredibly further along towards alpha than it was last time I posted, but of course that's to be expected for three more weeks of development.  The other result is that, visually, it's not as far changed as you might expect for three weeks of time, because the bulk of my effort has been on design and programming rather than the art.  There is some new cool visual stuff, but not as much as there has been in other similar stretches of time.  Next week that's going to flip-flop, and I'm really going to be cranking through the art while doing very little programming, so it's just something that comes in fits and spurts.

When Is The Next Video?
Later today, along with new screens and an actual description of all the stuff we've been working on!  I figured I'd go ahead and make this post first, though, rather than clutter up the other post with this info.  Stay tuned!

Tuesday, March 8, 2011

Creating 8-Bit Sound


The soundtrack for “A Valley Without Wind” is getting off to a great start. For those of you who have heard some of the music in the trailers, you’ll notice the key component in all the pieces: the 8-bit melody. It’s a sound that is not only fun to play with, but nostalgic for any one who grew up in the Atari/Nintendo age and can still hum all those classic game themes.

Most of the composers for the early games used Mod Trackers to generate these classic sounds. At first I thought about using some, but then found a great way to create these sounds in Logic.

The steps:

1) Open a new empty project
2) Create a “software instrument” track
      * The default software instrument track that Logic creates is “EVP88 Electric Piano”
3) Hold down the I/O “EVP88” button on the environment window on the left side of the screen. There you will see a variety of different options to choose from. Choose “ES P (Polyphonic Synth)->Stereo”
4) On the “ES P” window you will see a ton of different options. These are the settings you want:


5) Next, open up the “Mixer” window
6) Under your newly created 8-bit sound, hold down one of the empty “sends” boxes, and click on “Bus 1”. A new track will appear in the Mixer called “Aux 1”
7) On the new Aux track, hold down one of the empty “inserts” boxes, then go to “Reverb->PlatinumVerb->Stereo”
8) In the PlatinumVerb window, look at the top and you’ll see a button that says “view”. Click on it and select “Controls”. These are the settings you want:


9) You’ll notice in the Mixer Window that “Bus 1” is now highlighted inside one of the “sends” boxes.  To the right of the highlighted box is a circular dial. Click on it and set the dial to “-8.0”

And that’s it! Now you have an awesome, classic 8-bit sound to play around with. The last few steps in adding reverb are not necessary, but I like to use them because it makes the harsh 8-bit synth sound mix better with other instruments. Be sure to turn the volume down as well, the default “0.0” volume setting in the Mixer window is loud.

If you have Logic, try this out and play around with the 8-bit sound. It’s a whole lot of fun and brings back a ton of memories!

Friday, March 4, 2011

Multiplayer, More Regions and Buildings, Minimap, and the Energy Lance

Here's the latest video:



New this week: more buildings, more general objects, and some additional regions, as well as a lot more population scripts for the existing regions.  There's also a new Energy Lance spell, which makes cutting through big lines of objects or enemies easier (but it does lower damage to actual individual enemies).  We also added a ton to the HUD, including our actual in-game font, better organization, and a minimap to show exploration progress in each area!

The biggest new work this week, however, was multiplayer.  We've now got the basics of multiplayer working, and Keith and I were able to play together in the same server across the Internet with great success.  It's still jerky in multiplayer because we haven't put in any smoothing or prediction yet, but it functions and it's actually not any worse than some Mario Kart DS matches I've had in the past, even if the smoothing isn't there yet.

This week I'd hoped to get into interiors of buildings, but I did a lot of work on exteriors instead, as well as getting sucked into a lot of business stuff (taxes, distributors, etc) this week.  Next week looks to be markedly more clear, though, and this week was quite productive even so.  Stay tuned!