Jeff On Games

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?

Microsoft today announced that they're changing the pricing model for community games. I both like and dislike this, and in some ways it does actually hurt me in the long term, but I'll get to that. The only thing I like about the new changes is that they've pushed the minimum price point down to $1. I know there are games and applications out there that wanted to charge less, so pushing things down seemed smart.

But there are many things I don't like about the changes.

First, I'm unhappy that they moved the $2.50 price point to $3.00. No one actually keeps track of the conversions, and 200 points was a nice round number that people understood. It meshed with XBLA's round number schemes. 240 points, even though it actually translates to slightly more money, won't have people buying because it's a psychologically weird number. 40 points translates to 50 cents, but psychologically it translates into something completely different. Seeing this weird number, potential buyers might actually do the conversion and think about the price. As a person developing a game that will rely on the impulse buy, I'm not happy about that. In addition, people buying community games will now be left with a weird 60 point remainder, which they won't really be able to do anything with, unless we see XBLA games selling for 460 points ($5.50) or single downloads for 60 points. It's just odd, and it will turn more people away than it will attract.

Second, I'm unhappy that they moved the 50 meg cap to $1, instead of keeping it at $2.50. I'd rather have a 25 meg cap on $1, and a 50 meg cap at $2.50, or a 50 meg cap on both. I've actually been working hard to keep our sizes down to below 50 meg because I wanted to hit the $2.50 price point. Now that it doesn't matter, maybe I won't bother, but it'll just make me more lazy about things like asset optimization, not improve the quality of the game in any way.

Third, why did they feel the need to get rid of the $10 price point? I know very few games are good enough currently to warrant the price, but that doesn't mean it will never happen! Why are 3 price points the magic number here? Why can't it be 4? Why why why?!

Anyway, this all hurts me because my Community Game is getting close to finished, and I'd planned to release it at the $2.50 price point to grab some people doing impulse buys. I feel the game is worth more than $1, but I'm not sure others will feel that way, which is where the predicament comes in. With $2.50 being the lowest price point, anyone playing the game could easily just dismiss the set price as the lowest available. Now they'll actually think about whether or not it should have been priced at $1 over $3, coupled with the fact that it will leave them with that 60 point remainder. All in all, I think if the game I'm working on had been released before this pricing structure change, it would have done better than after the change, and that's just a damn shame.

One of the most frequent questions I get from high school and college students, especially after they read my school article in GCG, is "What programming language should I learn?" Generally, I reply to this question privately over email, but I figure it's something that I should have written about a long time ago, so here it goes. The answer is… it depends.

Now, I'm sure everyone was thinking the answer would be C++, and for the most part, you're right. But you're thinking I get this question from ONLY programmers, and only programmers that are at the level where they'd be able to work with C++ and not get intensely frustrated. Certainly, all people looking to be programmers in the game industry MUST learn C++ and MUST learn it well. But I'm getting ahead of myself. We should first look at the different type of people that ask this question and first ask them a key question: What do you want to be in the game industry? The answer to this isn't always a game programmer. Believe it or not, some artists ask this question, and I don't blame them. The more technical skills any artist has, the better they're going to be at their job. So, I've broken this down into three groups:

Programmers

If you want to be a programmer, and I mean a "real" programmer, and you're at least fairly comfortable with a computer, I recommend you start with C++. A lot of people are going to yell at me for this, because they think C++ is prohibitively hard to learn, that it's on its way out, that it will be taken over by more interpreted languages like Python or C# and that a programmer learning C++ is wasting his or her time. I don't buy it. Almost all AAA game companies still use C++ when it comes to systems level programming, and I don't see that changing any time soon. And even if I did, I'd still recommend C++. Why? Because you are always more comfortable in the language you start in, and C++, through its many idiosyncrasies (and, honestly, poor language design) forces you to think about things like memory management, simple optimizations, side effects, const variables, const methods, references, pointers and (as you get more and more advanced) things like v-tables, performance of virtual methods, memory layouts, and memory trashing. More modern languages do all they can to protect you against some of this stuff, but even they have weird performance pitfalls that, unless you have a sound basis in "close to the metal" programming, you won't fully understand and that you won't be able to optimize away.

In addition, many, many languages, are based off of C++ in some way shape or form. Regardless of whether they carry over any syntax or keywords, far too many languages are classified as "C-like" (including many scripting languages) for you to ignore it and think you'll be able to slide by without a full understanding of it.

That said, if you're in middle school or early high school, I will say there is no problem learning other languages that make your programming life easier, like VB, Python & PyGame, DarkBasic or C#. By the time you hit college, through, regardless of whether your school teaches it or not, you should be learning C++ on your own and some of the libraries that are used in game development with it (either OpenGL and / or DirectX, with a smattering of Win32, just for fun ).  Just be aware that if you're starting in a higher level language, that you may be forming some bad habits that may end up being hard to break.

Designers

Okay, so you want to be a designer. Join the club. Now, everyone wants to be a designer, and my advice for this was, not too long ago, think of something else to do. That is no longer the case. I now believe you can become a designer in the industry, just not the role some people think (aka, not the person who comes up with the idea for the game in the first place). Regardless, I won't go into detail about this in this article, suffice to say most designers should learn programming in some form. My recommendation is to learn the languages you will most likely use on a daily basis, and those are the languages that are used to automate tasks in Excel. This means VBA and VB.NET (and / or C#). You will be surprised just how powerful these languages are, and how much more effective you will become at working with Office after having learned them.

If you're really adventurous, you may also want to learn a scripting language like Lua or Python, and learn a game making framework like PyGame. Why? Well, cause, then you can make your own games pretty easily, and that's what you wanted in the first place right?

Artists

For your run of the mill artist, I say learn two languages: MaxScript (for obvious reasons) and Python. Unlike MaxScript, Python is actually used in other places than art, and is a more fully featured language. However, it's also integrated into most art tools, including Maya, so you waste no time by learning it. As a bonus, Python has PyGame, which means if you have even the slightest understanding of Python you can actually make your own games without programmer assistance. And if you can do that well, I hate you, as I have no art skills what so ever.

I also recommend that artists at least take a look at C#, as many game companies are starting to integrate C# into their tools pipeline, and a smart tools engineer will find ways to allow small C# "scripts" to be run on top of their tools (this is actually very easy to do, though it takes a bit of forethought in the tool's design, but I digress). Anyway, learning the language won't hurt you, and may help as C# becomes more common.

What about…

So, many people will read this and wonder what happened to their favorite tool or language. Flash and ActionScript in particular are missing, as are the scripting languages for tools like GameMaker. Well, in my mind these are specific tools, and if you want to use these tools (or you're forced to use these tools), then obviously you will have to learn their languages. The good part is that, as you learn programming languages, it becomes easier to pick up other programming languages, and the ones that I've mentioned as places to start are all languages that will give you a firm enough basis that you should be able to pick up other languages easily. I don't see the purpose of learning a specific language first. Their applications are so limited that their practicality is diminished.

So I hope that answers the question about what language you should learn. Hopefully this helps point some people in the right direction. Good luck everyone!

Gamasutra has an interview with VP of PR and Marketing for Bethesda Pete Hines about DLC. The article is pretty interesting (at least the DLC parts) and if you're at all interested in the subject I suggest taking a quick read. I wanted to make a few comments on it (as I'm interested in DLC models in games), but first I have to do a quick disclaimer first, so here it goes:

I am a former employee of Bethesda, but any comments I'm about to make do not reflect on the company's opinion of anything. I was never in any position to make any decisions about the design of their games, the business model of their DLCs or anything related to anything other than the lowest level system code. DO NOT ATTRIBUTE ANYTHING I SAY TO BETHESDA OR EVEN TO A FORMER BETHESDA EMPLOYEE PLEASE!!!

With that out of the way, I'd like to comment on Pete's stance on large expansions as DLC:

What we discovered was that we want to be able to do stuff that doesn't take a year to come out.

All these people are out there playing our game by the hundreds of thousands on a daily basis and we want to be able to bring those folks something they could do in a much shorter time frame, rather than just saying, "See you next year." That instantly ruled out doing a big expansion because those things just take so damn long to do.

I'm only partially with him on this one. I honestly think Oblivion got it right. Offer a wide gambit of stuff to get: small digestible chunks along with one (or two) big expansions. That way, you don't have to say "See you next year" and you still provide a big expansion, which increases the visibility of the game immensely (and encourages people to get more DLC). With the excellent design and art team they have at Bethesda, splitting the group into a set of small(er) DLCs and one large expansion just makes sense to me. It keeps the game fresh for those that are going to want things fast, but also increases the game's and DLC's profile when a giant expansion comes out.

I also think that there's one model that Bethesda isn't touching on, and I hope more companies think about as a future revenue model soon. That model is episodic DLC content; content that builds off of itself and is offered (say) once a month at a reasonable price point, then bundled together at the end. A game like Fallout or Oblivion (it seems to me) is the perfect place for something like this: a full game that's expanded over time with DLC. It strikes me as a better alternative to games like Gears, which were episodic, but at a full price point for each title, and on different disks. I think we're still placing too much emphasis on engine improvements when in some cases people just want to continue the game. Sure Gears 2 looked better, but couldn't they have released DLCs to continue the plot while working on the next engine in parallel?

Interestingly, it's been my prediction for a long time that more and more games will start looking towards DLC and episodic models to create games. This doesn't mean we'll see the end of "big blockbuster" games any time soon, but I think it will not only become more and more common to release things episodically, but almost an expectation of the audience. Already, you're starting to see games sell on the promise of DLC, or demands for DLC after a game ships (like Mass Effect). I think this is only going to become more common.

Right at the tail end of GDC, Microsoft released to developers the XNA Community Games sales figures. While many of the top sellers are keeping their data private (including Miner Dig Deep and the Masseuse products), many have released their data to Gamasutra, which has a very nice in depth discussion. The general consensus? Most developers are disappointed.

Now before I get into defending Microsoft and the XNA platform as a whole, let me say that the release of sales figures after GDC was certainly not a mistake. If sales had been going well, Microsoft would have done everything in its power to get those figures out either before or during GDC in order to bolster more developer support for the platform. As it is, they knew most developers would be disappointed with the figures, and thus waited until after GDC when the news would have the smallest impact. PR guys are smart like that. So trust me, Microsoft knew you'd be sad and is trying to cover up its mistakes on the platform.

Now I'm going to play the devil's advocate against the indies here (who I respect greatly), and just say that I think Microsoft is getting a bad wrap for poor sales figures. Most of the articles I'm seeing are about how Microsoft isn't promoting the platform, and how Microsoft isn't promoting their games, how Community Games are hard to find on the NXE (TRUE!!! I complained about this already!). No one's blaming themselves for the lack of good games on the system, which is relegating it to second class citizenship. No one is complaining about their own lack of marketing. In fact, some of the games that have pretty good sales figures (not great) are marketing themselves, and are seeing profits as a result. You can't expect Microsoft to do all of this for you, just because you're on their service that they provide you mostly for free. That said, even those with good marketing (like Weapon of Choice) aren't doing great, but at least it doesn't look like they're blaming Microsoft at all. They're just disappointed.

Of course, many are taking this opportunity to talk about how much better iPhone would be to develop for, but I can't stand these comparisons, mostly because the type of game that is going to sell well on the iPhone is going to be different from one that is going to sell well on a console. iPhone is all about the impulse buy. $1 for some small app that looks fun that I want to play right now because I'm bored on a bus, or that serves a need I have right now, but may never have in the future. If that's the game (or app) you're developing, you need to be on iPhone because your game isn't going to sell well on XBLCG anyway. Console sales just are not going to work that way, and you shouldn't expect them to. The amount of money, time, and polish that needs to go in to something that will be sold on a console is higher (IMO) than something sold on a mobile platform because it needs to capture the user's attention for longer. On iPhone you develop for a short attention span, and on XBLCG, you need to develop for the longer attention span. It's just necessary.

Lastly, I want to reiterate how Microsoft and Apple are the only people that are providing an open platform for development, and should be lauded for that alone. It seems both companies thought of the idea at the same time. The 1.0 refresh of XNA was released in April of 2007, a full year ahead of the iPhone SDK, and Microsoft announced Community games in February of 2008, a month ahead of Apple's SDK announcement (which included their app store announcement). However, Apple shipped first and with more features (including sales figures) starting in March of 2008, whereas the NXE (which included the CG store) launched in November of 2008, and didn't get sales figures until last week. In general, both companies deserve kudos for opening previously closed development platforms, and for giving the average person the opportunity to make money on the platforms, but when it comes down to it, they're still very different platforms with different concerns, and attempting to compare them (in my mind) is absolutely ludicrous, so much so that I won't even talk about the millions of features Microsoft HAS to offer in order to keep up with their own XDK technologies (including parental control) that Apple hasn't even touched on yet.

Really lastly, I have ideas on what really needs to happen for CG to really be a "quit your job" platform, but that will have to wait for another post.

I apologize for being quite silent on this blog recently. I've been super busy with work, personal projects, and my new blog, the Toolsmiths. In general, I'm super excited about the success of the Toolsmiths. We've been hit on reddit twice (with HUGE traffic spikes both times) and the comments have been generally excellent. I'm hoping that the momentum will continue straight into GDC, when I'll be hosting the Tools SIG roundtable to discuss the various ideas for the direction of the SIG in the coming year. The blog was a great start, and I think it has gotten people excited about the Tools SIG again by making it visible. Now we need to leverage that into community projects that can actually help the community.

As a side note, I can really only act on all of these plans if I'm elected Tools SIG chair. If you haven't voted yet, please remember to vote soon, as elections close on Friday.

In addition to the Toolsmiths, I've been working on some small side projects, including a port of Sort to XNA, and a port of Angel to XNA. I know a lot of people are interested in the Angel port, and so far it's coming along very nicely, though it does have a lot of differences from the original Angel (especially in the rendering department, obviously). Hopefully I'll have my first alpha for that available after GDC, but we shall see.

I took part in the Global Game Jam this weekend, and I have to tell you, it was a lot of fun. Version 1 of the game we created, The Game Of Nom, is available from the Global Game Jam site, and was voted third favorite at the location we were participating in, and I think that was a fair place for it to be (Move Mouse To Fulfill Destiny and The Beat were really awesome). I'm really happy with how the game turned out. It had the right feel and I think it really extracted the emotions from players that we wanted. The rules were simple enough that you could easily sit down and play it, hard enough that you could play for a while before winning, and interesting enough to be fun. That all said, the game is fairly buggy, especially when you're moving around flocks or trying to combine them, and that's a huge detriment to the game. At some point, Darren or I may actually fix a few of the issues and post a new version on the game jam site, but don't hold your breath.

So, for my own sanity and for future reference for everyone, I thought I'd do a post mortem of my experience.

What Went Right

1. Enlisting the full time help of an artist. Amanda did an amazing job of giving us a feel for the game very early. I have no doubt that without her, the game wouldn't have been nearly as fun or interesting, and wouldn't have achieved this balance of fun and message that we wanted. By having a cute style to the game, we were able to present the dark message without seeming overly pretentious, which was awesome. My new rule is "artists make things look cool quickly," so get them involved early and things will look cool early, and get everyone really energized for the rest of the jam.
   
2. Having a team. The first game jam I participated in, it was just me. Now, that was great for rapid iteration, but not for making something really interesting. I didn't have anyone to bounce ideas off of, and no one to really keep me focused and in line. Working with Darren not only allowed us to do something a little bit more complicated than we would have been able to do alone, but also ended up producing a much better product.
   
3. Not sweating the small stuff. For the most part, I think we did a good job not worrying about some of our problems until later, and getting the game playable quickly so we could test it and refine it as needed, instead of spending lots of time doing things like improving the flocking behavior (which, I'll admit, I spent a little too much time on anyway ). The key to Jams is knowing when things are "good enough," and I think we did a pretty good job with that.
   
4. Tools choice. Although we had some problems with it, XNA/C# is a really great prototyping language. Right before the Jam, Darren and I were considering other options, including the beta of Unity that was made available to the jammers. The things was, we didn't want to spend lots of time fighting to get things on screen and working, when we could spend time on the game play. XNA didn't give us a lot of pain for our simple little 2D game, and for that we were pretty thankful.
   

What Went Wrong

1. Needing a prototyping framework. XNA is awesome, but it's not a great prototyping framework. As I don't do too much prototyping, I really don't know what I need and what's overkill. I found that the two things I really ended up wanting / needing were a simple object manager and an actor framework / state machine framework. We actually implemented states very late in the process and they were very hacked together. I found myself wishing we'd had OnEnter / OnExit / ChangeState for the little blobs frequently, but implementing states would have taken more time than hacking around them. In this respect, we maybe should have gone with Angel which has that stuff already built in, but it'd come out the day of the Jam, and I didn't want to try to learn it while Jamming (I've learned my lesson from the OLPC jam).
   
2. Clear message, not so clear implementation. We knew what we wanted to get across to the player early, but not how to do it, and trying to discuss it mid jam was hard. Another twenty minutes talking about implementation would have helped, though during our initial discussion I was itching to get things running. What we really should have done is a "stand up" style meeting when everyone arrived in the morning to discuss where we were, and where we wanted to be each day. I think it would have helped a lot.
   
3. Not enough testing / balancing. We should have pulled in more people to play the game earlier, and should have gotten things for Amanda to play so he should see the results of her art changes quickly. As it was, I spent most of Saturday and Sunday balancing, but was so close to the game that I missed little problems. Having just one person play mid-day Saturday would have exposed lots of problems that could have been fixed by the deadline.
   

I'd love to know what people have to say about the game. We're rating well, and I think if we get around to fixing the bugs, it will rate even better. Thanks to everyone who organized the Game Jam for this great opportunity!

So, if you haven't noticed, this blog has been a little quiet recently.  It's not because I don't have a lot to say, but because I haven't had the time to say it.  One of those reasons for that is because I've been spending a lot of time working with the IGDA Tools SIG (which I've talked about before) to launch a new collaborative blog: The Toolsmiths!

The new blog has two other great authors, Geoff from Insomniac and Dan from Robotic Arm Software.  I'm really looking forward to the content we'll have over the next year or so, and I hope anyone interested in game tools will take some time out to read our posts.

My first post, on continous integration and build systems, will appear on Wednesday.  Hope you enjoy the new blog!

Okay, I'll admit, I'm sometimes a little hard on articles on Game Career Guide. Which is funny because I've had two articles posted there
myself. So, I thought it only fair that I point out that this article on creating a game programming portfolio is actually very good. Also, since I think most of my readership is programmers, and interestingly a good number of student programmers, I thought I'd point you to it.

I do have two very minor criticisms of the article though. First, I think a lot of really good demos can take the place of one complicated game.  Certainly I always want to see a complete game, but some of the examples he puts down are actually fairly complicated.  Asteroids or Breakout, so long as it's complete, is fine.  I'd rather see something original, but it's not necessary.  If you have a lack of good demos, though, you should go for something more complicated in your full game.

Second, I don't think he puts enough emphasis on how important providing good, clean source code is.  It doesn't have to be perfect, but even if your Breakout game works, if it's complete spaghetti code it won't earn you any points in my book.  Make sure the code you provide shows a good mind for organization and good software engineering principles. That's what I'm more interested in anyway.

Any professional game programmers have additional insight for my student readers?

So, as promised, I have some NXE first impressions. I think it's pretty important to do these "First Impressions" posts, because I think that the success of failure of an interface can really be determined by its first impressions. Once people get used to an interface, they start to forgive some of its failings, and sometimes even get used to them so much that the failure itself is considered a feature, not a failure. But I digress.

First, the positive about the NXE.

• It's way better than the old blade system. The blades were generally confusing and at some points just unusable. In addition, the blades weren't really extendible. They had limited real estate to offer advertisers. Now, while you may think that's a good thing, it really meant it was hard for you to get information about what had just been released on LIVE, especially if you're not as "plugged in" to the game industry as I'm sure many of my readers are. Despite other failings, the spotlight system actually allows Microsoft (and its advertisers) the opportunity to really get the word out.
  
• Avatars are a nice addition. Make as many jokes about Miis and Microsoft appealing to the "Casual Market" as you want. The only people that I know that haven't made an awesome avatar already are casual gamers. Seriously. Avatars are a nice addition, and a great way for you to personalize your experience on the Xbox. The Xbox has always (at least partially) been about personalization, so having avatars is nice.
  
• New Features. Netflix, Community Games, Party, Avatar integration into games, all excellent additions. Maybe more down the road? Who knows, but I'm happy for now.
  

Now, the negative.

• Sign In is still 3 clicks away. Signing in is normally the first step for most people that have an Xbox that are online. Sure, whatever game you play will immediately ask you to sign in, but if the box has more than one profile, isn't set to sign in automatically, and goes to the dashboard instead of directly into the game (which is a setting), I think there's a 99.9% chance that the person wants to sign in before doing anything else. And honestly, one button to cancel sign in, rather than 3 to confirm (or 4, depending on if you disabled the welcome profile) makes more sense to me.
  
• Spotlight is Occasionally Confusing. I'm a smart guy. I couldn't find the community games library on my first try. And I'm not the only one. Worse, even after I found it, I couldn't find it again. The problem is this: the spotlight for Community Games looks like it's the community games section, but it's not. This carries actually throughout the spotlight interface. The spotlight is an advertisement that explains that something is available, but doesn't take you there. In only a few cases, can you get what you want directly from the spotlight.
  
• Game Marketplace Spotlight is Always Confusing. This is where I wish I had a screenshot or a video. See, when you go into the main "Game Marketplace" portion of the NXE, it brings up its own spotlight. You have to hit a separate button to go into the actual games marketplace. It's weird! Maybe I'll do a post on this in the future and expose this as confusing with a video or something. Not sure how I'll do that, but I want to.
  
• Organization is still an issue. On the marketplace it's still very difficult to find what you want. I'm not sure why this is, as it's 100 times better than it was in the blades, but I can't tell you how many times I still get confused as to where I am, what I'm looking for, and what's available. I wish I could explain better, but really I can't.
  
• Hidden Options, Hidden Friends. On the NXE, you can't see all the options available to you. One or two are dimmed out at the top of the screen. I know why Microsoft did this. First was to prevent too much clutter, which is fine. Second, though this is speculation, I'm sure that list is partially populated by the LIVE servers, so they could now add categories without breaking the current functionality. But, the new friends channel I don't understand. Why take up all of the screen real estate with one friend at a time? Most of which is taken up with a background that the friend can't change anyway? Why can't you show me 4 or 5 avatars at a time, that way I can see most of who's on line at once without scrolling through the channel? Sure, I can still use the blade interface but, let's face it, the channel is way cooler, just not as usable.
  
• Breadcrumbs? For some reason, I always find myself wanting breadcrumbs in the NXE. I'd like to know where I came from to get to where I am, and where I'm going back to when I hit B. Personal preference.
  
• Reports of NXE instability. This is really disconcerting. There have been reports that not only does the NXE crash in the interface itself, but that it causes once stable games to crash more frequently. I didn't believe this until I actually saw some stable games crash on a friend's Xbox. Hopefully this isn't too widespread?
  

Again, the NXE is 100 times better than the blades. There are just a few places where I feel confused by the interface itself, and that's never a good thing. Thankfully, once I get used to it, I'll probably forgive it of its flaws, and maybe even come to depend on them.