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?

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.

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.

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.

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.

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.

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.

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

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

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.

Monday, September 21, 2009

Designing Emergent AI, Part 5: Don't Squeeze a Handful of Sand

In the fourth installment of this series, I talked about the asymmetrical nature of the AI in AI War. That was intended to be the final article in the series, unless more questions came up that I needed to address. Recently a discussion arose on the Arcen Games forums, however, which I think really helps to illuminate an important point that I never managed to cover in this article series before now.

The Question, From User "dumpsterKEEPER"

I really like the AI behavior that allows for retreats when faced with overwhelming odds. On a number of occasions however, I've noticed this general scenario:

The AI has a strike force on one of my worlds when I jump a fleet in to defend it. As it's a sizeable defense force, the retreat logic kicks in and the AI splits off into multiple groups heading towards exit wormholes. One or more of these groups travel to an undefended wormhole and exit the system without a scratch. However, another group will head straight towards a turreted/defended wormhole and get completely wiped out in their attempt to leave the system.

I would suggest that when retreating, the AI should attempt to prioritize exit wormholes that are undefended or lightly defended. This would make sense with their retreating posture and would leave more AI ships alive to attack again in the future.

My initial response
I thought about this, but it leads to some undesirable ways to then further trick the AI -- leave a REALLY big force on the other side of the undefended wormhole, and then the AI pops out and gets slaughtered. This is one of those places (like the gap in the wall logic) that leads to too-predictable AI in other games. I agree, it will often make the AI act slightly non-ideal in this case, but it also protects it from being trapped into REALLY non-ideal situations, if that makes sense.

One of the forum moderators then suggested that I might consider simply having the AI probe undefended wormholes to see if it's safe. My response to that:

Probing undefended wormholes requires

A) time, during which the AI ships have to do something (and during which time they might well just be getting killed, or giving the human player time to come up with a counter)

B) a way to evaluate if the other side is safe (is it safe if the wormhole is clear, but there are massive fortifications on the other planet? what about if it is a long string of planets, and the danger is somewhere further down? do we get into situations where the AI just runs back and forth between some planets because it can't find an acceptable exit to punch through at either end?).

C) a lot of coordination between the AI ships, which isn't super compatible with the whole emergent AI thing.

This is one of those times where the emergent AI will make a slightly nonideal choice sometimes, but that slightly nonideal choice is actually better in the long term than always making the predictable 100% best choice. I intentionally avoid coding in hard rules like that, because as soon as the AI is too predictable, even if it is very smart, the players can formulate some second-order strategies to counter it. I know this because my play group (the AI War alpha group) is expert at finding these strategies in pretty much all RTS games. We never did find anything too exploitative for RoL or RoN thanks to the lack of walls, but we did for AoE2, AoE3, Empire Earth, SupCom, and all the various expansions -- and the SupCom AI mods, as well, though that took longer.

This really goes to the fundamental nature of the AI in AI War, and why it is in the main better. Will it sometimes do things like this that are tempting to "fix?" Yes. When there is a direct way to evaluate this sort of thing on a per-ship basis, I try to do that while also still making sure it remains fuzzy. A lot of the recent minor AI rules updates have been that sort of thing. But when something requires a lot of intentional ship coordination, or a lot of looking-ahead or scouting or what have you, that's where I start getting very nervous and staying away. The premise of this sort of AI is to stay away from those sort of things, because even though they fix the direct problem, they often cause a whole raft of other problems and exploits down the line...

More from dumpsterKEEPER
Ah, that makes sense. I hadn't thought about it from the potential exploits perspective. Thanks for explaining your thinking though, that's helpful to understand why the AI sometimes behaves the way it does. I can understand the hesitation to add specific rules to the AI as eventually you'd essentially end up with a decision tree AI.

In regards to this issue in particular, I don't think it's a huge deal, it just sometimes strikes me as odd that a group of AI ships will impale themselves on obviously placed defenses. On the other hand, occasional sub-optimal decisions do sometimes catch me by surprise and make the AI feel more "human."

My closing notes
No problem! Glad it's not too big an issue. And, for sure, sometimes those groups of ships will, in the process of impaling themselves, do something important. Or sometimes they'll have enough strength to break through into the adjoining planet and do some real damage on the other side. One of the players in my game on Saturday actually lost his home planet to something like that.

When I was working on the AI code to start out, originally everything was rules-based. And when I switched to a more emergent style of AI code, I thought I'd have to build in more rules there, too. That's why I was so surprised how quickly the AI started being effective, and from that stage on I became careful of second-order effects. I think that's the unique bit of knowledge that I stumbled across by accident, which leads to more effective AI designs in general.

Effective AI is like holding a handful of sand: some sand will trickle uselessly from your hand no matter what, this can't be prevented, but most game AI programmers squeeze the sand more tightly to try and save it, and wind up losing so much more sand in the process.

Next Time?
Once again, we come to the "end." Unless readers bring up more topics that they'd like me to address, this will probably be the final article in my AI series. So, I'm sure that another AI-focused article will come up at some point, in other words, but I don't have any idea when or what the specific subject matter will be. In the meantime, I do have other articles planned on other game-related subjects!

AI Article Index
Part 1 gives an overview of the AI approach being used, and its benefits.
Part 2 shows some LINQ code and discusses things such as danger levels.
Part 3 talks about the limitations of this approach.
Part 4 talks about the asymmetry of this AI design.
Part 5 is a transcript of a discussion about the desirability of slightly-nonideal emergent decisions versus too-predictable "perfect" decisions.
Part 6 talks about player agency versus AI agency, and why the gameplay of AI War is based around keeping the AI deviously reactive rather than ever fully giving it the "tempo."

Wednesday, September 16, 2009

Why Rebalance A Released Game?

The main reason for making these changes (and balance changes in general, you don't have to click those links to understand this article) in AI War is to increase the opportunity cost for a number of actions, and to provide a more rich set of strategic options in general. Some expert players had concerns with the above linked changes that they would basically reduce the viability of certain advanced strategies, but the second link demonstrates why I feel like the strategies in question are all still very valid (but no longer abusable). However, these come with some cost.

But for purposes of this blog article, this isn't a discussion of any specific changes, but is rather a discussion of what makes for good changes versus bad changes. Some external commentators have noted that I am "faffing" about with game balance, which I take great offense to -- I know exactly what I am doing, in terms of my long-term goals, and my actions have all been purposeful and productive. I'm building a longterm game environment, of the sort you normally only see in MMOs. This requires some ongoing thought and commentary from expert players who find tricky ways to abuse the mechanics. But I'm getting ahead of myself.

Why Nerf Strategies?
When an advanced strategy comes up that I feel like is too exploitative of subtle unit interactions or too abusive of the game rules, I often will add a counter (either in AI logic, or in the game rules/mechanics themselves) to counter this. To some, on the surface this seems counter to the goal of having a strategically rich environment. Is it my goal to have all players playing the game exactly the same way, with minor variations? Of course not.

In general, the only reason I ever nerf a given strategy is if it gives too great a benefit at too low of a cost. There have been some really challenging issues of late with players taking too few planets and doing all sorts of clever things, which really causes the AI to be less effective and lowers the difficulty in an artificial way. My response to this has been partly to teach the AI some new behaviorlets, and partly to reduce the benefits and increase the costs for these more esoteric strategies.

Preserve A Rich Decision Space
When I look at AI War, or any game for that matter, the main thing I am looking at is the "decision space." When a single strategy or group of strategies are too effective, the decision space effectively shrinks because expert players would be fools to use any other strategy. This becomes a failing of the game which I have to address through balance updates and new/updated game mechanics in some cases. Individual ship balance is only the beginning, because how players use all the myriad types of ships in concert, plus how they plan their overall strategy, can have an even more complicated effect on game balance.

My goal is not to make all strategies exactly equal (because then the decision space is shrunk by nature of the fact that any strategy is as good as the next, so it doesn't really matter what you do). Having no interesting deviations in strategy is just as much of a game-killer as having one best strategy is.

Instead, my goal is to make strategies that are generally all within a standard deviation of one another, so that players with different playstyles can play as they wish, but also which are context-specific to a degree, so that the truly expert players will adjust their strategy very heavily depending on the specific circumstances of a given scenario. This not only adds to the richness of the strategy of the game, it adds to the replay value.

Of course, when players play below their true difficulty level, they have more latitude to just use their favorite strategy and have done with it. But when things are really neck-and-neck, players should have to make appropriate evaluations of the map and act accordingly, rather than being able to artificially lower the difficulty through exploitative tactics.

Balancing For Very Long-Term Play
Will this annoy some players who rely on these tactics to play at a higher difficulty level? Of course it will, and that is an unfortunate side effect. Any balance shift in any RTS game seems to annoy someone, while (hopefully) the majority rejoice. You might assume that because AI War is not a competitive pvp affair that these sorts of balance issues are not important. To a certain extent this is true, it is certainly much less important that the unit balance be perfect because of a number of facets of the AI War design. However, the overall strategic balance is critical for the longevity of the game.

When I play any RTS game, I am going so solo or co-op against the AI in skirmish mode. That's the only way I play. I basically can get 6-12 months of biweekly play out of most of the better RTS games, and that's the point at which I get bored with the game because I have figured out some sort of killer best strategy that the AI can't counter and that I can't top. At that point there's no other way that I really want to play the game, and I've lost interest playing the game using that best strategy, so there's pretty much nothing left for me to do with the game and I move on.

That's all well and good if you are trying to sell a huge series of RTS games, but with AI War I intend to grow and build it as a series of expansions, not sequels. That means that the core game had better be extraordinarily rock solid, with absolutely no best-paths that people discover after however many months of play. There are always tricky things that players figure out, of course, and so that makes an ongoing balance load for me. This is not unexpected -- Starcraft is still getting balance patches some 11 years after its release, from what I hear, and it is regarded as supremely well balanced.

As with the Starcraft balance updates, my goal is not to quash player innovation -- I applaud it. However, my goal is to keep all strategies within essentially a single standard deviation of the norm, and also to add as much context-sensitivity to the grand strategies as possible. The kiss of death for an RTS game, in my opinion, is when all the games start feeling basically the same to expert players. That's when it's time to move on and find a new game to play. My goal is to keep that from ever happening with AI War, because that's the only way I'll maintain my own interest in the game, let alone the interest of anyone else.

That sort of outlook will annoy a few players as I go, unfortunately -- and I need to be very careful to listen to player feedback and not do something that pisses people off for no reason, or which is hated by a majority of the playerbase. In general I'm pretty averse to doing things that players don't like, which I think is a crucial attitude for game designers to have (just "doing your own thing" or having a "take it or leave it" attitude is stupid and is suicide). However, it's impossible to please everyone when making any given change, and so player feedback has to be weighed against the longterm health of the game. Rebalancing a game that has already been released is always a tricky proposition, but you only have to look at examples such as Starcraft or World of Warcraft to see how incredible the results can be in the long term if care is taken.

Tuesday, September 8, 2009

Monday Depression In A Job You Love

I'm not a doctor, obviously, and I'm not an expert on the human mind or all the various chemical and psychological processes that are ongoing in our bodies and brains. However, like a lot of people, I've noticed that humans in general seem to be pretty cyclical in many of our moods. Obviously this is the most pronounced in manic depressive / bipolar disorder patients, but from observation it seems like they just have a (much) more extreme version of what every person goes through to some greater or lesser degree. I think that OCD patients are also just very heavily exaggerated symptoms of some of the underlying impulses that we all have.

Why am I bringing this up? Well, because it's the first day of the week, and I'm dealing with my usual bout of depression that brings. Today is Tuesday, but yesterday was a holiday in the US so I wasn't working. Usually the depression hits me on Mondays, but since I was off it is instead hitting me today. In the movie Office Space, one of my favorite films, they refer to this as "A case of the Mondays," and that seems about right to me. Certainly when I was working in a physical office, you could notice a distinct atmosphere difference on Monday mornings in all the staff, even those who intensely loved what they do.

So what gives? What on earth do I have to be depressed about right now, for instance? Things are going pretty well overall, I'm mostly doing what I want to be doing and seem to be moving in the right direction for being able to do it fulltime, and I've just had some really happy news in my personal life this morning. Plus, even just yesterday, I was excited about the work I would get to do today. Why on earth should I instead be feeling like things are so bad, and so much is wrong with the world?

Oh -- wait, are you waiting for me to give some big reveal as to why that is? Sorry to disappoint, I have no freaking clue. I'm sure a psychologist or a neurologist could give a better answer. All I know is that it happens, and I don't have clinical depression or anything (the rest of the week I'm generally fine, except when something happens that would make anyone a bit down for a few hours). So the question, for me, is not why this happens but what to do about it.

I had thought that if I was more into my work, that I would not have this trouble. But, clearly that's not the cure because I get this even when I'm working on game stuff right on Monday morning. I think it might have to do with the transition. Even if I'm looking forward to the work, getting back into the work can be a bit daunting. You start staring at that huge forest, rather than just the individual trees, and it can be depressing just how much there is to do.

It might have to do with having too many options and too many decisions to make, I don't know. Normally during the week, I have a short list of items that I am going to hit next. Sometimes new items get slotted into that list ahead of the original items, but that's no bother -- you just roll with it. But somehow at the start of the week it feels like there are more options.

Maybe that's what it is, I don't know. The solution, for me, is simply to start small. Just work on some little thing, important or not, that I can finish in 5-10 minutes. There are plenty of tweaks of that size in my queue. That usually gets me going, but if it doesn't then I just do a few more of those. Within an hour or so, I've completed several small tasks, am in the right mindset, and am ready to move on with the rest of my bigger tasks. The feeling of being slightly off then tends to persist for a few hours, sometimes the rest of the day, but after that initial ramp-up period I'm back in the saddle and at least not hampered by it. And the rest of the week, I'm perfectly fine.

This is perhaps a bit of an odd topic to touch on, especially considering my usual subject matter, but I think this is an important issue. At first this cyclical start-of-the-week depression had me worried that something was wrong, that maybe this was not the right profession for me after all (despite all of the evidence to the contrary). I don't know how many other game designers also have this problem. I think it's a common thing amongst people in general, but especially the "creative types." I'm convinced it doesn't mean anything, it's just some sort of biological problem such as needing sleep/food, or having low blood sugar or what have you. Do what you need to do to move past it as quickly as possible, so that it doesn't cost you a whole day of productivity (who can afford to lose 1/5 of their work week every week to this phenomenon?), and don't read too much into it.

The social tendency to not whine and talk about things like this (just "suck it up") is unfortunate, I think, because it tends to make people feel very alone when they have this sort of issue. But, anecdotally, it seems to be pretty universal to me. Most people just assume it is because there is actually something wrong, such as a job they don't love. That makes people who normally love their job worry even more about things like this. To that I say: let it go. There is some sort of process going on inside us that neither you nor I likely fully understand, but it doesn't mean anything. "Looks like someone has a case of the Mondays" is, for whatever reason, not limited to people who hate their jobs. Once you realize that, the phenomenon is not nearly so alarming.

Wednesday, September 2, 2009

On Writing For Games

A few players and reviewers have commented on the fact that AI War does not have much lore, or much story to it. Some players see this as a detriment, or at the very least as a noncritical oversight that they wish I would fix. Most players don't care either way, of course, and some have even made comments to the effect that they are happy they don't have to wade through a bunch of backstory just to play the game.

Given the above, you might assume that my motivation in having such a limited amount of story (15 lines of intro on the main menu) was simply for time-saving reasons since the majority of players don't care. Or you might assume that I don't like to read or write. In fact I love to write, and I'm an avid reader, so the truth is a lot more complicated.

It comes down to what I'm trying to accomplish with the game. I really do believe that Less is More in the case of certain games. I don't want more story than what your average Zelda game gives, for instance. I very much enjoyed the story in Super Mario RPG, but I find the stories in a lot of the Paper Mario games to be too longwinded. I enjoy Final Fantasy but find most western RPGs to be too longwinded. Etc.

In so many games, there is an abundance of story that is not all that original, not all that interesting, and kind of redundant and bloated in its execution. With some good cutting (and I mean cutting over 50%), you'd arrive at something more the quality of a novel, which I think is important. I prefer reading over television, and I've been an avid writer my whole life even though I never quite made it into print, so this isn't just the opinion of someone who doesn't want to read.

As a great example of Less Is More, you have Braid. A lot of people criticize the little story bits as being unintelligible or whatever else, but I thought it was well done and poignant. And with a lot of the older NES games, where text space was limited, a very limited amount of text was able to convey so much. Zelda 2 is absolutely one of my favorite games, partly just because of the atmosphere of exploration and mystery that is there. With pages and pages of text, I think it would have been a much less compelling experience.

As an example from film, I think that in a lot of movies it is important to not show the monster. Look at all of Hitchcock's films. Less really is more in those cases, because not knowing, not seeing, is what makes it significant. I liked the M. Night movie Signs, but the worst thing in that was when they showed the aliens. Bad, bad idea. The original Star Wars movies were so much better than the later ones also partly because they were more restrained in their storytelling, and followed the "show don't tell" rule (amongst so many other things they did better, but I digress).

Looking around at other mediums, take the comic strip Calvin and Hobbes. There is something called "The Noodle Incident" that Watterson never explains, though it is referred to several times. In one of his books about the strip, he talked about how that was intentional -- any prosaic thing he could come up with could never compare to the crazy half-formed ideas that immediately spring to mind in all the readers for what this "noodle incident" could possibly be.

Sometimes it is good to be explicit. Dialogue, characters, etc, are important in some games. Other times it is better to be more subtle. Show, don't tell -- this is a chief rule of good writing, but not all game writers bother to follow it. Games are a visual medium, and like with great movies, great games don't always have to have a lot of talking. The lore is right in front of you, staring you in the face. You are playing it, creating new lore as you do so. The half-formed stories in your head are vastly superior to the stories that you or I or anyone could actually put down in the game itself to make people read. When you put it on paper, it's showing the monster.

Some movies need to show the monster. Some games need to have a lot of text. But I think an important skill of a disciplined writer is to know when to write and when to hang it up. An amateur writer will always spill out pages and pages of narrative for even the slightest prompt, never pausing to think how original or interesting it really is. This is what you get in a lot of games, and I'm so against that. Ico is a game that is immensely evocative, and tells a wonderful story with hardly any dialogue at all. The latest Prince of Persia game has rafts of snappy dialogue between Elika and the Prince, but it's mostly pretty forgettable. They have some great lines in there, and if they had cut down to just those it could have been much more poignant, but as it was the Prince and Elika could ramble on for what felt like hours.

I guess I subscribe more to an older school of thought, which is not in vogue right now. Suspense movies have been supplanted by horror movies, after all, and I feel like that's a crying shame. A lot of remakes of older movies are actually inferior to the originals because they forget to show not tell.

In the end, what does this really mean? Does this mean I will look down on anyone who wants more story, or who wants to create fanfiction? Of course not. There are loads of games and stories where I want more, and where I considered writing fanfiction (or did write it). However, something I have realized through my trials and tribulations as a writer is that this very state of "wanting more" is in fact a good thing. Leaving the reader loving what was there but wanting more is where you want them -- if you satisfy every last craving for information about the universe of the story, you wind up with a lot of the more modern book series that I am not as much a fan of. It cheapens them.

Some people will disagree with that assessment, and will always clamor for more, or write fanfiction. That's cool with me. Just don't expect me to add to the official cannon for AI War beyond the minimum needed to create and maintain atmosphere. And the bulk of that atmosphere, as in the 8-bit classics of yore, is created via gameplay and gameplay alone. Will every game I code be like this? No. I intend to write some very story-heavy RPGs in the future. But I'm quite proud of how this one turned out.