Jeff On Games

I've been spending a bunch of time reading about continuations and microthreading recently, just trying to wrap my head around them and find areas where they might make sense, specifically in C# using the ISO CLI systems. Of course, the example that most people give is AI, like so the one provided by this article:

 
IEnumerable Patrol ()
{
     while (alive){
          if (CanSeeTarget ()) {
               yield return Attack ();
          } else if (InReloadStation){
               Signal signal = AnimateReload ();
               yield return signal;
          } else {
               MoveTowardsNextWayPoint ();
               yield return TimeSpan.FromSeconds (1);
          };
     }
     yield break;
}
 

Now, implementation details aside (I'm not a fan of the authors implementation of the scheduler), you can then have a scheduler for all of your microthreads that will run each method until it terminates. Run one (or more) of these schedulers in a background thread and everything's awesome right?

Well, I'm not so sure. I have questions about this myself. For example, I would think that this pattern is more useful in cases where you have a lot of things that need to be done in sequence, but potentially in other threads or for multiple frames. For example the "AnimateReload" state from the example. Well, what if that state looked more like this?

 
       if (NeedsReload)
       {
            Signal coverFound = BeginFindCover();
            yield return coverFound;
            if (CoverPoint != null)
            {
                 Signal atCover = MoveToCover(CoverPoint);
                 yield return atCover;
            }
            Signal reloadAnimation = AnimateReload();
            yield return reloadAnimation;
       }
 

This is a more common use case in my mind. Have a procedure that takes many frames of execution and has portions that can be delegated to background tasks (such as path finding, which might take a few frames) and have them written linearly so that it's easier to read.

Here's the problem. Because we've now put the "Alive" check farther and farther away from the actual call, we've ended up in a situation where, at any time, the AI can die, and thus its microthread will need to die with it. To combat this, we'd have to check if the AI is actually alive after every yield, creating this code:

 
     if (NeedsReload)
     {
          Signal coverFound = BeginFindCover();
          yield return coverFound;
          if (!Alive)
               yield break;
          if (CoverPoint != null)
          {
              Signal atCover = MoveToCover(CoverPoint);
              yield return atCover;
              if (!Alive)
                   yield break;
          }
 
          Signal reloadAnimation = AnimateReload();
          yield return reloadAnimation;
      }
 

To say nothing of if the state of the AI was forcibly changed for whatever reason (say, for example, if a Team AI Manager has told him to start running away, or regroup, etc). The only way I can think to combat this is through a special AIYield function which would handle most of that, but even then, I find it hard to think of a way to tell the system it needs to break from the current update thread and start a new one. Reschedule?

What do others think? Am I over thinking this? Am I thinking about this the wrong way? Am I using the wrong tool?

Today I realized another thing that went wrong with our GGJ product, that I felt needed sharing.

1. Starting At the End: This one is twofold. First, we spent a lot of time working on the end boss battle of the game, which, while awesome, had to be integrated with the rest of the game at the end of the jam, mostly in the last hour. The core mechanic of the game, the destruction and rebuilding of objects, suffered as a result. Second, when the game was pitched, I included a portion "at the end" where it turns out you're a horrible person for destroying the world. We never got to this because the game took precedence.

Basically, I've found that almost any game jam game that has the words "and at the end of the game" never gets to that point because developing the core mechanic and building gets in the way. And if you need the end of the game to keep with the theme of the jam, you're going to end up breaking theme.

I will say in defense of my team that it was mostly me talking about the "end of game" theme. Amanda pretty much spent the entire time telling me we wouldn't get to it, so this rest squarely on my shoulders.

In the end, I don't think Quest For Stick fit the main theme of the Jam (deception), but I think the core mechanic was awesome, and I'm happy we decided to make it instead of making something that would obviously fit with theme.

Last weekend, I took part in the Global Game Jam, like I did last year and let me say it was just as fun, if not MORE fun this year than last. Our game, Quest for Stick, was really, really awesome this year, and you can learn more about it from the GGJ page and from our Twitter account. We even have a video of a complete play through of the game. The game is super pretty, only a little bit buggy, and generally I think accomplished everything we wanted.

But this year I went in knowing what to expect. How'd I do this year? What did I learn?

What Went Right

1. The Team. Last year, I said one of the things that went right was having a team. This year, that was even more so. We had a total of 7 people working full time on the game, which, initially, I thought was way too many. So much so that I actually asked people to leave the team and considered leaving the team myself to reduce the number of people. But, when it came down to it, I decided I wanted to work on the game idea and went with the other 6 people to create the game. Honestly, 7 people may still have been too many, as communication and tasking did get hard near the end of the project, but there's no way the game would have been anything near what it was if we didn't have at least that many people. Everyone was basically tasked the whole time, and the game came out great because of it.
   
2. Getting Down To Business: We spent very little time talking design this time, which worked out to our advantage. Although we spent a lot of time later arguing about how exactly the game was going to play, it didn't take away from everyone working, which was good. We got down to making something playable quickly, and didn't try to design too much stuff up front.
   
3. Tools choice: Last year, I was super happy with XNA. This year, the team used AngelXNA, even though I was the only one familiar at all with it, and I was the really the only one well versed in XNA. Even though I spent a lot of time helping people understand Angel / XNA, it was still, by far, better than attempting to use only XNA. It performed a lot of the heavy lifting for us in terms of doing animations, placing and managing actors, and, surprisingly, editing levels, though this is its own bullet point.
   

What Went Wrong

1. Unclear tasking: Occasionally, we got duplicated work or weird moments of down time because, like most game jams, people just shouted out things they needed. Kate was really the only person keeping track of most of these tasks, and really only for herself. For the artists, no one was really in charge of knowing what art was still needed and who was doing what. For a team this large, what we needed to create and consult a list on a whiteboard or cork board that had any asset requests, who was potentially doing them, what was in progress and what was up for grabs. This would have avoided duplicated work and would have given us an idea of how much work was left.
2. Late Playable: Despite my work to prevent this (more on this later), we still didn't end up with an actual playable game until mid day on the last day. Just having *SOMETHING* sometime on Saturday to hand to the artists and designers to make levels on would have helped. We did have lots of pieces that worked, essentially, but didn't get them integrated together fast enough.
3. Encapsulation problems: We had three programmers working together on individual parts of the game, which helped not only keep them tasked without stomping on each other, but made it so people were in charge of very small systems. However, some of the systems were weirdly encapsulated, and required copying and pasting over when we actually got to the point of integrating. Though this actually ended up *helping* at the very end, I would have liked fewer instances where I had to copy and paste the code from one class to another in order to integrate a new system into the main game.

What Didn't Work

So, these things really didn't go wrong, but they were things I was hoping would help us during the jam, but didn't.

1. The Simple CI: Before the Jam, I wrote a simple python script that would query a mercurial repository, pull down new code, build it, copy it up to a network location, then message everyone over gchat. This was awesome in theory, but not so much in practice for a few reasons. First, it didn't work so well. If anyone was signed out of gchat when it went to message them, the CI would get stuck in an endless loop. Second, the network drive would occasionally flake out and not be able to take the new build. Third, we didn't have anything the team could play until Sunday, so the CI ended up being useless until then.
   
2. The Angel Editor: The editor in Angel was an awesome idea, but when we got to the Jam, it was buggy and untested. It didn't save out things correctly, crashed, spawned items in weird places, and didn't work at all with our custom actors. In addition, the editor saved all levels out to the build directory, which was great for everyone but the people who were using it. Besides fixing the other editor bugs, in the future, the editor will probably need to detect whether a debugger is attached, and figure out where to put the levels from there, or create a custom levels folder that can be easily moved back and forth and through to an integratable build.
   

All and all, an awesome Jam. Please play Quest for Stick, and let me know what you think. I'm super proud of it.

I got a few responses from my previous post, and now I want to share my feelings on the subject.

As I stated in the post, I don't agree with David Cage, but I also don't agree with the statement from the reader either. To dismiss what games can offer emotionally or just from a narrative perspective generally with a blanket statement about how games give you the "opportunity to fill the shoes of the lead character" misses the point entirely. What games offer has nothing to do with being in the shoes of the main character, and everything to do with choice and perceived agency.

To answer my own questions, I have never, really, felt like I was in the shoes of a main character of a video game, or that the main character was in any way a reflection of me. Since I can't say that I have ever felt that way, I can't say that there were any instances of having a heightened emotional experience because of it.

In my option, the tools for creating heightened emotional experience in games are frequently exactly the same tools used for creating heightened emotional experiences in movies. Both revolve around empathy, either for the main character or the characters that surround him. Then when something good or bad happens to those characters, you yourself feel good or bad (or embarrassed, or sad, or whatever). The thing is that movies are mostly limited to creating feelings through empathy, but they're better at it that games are for sure, partially because we are given no say in the choices of the characters, and yet we understand the choices they make.

It the comments, good friend Borut talks about a fictional slavery game, driven by empathy for the slave:

If I play a game set in the South before the civil war where the main character is an escaped slave, will I actually feel like a slave? Probably not – but I will have a deeper understanding of what it might have been like, a more powerful understanding than if I watched a movie about it.

I responded in the comments:

Are you sure games are any better at achieving this than other mediums? Could you make a game that captures the hardships of being a slave or an escaped slave be any better than Roots? Part of being a slave was the unfair punishment, something we avoid in games completely.

The classic whipping scene in Roots is probably my best example of a case where empathy actually works way better than agency. Imagine if you were Kunta Kinte in a Roots game, and after every whip, you were asked what your name was. How many times would you respond with the African name? When / if you finally responded with the English name, how would you feel? There is no reward for using your English name, and no reward for using your African name. In both cases, there is only punishment. Because we empathize with Kunta in the movie, we understand why he wants to use his African name, and feel horrible about the punishment he receives because of it. But given the same abstract choice in a game, how often would you respond with the choice that is correct for the character?

This does not, however preclude the idea of offering new or different types of emotional states in games. Borut, again, points out that "a couple Bioware games have made me feel guilt when I treat party members badly (guilt is unique to games)," and he's right. But the feeling of guilt is driven by empathy for the characters you're being mean to. And if the character you're playing should be mean to characters, doesn't this prove that you're not necessarily in the mind of the main character when you perform actions in games? Your character feels good about being a douchebag, shouldn't you? The feeling your having is a result of seeing the impacts of your actions on characters you care about. This is the key to emotional impact in games.

In my opinion, games heightened emotional states don't come from "being in the shoes of the main character," but though agency, and the feelings of agency given through choice. Without that, you're left only with the powers of empathy given in movies. Furthermore, players need to be able to draw the causal line from decisions they've made to the good or bad things happening to characters they care about. You can see this already, even in games that have no plot. Players can create strong emotional connections to, and empathize with, any number of things in games that, through the player's choices, end in a particular situation. This state is heightened when they know that the situation was cause by some specific choice they made, and not just hand of the evil writers. In plot based games I feel the impact can be heightened further, especially if the designers are able to both create empathy for the characters and provide the choices that allow those characters to succeed or fail. Just because it hasn't been done (well), doesn't mean it can't be done, and in fact I think it should be done, and soon.

There is, of course, more I want to say on this subject concerning who we are as characters in a video game, but I want to leave it at that for now.

I've complained about Game Informer before. As "the world's #1 video game magazine" it leaves a lot to be desired. Mostly I think it's just catering to its audience though, so frequently I just give it a pass.

Over the weekend, I read the latest issue of Game Informer and the following letter caught my eye:

I'm writing about your interview with David Cage in issue 198. He stated that video games are unable to generate an emotional experience like those present in movies, and I have to disagree. I feel that video games can offer even more of an experience than movies because of the opportunity to fill the shoes of the lead character.

The letter goes on, but that's the important part. Now, I don't agree with David Cage, but I don't agree with the writer of this letter either. I hear the "fill the shoes" / "you are the main character" argument concerning games and emotion a lot, and before I give my opinion on the subject, I want to ask these questions:

1. When was the last time you actually felt like you were the main character in a game, or, that the main character was you? And…
2. Can you name a time where you had a heightened emotional experience as a result of that feeling that could not have been achieved in any other medium?

I'd like to hear responses on this before I give my own.

I didn't do this last year. I don't know why. I probably wasn't in a reflective mood last year. This year, I've been in a very reflective mood, as you can probably tell from many of my blog posts over the year. I reflected on a lot of things: open standards and web identity, DLC, the possibility of being an indie game developer, and the state of computer science education. Until August, I was even able to post about twice a month, which is pretty good for me.

Besides blogging, what did I do in 2009?

• Me and several other Tools SIG members launched of the Toolsmiths blog, which is going very well, though we have dropped off a bit. Hopefully we'll be able to pick up again in the New Year.
• I participated in the Global Game Jam, which was a blast, and I'm sure will be a blast again this year. I've made plans already to make this a rockin Jam, and get everyone as coordinated as possible right out of the starting gate. We'll see how that goes.
• Darren and I also created AngelXNA, which I've been using and enjoying, and hopefully improving for this year's Global Game Jam. (More on that in another blog post).
• I learned to love distributed version control, a trend that I'm sure will continue.

So what didn't I do in 2009 that I really wanted to get done? The main one is that I didn't finish a game. I've got three currently on my plate, two of which are mostly coded one of which is still in prototype, but nothing finished. This is really frustrating for me for a few reasons. First, the longer I wait to release, the harder it will be to stand out, especially on services like XBLIG. Second, like most people, I entered the game industry to create games, but I've yet to see an actual design of my own make it to a finished, polished state, only ever to a useable prototype. I know this is true for many people, but considering my background I should be able to finish a game. I am going to try very hard to correct this this year.

What do I think is coming in the New Year and new decade? Hopefully you'll see my first game. For more serious predictions, I think you could do worse than listening to Joe Ludwig.

I think that we'll also see more trends towards user created content and personalization, to the point where I think you will actually, eventually, see a game come out on a console that will allow user created mods. The groundwork for this is already being laid out by the Rock Band Network, although it's still a long way from there to a console mod community.

Here's to a new year, new adventures, and hopefully some new games!

A few months ago, I gave a talk at GameX about improving builds and build process, and I've finally gotten around to posting the slides on my website. They are now available here.

There are a few things I wish I'd hit in the talk that just didn't make it in, mainly with asset optimization and best practices for version control, but much of that is in flux for me right now, especially with my new found fascination with Mercurial (and it's very real lack of binary / large file support). Eventually, I'd like to try working on systems for Mercurial and distributed version control which would allow feature branches of artwork, but I'm not sure where to even start.

But all of that is a subject for another day. For now, enjoy the talk!

My good friend and educator Bill Crosbie is asking some tough questions on Twitter, specifically about what to teach fledgling game programmers to make them the most marketable to game companies when they graduate. Now, you might not be able to tell from the Twitter conversations, but Bill is actually very concerned about giving his students a good, foundations based, computer science education, while also giving them the opportunity to make games, and giving them skills that they can immediately transfer into the workplace, all in less than the two years he happens to have them. And what he's asking are actually really hard questions, and got me thinking: What would I want out of programmers coming out of two year and four year programs, both those that are focused on game development, and those that aren't? What can I tell Bill to do to make sure that I would at least consider hiring his better students?

The Never Ending Conflict

This comes down to a never ending conflict that educators are well aware of: the conflict between giving a student marketable skills, teaching them the tools and technologies that are relevant "right now" that they can put on a resume and will immediately generate hits on job search websites, and giving them an actual solid education in computer science and software engineering. Ask most programmers in the game industry (at least the ones I know) and they will tell you the later is more important, but look at who actually gets hired and the former plays a very obvious role. The problem is that when I'm hiring a programmer, I want someone who's smart and gets things done, but I also don't want to take the time to teach them all of the skills that they're going to use on a daily basis. It's a tough balance, and getting programmers that don't understand things about your core technologies, or at least their underlying principles, can be dangerous.

In addition, technologies go out of date so fast that teaching one specifically can be counterproductive. C++ has been the de facto standard in the game industry almost since inception, as we've needed the control and power that C++ provides, but the technology that we're working with under the hood can dictate exactly how we can use C++. Students taught to think about single threads of execution on x86 processors, using primitives that would be perfectly fine in other industries (like stl vectors and strings) would be screwed in today's game industry, an industry which is (now) all about squeezing as much performance as possible out of multiprocessor, multicore systems on x86, x64, PPC and Cell chipsets. And interestingly, this is exactly what's happened. Students taught to think ONLY in an object oriented paradigm have trouble parallelizing their code and thinking in terms of small executable chunks that don't suffer from things like race conditions and cache misses, if they even know what those are.

But what's academia to do? Most game developers won't even look at a programmer unless they have C++ experience, understand OO concepts, have done at least some work in DirectX, OpenGL, or Win32 programming, and has as a significant portfolio of work. This leaves professors looking to help game industry hopefuls little time to discuss things that are essential to computer scientists, like the benefits and pitfalls of functional languages, strong and weak typing, lazy evaluation, early and late binding, combinatorics, state machines and automata theory, synchronization patterns (semaphores versus critical sections), common concurrency issues and how to avoid them, and even compiler and virtual machine theory. Even if they get through all that theory, how many schools will be able to talk about the inner workings of modern chipsets, cache coherency, synchronization primitives, compiler intrinsics, and virtual memory? If you're a recent college graduate that can actually give me a definition on all of those terms, explain how they're relevant to modern computer software and game programming, and has a fundamental understanding of any modern game API, you're way better than I was when I graduated, and maybe better than I am now because I'm not sure even I could do it. And I can't tell you how much of it is important to know when you graduate, and how much you can learn either on the job, or on your own. Even the IGDA curriculum framework lists so much stuff that it would be almost impossible to push through in a 2 or even 4 year program. You have to pick and choose.

So if I can't figure it out, what's an educator supposed to do? Take a best guess I suppose. Fundamentally, though, I think they need to teach what colleges and universities have said they're teaching for years.

Teaching How To Think, How To Learn, and How To Work With The Tools

Most liberal arts colleges and universities still say they teach their students how to think. They're not necessarily teaching skills, and I like that. That's what I want from my programmers: I want them to know how to think, and, more importantly, how to learn. But there's nothing that says that this must all be done with theory, or that it should be done purely with theory. In my mind, the problem is that Computer Science and Computer Game Programming programs come out of science and math programs, and follow their pattern for how to structure classes: either 3 credit classes with focused homework assignments with little to no cross class application, or 4 credit labs where a single lab is considered enough to create a program that demonstrates theory. This is not only not enough time, but it doesn't encourage long examinations of hard topics, it doesn't encourage learning by failure, and it doesn't encourage learning why it all works the way it does.

How many schools actually look to the art world for inspiration? In most art schools, you have 3 credit studio classes, which last actually 6 to 10 hours per week, have only 2 to 3 projects per semester, and are combined with classes on fundamentals that can help improve project work. I don't think I ever had a class structured this way during my computer science education. The closest I ever got was a Software Engineering class, which wasn't really about software engineering as much as software planning, which is completely different. But, for programmers, these project classes should not necessarily be introducing new technology. At least at the start, students should work from the base competencies of whatever the school was teaching the previous semester, and early project classes should expect failure (though not say this out right), and encourage students to spend several days at the end of projects to examine their work for flaws in their design and flaws in their process, not flaws in the final product. This is where we teach students how to learn, and how to find the problems in their own work: by screwing it up royally.

In addition, I feel that early theory classes should be kept separate from those that are teaching applications of programming, especially those that are focused on programming in specific languages. However, the two classes should be linked together and move in conjunction. Each class on algorithms and data structures should be paired with the class that teaches its specific application to the language they're working in, thereby teaching both programming and theory. This I think is the major failing of most CS programs. They teach programming, usually in a specific language, and expect the students to pick up theory on the way. In the worse cases, the students return later to have classes specifically on theory, which is sometimes a repeat of what they already learned, just presented as theory instead of a feature of the specific language. By making that clear separation of learning theory and learning practice in two separate but joined classes, your students should progress faster in both. It also creates a flow in teaching and a reason to move to languages as you progress. When theory classes are ready to introduce things like how memory works, caches, cache coherency, pointers, and the like, that's when you can move your classes on programming into teaching C++. As you learn concepts in functional languages, you can start teaching ML in programming classes. As they learn the theory, they can see how it was applied in the language they're learning.

Finally, by the end of any given program, students should be spending a majority of time in studio classes, working on projects that utilize everything they've learned with frequent review of architecture and progress from their professor. However, this should be supplemented with theory classes that go beyond what they'll need to use on simple projects, like topics in programming languages, lexer / parsers, and the ability to prove algorithms correct, and include seminars in currently relevant technology and concepts (guest speaker series are great for this).

Doesn't Answer The Question

Interestingly, I'm not sure if this actually answer's Bill's questions, but it gets a lot of thoughts off of my head. I actually had an entire set of semester plans that went with this post, but scrapped it when I realized I have absolutely no experience in that regard. I can tell you what I want, which is basically separate theory and practice classes joined at the hip in early stages, followed by advanced topics in CS and software engineering paired with Studio classes. But, for me to tell you exactly how those classes should be structured doesn't make any sense.

So hopefully, without answering the question, I've been at least a little helpful.

I just pushed a new feature to AngelXNA which integrates a very simple (and currently fairly dirty and incorrect) lexer / parser into the console. The nice thing about this lexer / parser is that it allows the Angel console to now track C# objects, instead of just strings. In addition, you can bind various properties and methods of those C# objects to be console callable, which has made actor and level definition pretty easy to do in the new versions.

Here's an example of the old Angel adf files:

ActorFactoryInitializeActorClass PhysicsActor
 
ActorFactorySetColor 0.5 0.5 0.8 1.0
ActorFactorySetSize 3 3
ActorFactorySetDensity 0
ActorFactoryAddTag maze_wall

Each of these was marked with the [ConsoleMethod] attribute bound to their singleton via reflection. It was cool, and it worked, but here's the new system:

ActorFactory.InitializeActor(PhysicsActor.Create())
 
Color = Color(0.5, 0.5, 0.8, 1.0)
Size = Vector2(3, 3)
Density = 0
Tag("maze_wall")

In the back end, ActorFactor.InitializeActor and PhysicsActor.Create are static methods on C# classes, marked with [ConsoleMethod], and the Console class automatically finds them. Initialize actor has an implicit "Using" which means that the object passed to it is the subject of any calls until an EndUsing (or EndActor). So, in reality, the new adfs are shortcuts for console scripts that would look like this:

ewActor = PhysicsActor.Create()
 
newActor.Color = Color(0.5, 0.5, 0.8, 1.0)
newActor.Size = Vector2(3, 3)
newActor.Density = 0
newActor.Tag("maze_wall")
 
World.Add(newActor)

Each of the calls to set actor properties (Color, Size, Density, etc.) are all just properties on the C# Actor object, marked with [ConsoleProperty].

What all of this means is that if you want a class that's accessible from the console and has properties and methods you can call here's what you do. First, create a class that has methods and properties that you want console accessible tagged appropriately, like so:

public class MyConsoleClass
{
     public MyConsoleClass()
     {
 
     }
 
    [ConsoleProperty]
    public string Name
    {
        get; set;
    }
 
    [ConsoleProperty]
    public string Value
    {
        get; set;
    }
 
    [ConsoleMethod]
    public string GetMyInfo()
    {
        return String.Format("{0}:{1}", Name, Value);
    }
 
    [ConsoleMethod]
    public static MyConsoleClass Create()
    {
        return new MyConsoleClass();
    }
}

Second, compile and run you AngelXNA application. It will automatically detect your new class and allow you to now issue the following commands in the console:

myVar = MyConsoleClass.Create()
myVar.Name = "My Name"
myVar.Value = "My Value"
Echo(myVar.GetMyInfo())

So, that's pretty cool! The whole system needs work, as it's fairly dirty. The execution / parse tree can't handle chaining right now, so commands like myVar.Actor.PerformAction() won't work. In addition, there's a lot of boxing / unboxing of values going on, and some wonkyness where the console works mostly in floats. I'm not sure how much of this I'll have a chance to correct, but hopefully much of it as we move forward.

In addition, this whole system needs documentation on our wiki. If you want to help out please let me know.

Lastly, Ian Bogost and Borut Pfeifer have pointed out (via twitter) that AngelXNA definitely needs to be more user friendly to start with. As Ian said, we need things that " will help people get started' and "help them get up and running" quickly. Borut pointed out we may need more screens for the Intro game to explore a lot of the features, but I'm thinking we need more than that. For people that have tried Angel / AngelXNA, what keeps you from starting work quickly? What's confusing? How can we improve the experience and get you working on prototypes quickly and efficiently?

As I said in my last post, I'm looking at releasing an Xbox Live Indie Game in the next few months. Today, along with Darius, I started doing a little bit of math about indie game numbers, and it's gotten me wondering, can you actually support yourself, and a company, on indie games (indie, in this case, meaning a smallish team experimenting with interesting gameplay concepts and styles). Now, I understand that this whole post, since it deals more with money than passion, may end up alienating me from the indie community, but as a developer I want to see small experimental games flourish, and I want to see those people developing them do well for themselves. This post questions whether or not that's even possible under our current thoughts and models.

We've been seeing recently a number of small game companies really hitting a wall when it comes to funding. Introversion had a post on their blog about their money problems, and Mommy's Best, though still pushing ahead, made it clear that the number's on Weapon of Choice were not good. We've had rants from game players about alternative funding models and suggestions from Gabe Newell about public funding for games. What can we take from all of this? What can we do for funding models?

So this whole thing starts with one piece of information: How many copies of a single game does a developer need to sell per year in order to support themselves? Let's start at a base line of $40k per year for a single developer. This may sound like a lot for indie developers and, let's face it, it really is. But I will tell you it SHOULD be a pretty good base line number, for a lot of reasons, not the least of which include the fact that, in the US, as a single developer, you will be taxed on that both as a business and again as a person. Also take into account health insurance costs and the possibility of supporting any person other than yourself, and $40k starts to sound pretty slim.

Now we need to figure in loss to distributors. Let's ignore distributors with up front cost / approval process (XBLA, PSN, and WiiWare) because even developing for these services usually requires either an already proven game or proven team, and we're assuming neither. This leaves us with iPhone, PC (in various forms, we'll focus on two as you'll see shortly) and Xbox Live Indie Games. For each platform, you need to look at distribution numbers, likely price points, and gross income, meaning the income after your distributor (or whatever) has taken their fair share.

iPhone

Let's start with the newest (and, for all accounts, sexiest) guy on the block, the iPhone. Most apps on the iPhone sell for $.99 to $3, with Apple taking 30% off the top. In addition, selling on the iPhone is really all about staying new, staying fresh, and staying on top of the most popular list. In order to do that, you need to stay at the lower price points to encourage impulse buys. That means staying at around $.99 for as long as possible. Here are the numbers:

So at the pretty much standard rate of $1, a single developer needs to push 57 thousand copies of their game per year in order to support themselves, or push multiple applications which can come up to that number. With the number of iPhones on the market somewhere around 6 to 10 million, the question is, how many sales can you except? Mac Rumors reports 4 apps that easily hit almost a million sales, but what's the data like for games? And indie games at that? The most telling post probably comes from the developer of Dapple, who wrote a very long post on how much money he actually made on the product (summary, he has sold a total of about 500 copies). In addition, this post on the price of apps versus their popularity shows very few indie games in the list, Field Runners (essentially an App Store Launch Title) being the notable exception, and very little money being made. Is it possible to be an indie and loved on the App Store? Only indies who have accomplished this can tell you, but 57,000 copies is a really hard number to hit with something interesting or experimental.

Xbox Live Indie Games

So what about Xbox Live Indie Games. Their Gross To Dev numbers are actually exactly the same, though the $2 price point doesn't exist, and the highest amount you can charge is $5. That said, until recently $2.50 was the lowest you could charge, which required about 22,800 copies to be sold per year. Unfortunately, XBLIG sales figures came up very short for most developers. Total download rates are low, as Indie games were hard to find on the dashboard until recently, and good apps are very hard to find, so I believe most people have been ignoring the service entirely. Sales for most games topped at probably around 5,000 copies since launch, far from the required 22 thousand to support a single developer.

PC

Finally we come to PC. On PC, sales numbers small, but you can expect to be able to charge more, though more is expected of a finished product. Games average anywhere from $5 to $30, even from indie developers, and you'd think that, hosting it on your own or through Steam, you'd get more of the pie. Steam unfortunately doesn't publish their numbers, but PayPal does, and we can actually use them as a baseline. Now, we're assuming that you're looking to get above $40,000 here, so we're going to use their range for $10,000 to $100,000, which is 2.2% + .30 per transaction. Here's the numbers:

Looking at these numbers, it's almost obvious why most successful indie developers start on PC. Even with the PC market shrinking (this talk form GDC shows us that you can expect PC sales numbers in the hundreds of copies, thousands if you're lucky), you get to keep a lot more of your money, and the audience is self selecting. People interested in indie games tend to have PCs and may buy your game. (A note to pirates: Look at those numbers and see how much you're taking from that developer, and the numbers EACH DEVELOPER has to hit before even becoming profitable. That, more than anything, should make you think twice about piracy). Hitting these numbers is possible, but not probable. It's quite obvious, to me, from these numbers why most successful indie devs are one man shops, making fairly quick games. This model doesn't scale to multiple developers, and definitely not for multiple years.

Alternative Funding Models

So what about Gabe's suggestion? Running basically a "stock market" for games where you can invest in projects, get a game out of it, and possibly see a little bit from the net profits off of a game? So far, We've seen a commission system partially go out, and partially work, but what about Gabe's suggestion?

Let's assume that for these systems, we're talking about multi-developer, multi-year projects. Still talking indie, let's say 4 developers over a year and a half, which is pretty reasonable I think. This totals (not taking into account taxes, office space, servers, or anything else) $240,000 that needs to be raised over the course of a year and a half. Though this is potentially possible, we'd have to look at other concerns. If a person invest in this game with a promise of returns on the net profits (after other expenses / taxes), he needs to understand the risks involved. After all, if a game company never hits that $240,000 number, and can't survive long enough to complete the game, that money is lost. Attached to this, is the idea of due diligence. Each investor is now an INVESTOR in your game, and can have possible legal rights to it. If you just take the money and never finish the game, they might be able to sue you. What is there in place to protect both the investor and the investee if this happens?

Now, provided these legal fees could be worked out, how much of net profit would you be looking at loosing, and how much would you charge for each point of net profit? What would developers look to gain, and what would investors look to gain. This post is all about numbers, so here we go.

First, let's start with a game that sells about 20,000 copies at $20 each (we're assuming these are good games that have a following, otherwise they wouldn't have been funded in the first place), on PC using the numbers above. That totals $391,000 revenue on the game, and let's assume (for argument's sake) that we have $41,000 in expenses for the game (to make nice round numbers). That leaves us with $350k net. Assuming we split to always end up with getting the funding we need, here's what the graph looks like:

In general, that's pretty grim. Only in the 70% case do the investors come out just breaking even, and the developers have enough to fund half of their next game. Is it possible? Maybe. But is it worth it for the investors? How many times will an investor loose most of their money from games that aren't finished, or games that don't break 20 to 30 thousand copies before they just kind of give up investing? How much work is required of developers just to set up the legalities to make sure they don't get sued, and their investors don't get screwed?

Another funding model for indie devs is to keep titles relevant from year to year, keeping sales of the title up while you work on the next title, and into your third.  By keeping these games selling, you can start to see actual profits. However, this also means consistently releasing games year after year, and surviving until these games come out. This takes a lot of start up capital, or at least the ability or desire to eat ramen for years on end, with only the smallest chance of reward (from looking at these numbers anyway).

Conclusion

These numbers make it really obvious to me why most indie (and, in some cases non-indie) business models exist, and why they produce the games they produce. To be successful, you need to be in one of a few situations:

• A single developer that makes a good title (Petri, for example)
• A single or set of developers with short release cycles to keep multiple games relivant over short periods of time.  (Almost all iPhone developers).
• A developer that has an already popular game and is able to get on one of the more visible services  like XBLA, PSN, or WiiWare (That Game Company, the Behemoth, 2D boy, Number None)

This is why indie games experiment the way they do.  Shorten the dev cycle, concentrate on mechanics and prototypes, keep art resources and requirements low, release lots of games quickly.  I feel like there needs to be more available.  I'm sure there are indies out there that want to experiment with things that take longer dev cycles, (weird dynamics, involved dynamic art styles, or, god fobid, strange narative structure), but can't for survivability reasons, and that's a damn shame.

So my answer to everything here is, maybe there's not a good living to be made in indie games. Even with alternative money sources, it doesn't look like you can sustain a business, even of small number of developers, without competing for AAA numbers, which seems to have a quality bar that almost requires a AAA team. Obviously, the math for that is wrong somewhere, as we've seen it happen, but is it worth it for me (or anyone else) to attempt the struggle when the reward seems to be mostly just more struggle? Is there an answer I'm possibly missing? Is there money to be made in remaining truely independent, or even survivability?  And if there is, can it be done for more models than what we have now?