Recently an IGF judge accused me of seemingly adding "complexity for the sake of complexity" to AI War. Naturally I disagree with him/her, but I think that it does raise some interesting design questions that are very much worth exploring. So here we are.
The Merits of Simplicity
First of all, let's talk about simplicity. Simplicity is a good thing in general, I think that most people agree. Most indie games that are successful are so because they are simple and have an immediate hook (AI War being one of the few that is both successful and more complex than your average AAA game. Also see: Dwarf Fortress, among a handful of others). Even AAA games have been going through a simplification process for years, partly in an attempt to simply improve usability in general and partly in an attempt to draw a larger audience. Both laudable goals, in general.
Nintendo has always made fairly usable games, in that their surface complexity is fairly low, but their games have become increasingly usable over time. There are fewer hard-stop puzzles in Zelda games nowadays, there is overall a lower difficulty to newer Mario games (or concessions such as more-frequent saves or save-anywhere compared to older games). These are positive trends, and I support them. In fact, certain upcoming of Arcen's own titles -- our upcoming casual puzzle game, and our tower defense game A Valley Without Wind -- are the sort of games that this very same IGF judge would probably approve of in terms of simplicity. For a great example of how a simple game can have amazing depth, see PixelJunk Monsters on the PS3 -- that's the sort of depth that IGF and the industry at large generally would approve of, and it's the sort of game that, overall, I prefer to play myself.
Why Complexity, Then?
So if simplicity is the bee's knees, all games should strive for that sort of design, right? Wrong. Very wrong, in fact. That's like saying that, because Mario Kart is so popular and accessible with its blue shells and its rubberband AI, hardcore racing sims should use the same sort of design. Gran Turismo fans are having heart attacks about now, let alone fans of the even more hardcore racing sims.
Now: I picked the above genre for a reason. Specifically, I love Mario Kart and I really don't like hardcore racing sims. I find them, as a genre, obtuse, too difficult to use, and all around un-fun. In other words, if I was to review one, it would get very low marks from me because I'd simply not be able to appreciate it. Luckily I'm not a reviewer, so that particular difficult situation is not mine to work out a solution to -- I don't personally like those games, but I can understand why others love them in an intellectual sense. But this post isn't about reviewers, anyway -- it's about game design.
I could list a lot of other major games with prohibitive complexity:
- Sim City, despite becoming more accessible over the years, is still very daunting in most respects. Just the basics of the various residential/commercial/industrial zones and water/electricity/fire/school supplies are enough to blow many people's minds, I think.
- Street Fighter IV (or any other fighting game) -- aside from people really into that genre, what most people do is spam punches or kicks, mash buttons until something good happens, and then lose interest because the game doesn't seem very deep.
- Demon's Souls I've written about in the past under the guise of talking about difficulty, but difficulty is also an expression of complexity in this sense, as is the case with Street Fighter IV. A lot of people give up on Demon's Souls due to it being "cheap" or something similar (just look on forums), and completely miss the wonderful experience that is there.
- Any online First Person Shooter game is complex in its own way -- just try logging into a random server, and you'll get shot pretty instantly if you don't know what you're doing. You not only have to be great with the mouse/keyboard (or dual analog sticks), you also need to learn the ins and outs of each map, weapon, class, and all the attendant strategies. Even with tutorials and more than a dozen hours of flight time in Warhawk, I don't last more than 30-60 seconds in the air in one of those vaunted aerial death machines (and that's considered pretty much normal). Any game where you "normally" die every 30-60 seconds if you are good has a pretty steep learning curve.
Clearly, without complexity, all of these games could not exist in anything resembling their current form. But that's a shallow answer. Many of these games have simpler modes or a way that even novices can enjoy them without pain and hours of time investment (see: offline mode/bots for FPSes, button-mashing for SFIV, "just messing around" in Sim City). Even the most complex of these has less surface complexity than, for instance, AI War or Dwarf Fortress (well, Sim City has perhaps a similar amount of surface complexity, actually -- same as flight sims, various other city builders after their game-long tutorials are over, etc).
Why Have Very Complex Games?
The argument that "X games that are popular couldn't exist without high complexity" is a pretty weak argument, really. Games are more than the sum of their parts, and it could be the case that those other games are popular in spite of their complexity, after all. In other words, maybe they would be even more popular if they were simpler -- sounds logical right? And in many cases that is perhaps true.
But, in the interest of designing with intent (also known as "knowing what you are doing"), let's assume that there is a reason the element of complexity is in all of these games. So what is that reason? I posit that, at a basic level, the reason is the same in all of the examples I have given. The reason is simple: to better simulate some aspect of the real world, or something resembling the real world. Let's take a look at these games again, through that lens:
- Sim City is complex because being a mayor + city planner is complex, and that's a subject that interests certain people. In other words, if I like Sim City (and I do, even if I'm not expert at it), it's because I'm interested in the topic at hand. And at some point, if I'm interested in that topic, I hit a point where I say "well, Los Angeles has X feature in its city, and I'd like to make a simulated city that explores that." Sim City is so complex that you can probably do so. You can make realistic, believable hamlets, metropolises, and so forth.
Sim City is interesting as a semi-instructional intellectual exercise, and as a "game" insofar as you get to come up with creative ideas and then try to realize them through the game engine. It's fun to see your ideas work, or learn why they don't work. It's fun to learn the game system and rules, which overall so closely mimic real cities. Of course, if the subject matter doesn't interest you or you don't inherently have a draw towards complex simulations, there is no enjoyment there for you. It will be frustrating, obtuse, slow, and boring. And that's okay -- lots of people like Sim City, but it isn't for everyone.
- Street Fighter IV is complex with its button presses in order to better simulate (very fantastical) fighting. Have you ever taken a martial art? In most of them there are a ton, a ton, of moves. Timing is critical, and you must remember the sequences of motions to each one, and so forth. Fighting games mimic this sort of thing through button combos that have many of the same attributes as their real-world counterparts: critical timing, sequences of motions (button presses), and so on. For fighting game purists, I think there is not a point where they will complain that their character has too many possible moves -- they will delight in being able to pull off ridiculously complex combos, because it shows their mastery of the virtual martial art they are practicing.
For those not very much into the fighting game genre (which mostly includes me), there is just a lot of button-pressing going on, and it all seems pretty random and shallow until you see some real experts play the game. Same as with real martial arts, non-experts tend to just flail around a lot and imagine that this will have results on par with what the experts can do. The experts, in both cases, delight in the knowledge that this is, in fact, not true.
- Demon's Souls, again, is something I wrote about at great length in the past, so I won't reiterate all that here. The short version is that the game is hard and nuanced in order to more accurately simulate the act of exploring hostile dungeons. It generates fear, and a genuine sense of place and exhaustion and a variety of other things like no other game I've played. If you've ever wondered what it would be like to really be the hero in any fantasy tale -- I mean be them, in a very real and mortal sense -- then this is the game for you. But you also have to have a certain amount of patience and skill to go with that true interest in the subject matter. People looking for a casual, unpremeditated experience need not apply.
- For the online first person shooters, it's all one big hierarchy of skill -- one big massive paintball game or virtual battle. I've been quite taken by these in the past, and am quite adept at them, so it's easy for me to look at an FPS game and decide if I think it is interesting for online play or not. The good FPS games for online play tend to have maps with more complexity, so that there are more possible decisions to make and more potential standoff locations. Maps that are too small, or too similar to past FPS games, tend to generate conflicts that are wholly predictable and thus boring.
All of the other aspects of an FPS game -- the various guns, the various classes, the meta-game rules for health and pickups and all that stuff -- all augment the basic skills required for FPS that have been around since Quake or before. Weapons that have strange and unusual powers are popular because they inject all sorts of subtle new strategies (assuming they are well-balanced), which is something that experts in a given genre tend to crave.
Subject Complexity Vs. Representation Fidelity
So, what are the common attributes of why these very complex games are the way they are? In all of these cases, there are one of two drivers: complexity of the subject matter or fidelity of representing that subject matter.
- SimCity is trying to simulate something that is extremely complex with a low degree of fidelity. You don't have to sign paperwork, hire contractors, or go through all the democracy and bureaucratic aspects of being a real mayor -- that takes a huge staff, and is a fulltime job. SimCity is a convincing approximation, as complex as it needs to be to be fun.
- Street Fighter IV is simulating something very complex with a moderate degree of fidelity. Real martial arts take a lifetime to learn, and include both mental and physical training. Fighting games include physical training only in terms of reflexes and hand-eye coordination with the controller, and the rest is mental training.
- Demon's Souls is simulating something that is moderately complex with a very high degree of fidelity, as far as games go. Dungeon-hunting is not simple, but neither does it take the sort of training that advanced martial arts in the eastern style requires (I contend). It's more about general physical fitness, awareness, quick-thinking, and bravery. Demon's Souls requires all but the first from the player.
- Online first person shooters simulate something that is moderately complex with a moderate degree of fidelity. The physics and ballistics are simplified, as are many other aspects of what gun warfare is really all about, but the cutthroat nature and "you can die at any time" aspects of gun warfare are right on. They tend to do a better job of simulating the adrenaline and furor of full-out modern combat than they do of simulating the actual combat itself. But that varies from game to game.
Expert Players Tend To Want Complexity
Genre plays a huge role in the sort of complexity that comes in games like the above. Sim City was groundbreaking for its time, but there were certain simpler precursors (which I can't name off the top of my head) which at least made the idea of a city simulation not entirely unfathomable. Don't get me wrong -- Sid Meier was years ahead of his time and a visionary, I'm sure, but it's not like he handed Street Fighter IV to people who had only ever seen Pong.
In the case of all of these other games, they are late entries in extremely well-established genres. They are banking on players having a certain amount of expertise in the genre as a whole, and their value is in adding a twist or extension onto the genre. Red Orchestra added realistic ballistics; Counter-Strike added strong team play; Half Life added a greater sense of immersion; Unreal Tournament added new game modes, a huge amount of fluidity, and the translocator.
Expert FPS players have played at least one of these games, or another FPS game that was influenced in part by one or more of them. So what does an expert FPS player want? More. I want more guns, or more players, or something new to do, or more maps, more variety, more types of vehicles, more game modes, more actions or specials or weapon slots... just, in general, more. In other words, I have played certain games and done everything I can with them. I had a really great time. Now I want something that is the same, but different. Something that includes everything that I liked about the other game(s) if possible, and which adds a bunch of new stuff to keep me occupied.
This is a trend that, in the end, leads to very complex games for a very hardcore audience. The counter-trend to this is then trying to make other games that are More in terms of graphics and production values, but which are at least somewhat simpler in gameplay. Thus those sorts of games are better able to draw in the hardcore and the less-so alike.
In the case of Sim City sequels, what do they advertise? More complexity, essentially, alongside better graphics (more complexity there, too). They have more buildings, more things you can do, more options, bigger maps, maps next to other maps in whole regions, more special events and special buildings you can put in your cities. In other words: I played an older Sim City, probably didn't do everything possible with it, but did everything that was fun for me personally. Now I want more to do.
Street Fighter IV and Demon's Souls also have lineages that you can trace, and which they expand on for similar reasons. Expert players play games in genres that they like, and expect each game to offer them more than did the one before it. They want there to be more to do than ever before, and they also want to feel like they are more a part of the world than they did in the past.
There are a number of popular variants on even games as old as Chess -- Speed Chess, Bughouse, etc -- and they are (surprise) more complex in some way than the base game itself, in that they add more rules and/or constraints, and are only fit for players who are already pretty good at Chess. The fact that games trend towards complexity is not limited to video games -- look at Magic: The Gathering (which is always getting more complex), or Descent: Journeys in the Dark (which gets more complex with each expansion, and which is itself a more complex take on older games such as Hero Quest).
Complex Simulation, Simpler Interface
One other counter-trend to the above is that of interface. In other words, interfaces for games are universally becoming simpler and easier to use, while the underlying games themselves are often becoming more complex.
Sim City 4's interface is easier to use than that of Sim City 1, although to new players it might not feel as such because the simulation of Sim City 4 is so very much more complex than the original. All that extra complexity has to manifest itself somehow, and that makes the sheer volume and depth of the menus more overwhelming to newbies, even if the menus are more sensibly laid out and better designed and more relevant.
In Real Time Strategy Games (shifting gears a bit here), there have been a similar huge, huge number of interface improvements over the years. Things like dynamic camera zoom, build queue looping, streamlined economies, better minimaps, various quick-menus and context-sensitive displays are commonplace now, and it's hard to go back to older games that didn't have this sort of thing. They can seem... archaic, by comparison. In the current market, you wind up with beginner-friendly RTS games, RTS games that are aimed at beginners and experts alike, and a few that are aimed solely at the true grognards. All of these tend to have streamlined interfaces, but the apparent complexity of the interface increases with the games that have a more complex underlying simulation.
Complexity and AI War
So all of this brings us back to my own game. I've pretty much made my case already -- I think it's now pretty obvious why I or any other game designer might make a game that is complex: we're designing for expert players (either those who are already experts, or those who are motivated to go from complete newbie to expert through one game engine). In the case of AI War, my logic is this: there are already a lot of very accessible, fairly easy RTS games out there. Those games are also beautiful to behold in graphics, and as an indie there is not much I can do to compete with that. Plus, as an indie, there has to be a secondary motivation for any project: I have to want to make it, for reasons other than profit.
I'm an expert strategy player, in terms of humans vs. AI opponents. I don't play pvp much at all, but in terms of AI opponents I can trounce the best AI of a dozen or so RTS games -- or could when I was in practice with each game, anyway, which is why I moved away from each game to the next. The other problem was that all of these other games, despite their polish and accessibility, were starting to become something of a blur to me. If you play enough FPS games, you start seeing the same sort of problem: no matter how many maps are added, no matter how many gun variants, etc, they all start feeling the same. Hence you get wild departures with realistic ballistics, co-op against zombies, etc.
In the case of RTS, what I wanted the most was a better, more interesting AI. But in order for an AI to be good, what does that even mean? That means it has to be inventive, and do the unexpected -- for the AI to be creative as a human opponent would be, basically. In a game with relatively few mechanics and pieces, there is less room for creativity. How creative is Mario Kart versus Sim City, for example? Sim City is so complex that you can really express yourself an a huge variety of ways. In AI War, not only do players need to be able to express themselves convincingly, but the AI does as well. This requires options -- a very wide decision space, in other words. So AI War got complex... and then more complex... and still more complex. And the AI turned out to be stellar partly because of all that complexity. A simpler RTS game could not use my style of AI with as much success.
The other issue, that of all RTS games starting to blend together, was something that was also addressed by complexity. Having a very wide array of units that interact in very different ways makes for a different feel to the game in the same way that the realistic ballistics makes Red Orchestra feel different: there are always more factors to consider than you can really consider, like in real life, but expert players are better at reading the subtle signs and acting accordingly. In AI War, having vastly larger unit counts, much-extended game times, and a huge variety of AI types and map types are all responses to the same symptom: blandness. Larger maps in an FPS game, with more players, leads to a very different style of play. So too, here.
Of course, AI War suffers from the same interface challenge that Sim City 4 does -- the interface in AI War is hugely refined, both in terms of innovations that it includes itself and all the cumulative evolutions of genre standards over the last 20 years -- but because, like Sim City 4, it has more to convey than its predecessors, it can seem worse to some players; most specifically those not as attuned to the genre, or at least AI War. In terms of the expert players of both Sim City 4 and AI War, the reaction is much more favorable in both cases (so far as I know about Sim City -- I certainly was much impressed, but I have not polled their player community).
In the end, what do you wind up with? An exceedingly complex game with a complex-but-streamlined UI. Something that people who have exhausted other RTS games absolutely adore, but which people who aren't into the subject matter are more than a bit mystified by (either feeling like it is too complex to be fun -- ala hardcore racing sims -- or feeling like it is largely random -- ala fighting games -- or feeling like it is very generic -- ala outsider reactions to most any FPS game). You also get plenty of reviewers who prefix their reviews with "I liked/enjoyed/loved this, but only hardcore genre fans need apply."
And those reviewers are largely right, although AI War itself has captured a surprising number of non-genre addicts (or recaptured those who were lost with the newer wave of too-friendly RTS games), or who are only expert at similar genres (4X, citybuilders, etc). Turns out that there is a certain minority of people who simply like complex activities, where "complexity for the sake of complexity" makes perfect sense to them. I am not generally one of those people -- my desire for complexity in a given genre is typically based on having become expert and thus bored.
Conclusion: The Proof Is In The Pudding
In the end, despite the commercial success of AI War (for an online-only indie game, we were one of the top sellers of 2009 -- aside from being the 40th best-reviewed PC game in general), perhaps the best indicator that its formula works for some players is the commercial success of its expansion. I don't know what normal numbers are for sales of an expansion to an existing game -- do 30% of the original customers buy it? 50%? Certainly the number is somewhere south of 100%. In the case of AI War, the first expansion to the game has sold well enough in its first five days to constitute 15% of the customers of the base game, and that number is still climbing.
Given that sales of the base game also are continuing I have no idea where the final percentile will wind up at, but it's notable: the expansion adds nothing except more complexity to an already "too complex" game, and yet at least 15% of the customers of the original wanted more. To me, this says that AI War has met the needs of a specific market segment, and has done so well enough to incur repeat business (as well as a lot of positive word of mouth). Given that Dwarf Fortress, perhaps the mother of all complex and unintuitive games, has enjoyed such positive word of mouth, I think the trend is not at all isolated to AI War.
All of this is just to say that very complex games tend to be complex for a variety of good reasons, and there is an audience for that sort of thing. They have a track record of selling well within their respective niches, but people outside of that niche have a hard time understanding the appeal in every last case. But it's okay that outsiders don't understand: the people in those niches are just happy they aren't being ignored by at least some game developers. Niche markets are still markets, and are worth serving especially if you're a small company with specialty interests of your own.
Monday, January 18, 2010
Sunday, January 17, 2010
What Makes For An Expert Indie Developer?
Last month, I wrote about a hypothetical funding model for indie games development. In it, I posited the question: is there such a thing as an "expert indie developer?" I quickly answered with my belief: yes, it's possible, and there are examples all around you. This post is about what makes for an expert indie developer.
Isn't "Expert Indie" An Oxymoron?
Because, after all, indie developers are sometimes seen as being inexpert by nature -- individuals or groups who are hoping to make it into the larger AAA industry by making a home-grown product of their own as something of a calling card, or as a student project, or just to get the experience. Sure, that sort of thing happens; you do see some indies go "pro" after a successful project or two, and some indies are openly trying to leverage their success in this market in order to get an "in" to the larger industry.
But. There are others of us who are indies not because we are forced to be, or because we are trying to break our way into larger-scale development. I've had some offers to at least interview at very large and respectable AAA developers, but I kindly turned them down, saying essentially "If it weren't for Arcen, that would be a great thing for me, but right now I have to see this through and this is ultimately where I'd like to stay if I can sustain the business." I've always worked in small business, and I've been the head of my projects for years, and I'm not inclined to change those things if I don't have to. Being indie also lets me work on exactly the sort of games I am most interested in, and do it my way, on my schedule. Indie is simply a perfect fit for me.
Another example is 2D Boy, who created World of Goo. You probably already know all about them, but the basic gist is that they started out in the AAA space, and then "went indie" to use their industry-begotten expertise to make projects that they couldn't have created at their previous employers. And thus you get a game like World of Goo. There are countless other examples of small studios being set up by ex-AAA-industry folks.
Okay... So What Makes For An "Expert" Indie?
In many respects, the same things that make any small company able to be an expert software developer. And the same things, overall, that make large companies good software developers. The studio has to know how to make products that people want, know how to position them within their market, and then also know how to support those products. That's a little vague and obvious, though. Here are some specific indicators that I would look for if I were going to choose between indie development studios to invest money in:
Design
1. Does the studio know how to formulate a vision and then stick to the broad outline of it -- while maintaining creative awareness and freedom during the process? In other words, do they (via upfront planning or iterative methods) make products that are sensibly cohesive, or are they a mess of unrelated ideas of various quality?
2. Does the studio know how to evaluate their own ideas? Do they often keep ideas that one or more team members simply love, but that don't work in practice -- despite evidence that the idea should be reworked or scrapped? (This sort of self indulgence is unacceptable in any commercial product, and highlights the need to Kill Your Darlings).
3. Conversely, does the studio know how to properly polish their product? Do they know how to go beyond the basics of simply getting the game functional into making it really feel as if it is professional -- whether the game is 2D or 3D, no matter how good or bad the production values are, some games just "feel right" and others feel shaky or worse. This problem is not limited to the indie arena, of course. Does the team know how to leave enough time to get this final polish done as it needs to be, or do they keep adding new, unpolished features right up until the end?
4. Does the studio know the target genre(s) they are working in? Are they producing designs that are in some way viable in that space. Innovation is great, but there are limits. And on the other side of it, if the studio is just interested in making indie clones of successful AAA games, that isn't very investment-worthy, either. They need to be doing something new, preferably pushing at least one new concept in some aspect of their game, but the game needs to be recognizable to players in some form or fashion to get much traction.
Marketing
1. Does the studio make strong efforts to market their games and get them in front of a larger audience? Whether or not they are successful in this endeavor is irrelevant -- great games get ignored all the time, indie and AAA both. What is important is if they are attacking the marketing problem with as much interest and intent as they did the creation of the game itself, or whether they are just assuming that success will find them on its own (it won't). The type of marketing efforts vary widely, and that's great and expected, but every expert indie studio should be making some sort of effort here.
2. Does the studio know how to build and nurture a player community? Do they foster a forums or similar where there is a reasonably friendly (as far as gamers go in the specific genre) group of players? For some genres, most notably casual, this is much less relevant. But, the main question is if there is an elite clique of expert players that are semi-endorsed by the studio and who are arrogantly driving out newcomers. Most successful indie games seem to have some sort of community, or at least some sort of public following of blog commenters, youtube commenters, or something, where there is more than just caustic toxins from the experts.
Support
1. Does the studio respond promptly, politely, and competently to support questions that arise for past released products? Do they know the answers to common questions, or are players largely left frustrated and having to find answers (or give up) on their own?
2. Does the studio have plans in place for how to support prior released products while developing new ones? Is time budgeted, for example, for making sure that at least severe bugs (but preferably everything that isn't completely trivial) are fixed within a reasonable amount of time?
Project Management
1. Does the studio know how to properly budget time? Do they spend inordinate amounts of time on low-value activities, or are they constantly reassessing their own time usage and making the best of the limited time that they do have? Specifically, are they spending a lot of time on "nice to have" features that they personally want, at the detriment of a reasonable schedule or more core aspects of the game design?
2. Does the studio know how to limit scope? At the start of a project it is great to have a ton of ideas, but past some certain point some ideas must be cut for reasons of time -- otherwise, projects tend to spiral on indefinitely without really becoming materially better from features added past some certain stage. Is there a project manager at the studio who is constantly evaluating features for potential cutting or simplification for the overall good of the project?
3. Does the studio have a method in place for evaluating their own products based on objective feedback, alpha/beta testers, or similar? In other words, do they work toward theoretical end goals based on assumed qualities of their current work? Or, do they have some method for validating that their assumptions about their current work are correct, and that their theoretical end state is in any way valid?
This Is A Living List
This list was last revised on 1/17/2010, but I may revise it some from time to time in the future. It isn't a complete list and probably never will be, and some of the items are subjective or can be bent or broken by certain studios that are nonetheless quite expert. But, in general this list is meant to be a good guide for at least defining what an "expert indie developer" would even mean.
To sum that whole thing up as briefly as I possibly can: An expert indie developer knows what they are doing, approaches their work in a professional and eyes-open manner, doesn't neglect the business side of their work or their customers post-launch, and ultimately knows how to build products that some customer segment is interested in. That's an expert indie developer, and you can find them all over the place if you look.
Isn't "Expert Indie" An Oxymoron?
Because, after all, indie developers are sometimes seen as being inexpert by nature -- individuals or groups who are hoping to make it into the larger AAA industry by making a home-grown product of their own as something of a calling card, or as a student project, or just to get the experience. Sure, that sort of thing happens; you do see some indies go "pro" after a successful project or two, and some indies are openly trying to leverage their success in this market in order to get an "in" to the larger industry.
But. There are others of us who are indies not because we are forced to be, or because we are trying to break our way into larger-scale development. I've had some offers to at least interview at very large and respectable AAA developers, but I kindly turned them down, saying essentially "If it weren't for Arcen, that would be a great thing for me, but right now I have to see this through and this is ultimately where I'd like to stay if I can sustain the business." I've always worked in small business, and I've been the head of my projects for years, and I'm not inclined to change those things if I don't have to. Being indie also lets me work on exactly the sort of games I am most interested in, and do it my way, on my schedule. Indie is simply a perfect fit for me.
Another example is 2D Boy, who created World of Goo. You probably already know all about them, but the basic gist is that they started out in the AAA space, and then "went indie" to use their industry-begotten expertise to make projects that they couldn't have created at their previous employers. And thus you get a game like World of Goo. There are countless other examples of small studios being set up by ex-AAA-industry folks.
Okay... So What Makes For An "Expert" Indie?
In many respects, the same things that make any small company able to be an expert software developer. And the same things, overall, that make large companies good software developers. The studio has to know how to make products that people want, know how to position them within their market, and then also know how to support those products. That's a little vague and obvious, though. Here are some specific indicators that I would look for if I were going to choose between indie development studios to invest money in:
Design
1. Does the studio know how to formulate a vision and then stick to the broad outline of it -- while maintaining creative awareness and freedom during the process? In other words, do they (via upfront planning or iterative methods) make products that are sensibly cohesive, or are they a mess of unrelated ideas of various quality?
2. Does the studio know how to evaluate their own ideas? Do they often keep ideas that one or more team members simply love, but that don't work in practice -- despite evidence that the idea should be reworked or scrapped? (This sort of self indulgence is unacceptable in any commercial product, and highlights the need to Kill Your Darlings).
3. Conversely, does the studio know how to properly polish their product? Do they know how to go beyond the basics of simply getting the game functional into making it really feel as if it is professional -- whether the game is 2D or 3D, no matter how good or bad the production values are, some games just "feel right" and others feel shaky or worse. This problem is not limited to the indie arena, of course. Does the team know how to leave enough time to get this final polish done as it needs to be, or do they keep adding new, unpolished features right up until the end?
4. Does the studio know the target genre(s) they are working in? Are they producing designs that are in some way viable in that space. Innovation is great, but there are limits. And on the other side of it, if the studio is just interested in making indie clones of successful AAA games, that isn't very investment-worthy, either. They need to be doing something new, preferably pushing at least one new concept in some aspect of their game, but the game needs to be recognizable to players in some form or fashion to get much traction.
Marketing
1. Does the studio make strong efforts to market their games and get them in front of a larger audience? Whether or not they are successful in this endeavor is irrelevant -- great games get ignored all the time, indie and AAA both. What is important is if they are attacking the marketing problem with as much interest and intent as they did the creation of the game itself, or whether they are just assuming that success will find them on its own (it won't). The type of marketing efforts vary widely, and that's great and expected, but every expert indie studio should be making some sort of effort here.
2. Does the studio know how to build and nurture a player community? Do they foster a forums or similar where there is a reasonably friendly (as far as gamers go in the specific genre) group of players? For some genres, most notably casual, this is much less relevant. But, the main question is if there is an elite clique of expert players that are semi-endorsed by the studio and who are arrogantly driving out newcomers. Most successful indie games seem to have some sort of community, or at least some sort of public following of blog commenters, youtube commenters, or something, where there is more than just caustic toxins from the experts.
Support
1. Does the studio respond promptly, politely, and competently to support questions that arise for past released products? Do they know the answers to common questions, or are players largely left frustrated and having to find answers (or give up) on their own?
2. Does the studio have plans in place for how to support prior released products while developing new ones? Is time budgeted, for example, for making sure that at least severe bugs (but preferably everything that isn't completely trivial) are fixed within a reasonable amount of time?
Project Management
1. Does the studio know how to properly budget time? Do they spend inordinate amounts of time on low-value activities, or are they constantly reassessing their own time usage and making the best of the limited time that they do have? Specifically, are they spending a lot of time on "nice to have" features that they personally want, at the detriment of a reasonable schedule or more core aspects of the game design?
2. Does the studio know how to limit scope? At the start of a project it is great to have a ton of ideas, but past some certain point some ideas must be cut for reasons of time -- otherwise, projects tend to spiral on indefinitely without really becoming materially better from features added past some certain stage. Is there a project manager at the studio who is constantly evaluating features for potential cutting or simplification for the overall good of the project?
3. Does the studio have a method in place for evaluating their own products based on objective feedback, alpha/beta testers, or similar? In other words, do they work toward theoretical end goals based on assumed qualities of their current work? Or, do they have some method for validating that their assumptions about their current work are correct, and that their theoretical end state is in any way valid?
This Is A Living List
This list was last revised on 1/17/2010, but I may revise it some from time to time in the future. It isn't a complete list and probably never will be, and some of the items are subjective or can be bent or broken by certain studios that are nonetheless quite expert. But, in general this list is meant to be a good guide for at least defining what an "expert indie developer" would even mean.
To sum that whole thing up as briefly as I possibly can: An expert indie developer knows what they are doing, approaches their work in a professional and eyes-open manner, doesn't neglect the business side of their work or their customers post-launch, and ultimately knows how to build products that some customer segment is interested in. That's an expert indie developer, and you can find them all over the place if you look.
Wednesday, December 23, 2009
Fire Sales In Digital Distribution
Right now there's a huge sale going on at Steam, with many games (including AI War) being on large discount. In a recent comment thread over at Rock, Paper Shotgun, some people were wondering how these sorts of sales affect the profits made by indie developers. I commented there, but thought I'd also turn this into a blog post.
Like Jonathan Blow, I can also confirm that the percentage cut is the same with these sorts of deals, with Steam and elsewhere. Digital distributors take a percentage of net profits, so discounts are taken off before that. So, in the case of Steam, that would meant that then the developer/publisher would make less on discounted sales, but so does Steam. However, the loss on any individual sale is generally greatly offset by the huge influx of sales in general that these sort of discounts bring.
With any digital distributor, having a sale on a given game is going to increase its sales volume 10x or more in my experience with AI War. Sometimes as much as 50x, depending on the day. For AI War, one of these sales can make us several month's worth of income from a distributor in a single week. That's why you see this sort of thing so commonly, and why it is becoming even more commonplace. I think that these sorts of sales tend to incite people to buy who might otherwise not, so it's not even really seeming to cut into longer-term sales at all. On the contrary, on the wake of any given sale, I tend to see a ripple effect of higher sales volume even for a week or so after the game returns to full price.
I assume that's people trying the demo while it's on sale, then not buying it in time, then deciding they like it well enough to buy it at full price. Or something along those lines, anyway -- those discounts are essentially marketing costs, is one way you could look at it, given the increase in visibility these sorts of sales bring.
Anyway, in my opinion there's no reason you should feel guilty at all for partaking of buying a game on discount, you're still helping the developer/publisher. If you really want the max money to go to them, you can always wait and buy it at full price, I guess, but I'm always happy to see new customers no matter when they buy it; if I wasn't cool with the discounted price, I wouldn't sell it at that discount, you know?
Like Jonathan Blow, I can also confirm that the percentage cut is the same with these sorts of deals, with Steam and elsewhere. Digital distributors take a percentage of net profits, so discounts are taken off before that. So, in the case of Steam, that would meant that then the developer/publisher would make less on discounted sales, but so does Steam. However, the loss on any individual sale is generally greatly offset by the huge influx of sales in general that these sort of discounts bring.
With any digital distributor, having a sale on a given game is going to increase its sales volume 10x or more in my experience with AI War. Sometimes as much as 50x, depending on the day. For AI War, one of these sales can make us several month's worth of income from a distributor in a single week. That's why you see this sort of thing so commonly, and why it is becoming even more commonplace. I think that these sorts of sales tend to incite people to buy who might otherwise not, so it's not even really seeming to cut into longer-term sales at all. On the contrary, on the wake of any given sale, I tend to see a ripple effect of higher sales volume even for a week or so after the game returns to full price.
I assume that's people trying the demo while it's on sale, then not buying it in time, then deciding they like it well enough to buy it at full price. Or something along those lines, anyway -- those discounts are essentially marketing costs, is one way you could look at it, given the increase in visibility these sorts of sales bring.
Anyway, in my opinion there's no reason you should feel guilty at all for partaking of buying a game on discount, you're still helping the developer/publisher. If you really want the max money to go to them, you can always wait and buy it at full price, I guess, but I'm always happy to see new customers no matter when they buy it; if I wasn't cool with the discounted price, I wouldn't sell it at that discount, you know?
Thursday, December 10, 2009
Encapsulated Businesses For Indie Development
Justin Vincent recently wrote a blog post about what he calls the Venture Matrix, which is basically a way to create a huge company out of a lot of little companies-- or, alternatively/additionally to make it easier to launch successful startup companies. It's a long article, and it starts out with a lot of semi-tangential discussion about centralized necessities, but if you look down at the heading The Birth of Companies and on, there are some really novel ideas there; or rather, he's cleverly applied some best practices from good programming to real world business, and that in itself is quite novel.
The article is well worth a read, and it flows well with a lot of things I have been thinking about recently. I've always worked for small businesses, but often I've had very large businesses as key clients, and so I've had an opportunity to see it from both ends. I much prefer being in a small company because of the autonomy and room for creativity that provides (and the increased possibility of returns if the business does very well), but there's a key aspect often missing from small companies: security. That in itself can be a good thing, because it can prompt the business to be proactive where larger companies might be lethargic. But...
The Inevitable Challenge Of Traditional Small Businesses
On the other hand, lack of funding can lead to lack of certain expertises among available staff. In the past I've been in a company where we had excellent programming staff and support staff, but sales staff that couldn't sell the product, and a very novice marketing staff. That business actually did okay based on word of mouth alone, because clients liked our product and told other clients, but how much better might things have gone if we'd had really excellent sales and marketing staff to match our excellent product?
Or, to cite another example, I once did some contract work for a small company that had developed the world's smallest (at the time) cell phone motherboard. It was about half the size of anything else on the market, back when cell phones were much larger; the possibility of such a motherboard was staggering, because it would have allowed for phones the size of today's devices about 3 years before those actually hit stores. Unfortunately, the company was completely unsuccessful in selling their work because they didn't have the needed expertise on the business development end of things.
I love Justin Vincent's talk about encapsulation in his article, because that's exactly what is needed for companies like these. A lot of startups are product-focused, and they know how to make a product that is really unique and useful inside some niche. But unless they just happen to be lucky enough to have staff who are really ace at sales, marketing, and business development, that great idea is likely to languish in obscurity or at least not reach its full potential.
AI War, for example, has done extremely well for an indie game and is still seeing a significantly growing playerbase every month, but marketing has always been a huge challenge for us. And none of the success we have seen would have been possible without all our digital distribution partners, and our upcoming retail partners. It's still quite a challenge to launch a product even in the digital marketplace, and I had to essentially work two jobs for years and luck into the right partnerships in order to make it happen.
My Ideal Approach For Indie Development
I have been thinking for the last few months about how the ideal setup for indie development would work. In other words, how to maximize output from indie developers, maximize revenue for them and their partners, and in general serve the gaming consumers the best by getting them the widest possible variety of truly quality titles at reasonable prices. Here's the ecosystem I imagine:
Indie Development Company: This obviously already exists, but currently the indie developer has to do most everything -- game development, support, funding themselves, marketing, business development, and so on. In my imagined environment, the indie development company would mainly be responsible for game development and technical support/patches (basically what AAA game development companies are responsible for).
Digital and Retail Distributors: These companies also clearly already exist, and I think that they by and large serve their function admirably. The challenge for most indie developers, however, is actually getting the notice of these distributors. The challenge for these distributors is that they get so many totally crap submissions that it is hard to evaluate what is good and what is not. This is very similar to the book publishing industry, incidentally, which leads us to...
Indie Game Agents: These currently do not exist, not in the sense of the book publishing world. Certain well-connected individuals can act as agents, and in fact there are regional sales agents for retail, but they don't act as quite the career partner and liaison that you see with book author agents. More to the point, most indie developers don't even know these agents exist, and/or don't have any way to contact them. It basically requires having the right network connections, and a track record of existing success in the digital market. If you're unheard-of, then forget about it at present. So, the theoretical agents would be:
1) Available for submissions from all indies (acting as talent scouts), as with book publishing agents.
2) In exchange for an ongoing commission (10% to 15% of what the indie developer earns) but no upfront fees, will handle coordination of marketing, sales, business development, and so forth in both the digital and retail spaces. They would basically be the indie developer's business guide, advocate to business associates, and so on. Again, like book publishing agents.
3) These agents would be known and trusted by the distributors based on their past successes in finding diamonds in the rough that went on to be successful, and so if your game were to catch the eye of an agent that would be a sure-in to digital distribution at the least. These agents would be the valuable filters to the distribution pipeline, and the net effect in the short term would be to get more quality titles through. Fact is, a lot of indie developers themselves are not persistent enough or good enough at describing their work to catch the interest of distributors who have so much else to do. Right now, to get even digital distribution deals, you have to catch someone's eye at just the right time.
Advertising/Marketing Agencies: These certainly exist, but these are vendors, not partners, in almost every case. They perform a service for a fee for anyone who can pay the fee, and then their work is done. They have no stake in the success of the product (they don't even have to like the product, let alone fully understand it), and they are inaccessible to anyone who can't afford the upfront costs. In the ideal model for the indie market, these agencies would be full partners on an individual game's public image, coordinated by the game agent.
In other words, they would handle the details of advertising and marketing, as overseen by the game agent (who would also be responsible for selecting a good advertising/marketing agency), and they would not see any return on their work except a percentage of sales revenue. This could be anywhere from 5% to 10% of what the game makes in total. This is akin to having a talented in-house advertising/marketing staff, since they have a vested interest in making the products they represent quantifiably more successful.
Investment Partners: The last big problem for indies is funding. Creating a game takes quite a long while to do, and this requires money for staff salaries, contractor pay, health insurance, licensing of development tools, possibly office space (for those that aren't virtual offices), and so on. Really polished indie games are likely to cost anywhere from $200,000.00 USD to $400,000.00 USD (or more) if the staff isn't being paid a pittance upfront in hopes of later return. The idea of the investment partners is that they would be contacted by the game agent, or directly by the indie developer in a few cases, and they would provide upfront funding for projects that can demonstrate their worth.
That doesn't necessarily mean a detailed and rigid design document, given that part of the strength of an indie developer is their ability to innovate and use iterative design techniques. Rather, it's a matter of proving out the team and their ability to execute and refine solid ideas. That could be based on past products (spare-time, second-job type affairs), or based on a prototype. Some of the products an investment partner picks up will flop, as is the case with any such market, but the idea is that the investment partner is structured in such a way that even if 9 out of 10 indie projects they take on do not make a positive return, they as a company still see a positive return based on the 1 out of 10 that is a much larger success.
With the advertising/marketing partners and game agents in place, the likelihood of success only goes up. Additionally, for the savvy investment partner that invests only in indie developers with a history of past success (whether that means commercially-speaking, or in terms of potentially marketable ideas brought to fruition, or whatever the criteria is), the return is likely to be much higher. I could see several tiers of investment partners forming, with higher-percentage-taking investors that might prefer higher-risk investments, and lower-percentage-taking investors that only the "premium" indie developers with mega-hits under their belts could have access to. Arcen would likely be slotted with an investment partner somewhere in the middle of that spectrum, for instance.
What Would This Sort Of Indie Development Approach Really Change?
It would provide a way for indie developers to start small and stay small, which has many advantages as noted in Justin Vincent's article. I am dismayed that so many indie developers basically create a pet project as a way to then launch into the larger industry. Indie development shouldn't just be about launching yourself into AAA development. I started indie, and I want to finish indie, if at all possible.
What does indie really mean, anyway? It does mean smaller projects (not multi-million dollars), but also projects with a lot more creativity -- and therefore risk. It means having freedom to experiment, and less structure to the start of the development process. There is less known up front, and more discovered as you go. With expert developers, you'll get products that would never come about any other way. If you take Jonathan Blow, give him some money and some time, then stay out of his way, you can trust he'll come out with something amazing that he'd never create if he was working at someplace like EA.
Is it possible to be an expert indie developer? You bet. This subject probably deserves a post all of its own, but for now let it suffice to say that there are examples all around the industry. Even just purely from an ROI standpoint for investors and partners, I think that's something worthwhile to cultivate in a more structured way from the business side of things (let alone all of the larger creative benefits to the industry as a whole). The goal is to give the indie development business more structure and security, have encapsulated partners who are better at handling the things that your average indie developer is poor at, and then just let the indie developers do their work.
The investors and partners will of course want to keep an eye on the developers, especially the not-yet-fully-proven ones, to make sure they don't go off on a crazy tangent -- but otherwise they need to just trust that the developers are doing what they need to do to make an innovative product that people will want to buy. If a developer doesn't deliver, which occasionally one won't (these are humans we're talking about), then that developer will likely have an extremely hard time of ever getting significant funding again. So the onus is still on them to deliver a very solid product.
In the end, you wind up with a team of companies that are all focusing on what they are best at, working together to create, deliver, and market products that are superior to what one of the companies could ever have hoped to achieve alone. In terms of percentages, each might have to take a lower amount than they might otherwise prefer (this especially applies to the indie developers themselves), but given the increase this is likely to have on sales volume, the actual amount of revenue received by each party would generally be higher in the end. All of the businesses I just described in my imagined indie ecosystem should be able to be profitable, even quite profitable, if they do their respective jobs well.
And that's still with a $20 or less price point for the games, which is good for consumers. Also good for consumers: if indie developers have the time and money they need to be secure and just focus on creating amazing products, you'll see better products. That's a win for everyone.
The article is well worth a read, and it flows well with a lot of things I have been thinking about recently. I've always worked for small businesses, but often I've had very large businesses as key clients, and so I've had an opportunity to see it from both ends. I much prefer being in a small company because of the autonomy and room for creativity that provides (and the increased possibility of returns if the business does very well), but there's a key aspect often missing from small companies: security. That in itself can be a good thing, because it can prompt the business to be proactive where larger companies might be lethargic. But...
The Inevitable Challenge Of Traditional Small Businesses
On the other hand, lack of funding can lead to lack of certain expertises among available staff. In the past I've been in a company where we had excellent programming staff and support staff, but sales staff that couldn't sell the product, and a very novice marketing staff. That business actually did okay based on word of mouth alone, because clients liked our product and told other clients, but how much better might things have gone if we'd had really excellent sales and marketing staff to match our excellent product?
Or, to cite another example, I once did some contract work for a small company that had developed the world's smallest (at the time) cell phone motherboard. It was about half the size of anything else on the market, back when cell phones were much larger; the possibility of such a motherboard was staggering, because it would have allowed for phones the size of today's devices about 3 years before those actually hit stores. Unfortunately, the company was completely unsuccessful in selling their work because they didn't have the needed expertise on the business development end of things.
I love Justin Vincent's talk about encapsulation in his article, because that's exactly what is needed for companies like these. A lot of startups are product-focused, and they know how to make a product that is really unique and useful inside some niche. But unless they just happen to be lucky enough to have staff who are really ace at sales, marketing, and business development, that great idea is likely to languish in obscurity or at least not reach its full potential.
AI War, for example, has done extremely well for an indie game and is still seeing a significantly growing playerbase every month, but marketing has always been a huge challenge for us. And none of the success we have seen would have been possible without all our digital distribution partners, and our upcoming retail partners. It's still quite a challenge to launch a product even in the digital marketplace, and I had to essentially work two jobs for years and luck into the right partnerships in order to make it happen.
My Ideal Approach For Indie Development
I have been thinking for the last few months about how the ideal setup for indie development would work. In other words, how to maximize output from indie developers, maximize revenue for them and their partners, and in general serve the gaming consumers the best by getting them the widest possible variety of truly quality titles at reasonable prices. Here's the ecosystem I imagine:
Indie Development Company: This obviously already exists, but currently the indie developer has to do most everything -- game development, support, funding themselves, marketing, business development, and so on. In my imagined environment, the indie development company would mainly be responsible for game development and technical support/patches (basically what AAA game development companies are responsible for).
Digital and Retail Distributors: These companies also clearly already exist, and I think that they by and large serve their function admirably. The challenge for most indie developers, however, is actually getting the notice of these distributors. The challenge for these distributors is that they get so many totally crap submissions that it is hard to evaluate what is good and what is not. This is very similar to the book publishing industry, incidentally, which leads us to...
Indie Game Agents: These currently do not exist, not in the sense of the book publishing world. Certain well-connected individuals can act as agents, and in fact there are regional sales agents for retail, but they don't act as quite the career partner and liaison that you see with book author agents. More to the point, most indie developers don't even know these agents exist, and/or don't have any way to contact them. It basically requires having the right network connections, and a track record of existing success in the digital market. If you're unheard-of, then forget about it at present. So, the theoretical agents would be:
1) Available for submissions from all indies (acting as talent scouts), as with book publishing agents.
2) In exchange for an ongoing commission (10% to 15% of what the indie developer earns) but no upfront fees, will handle coordination of marketing, sales, business development, and so forth in both the digital and retail spaces. They would basically be the indie developer's business guide, advocate to business associates, and so on. Again, like book publishing agents.
3) These agents would be known and trusted by the distributors based on their past successes in finding diamonds in the rough that went on to be successful, and so if your game were to catch the eye of an agent that would be a sure-in to digital distribution at the least. These agents would be the valuable filters to the distribution pipeline, and the net effect in the short term would be to get more quality titles through. Fact is, a lot of indie developers themselves are not persistent enough or good enough at describing their work to catch the interest of distributors who have so much else to do. Right now, to get even digital distribution deals, you have to catch someone's eye at just the right time.
Advertising/Marketing Agencies: These certainly exist, but these are vendors, not partners, in almost every case. They perform a service for a fee for anyone who can pay the fee, and then their work is done. They have no stake in the success of the product (they don't even have to like the product, let alone fully understand it), and they are inaccessible to anyone who can't afford the upfront costs. In the ideal model for the indie market, these agencies would be full partners on an individual game's public image, coordinated by the game agent.
In other words, they would handle the details of advertising and marketing, as overseen by the game agent (who would also be responsible for selecting a good advertising/marketing agency), and they would not see any return on their work except a percentage of sales revenue. This could be anywhere from 5% to 10% of what the game makes in total. This is akin to having a talented in-house advertising/marketing staff, since they have a vested interest in making the products they represent quantifiably more successful.
Investment Partners: The last big problem for indies is funding. Creating a game takes quite a long while to do, and this requires money for staff salaries, contractor pay, health insurance, licensing of development tools, possibly office space (for those that aren't virtual offices), and so on. Really polished indie games are likely to cost anywhere from $200,000.00 USD to $400,000.00 USD (or more) if the staff isn't being paid a pittance upfront in hopes of later return. The idea of the investment partners is that they would be contacted by the game agent, or directly by the indie developer in a few cases, and they would provide upfront funding for projects that can demonstrate their worth.
That doesn't necessarily mean a detailed and rigid design document, given that part of the strength of an indie developer is their ability to innovate and use iterative design techniques. Rather, it's a matter of proving out the team and their ability to execute and refine solid ideas. That could be based on past products (spare-time, second-job type affairs), or based on a prototype. Some of the products an investment partner picks up will flop, as is the case with any such market, but the idea is that the investment partner is structured in such a way that even if 9 out of 10 indie projects they take on do not make a positive return, they as a company still see a positive return based on the 1 out of 10 that is a much larger success.
With the advertising/marketing partners and game agents in place, the likelihood of success only goes up. Additionally, for the savvy investment partner that invests only in indie developers with a history of past success (whether that means commercially-speaking, or in terms of potentially marketable ideas brought to fruition, or whatever the criteria is), the return is likely to be much higher. I could see several tiers of investment partners forming, with higher-percentage-taking investors that might prefer higher-risk investments, and lower-percentage-taking investors that only the "premium" indie developers with mega-hits under their belts could have access to. Arcen would likely be slotted with an investment partner somewhere in the middle of that spectrum, for instance.
What Would This Sort Of Indie Development Approach Really Change?
It would provide a way for indie developers to start small and stay small, which has many advantages as noted in Justin Vincent's article. I am dismayed that so many indie developers basically create a pet project as a way to then launch into the larger industry. Indie development shouldn't just be about launching yourself into AAA development. I started indie, and I want to finish indie, if at all possible.
What does indie really mean, anyway? It does mean smaller projects (not multi-million dollars), but also projects with a lot more creativity -- and therefore risk. It means having freedom to experiment, and less structure to the start of the development process. There is less known up front, and more discovered as you go. With expert developers, you'll get products that would never come about any other way. If you take Jonathan Blow, give him some money and some time, then stay out of his way, you can trust he'll come out with something amazing that he'd never create if he was working at someplace like EA.
Is it possible to be an expert indie developer? You bet. This subject probably deserves a post all of its own, but for now let it suffice to say that there are examples all around the industry. Even just purely from an ROI standpoint for investors and partners, I think that's something worthwhile to cultivate in a more structured way from the business side of things (let alone all of the larger creative benefits to the industry as a whole). The goal is to give the indie development business more structure and security, have encapsulated partners who are better at handling the things that your average indie developer is poor at, and then just let the indie developers do their work.
The investors and partners will of course want to keep an eye on the developers, especially the not-yet-fully-proven ones, to make sure they don't go off on a crazy tangent -- but otherwise they need to just trust that the developers are doing what they need to do to make an innovative product that people will want to buy. If a developer doesn't deliver, which occasionally one won't (these are humans we're talking about), then that developer will likely have an extremely hard time of ever getting significant funding again. So the onus is still on them to deliver a very solid product.
In the end, you wind up with a team of companies that are all focusing on what they are best at, working together to create, deliver, and market products that are superior to what one of the companies could ever have hoped to achieve alone. In terms of percentages, each might have to take a lower amount than they might otherwise prefer (this especially applies to the indie developers themselves), but given the increase this is likely to have on sales volume, the actual amount of revenue received by each party would generally be higher in the end. All of the businesses I just described in my imagined indie ecosystem should be able to be profitable, even quite profitable, if they do their respective jobs well.
And that's still with a $20 or less price point for the games, which is good for consumers. Also good for consumers: if indie developers have the time and money they need to be secure and just focus on creating amazing products, you'll see better products. That's a win for everyone.
Wednesday, December 9, 2009
Design Mostly Right: Co-Op In New Super Mario Bros. Wii
This post is a response to the co-op review of New Super Mario Bros. Wii on Co-Optimus. I'm a longtime fan of co-optimus, and so I found it interesting that they gave NSMBW a 2.5/5 on their co-op review, and a 4.5/5 overall. I've had the game for a few days now, and have made it through the first six worlds playing co-op with my wife. Here are my thoughts, from a design standpoint (make sure you read the co-optimus review first):
I see the points in the co-optimus review, and as a game designer I would certainly never have made the players collide with one another in a platformer about precision timing. It's like having extreme friendly fire turned on all the time.
However, that said, for lack of the "perfect" mode of co-op in a Mario game, this is certainly quite wonderful and my wife and I really enjoy it. The bubble has been used to great effect, usually as a last-ditch "save yourself" effect when one player gets too far ahead of the other, or one is about to fall off, or whatever.
The interesting thing is that I feel like the "always having friendly fire on" requires and encourages more cooperation for true success. You can go in and fight and bicker through levels, but you'll never succeed on the harder ones that way. The only way to really succeed is to pay close attention to what your teammates are doing.
Now, granted, I've only played this with two players (not 1, 3, or 4), and I imagine that with 3-4 players this would be a nightmare. But with 2 it's great. One of the most enjoyable Mario games I've played in a long time (and I've played them all), and a lot of that is because it is so hardcore-oriented along with having co-op in it.
For those who were hoping for a co-op experience that would allow for players of wildly different skill levels to play together (which would have been ideal by far), I can see why this scored a 2.5/5. For myself and my wife, this has been a 4.5/5 experience or higher, because of the co-op and the game experience in general. If the co-op had been a bit better, this would have been a 5/5, definitely.
One comment about the mushrooms being the secondary items coming out of question blocks. From my experience, that is not actually true. If all of the players are small, then yes, that's what happens. Normally in single player you would just get a single mushroom, so the extra powerup is sort of a bonus. But if there are a mix of big-or-better players and small players, you will get one good powerup per non-small player, and one mushroom per small player. If everyone is non-small, you just get good powerups. Seems sensible to me.
This game is not perfect, and part of me can really understand why co-optimus gave it a 2.5/5, but I hope that doesn't turn people away from the game who might otherwise enjoy it. It's quite good in co-op, under the right circumstances. It's that caveat there that's the cause of all the trouble.
And that, in a nutshell, is the case for getting feedback from players early and often. It could so easily have been all but perfect as a game. As it stands, I still love it, but not everyone will.
I see the points in the co-optimus review, and as a game designer I would certainly never have made the players collide with one another in a platformer about precision timing. It's like having extreme friendly fire turned on all the time.
However, that said, for lack of the "perfect" mode of co-op in a Mario game, this is certainly quite wonderful and my wife and I really enjoy it. The bubble has been used to great effect, usually as a last-ditch "save yourself" effect when one player gets too far ahead of the other, or one is about to fall off, or whatever.
The interesting thing is that I feel like the "always having friendly fire on" requires and encourages more cooperation for true success. You can go in and fight and bicker through levels, but you'll never succeed on the harder ones that way. The only way to really succeed is to pay close attention to what your teammates are doing.
Now, granted, I've only played this with two players (not 1, 3, or 4), and I imagine that with 3-4 players this would be a nightmare. But with 2 it's great. One of the most enjoyable Mario games I've played in a long time (and I've played them all), and a lot of that is because it is so hardcore-oriented along with having co-op in it.
For those who were hoping for a co-op experience that would allow for players of wildly different skill levels to play together (which would have been ideal by far), I can see why this scored a 2.5/5. For myself and my wife, this has been a 4.5/5 experience or higher, because of the co-op and the game experience in general. If the co-op had been a bit better, this would have been a 5/5, definitely.
One comment about the mushrooms being the secondary items coming out of question blocks. From my experience, that is not actually true. If all of the players are small, then yes, that's what happens. Normally in single player you would just get a single mushroom, so the extra powerup is sort of a bonus. But if there are a mix of big-or-better players and small players, you will get one good powerup per non-small player, and one mushroom per small player. If everyone is non-small, you just get good powerups. Seems sensible to me.
This game is not perfect, and part of me can really understand why co-optimus gave it a 2.5/5, but I hope that doesn't turn people away from the game who might otherwise enjoy it. It's quite good in co-op, under the right circumstances. It's that caveat there that's the cause of all the trouble.
And that, in a nutshell, is the case for getting feedback from players early and often. It could so easily have been all but perfect as a game. As it stands, I still love it, but not everyone will.
Tuesday, December 1, 2009
Indie XMas, And The Start Of A New Adventure
First off, let me plug the Indie Games Xmas 2009 Calendar. This was something originally proposed over on the excellent GameProducer blog, which we at Arcen quickly knew we wanted to be a part of. The idea is that this is an Advent Calendar wherein every day a new indie game, trailer, or similar is released. As it turns out, the first day (today) is revealing AI War. Be sure to check back every day of the month for more updates on lots of great indie games, however; the idea is to promote some great gems you might not otherwise have heard of during a season where the AAA games typically steal the spotlight.
In other news, coincidentally this is also my first day working fulltime for Arcen Games. Up until now I've also been holding down a day job as the CTO of a SaaS software company, but since our 2.0 release and release on Steam, Arcen is now doing well enough to support myself and our composer fulltime in addition to our artist, who has been fulltime since August.
My posts tend to be lengthy, but for this momentous (to me) post, I'm going to keep it quite brief. I've been at my past company for over 8 years, and I'll really miss the people and the clients there -- it's been a great time there, and I'm a bit bummed to no longer be part of that great team. Of course, it was my own choice to leave, and at the same time as I am a bit sad about leaving my last post, I couldn't be happier or more excited about moving into fulltime game development. There's lots of exciting stuff brewing for Arcen in 2010, so I'll be sure to post about that as they come up!
And, you know, I'll post some more on game development topics before too long, too! It's just been a very busy month.
In other news, coincidentally this is also my first day working fulltime for Arcen Games. Up until now I've also been holding down a day job as the CTO of a SaaS software company, but since our 2.0 release and release on Steam, Arcen is now doing well enough to support myself and our composer fulltime in addition to our artist, who has been fulltime since August.
My posts tend to be lengthy, but for this momentous (to me) post, I'm going to keep it quite brief. I've been at my past company for over 8 years, and I'll really miss the people and the clients there -- it's been a great time there, and I'm a bit bummed to no longer be part of that great team. Of course, it was my own choice to leave, and at the same time as I am a bit sad about leaving my last post, I couldn't be happier or more excited about moving into fulltime game development. There's lots of exciting stuff brewing for Arcen in 2010, so I'll be sure to post about that as they come up!
And, you know, I'll post some more on game development topics before too long, too! It's just been a very busy month.
Monday, October 26, 2009
Design Right: Demon's Souls
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.
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 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)