In this new feature, Design Right, I'm going to look at games other than my own -- specifically, at certain things that other games do right. I spend a lot of time thinking about other games and what they do well, and I think it's useful for discussion.
So. Demon's Souls, for the PS3. Yes, I am more than just a PC Gamer -- have been my entire life (early childhood was a mix of Atari, NES, and the 386). At the moment I've got three gaming PCs in the house, a Wii, two DS lites, a GBA, an original Gameboy, a PS3, a PS2, an N64, a SNES, and a NES. I enjoy a wide variety of consoles, and the absence of the 360 isn't anything against it; I imagine I'll pick one up in the next year or two. But that's really a digression.
Critical Reception & Target Audience
Demon's Souls (DS from now on) is pretty well-loved critically at this point, and player reaction also seems pretty positive in the main. I've noticed a fair bit of griping from players about how hard it is, or that it's got repetitive hack and slash gameplay, or that it really isn't that innovative, or this or that other complaint. I'm not here to bash (or even review) other developers' games, but I think those criticisms bear noting in the context of a design discussion. In short: I think the people with those complaints are outside the target audience of the game, plain and simple. DS is a demanding game, and people outside the demographic at which it is squarely aimed probably have a lower likelihood of enjoying it. True for any game to an extent, but especially true for a game with such a demanding difficulty game.
For my own part, I place myself outside the target audience that I think would really normally enjoy the game -- I had planned on giving this game a miss, to be honest, but then reading a diary of a player's experiences with the game changed my mind. I'm not generally a hack and slash fan, I enjoy a few dungeon crawlers but not usually on the Playstation systems, and while I do enjoy a difficult game it has to really grab me with its setting in order for me to want to play it. So DS was an obvious miss for me.
And yet I bought it, and I love it. Why? This is because it gets one single aspect of the design absolutely right. It took me a while to figure out exactly what that was, but here it is: realistic fear. When I play Demon's Souls, I feel like I'm really a semi-formidable hero out adventuring in a world full of danger. Death is real, and is everpresent. Mistakes are costly.
My Play Experience
Those sound almost like negatives, don't they? So let me back up just a hair. This was my experience with DS:
1. I started as a Hunter, did the tutorial easily, thought the mechanics were kind of okay, and proceeded to level one.
2. I spent two and a half hours dying in level one, accomplishing literally nothing permanent. Well, I picked up some random junk off of bad guys, a cruddy ring, and a few weapons that were all worse than my starting weapons. I gained no experience, I gained no levels, I gained no permanent items of worth -- in fact, I ran out of permanent items, with no easy way to replenish them. Arrows for my bow and healing herbs were in dangerously low supply, making the game even harder as I went.
3. I was getting better, however, so I decided to start over. This time I decided to start as a Barbarian, since he has better stats and worse equipment. I figured that with my growing skills at the game, this might make for the best path overall. To some extent, this was a bit true -- for the next two and a half hours, I largely did better than before. I explored a tiny few areas that I'd never been to as the Hunter, but the battles with armored knights were absolutely brutal because of my lack of armor. I could win against a few, but over time I'd wear down and one would get me. I figured I had to be getting close to the first boss, though.
4. I wasn't, not even close. After seeing a note online about how Royalty was the easiest class (a fact of which I was very skeptical, not having used magic yet and wary of another perishable weapon such as my Hunter's arrows), I decided to start over with a female Royal. This time, the game was a breeze by comparison. My lady spellcaster went blasting all over the level, killing most enemies from a distance in one or two hits. And she had better armor than the Barbarian. And her magic power regenerates, unlike the Hunter's arrows. I was starting to have piles and piles of healing herbs, because it was so straightforward to stay out of range. I started getting further into the first level, and discovered that I'd previously only seen the first 20% of the first level, if that. Within an hour, I'd beaten the first level with ease.
5. Another half hour, and the second level was mostly complete, though it took me a couple of tries with the boss. Another half hour, and the third level was complete, and I beat the boss on the first go. Another hour and a few deaths in the fourth level, and I beat that boss on the first go. Mostly just spamming my one magic spell, but resorting to my fairly-reasonably swordplay skills gained from 5 hours of dying with my other two characters. And the best part: I actually got to level up and improve my character -- a lot. 35 levels' worth in just a few hours, in fact.
6. Now I'm in the fifth level, and I haven't died yet. It's sort of challenging, and certainly death lurks around every bend the same as in the other past levels, but with caution nothing feels unfair to me. There are some traps, but with care they can be avoided, and some were even survivable when I triggered them, which was a surprise. There were three separate occasions in the fifth level where I was sure I was dead, but I survived with a sliver of health.
What Am I Getting Out Of This Now?
So, what is it that I'm getting out of Demon's Souls at this stage? The combat is pretty okay, but mostly I'm just spamming the same single spell repeatedly, dodging, and occasionally blocking. Very occasionally I whack something with my sword, using either Strong Attack or Normal Attack (R1 or R2). Once again, this doesn't sound riveting on paper -- unless you've been paying attention very closely, or have already played the game and have an affinity for it.
The reason DS works for me, and I suspect for others, is that fear factor. When you die, you entere a Soul state, which you remain in until you defeat another boss (or complete one of a few other conditions). When in the Soul state, you have even less health, and a few other disadvantages. This is huge! This means that there's a massive disincentive to just run into a room, die on a trap (while seeing what it does), and then respawn and avoid the trap. If you do that, not only are you put back to the start of the level (losing all your EXP/currency), but you also go into Soul state if you aren't already.
What Is Lost On Death, And Why It Works
The loss of the EXP/currency is bad enough by itself, to be honest. That creates a state of tension past a certain point where you really don't want to die because it undoes enough progress that you'll have some pain regaining it. This is just the sort of design decision I've lamented in other games, such as when save points are too few and far between in Final Fantasy titles, though -- what's different here? First, this is an action game; in Final Fantasy you have random encounters often with foes of ranging difficulty, and occasionally which are inescapable. So in Final Fantasy, when I have accomplished a lot but haven't saved, the pressure to save is extremely unpleasant, because it feels like my progress might be arbitrarily taken away at any time if I don't find a save point. That aspect is not fun when it occurs, though I love Final Fantasy in general.
With DS, as an action game, this is a situation where there are no random encounters. I can always run at high speed back through the level to the exit to go spent my EXP/currency if I'm really worried, without too much risk of getting killed that way. So retreat is always an option, which takes the edge off of my feeling trapped into the current level, which I think is really important. Secondly, except for traps (which mostly have not killed me in one hit so far -- up through most of the 5th of 15 levels), I can pretty much see enemies coming. So if an enemy looks too formidable, I can always, once again, retreat if my current wares are too valuable. Thirdly, since this is an action game without random encounters, I know that my survival mostly depends on my own skills at combat and observation.
There is also the fact that the ONLY thing I lose is my EXP/currency, and the transition into soul state. In other words, important things that I've triggered in the level (doors opened, switches tripped, etc) stay as I left them even after death. Plus, any items that I've picked up remain mine. That's another huge difference between the Final Fantasy model, where you're literally dumped back at the last save point with nothing to show for it after a death (FFVI let you keep your EXP, actually, but most did not do this to my knowledge).
Generating Fear
I love Silent Hill 2 partly because it scares the crud out of me. All of that is thematic fear, based on a story, plus the absolute incompetence of your character as a fighter. I love Left 4 Dead in spite of the fact that it never scares me at all, because it's fun for other reasons. Those two are both obvious candidates for dealing in fear because of their subject matter. DS is less obvious as a source of fear, but that's part of why it works so brilliantly: it takes the ordinary game activity of a hero questing, and makes commonplace activities filled with danger.
The death mechanic that I've described above is vital to this. Death is everpresent in DS, and it really hurts, but it's also not so devastating that it saps the player's will to go on (well, those that like the game, anyway). This creates a finely balanced sense of fear versus exploration. When I find a new side tunnel, or what I suspect is a side tunnel, I know that there might well be high-level enemies waiting along it. On the other hand, this might not be a side tunnel or it might contain some worthwhile treasure. So I proceed, albeit very carefully. Every step is measured, every nook and cranny warily eyed, every echoing footstep (from myself) slightly unnerving.
In short: if I was a reasonably brave hero proceeding down such a tunnel in real life, I have a feeling this is how I'd be feeling and reacting. And that, right there, is what Demon's Souls has offered me that no other game that I can think of has. No other game has transported me quite so convincingly, simply because I've never felt the real-life-style risk of being a flesh and blood being in a very dangerous place. I've felt that in real life in a few circumstances I'd rather not enumerate here, and DS does the best job I've ever seen of approximating that feeling. To be fair, Silent Hill 2 comes close to that feeling from a completely different design angle, but it's a different sort of beast in general.
New Subgenre?
So that's basically what DS is, to me. It's a Dungeon Simulator. It's like a Flight Simulator for planes, except for heroes exploring dungeons. Most people who aren't really into planes are going to prefer more arcade-style flight controls (I know I do), and the same is probably true of people who aren't really into dungeons, or scary stuff, or whatever other themes they connect with in Demon's Souls.
I can see why some people hate the game, for the same reason that some people hate flight simulators. These games ask a lot of preparation, and the payoff is only worth it if you are the sort of personality already primed to receive it. The act of flying a plane using a flight simulator is very complex, and that takes a lot of the visceral thrill out of the flying, for me. By contrast, the combat in DS is comparatively simple to a lot of other hack and slash games (no real combo system, fewer attacks in general so far, etc), and this is going to alienate the action game players who liked, for instance, the second two Prince of Persia games on the PS2.
The purpose, in both cases, is essentially the same: with a flight simulator, it is to realistically simulate the complex activity that is piloting an aircraft. With a dungeon simulator, it is to realistically simulate the simple-yet-terrifying experience of surviving a dungeon full of monsters that are stronger than you. Let's be honest: if you're exploring a dungeon, and your life is really at risk, how much fancy swordplay are you likely to employ? You're going to kill your enemies as efficiently as possible and have done with it, breathing a small sigh of relief with each downed foe. The ease of dispatching any given enemy is irrelevant to you, you're just glad your attention is no longer diverted from whatever other dangers might be about to spring upon you.
What Did I Get Out Of This At First?
So, clearly I like the game at this point. But how on earth did I ever get past the first five hours of nothing but death, death, death, and little exploration? I mean, there was almost no tangible reward for all that effort... right?
Well, in an in-game sense, that is true. My only real reward in-game was occasionally getting one room further along some path or another. There were a few divergent paths past a certain point, and I explored all of them to at least a small degree before finally creating my Royal. To some extent, those few glimpses of that-which-was-just-out-of-reach was enough to keep me going.
But also, there was a noticeable improvement in my skills with the melee weapons as I progressed, and that was also gratifying even if it wasn't yet getting me anywhere. I'm as adept as anyone at Zelda, and the Sands of Time game was no trouble either, but I rather avoided the sequels to SoT. As I played, I was very surprised how many parallels the control scheme was suddenly having to Zelda, except it was a more robust, satisfying-when-you-win version of the Zelda combat.
Old School Charm?
So, that was it. The combat was simple, but still deep enough that I could feel myself getting better at it, and that was fun. There was enough tantalizing newness on the horizon to justify going back. Frankly, this reminded me a lot of my days on the NES and the Atari, when I was a kid playing the same level(s) over and over in hopes of advancing to the next. The feeling of satisfaction I got from progressing to the next level was unlike anything you can get from most modern games, simply because they are (and this is almost always a good thing) more forgiving.
As unlikely as it seems, though, DS managed to hit just the right amount of old-school-difficulty mixed with modern sentiments via its death mechanic, it's simplified combat, and it's general style of level design. That's a really hard thing to pull off, I'm certain, though I've never tried to design a game like that. There are plenty of games out there that are simply Too Hard To Be Fun (except for the masochist hardcore players, who flock to them), or which are Old School But Not In A Good Way (in other words, retro without allowing for any of the advances of the last 20+ years of game design innovation).
What To Take Away From This?
Demon's Souls walks a very fine line indeed, and it is hard to sum up what it does without the shorthand of a subgenre like "Dungeon Simulator" for reference. However, I think it's a testament to the fact that it is largely designed right that so many people, reviewers included, are so excited about the title. It was one I never thought I'd buy, but I'm glad I did. I suppose this has almost taken on the tenor of a review at this point, but that wasn't my intention -- rather, I think the instructive thing being discussed here are those few key design tweaks that make DS into a success for the audience it has found, including myself, whereas with just a few small changes in the wrong direction the entire game could have been an utter failure.
I think it's partly that "I can't believe I like this, but it's actually pretty awesome" sentiment that has made the game such a hit with those reviewers who have liked it; and for anyone who is laboring away on a game design that is just not working, I think that the realization that all it takes is a few small tweaks to an otherwise broken formula is a good thing to know.
If you were working on a broken version of a game like DS, where the difficulty is brutal in an un-fun way, how would you go about lessening that un-fun factor while keeping the difficulty pleasingly high? DS shows us that you can make a mix of penalties that are very severe, combined with those that are very forgiving (keeping all the items and all the triggered switches, etc, is extremely kind in the middle of a very unkind game), to make a game that feels extremely tough without feeling cheap or unfair (to most).
But, more than that, it shows the value of waiting until your gameplay mechanics are perfectly balanced against one another, rather than calling "good enough" and just stopping. The difference between that one bit of polish could just be the difference between huge critical acclaim and complete obscurity -- and given how much other work goes into any game, not taking the time to put on that final, critical layer of design polish is the same as running the entire race just to give up three feet from the finish line.
Monday, October 26, 2009
Monday, October 19, 2009
Free Graphics For Indie Developers!
Here's the link: Download The AI War 2.0 Graphics Library
And here's the contents of our readme file:
-------------------------------------------------------------
AI War 2.0 Graphics Library: Free To Use For Indie Developers
-------------------------------------------------------------
I'm going to keep this as brief as possible, for the sake of clarity. This library contains the graphics for the indie space RTS AI War: Fleet Command, as of version 2.0 of that game. This readme is written by Chris Park, AI War's creator.
Whoever you are, an indie developer or otherwise, you're free to use the graphics in this library for whatever purposes you want. Don't sell these graphics by themselves, but you can include them in your game, your pictures, whatever, and then you can sell your work with this art intact. You can modify them as much as you need for your purposes, as well. Make a new RTS, make some other genre of game, whatever. Just please be sure that you attribute the art to the artist(s) that created it.
---------------------
Who Created This Art?
---------------------
The original art for AI War 1.0 was all by myself (and not that good), or by Daniel Cook (mostly the ship graphics, but also some other aspects, and quite good). For almost everything that is by Daniel Cook and included in this library, it has also been modified by myself (Chris Park) to a greater or lesser degree. But the work is still primarily Danc's (I mostly only bring up my involvement so that some of the... less appealing... compound works that are in the Daniel Cook folder are not mistaken as something that he put together. If it looks a bit lesser quality, that's probably my hand at work).
After release, an AI War player named Hans-Martin Portmann, who is also an artist, was gracious enough to donate some art to help improve the game. His suggestions also led to a lot of the improved special effects, even for those where he did not directly contribute images.
After version 1.013 of the game came out, Philippe Chabot joined the Arcen Games team and upgraded much of the art, replacing a huge amount of it outright. He also did some significant upgrades to some of Danc's/my work, making it larger, or animated, or more detailed in certain ways, or whatever.
So here's how you know who the artist is, looking at the folders in this archive:
ChrisPark
----------
The work in this folder is original to me, and there is not a whole lot of it left at this stage.
DanielCook (http://lostgarden.com/)
-----------------------------------
Everything in this folder was created by Daniel Cook, and probably also altered to some degree by Chris Park. A few things that were orignal to Chris Park might have been stuck in here as well, but that's just things like numbers or a check mark, etc.
Tyrian: http://lostgarden.com/2007/04/free-game-graphics-tyrian-ships-and.html
Iron Plague: http://lostgarden.com/2005/03/download-complete-set-of-sweet-8-bit.html
Hard Vacuum: http://lostgarden.com/2005/03/game-post-mortem-hard-vacuum.html
DanielCookPhilippeChabot
------------------------
The work in this folder started out as Daniel Cook's work, and then way probably also altered to some degree by Chris Park, and then was altered to a much more significant degree (in most cases) by Philippe Chabot.
HansMartinPortmann
------------------
The work in this folder is all original to Hans-Martin Portmann.
PhilippeChabot
--------------
The work in this folder is all original to Philippe Chabot.
----------------------------------------
Why Are You Releasing This Art For Free?
----------------------------------------
As I mentioned above, AI War started out with just unimpressive programmer graphics mixed with the excellent work of Danc. The game went on sale in this state, and sold into the four digits of units sold without any art upgrades from Philippe. The primary determinant of our sales was the game itself, of course, but having graphics that weren't all as terrible as they would have been if I had had to make them all myself was a huge boost, I think. I couldn't afford to pay for art at the start, as I was developing AI War in my own spare time and had no budget to speak of.
Danc releases some of his old pixelart on his website -- some of it is from Tyrian, and some of it is from some other older games of his that were not actually ever released -- and it's safe to say that AI War wouldn't have existed in at all its released form without his having decided to do that. His generosity helped get AI War off the ground, and once AI War was to the point where it was making enough money that I could afford to hire an artist, I knew I wanted to give back in the same way.
All of Philippe's art in this library was done as work for hire and so belongs to Arcen Games, but Philippe was very much on board when I pitched him the idea of making a library for other indies to be able to reuse from. There simply isn't much out there aside from what Danc puts out and maybe four other sources for free pixelart that indie developers can use in commerical products, and so hopefully you'll find this library useful. It's our way of giving back to the indie community, in hopes of bootstrapping some other talented developer the way that Daniel Cook bootstrapped Arcen Games.
And here's the contents of our readme file:
-------------------------------------------------------------
AI War 2.0 Graphics Library: Free To Use For Indie Developers
-------------------------------------------------------------
I'm going to keep this as brief as possible, for the sake of clarity. This library contains the graphics for the indie space RTS AI War: Fleet Command, as of version 2.0 of that game. This readme is written by Chris Park, AI War's creator.
Whoever you are, an indie developer or otherwise, you're free to use the graphics in this library for whatever purposes you want. Don't sell these graphics by themselves, but you can include them in your game, your pictures, whatever, and then you can sell your work with this art intact. You can modify them as much as you need for your purposes, as well. Make a new RTS, make some other genre of game, whatever. Just please be sure that you attribute the art to the artist(s) that created it.
---------------------
Who Created This Art?
---------------------
The original art for AI War 1.0 was all by myself (and not that good), or by Daniel Cook (mostly the ship graphics, but also some other aspects, and quite good). For almost everything that is by Daniel Cook and included in this library, it has also been modified by myself (Chris Park) to a greater or lesser degree. But the work is still primarily Danc's (I mostly only bring up my involvement so that some of the... less appealing... compound works that are in the Daniel Cook folder are not mistaken as something that he put together. If it looks a bit lesser quality, that's probably my hand at work).
After release, an AI War player named Hans-Martin Portmann, who is also an artist, was gracious enough to donate some art to help improve the game. His suggestions also led to a lot of the improved special effects, even for those where he did not directly contribute images.
After version 1.013 of the game came out, Philippe Chabot joined the Arcen Games team and upgraded much of the art, replacing a huge amount of it outright. He also did some significant upgrades to some of Danc's/my work, making it larger, or animated, or more detailed in certain ways, or whatever.
So here's how you know who the artist is, looking at the folders in this archive:
ChrisPark
----------
The work in this folder is original to me, and there is not a whole lot of it left at this stage.
DanielCook (http://lostgarden.com/)
-----------------------------------
Everything in this folder was created by Daniel Cook, and probably also altered to some degree by Chris Park. A few things that were orignal to Chris Park might have been stuck in here as well, but that's just things like numbers or a check mark, etc.
Tyrian: http://lostgarden.com/2007/04/free-game-graphics-tyrian-ships-and.html
Iron Plague: http://lostgarden.com/2005/03/download-complete-set-of-sweet-8-bit.html
Hard Vacuum: http://lostgarden.com/2005/03/game-post-mortem-hard-vacuum.html
DanielCookPhilippeChabot
------------------------
The work in this folder started out as Daniel Cook's work, and then way probably also altered to some degree by Chris Park, and then was altered to a much more significant degree (in most cases) by Philippe Chabot.
HansMartinPortmann
------------------
The work in this folder is all original to Hans-Martin Portmann.
PhilippeChabot
--------------
The work in this folder is all original to Philippe Chabot.
----------------------------------------
Why Are You Releasing This Art For Free?
----------------------------------------
As I mentioned above, AI War started out with just unimpressive programmer graphics mixed with the excellent work of Danc. The game went on sale in this state, and sold into the four digits of units sold without any art upgrades from Philippe. The primary determinant of our sales was the game itself, of course, but having graphics that weren't all as terrible as they would have been if I had had to make them all myself was a huge boost, I think. I couldn't afford to pay for art at the start, as I was developing AI War in my own spare time and had no budget to speak of.
Danc releases some of his old pixelart on his website -- some of it is from Tyrian, and some of it is from some other older games of his that were not actually ever released -- and it's safe to say that AI War wouldn't have existed in at all its released form without his having decided to do that. His generosity helped get AI War off the ground, and once AI War was to the point where it was making enough money that I could afford to hire an artist, I knew I wanted to give back in the same way.
All of Philippe's art in this library was done as work for hire and so belongs to Arcen Games, but Philippe was very much on board when I pitched him the idea of making a library for other indies to be able to reuse from. There simply isn't much out there aside from what Danc puts out and maybe four other sources for free pixelart that indie developers can use in commerical products, and so hopefully you'll find this library useful. It's our way of giving back to the indie community, in hopes of bootstrapping some other talented developer the way that Daniel Cook bootstrapped Arcen Games.
Thursday, October 15, 2009
Fun with Windows (XP and 7).
Well, this morning right after checking my mail, I was logging on to my work VPN and found out that remote desktop would not open. Odd, I thought, but I was running north of 3GB of RAM and had not rebooted in over 6 months. So I figured I just needed to clear the air a bit, so to speak. Down went the various programs as I closed them, including Explorer.exe, which has an annoying memory leak in XP (at least when TortoiseSVN is present). Then tried to reopen Explorer.exe through Task Manager -- no go. Huh, that's odd, and not a good sign, I though. Time for a reboot for real, then.
The OS comes back up to a black screen, with a mouse cursor, and then just sits there blinking the hard drive light at me. Lovely. But I've had much more dire situations than this in the past, such as when a production server does something similar because of an extra bit of charge in the SCSI card. So I try all the usual tricks -- powering down and waiting 30+ seconds, running Last Known Good at least 1 more time than I had previously booted, then getting more concerned and trying to load Safe Mode (with the same result), then getting really concerned and deciding to do a Repair Install off of my slipstreamed XP SP2 disk... with the same result on reboot.
Oh, fun. What caused this? I have no idea. My hard disk and everything else seems to be okay. But it was clearly time for a reinstall. I've got an MSDN subscription, so I figured I'd install the Windows 7 64 RTM instead of just going back to XP 32. I have Vista 32 on a secondary tower that I use for testing with AI War, but I hadn't yet taken a look at Win7 directly. I'd heard good things from people I knew, though, and also felt like I couldn't stay on XP forever.
So, two hours later (the MS connection is really slow, even though my connection is really fast). I decided to just install Windows 7 onto the same single 500GB partition that I'd used for XP and all my data (gasp, I know). The install process for Windows 7 was slower than I expected, taking over an hour and half if I'm not mistaken (at least an hour) on my Q6600 quad. Hmm. Not off to too good a start.
Once the OS boots up, the first thing that I do is disable Aero (which is slow as well as nonfunctionally ugly in my opinion), returning to the Windows Classic theme. I also play around with the new taskbar a bit, returning it to something more like what I'm used to using (four rows tall, with autohide on). The quick launch bar is gone, but the new application pinning works really well. I decide to turn off the large icons and re-enable the text display (and turn off grouping). Perfect, it's now just about like what I prefer, and in some ways is a little bit better (I no longer have to install a little widget to allow me to drag around taskbar entries, for instance).
The next thing I notice is that explorer needs to reconfiguration to be a little more like what I like. Of course, the next next thing I notice is how insanely awesome the new Libraries feature is. How incredibly handy. By now I'm also marveling at how fast the (non-Aero) desktop experience is. It's about as fast as Windows XP, and tons faster than Vista, on this particular machine. The memory usage is higher, but since all 4GB of my RAM now actually registers with the OS (since I was on 32bit before, it capped out at around 3.3GB usable), it works out around the same anyway.
No problems with drivers, and all of the software that I have to install (including Visual Studio 2008) installs amazingly, blazingly fast. Huh. I've installed various versions of those pieces of software many times, on many machines, on several OSes over the years, and none of them ever installed even 1/8th as fast as it did on my machine here. Again, huh. That's pretty cool.
The rest of the software is similarly speedy and uneventful so far, and I'm down to only half a dozen more programs that I need to install, most of them noncritical for my daily work. I have noticed a few other changes, such as those to network places (meh), calculator (meh), remote desktop (wow!), windows find (wow!), IE8 (a hearty blah), picture viewer (pretty nice), and others. And the drivers seem pretty great for all my hardware, graphics card excepted.
In all this set me back around a day, though fortunately it was a day where I had a lot of meetings anyway so I could just do those on my other PC while the installs were running. So, not nearly as bad as some reinstalls I've had to do in the past. I find myself pleasantly pleased and surprised with Windows 7, too. It's not amazing in most respects so far as I can tell, but it's modern and unobtrusive, which is really what I was looking for. I always loved XP (and 2000 before it), after getting excited about (and burned by)about ME. But XP was starting to feel sort of dated, in areas that Win7 addresses. Simple usability improvements, like the taskbar, the dragging of windows to one side of the screen, the better truetype calibration and monitor sizing, the libraries, etc.
The sum of a hundred tiny improvements, which basic users may never even see, make me really happy with Win7.
The OS comes back up to a black screen, with a mouse cursor, and then just sits there blinking the hard drive light at me. Lovely. But I've had much more dire situations than this in the past, such as when a production server does something similar because of an extra bit of charge in the SCSI card. So I try all the usual tricks -- powering down and waiting 30+ seconds, running Last Known Good at least 1 more time than I had previously booted, then getting more concerned and trying to load Safe Mode (with the same result), then getting really concerned and deciding to do a Repair Install off of my slipstreamed XP SP2 disk... with the same result on reboot.
Oh, fun. What caused this? I have no idea. My hard disk and everything else seems to be okay. But it was clearly time for a reinstall. I've got an MSDN subscription, so I figured I'd install the Windows 7 64 RTM instead of just going back to XP 32. I have Vista 32 on a secondary tower that I use for testing with AI War, but I hadn't yet taken a look at Win7 directly. I'd heard good things from people I knew, though, and also felt like I couldn't stay on XP forever.
So, two hours later (the MS connection is really slow, even though my connection is really fast). I decided to just install Windows 7 onto the same single 500GB partition that I'd used for XP and all my data (gasp, I know). The install process for Windows 7 was slower than I expected, taking over an hour and half if I'm not mistaken (at least an hour) on my Q6600 quad. Hmm. Not off to too good a start.
Once the OS boots up, the first thing that I do is disable Aero (which is slow as well as nonfunctionally ugly in my opinion), returning to the Windows Classic theme. I also play around with the new taskbar a bit, returning it to something more like what I'm used to using (four rows tall, with autohide on). The quick launch bar is gone, but the new application pinning works really well. I decide to turn off the large icons and re-enable the text display (and turn off grouping). Perfect, it's now just about like what I prefer, and in some ways is a little bit better (I no longer have to install a little widget to allow me to drag around taskbar entries, for instance).
The next thing I notice is that explorer needs to reconfiguration to be a little more like what I like. Of course, the next next thing I notice is how insanely awesome the new Libraries feature is. How incredibly handy. By now I'm also marveling at how fast the (non-Aero) desktop experience is. It's about as fast as Windows XP, and tons faster than Vista, on this particular machine. The memory usage is higher, but since all 4GB of my RAM now actually registers with the OS (since I was on 32bit before, it capped out at around 3.3GB usable), it works out around the same anyway.
No problems with drivers, and all of the software that I have to install (including Visual Studio 2008) installs amazingly, blazingly fast. Huh. I've installed various versions of those pieces of software many times, on many machines, on several OSes over the years, and none of them ever installed even 1/8th as fast as it did on my machine here. Again, huh. That's pretty cool.
The rest of the software is similarly speedy and uneventful so far, and I'm down to only half a dozen more programs that I need to install, most of them noncritical for my daily work. I have noticed a few other changes, such as those to network places (meh), calculator (meh), remote desktop (wow!), windows find (wow!), IE8 (a hearty blah), picture viewer (pretty nice), and others. And the drivers seem pretty great for all my hardware, graphics card excepted.
In all this set me back around a day, though fortunately it was a day where I had a lot of meetings anyway so I could just do those on my other PC while the installs were running. So, not nearly as bad as some reinstalls I've had to do in the past. I find myself pleasantly pleased and surprised with Windows 7, too. It's not amazing in most respects so far as I can tell, but it's modern and unobtrusive, which is really what I was looking for. I always loved XP (and 2000 before it), after getting excited about (and burned by)about ME. But XP was starting to feel sort of dated, in areas that Win7 addresses. Simple usability improvements, like the taskbar, the dragging of windows to one side of the screen, the better truetype calibration and monitor sizing, the libraries, etc.
The sum of a hundred tiny improvements, which basic users may never even see, make me really happy with Win7.
Sunday, October 11, 2009
AI War Trailer 3
View On Youtube - Download Full Quality Version
AI War: Fleet Command is one of the surprise indie hits of 2009. One of the most popular indie titles on Stardock's Impulse, AI War is coming to Steam in October 2009 with online leaderboards and achievements, as well as the huge 2.0 graphical and gameplay enhancements that will be available to all existing customers (through Impulse, GamersGate, or our website) for free! This trailer shows you what all the fuss is about.
Friday, October 9, 2009
The Reticule Interviews Chris Park About AI War, Part Two
The Reticule concludes the interview Chris Park, the developer of AI War. Topics in this part range from 2D games, why many indies smartly avoid DRM, the future of AI War, other upcoming Arcen titles, and our upcoming release on Steam.
Read The Interview
Read The Interview
Thursday, October 8, 2009
The Reticule Interviews Chris Park About AI War, Part One
The Reticule interviews Chris Park, the developer of AI War, about a variety of subjects: the game's AI, co-op features, and how we managed to get such massive unit counts, amongst others. Check back tomorrow for part two!
Read The Interview
Read The Interview
Monday, October 5, 2009
Iterative Game Design The Right Way
The industry standard way of designing games is to do so in advance, crafting a hefty "design document" that is basically the bible of how the game will be created. I can see the value of this when working with a huge team of staff, and certainly I can see the value of this when trying to get funding from a publisher. Many times the various realities of the industry simply dictate the designed-in-advance methodology.
Some design teams try to circumvent this a bit by prototyping -- basically, while the design document is being crafted, a prototype is also being developed. Revisions and alterations and discoveries during this prototyping phase are then integrated into the final design document, and this almost invariably is going to result in a better end product.
For a large company with a large team, or for a company that must take their design ideas to investors, or a publisher, or management, in order to secure funding for a new IP, I can't think of a better way to handle this. But, boy oh boy, does this make me happy to be an indie.
What Iterative Design Isn't -- And What I Mean By "The Right Way"
On the surface, it must seem pretty arrogant of me to proclaim that my way of iterative design is the "right" way, against all comers. To be fair, I don't think this is the only valid approach, but the benefits are many and I'm basically just cross-applying some concepts from the larger pool of software development thought. It's very much similar to Rapid Prototyping, or Agile Software methods, or to a certain extent Extreme Programming, etc. My background is in business programming, and these sorts of methods are much more common there -- I've been using and refining my own shade of agile programming in a professional environment for about seven years now, and all I've done is carry it over to game design.
So what's this "right way" business, then? Well, I think that iterative design has, in certain circles, become shorthand for "lazy" or "unprofessional." As in, the designer just sits down without a plan, and cranks out whatever comes to mind. The end result of such an endeavor is rarely good, and/or generally isn't very cohesive or original. It's like sitting down to create a chair out of a bunch of wood, and just starting on the first leg without any plans or advance thought, then moving on to each other leg and the rest of the chair as you come to it. The end result is unlikely to sit particularly level, and for that matter the style of the later legs is likely to be subtly or majorly different from the first leg.
If that's what you think iterative design is, no wonder you'd look down your nose at it. I have similar disdain for such a method as unprofessional and unlikely to work in a real production environment. Sure, there might be outlier successes using such a method, but that's more luck than anything else. Fortunately, what I just described isn't iterative design.
A Starting Point For Iterative Design: Goals
When you set out to iteratively design a game, or any other piece of software for that matter, the most important thing is that you don't start with a completely blank slate. You must have some sort of immutable design goals, and these are ideally paired with some initial design concepts that will guide early prototypes.
In the case of AI War, for example, here were my immutable design goals, which I set several months before starting on the AI War prototype:
1. The game must support co-op play in a way that is fun and painless.
2. The 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.
Additionally, here were my soft design goals (amongst a few dozen other lesser ones):
1. Ideally, it should have the feel and general controls of RTS. Also the realtime nature, i.e. no waiting for other players to do something as often happens in CivIV.
2. The game will be turn-based, with an emphasis on Line of Sight (LOS) as in Chess, to provide extra depth to tactics, and more strategy to the game overall.
3. The turns for players will be simultaneous, with "action points" being granted over some interval, to keep things moving.
4. The game will take place across multiple planets, with infinite effective play space around each planet.
5. The game will feature around 10,000 units in realtime, if possible, most likely with individual units combined into larger ur-units ("strike groups?" that are moved around as a single entity).
As AI War players will note, numbers 1 and 4 were kept (although the infinite playspace was removed and then reimplemented in a revised manner post-release), while 2 and 3 were completely discarded as nonviable rather early in alpha. #5 turned out to be vastly more feasible than I had anticipated, and the unit counts grew to 3x to 6x my original max estimation, making the ur-units completely unneeded (and thus saving me some valuable development time in being able to skip their implementation).
There were hundreds, perhaps a thousand or more, other soft design goals that rose and fell during the 7 month development cycle of the game, but this was just part of the iterative design process.
Implementing The "Immutable" Goals, Two Examples
In looking at my immutable design goals, not one did I have to deviate from. These were the core design tenets for the game, and spoke more to the feel and style of the experience than a particular methodology, after all. Experienced AI War players might look at that list and think of the specific end implementation that I arrived at and think that the end implementation is what I had in mind from the start -- but that's not true at all. Some examples out of the hundreds, nay thousands, of important iterative design processes relating to these immutable goals:
Example 1: Co-Op Play Shifts
Problem: For #1, an important sub-goal was that co-op players would never be "out of the game" early, because that would lead either to boredom on the part of that player, or, more likely, to all the players giving up and starting a new game. Having played other RTS skirmishes cooperatively for years, this was the age-old pattern that I really wanted to break.
Background: Early versions of the AI War alpha had the central unit of the game as the Flagship, a mobile starship (then called a capital ship) that had high firepower and defenses, but which was also what caused you to lose the game if destroyed. It was also what let you build most other ships (it was basically replaced by the Home Orbital Command Station, if you are familiar with the release versions of AI War). This also functioned kind of like the Supreme Commander unit in the title by the same name.
Initial Design Solution: When a flagship is destroyed, it turns into a "flagship core," a weak ship that can nevertheless produce a limited number of four or five different kinds of "core" ships for the player, which are devastatingly powerful compared to normal ships but fewer in number. The players-who-are-out thus get to roam the galaxy with their small core of ships, wreaking havoc and causing problems for the opposing players wherever possible (note to AI War players: all of this was before the AI was asymmetrical, and thus before "core" ships took on Mark V status).
Problems With The Initial Design: The problems with this were many, and were interrelated with a whole host of other problems such as the fact that having a powerful, mobile "king" type unit was strategically unbalancing and too similar to Supreme Commander. However, the biggest problem was that playing as the "Flagship Core" with its associated ships was not very fun for very long. This violated immutable rule #3, of always having lots of options open to the player at all times.
Eventual Solution: In the end, many of the related game mechanics shifted, and the concept of the Flagship core disappeared entirely. I did not relish the thought of having to create an entire duplicate tech tree just for deceased players to use (to keep to immutable rule #3), so the decision was to let deceased players keep playing completely as normal so long as their team is surviving.
There is an economic penalty to losing your home command station (since it produces a high number of resources), but the options available to the deceased players are otherwise not diminished. If they are able to fight their way back up and claim some more planets, they can replenish their lost income and more. Each team wins or loses as an entire unit, which makes perfect sense for co-op and was one of those "it's so obvious why didn't I think of that before" moments when it later occurred to me.
Example 2: Number of Options Shifts
Initial Design Problem: For most of the alpha phase of AI War, any player could build any ship class at any time. They had to unlock more advanced versions of each ship type as they went, as now, but the available ship types were not constrained and so there were 30 distinct classes of mobile military ship available to the players at any given time, along with all of the classes of turrets, defensive ships, etc.
This, as you may expect, caused "analysis paralysis" in even the alpha testers, who were very experienced with the game. There were far too many options with too many factors to weigh at any given time. So players tended to gravitate to a few ship types they preferred, building only them, or they tended to just flail about building a random mix of ships. In either case, the strategy was all but killed for ship-building.
Eventual Solution: It was actually my dad who suggested limiting the number of ships available at the start. I was vehemently opposed to the idea at first, believing that it conflicted with my immutable rule #3, but over the course of a wide-ranging design discussion that lasted several hours one Sunday in late March or early April, I came to see the wisdom of what he was suggesting and added several twists of my own -- the per-ship-type-and-level caps, the method of having start positions per map seed (with "bonus ship types" tied to each location), and the Advanced Research Stations.
This was a fundamental shift to the entire game, and really brought it into focus and made it very close to the final product that is now available. I had been so focused on creating a game without constraints on the player before that point, so that players could build their own civilization as they saw fit, that I failed to see that this very lack of constraints also fed into creating best paths for players (in violation of immutable goal #5), a severe problem that I was wrestling with through other angles until this solution was suggested.
A Point When Everything Comes Together
In the second example in particular, you can see how one solution solves a whole host of problems at once, including some problems that seemed unrelated to the issue at hand. In the first example, you can see some examples of how playtesting revealed an "obvious" course of action that never would have occurred to me just staring at design documents.
Basically, here's how iterative design works: you start with good intentions, and some good basic rules, but you create something that is (at first) horribly flawed. Of course, it is horribly flawed, it was only designed in the loosest sense. However, you very quickly have a prototype that works, that is a product, if not a very fun one. But you can start playing it, and you can see what is fun and what is not. With playtesting, you can sometimes even see why certain things work and others do not.
But most importantly, you can see how all of the various ideas interact. AI War is an exceedingly complex game, built upon many different complex interrelating systems. I'm a smart guy, but there's no way I could ever have conceived of all of that in advance. There are simply no other models in the genre to point to for a lot of this stuff, and the interrelationships are all too complex. There are too many nth order effects that only come up through playtesting, and which don't always even come up immediately then.
Building a successful game that is highly complex and innovative is an exercise in constant revision. There are too many hidden problems and "gotchas" if you are trying to push the envelope and do something new. If you never stumble, if you never hit upon an idea that does not work, then you are either very lucky or not really innovating all that much. Because, the fact is, if you innovate in one area, that pretty much requires changes in other areas. And those secondary changes require tertiary changes, etc.
With iterative design, you can work and work and work until the point where everything comes together, twisting and turning each puzzle piece until the ones that fit together have created a beautiful mosaic. Not quite the mosaic you set out to create, but within certain bounds, and with a lot of never-before-seen qualities to it.
You Can't See Around Corners
My theory is that AAA games stick to tried-and-true gameplay models with slight variations largely out of a need to manage these nth order effects in those original design documents that are so prized. It's just too much complexity for any individual or even team to manage in advance of any actual playtesting feedback.
There are two main metaphors I like to use for this conundrum for up-front designs. The first is the image of a twisty hallway that stretches off into the future. You can see to the first bend, but no further. Planning your route in advance is nearly impossible, because you can only see around each corner as you come to the corner that precedes it (as in iterative design).
The other metaphor that I like is that of Chess. Let's say that you are playing a sort of solitaire version of Chess, where each move you make has some sort of semi-predictable opposing reaction. You make a move, and the opponent makes a predictable corresponding move. A game of Chess, like the design of a game of any significant complexity, is going to comprise hundreds of "moves." You can plan the first few with confidence. But as you get further and further into the future, it becomes harder and harder to keep the board state in your mind. There are simply too many variables, especially if you start wondering "what if I did X instead of Y" 5 turns back? That changes everything.
The Chess example is easy to grasp because we all know the supercomputing power required to play Chess at an expert level. Planning the whole of a highly original, complex game in advance requires a similar magnitude of computing power, and I posit that no human can do it. The best anyone can manage is some evolutionary steps in a variety of areas, possibly with some unexpected twists thrown in as data is gathered through playtesting and development. Granted, some highly original games have a lower base complexity, and can be planned out completely in advance. But, for myself at least, as well as many other agile designers/programmers, the idea of all the mental stress and strife involved in such an exercise in advance planning is just too much to bear.
A Chess Grandmaster can look 12 to 14 moves ahead, but that's all. Asking even the best in the world to plan the entire game in advance, even if they knew how their opponent would definitely react to every move, is just too much. This isn't slackness, it's expediency and a desire to explore the unknown.
In Conclusion
Advance planning can indeed allow for the designer to come up with a number of innovations -- even major ones. It happens all the time. My point is not to insult other designers who plan in advance (indeed, I'm in awe of the mental fortitude it takes to balance that many variables with little or no feedback). There is more than one way to design games, for that matter, and I don't begin to suppose that my method of iterative design is the only valid way.
But rather, I posit this: given the same designer with the same initial goals, that designer will produce more innovation via a properly-managed iterative design process with continual feedback than they would trying to design in advance with nothing but self and peer conjecture for feedback. I contend that better data to the designer, earlier in the design process, will lead to better designs. Iterative design probably isn't the only way to arm the designer with that sort of data (extensive past experience is certainly another valid route), but it's a simple and effective method, and one that I think is erroneously scoffed at. AI War wouldn't exist as you know it without iterative design, and that's no joke.
UPDATE: If you want to read more on this subject, check out my post from a year and a half later, More Musings On Iterative Game Design.
Some design teams try to circumvent this a bit by prototyping -- basically, while the design document is being crafted, a prototype is also being developed. Revisions and alterations and discoveries during this prototyping phase are then integrated into the final design document, and this almost invariably is going to result in a better end product.
For a large company with a large team, or for a company that must take their design ideas to investors, or a publisher, or management, in order to secure funding for a new IP, I can't think of a better way to handle this. But, boy oh boy, does this make me happy to be an indie.
What Iterative Design Isn't -- And What I Mean By "The Right Way"
On the surface, it must seem pretty arrogant of me to proclaim that my way of iterative design is the "right" way, against all comers. To be fair, I don't think this is the only valid approach, but the benefits are many and I'm basically just cross-applying some concepts from the larger pool of software development thought. It's very much similar to Rapid Prototyping, or Agile Software methods, or to a certain extent Extreme Programming, etc. My background is in business programming, and these sorts of methods are much more common there -- I've been using and refining my own shade of agile programming in a professional environment for about seven years now, and all I've done is carry it over to game design.
So what's this "right way" business, then? Well, I think that iterative design has, in certain circles, become shorthand for "lazy" or "unprofessional." As in, the designer just sits down without a plan, and cranks out whatever comes to mind. The end result of such an endeavor is rarely good, and/or generally isn't very cohesive or original. It's like sitting down to create a chair out of a bunch of wood, and just starting on the first leg without any plans or advance thought, then moving on to each other leg and the rest of the chair as you come to it. The end result is unlikely to sit particularly level, and for that matter the style of the later legs is likely to be subtly or majorly different from the first leg.
If that's what you think iterative design is, no wonder you'd look down your nose at it. I have similar disdain for such a method as unprofessional and unlikely to work in a real production environment. Sure, there might be outlier successes using such a method, but that's more luck than anything else. Fortunately, what I just described isn't iterative design.
A Starting Point For Iterative Design: Goals
When you set out to iteratively design a game, or any other piece of software for that matter, the most important thing is that you don't start with a completely blank slate. You must have some sort of immutable design goals, and these are ideally paired with some initial design concepts that will guide early prototypes.
In the case of AI War, for example, here were my immutable design goals, which I set several months before starting on the AI War prototype:
1. The game must support co-op play in a way that is fun and painless.
2. The 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.
Additionally, here were my soft design goals (amongst a few dozen other lesser ones):
1. Ideally, it should have the feel and general controls of RTS. Also the realtime nature, i.e. no waiting for other players to do something as often happens in CivIV.
2. The game will be turn-based, with an emphasis on Line of Sight (LOS) as in Chess, to provide extra depth to tactics, and more strategy to the game overall.
3. The turns for players will be simultaneous, with "action points" being granted over some interval, to keep things moving.
4. The game will take place across multiple planets, with infinite effective play space around each planet.
5. The game will feature around 10,000 units in realtime, if possible, most likely with individual units combined into larger ur-units ("strike groups?" that are moved around as a single entity).
As AI War players will note, numbers 1 and 4 were kept (although the infinite playspace was removed and then reimplemented in a revised manner post-release), while 2 and 3 were completely discarded as nonviable rather early in alpha. #5 turned out to be vastly more feasible than I had anticipated, and the unit counts grew to 3x to 6x my original max estimation, making the ur-units completely unneeded (and thus saving me some valuable development time in being able to skip their implementation).
There were hundreds, perhaps a thousand or more, other soft design goals that rose and fell during the 7 month development cycle of the game, but this was just part of the iterative design process.
Implementing The "Immutable" Goals, Two Examples
In looking at my immutable design goals, not one did I have to deviate from. These were the core design tenets for the game, and spoke more to the feel and style of the experience than a particular methodology, after all. Experienced AI War players might look at that list and think of the specific end implementation that I arrived at and think that the end implementation is what I had in mind from the start -- but that's not true at all. Some examples out of the hundreds, nay thousands, of important iterative design processes relating to these immutable goals:
Example 1: Co-Op Play Shifts
Problem: For #1, an important sub-goal was that co-op players would never be "out of the game" early, because that would lead either to boredom on the part of that player, or, more likely, to all the players giving up and starting a new game. Having played other RTS skirmishes cooperatively for years, this was the age-old pattern that I really wanted to break.
Background: Early versions of the AI War alpha had the central unit of the game as the Flagship, a mobile starship (then called a capital ship) that had high firepower and defenses, but which was also what caused you to lose the game if destroyed. It was also what let you build most other ships (it was basically replaced by the Home Orbital Command Station, if you are familiar with the release versions of AI War). This also functioned kind of like the Supreme Commander unit in the title by the same name.
Initial Design Solution: When a flagship is destroyed, it turns into a "flagship core," a weak ship that can nevertheless produce a limited number of four or five different kinds of "core" ships for the player, which are devastatingly powerful compared to normal ships but fewer in number. The players-who-are-out thus get to roam the galaxy with their small core of ships, wreaking havoc and causing problems for the opposing players wherever possible (note to AI War players: all of this was before the AI was asymmetrical, and thus before "core" ships took on Mark V status).
Problems With The Initial Design: The problems with this were many, and were interrelated with a whole host of other problems such as the fact that having a powerful, mobile "king" type unit was strategically unbalancing and too similar to Supreme Commander. However, the biggest problem was that playing as the "Flagship Core" with its associated ships was not very fun for very long. This violated immutable rule #3, of always having lots of options open to the player at all times.
Eventual Solution: In the end, many of the related game mechanics shifted, and the concept of the Flagship core disappeared entirely. I did not relish the thought of having to create an entire duplicate tech tree just for deceased players to use (to keep to immutable rule #3), so the decision was to let deceased players keep playing completely as normal so long as their team is surviving.
There is an economic penalty to losing your home command station (since it produces a high number of resources), but the options available to the deceased players are otherwise not diminished. If they are able to fight their way back up and claim some more planets, they can replenish their lost income and more. Each team wins or loses as an entire unit, which makes perfect sense for co-op and was one of those "it's so obvious why didn't I think of that before" moments when it later occurred to me.
Example 2: Number of Options Shifts
Initial Design Problem: For most of the alpha phase of AI War, any player could build any ship class at any time. They had to unlock more advanced versions of each ship type as they went, as now, but the available ship types were not constrained and so there were 30 distinct classes of mobile military ship available to the players at any given time, along with all of the classes of turrets, defensive ships, etc.
This, as you may expect, caused "analysis paralysis" in even the alpha testers, who were very experienced with the game. There were far too many options with too many factors to weigh at any given time. So players tended to gravitate to a few ship types they preferred, building only them, or they tended to just flail about building a random mix of ships. In either case, the strategy was all but killed for ship-building.
Eventual Solution: It was actually my dad who suggested limiting the number of ships available at the start. I was vehemently opposed to the idea at first, believing that it conflicted with my immutable rule #3, but over the course of a wide-ranging design discussion that lasted several hours one Sunday in late March or early April, I came to see the wisdom of what he was suggesting and added several twists of my own -- the per-ship-type-and-level caps, the method of having start positions per map seed (with "bonus ship types" tied to each location), and the Advanced Research Stations.
This was a fundamental shift to the entire game, and really brought it into focus and made it very close to the final product that is now available. I had been so focused on creating a game without constraints on the player before that point, so that players could build their own civilization as they saw fit, that I failed to see that this very lack of constraints also fed into creating best paths for players (in violation of immutable goal #5), a severe problem that I was wrestling with through other angles until this solution was suggested.
A Point When Everything Comes Together
In the second example in particular, you can see how one solution solves a whole host of problems at once, including some problems that seemed unrelated to the issue at hand. In the first example, you can see some examples of how playtesting revealed an "obvious" course of action that never would have occurred to me just staring at design documents.
Basically, here's how iterative design works: you start with good intentions, and some good basic rules, but you create something that is (at first) horribly flawed. Of course, it is horribly flawed, it was only designed in the loosest sense. However, you very quickly have a prototype that works, that is a product, if not a very fun one. But you can start playing it, and you can see what is fun and what is not. With playtesting, you can sometimes even see why certain things work and others do not.
But most importantly, you can see how all of the various ideas interact. AI War is an exceedingly complex game, built upon many different complex interrelating systems. I'm a smart guy, but there's no way I could ever have conceived of all of that in advance. There are simply no other models in the genre to point to for a lot of this stuff, and the interrelationships are all too complex. There are too many nth order effects that only come up through playtesting, and which don't always even come up immediately then.
Building a successful game that is highly complex and innovative is an exercise in constant revision. There are too many hidden problems and "gotchas" if you are trying to push the envelope and do something new. If you never stumble, if you never hit upon an idea that does not work, then you are either very lucky or not really innovating all that much. Because, the fact is, if you innovate in one area, that pretty much requires changes in other areas. And those secondary changes require tertiary changes, etc.
With iterative design, you can work and work and work until the point where everything comes together, twisting and turning each puzzle piece until the ones that fit together have created a beautiful mosaic. Not quite the mosaic you set out to create, but within certain bounds, and with a lot of never-before-seen qualities to it.
You Can't See Around Corners
My theory is that AAA games stick to tried-and-true gameplay models with slight variations largely out of a need to manage these nth order effects in those original design documents that are so prized. It's just too much complexity for any individual or even team to manage in advance of any actual playtesting feedback.
There are two main metaphors I like to use for this conundrum for up-front designs. The first is the image of a twisty hallway that stretches off into the future. You can see to the first bend, but no further. Planning your route in advance is nearly impossible, because you can only see around each corner as you come to the corner that precedes it (as in iterative design).
The other metaphor that I like is that of Chess. Let's say that you are playing a sort of solitaire version of Chess, where each move you make has some sort of semi-predictable opposing reaction. You make a move, and the opponent makes a predictable corresponding move. A game of Chess, like the design of a game of any significant complexity, is going to comprise hundreds of "moves." You can plan the first few with confidence. But as you get further and further into the future, it becomes harder and harder to keep the board state in your mind. There are simply too many variables, especially if you start wondering "what if I did X instead of Y" 5 turns back? That changes everything.
The Chess example is easy to grasp because we all know the supercomputing power required to play Chess at an expert level. Planning the whole of a highly original, complex game in advance requires a similar magnitude of computing power, and I posit that no human can do it. The best anyone can manage is some evolutionary steps in a variety of areas, possibly with some unexpected twists thrown in as data is gathered through playtesting and development. Granted, some highly original games have a lower base complexity, and can be planned out completely in advance. But, for myself at least, as well as many other agile designers/programmers, the idea of all the mental stress and strife involved in such an exercise in advance planning is just too much to bear.
A Chess Grandmaster can look 12 to 14 moves ahead, but that's all. Asking even the best in the world to plan the entire game in advance, even if they knew how their opponent would definitely react to every move, is just too much. This isn't slackness, it's expediency and a desire to explore the unknown.
In Conclusion
Advance planning can indeed allow for the designer to come up with a number of innovations -- even major ones. It happens all the time. My point is not to insult other designers who plan in advance (indeed, I'm in awe of the mental fortitude it takes to balance that many variables with little or no feedback). There is more than one way to design games, for that matter, and I don't begin to suppose that my method of iterative design is the only valid way.
But rather, I posit this: given the same designer with the same initial goals, that designer will produce more innovation via a properly-managed iterative design process with continual feedback than they would trying to design in advance with nothing but self and peer conjecture for feedback. I contend that better data to the designer, earlier in the design process, will lead to better designs. Iterative design probably isn't the only way to arm the designer with that sort of data (extensive past experience is certainly another valid route), but it's a simple and effective method, and one that I think is erroneously scoffed at. AI War wouldn't exist as you know it without iterative design, and that's no joke.
UPDATE: If you want to read more on this subject, check out my post from a year and a half later, More Musings On Iterative Game Design.
Subscribe to:
Posts (Atom)