Some interesting observations:

• I made zero income in my first two years as as independent developer! I was supplementing my income writing a column for Game Developer Magazine, teaching classes, and doing some contracting. I even started interviewing thinking I would have to give up the indie life and go back to work for a company. I always tell new game developers to be ready not to make any money for a while for this reason.
• Flower Garden seems to have a reasonable tail in spite of minimal updates. Every so often I feel a bit guilty for not doing more with it, but even if I wanted to spend time on it, I can’t think of anything that would increase sales.
• Subterfuge is a blip in the radar. But what’s even worse, Subterfuge took 3.5 years to make, whereas Flower Garden was around 2 years (including all updates).
• The US tax system isn’t really set up for people with really spikey income like this.
• I need to make games more quickly.

Here’s to releasing a game in 2017 that is visible on that chart!

Instead, I’m going to try something a bit different. I want to highlight the games that have had the most influence on me as a game maker. Not the best games, not the most memorable games, not the most impressive games, but the ones that have directly influenced me and the games I’ve made.

It was actually really hard coming up with this list. I initially had games that I absolutely love as a player and I spent many hours playing them. When I started fleshing things out, I realized they didn’t directly influence me as a designer, so I ended up cutting them, even though it was really hard to do that (anyone who knows me will wonder why Fallout or Master of Orion are missing from this list).

Sorcery (1985)

This game single-handedly set me in the course of making games. I saw Sorcery at a friend’s house, and I knew I had to make my own games, even before I owned a computer. I was blown away with everything about it: The sense of exploration and adventure, the atmosphere, the graphics, and the gameplay. I even dared replay this game recently and it mostly stands the test of time (although the tunnels over water are as frustrating as always).

The Hobbit (1982)

This is the oldest game in the list, but I actually didn’t discover until later. The Hobbit, along with other text adventures, changed my preconceptions of what games could do. I felt I was free to walk around and interact with the world in any way I wanted in a way that graphic adventure games wouldn’t let me.

I also learned the power of text in games, and how some good paragraphs of text can be much more evocative than graphics.

All of this led to the first serious game I completed: La máquina del tiempo (which was an adaptation of H.G. Well’s The Time Machine).

Macadam Bumper (1985)

This was the first game I played that allowed me to create my own levels (I suppose that in another world I should have played the earlier Pinball Construction Set). For a budding game creator, this was a dream come true. I remember spending many afternoons with my cousin making our own version of a pinball table at the local arcade. I didn’t play it much beyond that, but the seed of games with built-in level creation had been planted.

Casey’s Contraptions is clearly the game I created that was most directly influenced by Macadam Bumper.

Sim City (1989)

The idea of a game being a simulation you can interact with was completely new to me, and I was instantly drawn to Sim City (even with the horrendous initial graphics). Later versions became much prettier and refined, but the basic idea remained the same. As a game designer, simulations are probably my favorite genre, and I’m planning on exploring them more in the future.

Magic: The Gathering (1994)

Another love at first sight. So many ideas from this game were new to me! Customization, card interactions, expandability… I also saw first hand how a game can grow beyond being a game that you play and “finish” to a full hobby that becomes part of your life. I’ve taken some breaks from the game over the years, but even today I’m playing it quite actively.

In spite of its flaws, I consider it one of the best and deepest games I’ve ever played.

There’s a lot I could write about Magic, but I’m going to save it for another (or multiple) posts down the line.

Braid (2008)

Braid (along with World of Goo) really showed me how an independent developer can make not just similar, but better and different games than traditional companies. This was particularly relevant to me at the time since it was around the time I had quit my full-time job to go independent and make games with a friend.

Playing through Braid and listening to Jon’s talks also opened my eyes to the idea of deliberate design. In Braid everything has a reason to be where it is. Every puzzle explores a slightly different consequence of the rules of the game (even when they’re not very player friendly). That’s an important idea I’ve tried to carry with me since then, and it definitely had an impact in Subterfuge.

Binding of Isaac (2011)

Binding of Isaac is a bit of an odd duck in this list. I’m usually not a big fan of games that rely on speed and reflexes, yet Binding of Isaac is very much a twitch game. It’s also a game that was not love at first sight. I played it for a bit and put it down. I even remember asking on Twitter what’s so good about it. Fortunately some friends convinced me to give it another try, thinking about it less as an arcade game and more as the rogue-like it really is. At that point everything clicked in and I was hooked.

It was my first and strongest experience with rogue-like games (sorry Spelunky, I tried but never really got into you). I fell in love with the idea of games that can be completed relatively quickly, but are intended to be replayed over and over as things change from play to play.

Observations

I had no idea what list I was going to come up with when I started writing this, so it’s quite interesting to see the date distribution. There are more games from the 80s in this list than any other decade. That’s to be expected since that was my first contact with games and that’s when I had the strongest influences.

What’s more interesting is that all decades since then are represented. I consider myself to be pretty jaded with respect to games (and movies and books), so it takes a lot for me to take notice of something and get excited about it. So I’m really glad to see that there are standout games recently that wow me with something new and awesome.

Another interesting point is that there are no Japanese games in this list. Most game developers I know (especially in the US), grew up with Nintendo and Sega consoles and playing lots of Japanese games there. On the other hand, I never played more than 5 minutes of a Mario, Zelda, or Castlevania game! Instead, I grew up on Jet Set Willy, Roland in Time, and Dizzy. Whether you want it or not, that definitely changes the way I see and interpret games today (it never happened, but maybe I’ll revisit the idea in the future).

At one point I was even going to use that source of uniqueness to make a game based around my love of the old games I grew up with. The idea was to present something familiar but that would be different to most people that had a different gaming background than me.

Finally, the game I’m currently working on (which I hope we can announce any day now) has very clear influences from games on this list:

• Strong game element interactions and combinations(Magic: The Gathering).
• Some simulation elements (Sim City).
• Deliberate design (Braid).
• Rogue-like structure (Binding of Isaac).

Hopefully next post I can finally talk about this super-duper secret project.

Happy new year!

2015 was the year when I started focusing on playing more often the games I loved, and stopped chasing after trying all the hot new games.

Towards the end of 2014 it dawned on me that most new board games I was playing were ranging from bad to just OK, and only a selected few made it into the good or very good category. So why was I spending so much time and energy playing new games? It’s not like I had played the old ones too much and was done with them. As a matter of fact, I was frustrated with how little I was playing them, and how, if I only play a game once every six months or a year, I’m basically starting over from scratch. So I was always playing games at a very superficial level, without being able to get deeper into them. Not to mention it’s a pleasure to pull out a game and not have to worry about reading or explaining the rules!

2015 was the year of depth for me.

Of course depth comes at the cost of breath, so when it comes time to make a best-of list for 2015, I don’t have nearly as many different games to draw on as other years. Because of that, I’ll limit my list to just 3 games.

Honorable mention: Magic: The Gathering

Magic: the Gathering and I go a long way back. I’ve played Magic on and off for over 20 years and it’s irrevocably intertwined with a lot of the different stages of my life. It has also strongly influenced me as a game designer.

But why list Magic as one of the best games of this year? Because I started playing seriously it again and it’s an amazing game, in every way better than it was in 1995. Standard competitive play is constantly evolving and adapting, and booster draft is very balanced, fun, and skill-intensive. Wizards of the Coast did an amazing job with the Khans of Tarkir, Fate Reforged, Dragons of Tarkir, and Origins sets, and even though Battle for Zendikar was a big let down, I have my hopes up for Shadows Over Innistrad.

3. The Gallerist

Even though I’m moving away from complex games, one of my favorite games of 2015 was The Gallerist by Vital Lacerda. Kanban, by the same author, snuck in my top games of all time list that I created last year, and I like the Gallerist better. The theme is quite unique, the mechanics fresh and different, and you’re hardly ever locked out of a particular action, which is something I find very frustrating in games. The game feels like a giant puzzle with lots of gears where you need to figure out how to make the most money before the end.

To top it off, my wife Amy had a painting accepted in the abstract paintings category, so it’s really cool to play a game with a piece of her art in it.

2. Grand Austria Hotel

I love it when a neat theme meets good design into a very cohesive game. That’s exactly what happened in Grand Austria Hotel, and somehow, it manages to go beyond the usual resource-conversion-to-points-engine to something fairly unique and interesting. Two warnings with this game though: 1) It can be a bit brain-burning towards the end with all the bonus actions, and 2) I would avoid playing this at full player count. There’s a fair amount of downtime, and the board state would probably change too much between turns. It worked great at two players and I suspect it would be good with three as well.

1. Pandemic Legacy

(Spoiler free) And the #1 game for 2015 is… Pandemic Legacy! But… this is not the glowing review you may be expecting of the game that rocketed up the BGG rankings and was the first game to displace the Twilight Struggle from the top spot in many years.

I love Pandemic and I love the Pandemic expansions. My wife and I play it frequently and it’s always a fun experience, teetering between success and world collapse. We can play it over and over. None of this should be a surprise since Pandemic was #6 of my all-time games list from last year.

How about Pandemic Legacy? Frankly, if I have to choose, I’ll pick regular Pandemic. Pandemic Legacy is a nice little distraction. It’s a sequence of games where the rules keep changing a bit, sometimes half way through a game. If I didn’t already know and love Pandemic, I might even find it annoying. We’re only about half way through the campaign, but I feel that nothing we do has a meaningful impact in the overall storyline. Things are going to happen independently of what you do, and you’re just going to reveal the next card in the legacy deck.

Still, is Pandemic Legacy fun? Yes, but because it’s Pandemic. It’s good enough to take the #1 spot for 2015 for me. But plain Pandemic is better and it’s the place you should start if you haven’t already.

How about you? Any interesting picks for you top board games of 2015?

This list was inspired by Casualgod’s 3rd Annual Top 20 Games of All Time. David and I have a lot of overlapping tastes, so if you like what you see here, make sure you check out his list as well.

20. Arkham Horror

I make no claims this is a good game. However, this game is an amazing experience. The cooperative aspect is very important, and it’s definitely a game that you get better the more you play.

Our first few games were way too long (3-4 hours), but once we got the rules down, now we can knock a game out in 2 hours or less.

The expansions add a lot of much-welcome variety. My favorite way of playing with them is to focus on each expansion, by just using about half the cards from the base game, and the rest from the expansion. That way each expansion shines to the maximum, with a lot of encounters being directly relevant to the theme of the game. Mixing them all just dilutes the experience and makes it a worse game than just plain base game.

19. Keyflower

The rating for Keyflower could change quite a bit (up or down) simply because I haven’t played it enough. My plays of it have been great, and I’m looking forward to playing it a lot more.

The mix of bidding on tiles and using them at the same time is brilliant. Knowing some of the winter tiles ahead of times let’s you plan more strategically for the end of game scoring. At least for the first few plays, this is probably best with 3 players, otherwise it’s too many villages to keep track of.

18. Kanban: Automotive Revolution

This is the only entry in this list for a 2014 game, and it wasn’t even part of the original list when I first put it together. However, a couple more plays quickly shot this up the ranks. I wouldn’t be surprised to see this higher up in next year’s list.

Kanban is a complex game, and on the surface like the kind of games I’ve been getting away from recently. I don’t like games that are complex for complexity sake (like Madeira), but Kanban pulls it all together and makes it work very well.

There are a lot of things going on on the board, but each department is quite simple. The complexity comes in how to put together all the actions in the most efficient way. I’m four plays into this game and still learning new games.

Also, each play is quite different given the meeting goals and end of game bonus. Variability between games is a theme that will appear over and over in this list.

17. Notre Dame

One of my favorite Feld games (Castles of Burgundy barely missed the list). It plays in about an hour, the card drafting adds a nice limitation on your actions and keeps you very interested in what your neighbors are doing.

The extra cards in the mini-expansion make the game much better since it’s more varied from game to game.

16. The Palaces of Carrara

I have to admit that my first play of this was underwhelming, but repeated plays quickly turned it around, and eventually pushed it all the way to #16.

Variability in this game is huge and no two games are alike. You have to re-evaluate everything depending on the scoring cards that come up for each game. Sometimes you build wide, sometimes you go tall, sometimes you focus on some buildings, or cities, or… The resource market is very simple and interesting, and the bits are great too.

Word of advice: Ignore the basic game. Sure, play with the basic goals once, but with the rest of the advanced rules (not moving the wheel, upgrading buildings, 8-point buildings, etc). I didn’t and I almost missed out on this gem of a game.

15. In the Year of the Dragon

This is my other Feld on the top 20, and not surprisingly, it’s from the same period as Notre Dame. It’s still pretty focused, and quite different than most other games: You see all the disasters ahead of time, it’s a matter of planning around them, maximizing scoring opportunities, and fighting everybody else who is trying to do the same thing. Deliciously tight and it plays great with 5 (and also great at lower player counts).

14. Race for the Galaxy

Yet another game that is hugely variable from play to play. Here you have some control (through Exploring) but ultimately it comes down to what you find and how you use it.

This is one of the rare games that has simultaneous action selection that I actually like, probably because other people’s choices can only benefit you, and never negate your whole turn (unless you tried to get really cute).

I haven’t even started playing with the expansions, or with any of the alternate lines. Looking forward to many more plays of this.

13. Santiago

Santiago was a total surprise. Yes, I had read very good comments from my Geekbuddies, but I really wasn’t expecting it would be that good.

Santiago embodies everything I’m looking for in games these days: - Strong player interaction (you’re competing but still need to rely on other people) - Short playtimes - Simple ruleset

The result is an amazing game that some people describe as vicious, but I choose to think as self-interested. You’re in it to win, and other players will have to make it worth your while if they want you to do something in particular. It’s great that the game can be won through smart bidding, being a hard negotiator as the Overseer, or just by saving up lots of money and being opportunistic.

12. The Great Zimbabwe

This is a very unique race game (the same way that Race for the Galaxy is a race) where you can change the ending line in exchange for some advantages. It features the kind of player interaction I like, where you’re competing with people, but at the same time using each other’s resources in a positive way.

Each game is very different depending on the map layout and which gods come out. The only downside is how suddenly the ending can arrive, and how it can be spotted a turn or two in advance and there’s nothing that can be done to stop it.

My favorite player count for this is probably 3 or 4.

11. Troyes

I never made a top-20 list last year, but I think this would have ended up much higher on last year’s edition. Unfortunately I only played it twice on 2014, so I’m not surprised it slid down a bit. Maybe next year it’ll go back up.

I love dice as inputs, coupled with dice-manipulation mechanics, and this game is all about that.

Extremely varied gameplay is again present here: Only a few cards come up in each game, that those completely determine how the game is played (along with the event cards). No two games are alike, although that sometimes can be a bad thing (I introduced a friend to this game and we ended up with punishing events and cards that didn’t combine very well with each other).

I was a bit disappointed with the expansion, so those of you looking for it, I’d say skip it and save all that money.

10. Ra

By now this list has quite a few games with bidding mechanisms (and there will be more further down). Ra is the purest of them all in that it’s only about bidding.

It’s another one of those games with a very simple ruleset that I love (with a slightly complicated end-game scoring, but it’s easy enough with the player mats).

The thing that makes Ra stand out is that the bidding is very “chunky”. You have four tiles and you can bid one of them. That’s all. Sure, it makes valuing things easier than Medici, but that’s not a bad thing.

9. Lord of the Rings: The Card Game

It’s not surprisingly that an LCG is very variable, but I’m always amazed at how completely different each scenario makes this game feel. And by that I don’t mean that one scenario is more combat heavy and another one more questing heavy. It’s that the new rules and events for each scenario change the game completely, and at the same time make it so extremely thematic. For example, in Journey Down the Anduin, at one point you get on a boat and you’re not attacked by the enemies in the engaging area, but you draw an extra card during the encounter phase (because you’re traveling so quickly).

I haven’t tried this solo yet (which I hear is brutally hard), but it’s great fun with two players. Some scenarios are extremely hard though (I’m looking at you, The Hobbit!), and most of them encourage you to tweak your decks in different ways.

8. Glen More

I love the jump-ahead mechanic in this game. There’s always a great tension between getting something before other people, and still getting the other tiles you want along the way. The end-of-game penalty for having larger towns makes it even more interesting.

The tile-laying part of the game is very interesting too, because you have some restrictions (roads and river) and only the tiles next to a tile you lay down are activated, so you need to plan very carefully.

All in all, it combines short play time, and extremely meaningful and difficult decisions. Oh and it plays great with two as well.

7. Hansa Teutonica

For the longest time I kept reading about Hansa Teutonica as the poster child of boring, dry euros, as well as having a reputation for being extremely aggressive.

I don’t mind my euros dry, but I typically don’t like them aggressive. However, it turns out this was love at first sight for me. From the first play, I enjoyed every minute of this game. I didn’t see the play as aggressive, but more of a blocking play that you get a benefit when someone moves you out of the way.

Unlike many other games in this list, this doesn’t have much (any?) variability from game to game, but because there are so many ways to approach it, it can still feel quite different.

I’m looking forward to many more plays and trying some of the expansion maps as well.

6. Pandemic

My highest-rated cooperative game. There may be some nostalgia in here, but I would pick this one above all other coops.

Cooperative games have strong random elements, and sometimes things are stacked in such a way that no matter what you do, you will fail. That’s the nature of the game. Pandemic has that problem as well, but play time is short enough that it doesn’t matter. You pick up the cards and do it again.

I love that the infection is driven by a deck of cards because you have a lot of information about what is likely to come up soon (since the discard pile is shuffled and put on top after every epidemic). That’s something that was sorely missing from Pandemic The Cure (the dice version of Pandemic).

Finally, in case things start feeling too samey, the expansions add a lot of variability (I didn’t like my first play of In The Lab, but I suspect it has a very steep learning curve).

5. Kingdom Builder

This game is the definition of variability from game to game. The rules themselves are just a couple of mechanics on how to put settlements on the board, and the scoring is mostly down to the cards that are drawn at the beginning of each game.

This was another one of those games that the first play felt a bit underwhelming. I thought the game was playing me, rather than me the game. It wasn’t until the second game that I realized it was about positioning myself to accomplish what I want to do, rather than trying to select different terrain cards. It’s also really interesting how you have very different goals early in the game (minimize terrain adjacencies so you can move to other places on the board), than you do late in the game (touch as many terrain types as possible so you can put your pieces anywhere you want).

Yes, you can get some ridiculously broken power/scoring combos, but again, games are quick. Have a laugh and play it again.

4. Homesteaders

Short, tense, and every decision is extremely meaningful. There are only 10 rounds to the whole game, and you won’t even get a building in each round. You can go hugely in debt, and yet (hopefully) everything kind of comes together at the end.

It certainly fits with me liking bidding games, but it might initially stand out as a game with very little apparent variability from game to game. Rahdo even dismissed it because it didn’t vary enough. Let me tell you something: This game is so tight, that minor changes will throw off your long-term plans in no time. I recently started a game where I had decided I was going to go for the Church and in-game points, but the way the bidding tiles came out, and the way Amy was bidding against me, I was forced to change plans and go for a resource/dudes strategy. So much for lack of variability!

It plays fantastic with any player count. The only downside is that a lot of buildings are available right from the start, so it’s a bit overwhelming for new players. Well worth a small time investment to learn this fantastic game though.

3. Age of Steam

I’ve tried a lot of train/route-building games, and Age of Steam comes out clearly on top (I need to play more Steam to decide between the two though).`

The auctions for player order/bonus are extremely interesting an unforgiving. The roles themselves are very well thought out so even if you don’t get first place, you can still snatch first build or first move.

The route building and delivery aspect are always very fun and satisfying, the only downside is the randomness of where new goods appear on the board (yes, you see where they’ll appear, but you don’t know when, which makes all the difference in the world). Players can also find themselves in a downward spiral that takes them out of the game completely, but that’s part of the experience of the game (although I agree that a 2-3 hour game where you’re out of contention for half of it is not very fun, experience or no experience, so don’t let that happen).

Finally, the variety of maps for Age of Steam out there make this game infinitely replayable. It’s not jut a different distribution of mountains and rivers, it’s that most maps radically change a few rules and transform the experience into something completely different.

2. Dominion

Speaking of variability, here’s Donald X’s other hugely variable game. Dominion was the first deck builder. I’ve played a bunch since then, and I keep coming back to this one: it plays quickly, works great with any player count (but best with just 2 or 3), and it’s always completely different.

Just like Troyes, some games are going to be more amazing than others depending on the combinations that come up, but it’s always really fun looking at that new set of cards and figuring out a path to victory.

1. Brass and Age of Industry

I’m giving my #1 game of all time award to both Age of Industry and Brass. It might feel like I’m cheating, but I really consider Brass as a particular Age of Industry map with some funky rules thrown in. The fact is, both games feel very similar (with card drawing being the main difference).

I might give Brass the edge as a best game, but Age of Industry wins because of the different maps available and the different experiences it provides. I go back and forth between which one I like better, but I have them both rated as 10 (my only two 10 ratings on BGG).

They have the exact kind of player interaction that I love, where players are jockeying for position, using each other resources, and yet trying to out-do each other. I love that player order is determined by how much you spend in a turn, which gives you very interesting control over your turn.

I also consider Brass to be game that can be best played online: each turn is fairly long and meaty, and there are at most 16 turns in a 4-player game (most likely you’ll have a couple of them back to back, so more like 14). As opposed to games that are 100+ turns long, and in each turn you’re just clicking OK to something. I’m always up for a game of Brass online, so if anyone is interested, let me know me and let’s play.

This list first appeared on BGG

I try to log every board game play, so I can see that I logged 674 different plays during the course of the year, and 246 of those were games new to me. I didn’t invent a time-expanding machine, so the time for that has come straight from TV, movies, and video games. After realizing that we were spending just about every evening playing board games, my wife an I cancelled our Netflix subscription and never looked back. I also only played a handful of PC and iOS games during the whole year.

Another good portion of those games were due to going to local game days, and to two board game conventions: Origins and BGGCon.

Having played that many games, I figured it would be interesting to write a best-of list for the year. For this one, I wanted to focus exclusive on games that came out on 2013. I played 43 games that came out on 2013, and of those, these are my favorites.

5. Nations

I absolutely love Civilization and Civ-like games. Unfortunately, for the most part, those work best on a computer due to the long play time, and the large amount of parts, pieces, and interconnecting systems. I’ve tried playing some board game versions (Through the Ages, Clash of Cultures) and while they weren’t bad, I would probably rather play the computer version of Civilization.

Nations is finally the first civilization board game that works really well for me. It has a reasonable play time (under 2 hours for 4 players), interesting player interaction without direct conflict, and a great power curve. One of the key things design aspects that allows this game to work so well is that they did away with the map (just like Through the Ages), so players can focus exclusively on advancing their civilization rather than exploring the map.

4. Bora Bora

It’s no secret that I like a lot of Stefan Feld games. I particularly like some of his earlier games (In The Year of the Dragon, Notre Dame), but I also like some of his recent ones (Castles of Burgundy). Some critics dismiss a lot of his designs as “point salads”, but I do like my veggies! Seriously, there are badly done point salads, where the things you do have little significance beyond getting you some points (Trajan fell in that category for me), and well-done points salads like Bora Bora, where you’re showered with points, but you’re also opening up new paths and possibilities with each new action. Bora Bora hits all the right buttons for me: interweaving of effects on the board, different strategies, and the sense of building something. It’s a tad long with 4 players, but it plays great with 2 or 3.

3. Spyrium

While Bora Bora is a game that hits you with its colorful game board, fancy player boards, and loads of chits, Spyrium stands in stark contrast and it manages to do with very few components: A deck of cards, a few tokens, and a minimal (almost unnecessary) central board. Spyrium is a amazing piece of design because it manages to have a very rich and deep gameplay with minimalistic components.

In spite of having so few components, Spyrium has a huge amount of variability between games. Apart from the variations from the actions other players take, there’s the order in which cards will come up, the order of events for each round, and even the tokens that go on the cards themselves (which is an extra layer of variability for those cards since it changes their cost or effect).

The key mechanic of adding or removing workers for money or the card is very innovative and fresh. It’s also a game that plays well, but very differently, at different player counts. So playing with 4 people after learning the game with 2 will cause you to re-learn everything you thought you knew about it.

2. Prosperity

Prosperity was co-designed by Reiner Knizia and Sebastian Bleasdale. While Dr. Knizia is the big name there, I’m a particular fan of Bleasdale’s earlier design, Keyflower. In spite of that, I was afraid this game was going to be a too-abstract tile-laying game not to my tastes.

Boy was I wrong! Prosperity was my surprise game of the show at BGG Con (and I played a lot of games at the con). It hits the perfect level of abstractness that you feel you’re in charge of a city, but without degenerating in a sea of details that bog the game down. It manages to hit that magical middle-weight game category, that packs a lot of very interesting decisions in a playing time of an hour or less.

1. Bruxelles 1893

Unlike other simpler games, Bruxelles 1893 presents the player with a myriad of choices. It falls a bit in the camp of a Feldian point-salad game, but where each action and choice is very interconnected to the rest of the actions and the state in the board. You want to do action A, but if you do action B before, then A will be a lot more efficient. But of course, if you do C, then B will be even more powerful. Those kind of tough choices elevate this game to the top of my 2014 games.

Bruxelles 1893 is by new designer Etienne Espreman, but with some involvement by Sébastien Dujardin, who designed my favorite board game, Troyes.

Maybe even more interesting than looking at the list itself, is to look at what those games have in common. I have fairly varied tastes in games, but all the games in this list have some strong common elements:

• Tough, interesting choices
• Themes that appeal to me (no generic fantasy or zombies)
• They play well with 2 players
• Some player interaction, but no direct player confrontation and screwage
• Play times under 2 hours

Some of my other favorite games for this year that didn’t quite make it in the top 5 were:

• Freedom: The Underground Railroad: A cooperative game (a weakness of mine) with a very strong history theme.
• Nauticus: By wonder duo Michael Kiesling and Wolfgang Kramer. I wasn’t impressed with their other 2013 release, Coal Baron, but Nauticus is a perfect middle-weight game with possibilities for clever play.
• Coup: Technically this is a 2012 release, but it became much more widely available in 2013. It’s an amazing, quick, social game of bluffing and deduction. . The love child of Resistance and Love Letter.
• La Boca: A unique spacial game that forces players to collaborate to build something they can only see from their side. You really have to experience to understand it.
• CV: A quirky dice-rolling game with delightful art where you build the life of your character. It’s mostly luck-driven, but it ends up with very memorable stories.

I didn’t play every board game released on 2013 (or even close), so take my list with a grain of salt. As a reference, these are the other games I played that didn’t make the cut: Amerigo, Bang! The Dice Game, Blueprints, Bremerhaven, Bruges, Canterbury, Caverna: The Cave Farmers, Cinque Terre, Coal Baron, Concordia, Cornish Smuggler, Francis Drake, Island Fortress, Legacy: The Testament of Duke de Crecy, Letnisko, Lewis & Clark, The Lord of the Rings Dice Building Game, The Lost Dutchman, Lost Legends, Mount Everest, Náufragos, NOIR: Deductive Mystery Game, Plunder, Quantum, Quarantine, Rialto, Rococo, Russian Railroads, Shadows over the Empire, Stone & Relic, Sushi Go!, Time ’n’ Space, Via Appia, Viticulture.

I’ve always loved board games, but being an only child, it was always challenging to find people to play with. My dad was often willing to play, and I would often pull out some of my favorites when friends came over. But it never felt like I could get enough.

It was no big surprise then, that as soon as I saw games on a computer I fell in love heads over heels. My first thought was “Wow! I can play games with the computer without having to depend on other people being here”. Imagine that! It didn’t matter that the games were uniformly horrible, hardly responsive, chunky, and monochrome. It was nirvana for me.

My second thought after seeing a video game was “I want to make those!” And that’s what I’ve been doing pretty much constantly since that day almost 30 years ago.

During that time board games took a back seat. My love was still there, but I was too busy with video games to consider them as serious entertainment. At times I’m sure I even thought that video games were a step up from board games; the next logical step in evolution.

That phase of my life lasted until grad school. That’s when a good friend of mine introduced me to this new little game that had just come out a couple of years before called Magic The Gathering. You’d think that grad school wouldn’t be the best time to get hooked on a game like that, and you’d be right. It was an amazing ride for several years (from Fallen Empires until Exodus for those of you keeping track). I realized how much I loved the physical and social aspect of board and card games, and how it was mostly missing from video games. At the time I was playing a lot of Warcraft and Quake 1 online, but the experience was nothing like playing Magic across the table from another person.

After my Magic phase, I tried some of the flourishing “euro” games that were just coming out at the time, but I was mostly absorbed back in video games again. Steam and iOS were taking up all my gaming time for a few years.

Then, last year, everything changed. Miguel came to visit with a car trunk full of board games. Literally! Not only did I have an absolute blast playing board games all week, but so did Amy, my wife. We were instantly hooked. Now all my gaming time is dedicated to board games, and I have hardly touched some kind of video game in the last year.

Why I Love Board Games

My love of board games comes from many different reasons.

Physical aspect. I love the convenience of digital distribution of books, music, and video games. But at the same time, I’m tired of manipulating pixels on the screen for all my activities (both work and entrainment). Touch screens are a small step in the right direction, but they still feel very artificial. When it comes down to it, nothing beats the feel of some wood pieces as you move them around the table. There are already too many screens and digital bits in my life.

Social aspect. Video games are mostly solitary experiences. Even multiplayer games, you’re usually not facing the people you play with, unless it’s with one of my favorite patterns: local multiplayer games, which are not extremely popular (and it’s hard to have the right people to play with around). On the other hand, most board games are inherently social. Not only I get to spend lots of extra time with my wife and friends, but I also get to meet lots of new people at conventions and game days.

Variety of experiences. I didn’t quite realize what a huge variety of experiences board games offer. Just a few games off the top of my head that offer a huge range of different experiences: Pandemic, Castles of Burgundy, Escape, Puerto Rico, Mr. Jack, Arkham Horror, or Dixit. And that’s only games in my collection, which is limited to my own tastes and doesn’t include war games or much Ameritrash. Video games probably offer an even wider range of experiences because a computer can be so versatile, but the board game landscape feels more varied and healthy. That might be due to video games being mass market, while board games are still trying to get there. I suspect that’s a topic for a future post.

Learning new games. I love learning new games. You could even say I’m addicted to it. I love to see how things fit together, how the game plays out, and trying to figure out a good strategy. Generally, I’m much happier playing 20 new games 5 times than playing a single game 100 times. With video games, since the game is the running the simulation, not me, there’s a lot less to learn. There’s also something about tutorials that are an absolute chore and I dread learning a game through them.

Replaying games. At the same time, I love replaying games I already know how to play. This is something that often doesn’t happen with video games. A lot of them are intended to make more progress every time you play, culminating in some climax at the end, after 10-20 hours of play. After that, you can play it again, but I usually move on to some other game. One recent notable exception is one of my all-time favorite games: The Binding of Isaac, which forces you to replay it over and over.

They’re for me. I feel I’m squarely in the target audience for a good portion of board games being released. I’m eagerly anticipating releases later on this year, and I can’t wait to read about the new Essen announcements. Most video games, on the other hand, with a few notable exceptions, leave me completely cold appealing mostly to adolescent power fantasies. A quick glance at the top sellers on the App Store or even most console titles, and it’s clear that I don’t belong there.

Fun New World

I love the experience of taking a field I didn’t know much about, and diving right in. I’ve been fully immersing myself in the world of board games. Every day I play one or more board games, and I go to a full-day gaming events once or twice a month. Sometimes it feels like drinking from the proverbial firehose. I’m constantly learning about new gameplay mechanics, the art of finely balancing a game, game evolution and trends, or even the works of specific designers and how they changed over time.

During a period like this, I tend to grow creatively a huge amount. Being exposed to something new causes all sorts of new associations result in a constant stream of new ideas. Some of them are related directly to board games, but a lot of them spill over into video games and even other parts of my life.

So what’s next for me? I’m not giving up making video games any time soon, don’t worry. I love making games in any format, and my goal is to continue making a living making games for different platforms. Board games are like another platform, but one with some strong challenges and constraints.

Of the video games I’m working on, one of them has very heavy board game influences in its design. I have no doubt that it would be completely different had I not rediscovered board games recently. We’re hoping to announce the game and talk more about it soon.

In addition to that, I’m, of course, dabbling on the side with board game ideas. Unfortunately there’s virtually no money in physical board games, so it’s just purely a hobby, but it’s a really fun one. And who knows, I might be able to make a digital version of one of those board games if I end up with a good design.

In the meanwhile, I expect to write quite a bit here about board games, and especially of the cross over between board and video games and what we can learn from each of them to make better games. You can also find me regularly on BGG.

However, the question I was asked over and over was why am I making games? What are my answers to that question? As I said before, there are no right or wrong answers. Everybody needs to find their own answers, so in that respect, my answers don’t really matter.

On the other hand, since what I write here is purely personal, and a lot of people are curious about it, I figured I would give it a shot and answers those questions publicly.

Another thing I also want to stress is that these are not even permanent answers for me. These are my answers for the projects I’m working on right now. Whenever it’s time to start a new project, I will ask myself this question again and probably come up with different answers. That, I think, it’s key to be able to focus on some aspects at the expense of others, instead of always compromising and trying to achieve a bit of everything.

Why I Am Not Making Games

You thought I was going to get right away to the reasons why I was making games? No, it’s not that easy. I need to start with the reasons I thought I was making games, but turns out I discarded (for this time around).

Innovation/awards

I’ve always felt an urge to innovate and create something original. Something that would be worthy of getting some awards and recognition. Even back in the Power of Two Games days, Charles and I (half) joked that if we won an IGF award, we would eat a whole cheesecake from E Street. Unfortunately (or fortunately, depending from your point of view), that never happened, and the cheesecake remained safe behind the glass. Flower Garden was pretty innovative (even to this day, there aren’t many similar games–if you can even call it a game). Casey’s Contraptions had some original aspects, but its main strength was in polish of execution.

For this time around, I decided that this was not going to be one of the main reasons behind me making games though. I’m sure I’ll come back to this one very soon though.

Money

It’s hard not to think about money when one of your main target platforms is iOS. I know they’re mostly the exception, but looking at the huge financial success of some indie developers, or the revenue of some of the games on the Top Grossing chart, it’s only natural to want a slice of that pie.

Since free-to-play is one of the most profitable approaches on the App Store, I originally started out some of my designs by trying to do “free-to-play done right”. I was going to show the world how you can make a free-to-play game, treat players as human beings, not play any psychological tricks, not make the game suck on purpose, and still make a boatload of money.

Along the way, two things happened:

1. It’s a lot harder to design a game that does all those things than to write it out in a neat, little sentence like I just did.
2. Chris called me on it. He asked the really pointed question of “if you don’t need the money, why focus your design around that idea when there are so many interesting design aspects out there to explore?” He was totally right! At this moment, I don’t have the financial pressure to ship a game, so why limit my game artificially like this?

Those two things, combined with the fact that I hate most games in the Top Grossing chart of the App Store, means that I should not even try making a game aimed at that audience.

Since money eventually runs out, I will have to consider money more seriously in future projects. Even so, I will probably go the route of making more personal, niche games that appeal to a small percentage of people, rather than try to go after a pure mass-market approach.

Expressing something

I fall in the camp of people who believe that games are (or can be) art. That’s especially true of indie games, which carry the strong creative touch of an individual or a small team. Starting from something you want to express. For this one time, I was going to put that aside and focus on other aspects.

Why I Am Making Games

After removing all those reasons (and lots more that I didn’t talk about), why am I making games? Or rather, why am I making the games I’m currently making? It turns out, the reasons for these game are mostly selfish.

Enjoy the development

I wanted to make a game where I would enjoy the actual development as much as possible. This is a lot more constrictive than it may seem at first glance, and it means many things:

• I wanted to avoid games with large components that are uninteresting to design and implement (in-game stores, credits, managing users, etc).
• I need to be exploring new concepts (to me) and trying new things to really enjoy the development process, so the game needs to be substantially different from other games that I made in the past: no growing virtual plants, or creating physics puzzles to share with friends.
• The focus of the game should be on the design itself, not some technology. Even though most of my past experience comes from programming, I’m only interested in design these days. Programming is just a means to quickly convert my ideas into something the computer can do, but I’m not interested in programming for the sake of programming (as anyone who looks at my code can attest to).

Create something I’ll be proud of afterwards

This is an easy one. It doesn’t matter how much money the game makes, but I wanted it to be something I can be proud of afterwards. Interestingly, the “innovation/awards” point is a subset of this reason, but this point is more general, and I can be proud of the games I make for many reasons.

You would think that this point should go without saying, and nobody should be making games they’re not proud of. Unfortunately, just a glance at the App Store will quickly convince anyone that’s not the case.

One more thing…

Indie game development can be a pretty solitaire affair, but that’s not something that bothered me too much (maybe growing up an only child had something to do with that). I never needed someone else to keep me motivated in or committed to a project.

I am currently working on not one, but two different projects at once. Soon I’ll be able to start talking about them in detail. Both of those projects are collaborations with other people. After working on them for a few months, I have come to realize that working with the right people can be really invigorating: Bouncing ideas back and forth and see them grow into something bigger than they started, or just pushing and motivating each other has become completely invaluable for me. I’m hoping to be able to continue working and collaborating with amazing people in my future projects.

Why are you making games? No, I don’t mean “why are you making games?”. Also, I don’t mean “why are you making games?”. And I certainly don’t mean “why (on earth) are you making games?”. I mean the question in the purest, most abstract sense. Just “why are you making games?”.

This was a key question for me last year, I spent a lot of time thinking about it, and I thought other people might benefit from asking themselves the same question. To see where I’m coming from, let’s do a quick flash back.

It’s late 2011. Miguel and I finished working on Casey’s Contraptions and my daughter was born. I took a couple months completely off from work (new dads will understand why), and then, right at the turn of the new year, I decided to start working again. The plan was to prototype a few of the juiciest ideas, pick one that really stood out, and make a new game in a few months. How hard could it be, right?

Right?

It turns out it was a lot harder than I ever imagined. I was confident in my list of hundreds of game ideas that I had been adding to over the years. I picked one idea, made a quick prototype in a day or two, and decided that I wasn’t as excited about that idea as I thought. So I picked another one, and another prototype that didn’t go anywhere. Then another, then another, and then another. This went on for months.

By the time I realized that my prototype icons weren’t fitting in a single page on my development iPad, I started worrying that something was wrong. Prototyping is great, it allows you to find the truly great ideas and all of that, but I wasn’t any closer to a game idea I wanted to make than when I started.

At this point, I even started prototyping game ideas I knew I was not going to make, just to remove any pressure on me, as well as to get it out of my system how much I hated those game genres. It was an interesting effort, but, as you can imagine, it didn’t lead to any shipped games.

I did, however, help me start figuring out what was going on. I realized that the prototypes I was creating were dissatisfying because my intentions were unclear. I wanted too many conflicting things out of this next game, and that was pulling the game in all kinds of opposite directions.

I wanted to make a unique a different game, yet at the same time I wanted it to reach a huge audience. I wanted to ride the wave of financially successful iOS games, but I didn’t want to sell my soul with freemium-based games, and instead, I was going to make a “good” freemium game. I wanted to make something innovative, but I wanted to do it in just 6-9 months. I wanted it all, and I wanted it yesterday. Bad combination.

That’s when I sat down and asked myself point blank “why am I making games?”. Or at least the more concrete version “why am I making my next game?”. That’s a surprisingly hard question to answer really honestly. I had to peel away a bunch of layers until I found the answers to my question.

My specific answers don’t matter because there isn’t a right and wrong answer. Any answer is good as long as it’s honest, from the bottom of your heart. There are as many valid answers as game developers out there. Some people make games because they want to be famous, others because they want to make money, others because it’s the only thing they know how to do, others because they want to win awards, others because they want to reach as many people as possible, others because they want to tell stories, etc, etc.

It’s actually amazing it took me this long to ask and confront this question. When you’re working on a game company things are different, and you don’t need to do that level of introspection. But once you go indie, it becomes really important. Even though I’ve now been indie for 6 years, I’ve been going in automatic pilot all this time, kind of skirting around this issue and winging it. I see a lot of indie developers out there doing the same thing, with greater or lesser success, but still conflicted internally about what they’re doing.

Once you have the answer to your question, you can use it to guide you in any big decisions related to game development, and even in life in general. Which projects to tackle, or even what features to add to your game, will often be easy to decide if you keep your goals in mind.

For me, within two weeks of answering the question, I had settled on not just one, but two different projects that I was super-excited about. Both projects are still moving along and I hope to start sharing information about them soon.

So I encourage anybody reading this to make some quiet time in the next few days, and pose yourself the question “why am I making games”. Once you find your answer, not only will it help you with future decisions, but it will make you more satisfied with them.

Having a separate office not only gives me the distraction- and interruption-free environment I need, but also gives me some much-needed separation between home and work. My office is about a mile away from home, so that makes for a very nice 15-minute walking commute (with the Macbook Pro in my backpack). It’s also located right in the Carlsbad village, so it’s a block or two away from tons of cool places to have lunch, grab a coffee, or even go to the beach for a quick break!

Here are a few pictures from the new office. Things aren’t completely set up yet (that bare wall is waiting for some Flower Garden and Casey’s Contraptions posters that should be arriving today).

The thing I like the most about this office is the light. It’s a corner office and it’s aiming north, so that means great, indirect light all day long. Oh, and the windows can be opened to let some fresh air in. That might seem like an odd detail to mention to some of you, but you’d be surprised how many office buildings in the US have windows that can’t be opened. Really.

Both desks are adjustable, standing desks. The main desk in the pictures is the large frame GeekDesk one. I used to have the small frame because I didn’t have the room at home, but I love the extra space, especially with the 30" display! I’ve kept the small desk to the side, that way I can invite other people to come work from here for the day (indie work day!) or even (gasp) hire someone if the right time comes.

The rest is pretty standard: whiteboard (I prefer use one much larger, but that’s what I had around), bouncy ball (gotta have a bouncy ball!), and couch (pretty important to unwind, or just to take a break from standing all day).

So far, I’m very happy with this setup. Working from here is definitely invigorating, and the separation between work and home helps a lot in both locations. Maybe once our daughter is older and going to school I’ll consider working from home again, but this is perfect for now.

What does your work setup look like? Post some pictures and let me know. I love seeing other devs work setups.

To put all the whining and complaining that’s about to come in perspective, I want to build some character references first. I’ve been programming for 27 years, 13 of those professionally in the games industry, although the non-professional years I probably did just as much coding. I have used everything from emacs + make files to the gamut in IDEs: Turbo C++, Visual Studio, KDevelop, and Xcode 3 among others.

Contrary to popular belief, I’m not that picky when it comes to a development environment. Or at least, it doesn’t feel that way to me. I want the basics, that’s all. Doesn’t everybody want this?

• Have 2-3 source code windows opened side by side.
• Build and see the output.
• Do everything with keyboard shortcuts.

There are lots of other things I want (project configuration, debugging, run tests), but those are the ones I’m doing 99% of the time. I never had a problem doing any of those things with past development environments.

The hit list

Having more tools and options is great. I love having the option to do advanced operations on my code, but I want to decide when to use those tools, not being bombarded by them. That, in a single sentence, is why Xcode 4, out of the box, is completely unusable for me.

Attempting to do something as simple as type code and build it is extremely frustrating. Xcode will react to me doing that by flashing all sorts of stuff on screen, bring up sidebars with messages, change which source files are displayed, draw squiggles all over my code, and flash alerts overlays. All of that, while not showing me the build output.

Working on Xcode is an extremely noisy (visually) and distracting experience. I understand it’s trying help me, but it’s failing miserably at it. I’m trying to concentrate on what the code does, and I feel I have a parrot yelling stuff from my shoulder and flapping in front of the screen in some misguided attempt to help me code better.

That might work for some people, but not for me. I’m the guy who turns off “spell check as I type” everywhere because I don’t want to be taken out of flow while I’m typing (I’ll do a spell checking pass later on, thank you). I don’t have notifications on my mail or Twitter; I check them explicitly when I want to. Now take that kind of annoyances and multiply it times 10 and you start getting an idea of what working on Xcode 4 is like. Xcode 4 feels like it’s squarely designed for the texting/ADD generation.

Fortunately, most of it can be remedied and turned into a half-way sane environment.

Here’s how to tame the noise in Xcode 4:

• Autocomplete is one of the worst offenders. Turn it off! Good autocomplete is awesome, but I’d rather ask for it (with a keystroke) than have it bombard me constantly. Not just that, but it’s so badly implemented that it will a) put shadows on top of the text I’m typing b) replace the text I’m typing on the fly so I can’t even see what I typed (see screenshot below). Off with it!

• Having the whole screen flash with squiggles on and off while I’m typing isn’t helping in any way. Xcode is trying to “highlight instances of selected symbol”, which is a really useful tool, but not while I’m typing/thinking! Not just that, but half the time it will add extra squiggles to the screen to make sure I can’t even read the symbols themselves. So off with that one too.

  

  Here’s one very frustrating thing: When I turn off the option to automatically highlight instances of the selected symbol from the settings, I lose the ability to do that at all. Yes, you heard that right: I can’t (as far as I can tell) press a key and have the IDE highlight all the instances on demand. No sir, that’s not the way it was intended.

• Continuing with the theme of noise and distractions, having a sidebar popup and start showing me errors with my code as I’m typing is also definitely NOT helping. Fortunately we can turn off “Show live issues” in the general settings.

• One thing that Xcode 4 appeared to have gotten right is the idea of showing multiple source files at the same time. Now many IDEs do that by default these days, so that was a plus. Unfortunately, it’s part of the “smart” assistant. As a general rule, I end up turning off anything with the word “smart” in it, and this is no exception. The assistant tries to present “relevant” files to the one I’m working on. No, no, no, no! *I* want to decide what to display and what to work on. Just get out of the way and let me do that easily. You can turn off the view to “Manual”, which helps a huge amount.

Just those changes make Xcode 4 into something that at least I can type into and not get sick at my stomach. We’re making progress.

Now I can finally build and… everything goes wrong. Xcode doesn’t show me the build output and it decides to flash a “build completed” screen overlay in case I looked away in the two seconds it took to build. Seriously? Maybe my attention was drawn into some of the flashing squiggles and I forgot it was building.

Fortunately for my sanity, it’s possible to fix both those things. The alert is easy: Go to behaviors, “Build succeeds” and turn off “Show bezel alert” (make sure it’s off for all the others while you’re there).

The other one is a bit trickier, but it’s certainly possible. Set up the “Build starts” behavior to open a named tab and go to the current log. Like this:

Now when you build your project, you’ll get to see something sane like this. It might initially be as a tab, but you can drag that out and make it into a separate window of its own so it doesn’t obscure the source code window:

You should be able to navigate through any issues found during the build with Cmd + ‘, or, if you like the fancy issue display, press Cmd + 4. Things are so much better when you initiate them on demand rather than when they’re forced on you!

Finally, a couple minor UI annoyances that are easily fixed:

• The toolbar is positively huge. I feel crammed in the high-res 15" MBP (1680 x 1050), so I can’t imagine how anyone works with something smaller. In any case, hiding the toolbar helps tremendously. As a bonus, the setting is per window, so your source code windows get the extra real estate, but the build output window keeps the toolbar so you have easy access to changing the target platform.
• Line wrap is on by default. Seriously? Off.

The suck list

If that was everything, I’d be happy. It means that even though Xcode 4 ships with retarded defaults, it can be whipped into shape into something usable. Unfortunately, there are a two major things I haven’t found a workaround for:

• Can’t build a single file. Someone at Apple, in their infinite wisdom, decided that building a single file was obsolete with the awesome new feature of “show live features”. Except that “show live features” sucks and has to be turned off. Apparently you either take it their way, or the highway, because there isn’t an alternative. As with the case of highlighting symbol instances, there isn’t a command I can use to “show live features” on demand.

  The alternative is doing a full build. Most of the time that’s fine, but whenever you’re doing one of those refactorings that breaks half the codebase, then you’re really screwed. The only way I can stay focused in a case like that is by cleaning up one file at the time, but this makes it impossible as you keep getting errors from all over the codebase. And as you fix one, the first error in the next build might be in a different file. Very annoying to say the least, especially because this was working and they removed it on purpose. I never file radar bugs (long story), but I made an exception just for this.

• Build configurations and schemes. Did you notice that when you built the project earlier there was no option to choose debug vs. release or some other configuration? That’s another one of those decisions that make you wonder if Apple uses Xcode to manage their own projects (and if they do, what kind of developers or projects they have).

  They turned something simple like project configurations that nobody ever complained about, into something byzantine worthy of some of the best efforts from Redmond. This gets the award for “most complicated feature nobody needed or wanted”. It seems now we have an extra layer of indirection. So you act on a scheme, which then decides which configuration to build and what to do. That’s why there are “Build for analysis” (debug), “Build for running” (release), “Build for testing” (WTF?), “Build for archiving” (distribution?).

  After spending some time with it, I’m still confused how I would go about running the release configuration, or how to mass-edit all the schemes at once (every target seems to get a different scheme).

  The whole schemes thing leaves me completely speechless, and that vein on the side of my forehead is pulsating just from thinking about it, so let’s just move on.

The good

After you take the time to fix Xcode 4 into something usable, and (somehow) put up with the new broken features, is there something to like?

I had to dig deep, but I found a couple of things that I like better than Xcode 3:

• Much better project settings UI: Multiple panes, showing multiple values for different configurations, etc. Way better than Xcode 3.
• Better semantic analysis. During the build process, Xcode 4 was able to correctly flag some problems in my code that Xcode 3 never warned me about. Mostly to do with constness of parent-scope variable when using blocks.
• Better keyboard shortcut support for opening files in different windows (assistant pressing the Option key). I never found a way to open a file in a specific window in Xcode 3 without having to use the mouse.

And that’s pretty much the whole good list that I was able to find :-|

Conclusion

Xcode has been progressively evolving from version 1 until version 3.2. I have no doubt that’s the reason for some of the quirks in the later versions. Xcode 4 seems to be a total re-design and re-implementation, and suffers from the classic second system effect. It’s change for the sake of change, most of the time scrapping useful features and not offering useful alternatives.

I’m sure I only scrapped the surface of the horrors of Xcode 4 in the day I spent with it. I didn’t look very closely at the debugger or the Interface Builder (saving those for another day). I keep hearing about developers with stability problems with Xcode, although I didn’t run into any crashes (but I hardly did any real work with it).

Overall, my recommendation is that, if you’re comfortably working on Xcode 3, stay as far as possible from Xcode 4. We’ll all be forced to move there sooner or later, but in the meanwhile you can continue being productive. Maybe by the time they discontinue Xcode 3, Xcode 4 will have improved a bit.

These are mostly quick notes to myself so I remember what to change when I upgrade my main machine, but I thought other developers hesitant to upgrade to Lion might find it useful as well.

Things that had to go

I found Snow Leopard (and Leopard before it) to be very palatable out of the box. I don’t remember any things I absolutely had to do. Lion, however, had some questionable defaults. Or at least, ones that I just can’t take.

After making these changes, Lion was quite usable:

• Turn off “natural” scroll direction. The fact that before you can run Lion for the first time it forces you to scroll that way should be a tip off that people aren’t ready for this one yet. Maybe in a few years it will make sense to have it as the default, but now it’s just against every single computer out there (including most Macs).

• Autocorrect. This is not an iPhone. It *has* a perfectly fine keyboard. Thank you.

• Setting up Spaces. Oh, excuse me, Mission Control (sigh). This is the one I was really afraid of. I absolutely rely on having about 8 spaces (2 monitors in each) open at all times and swapping with a keystroke. That’s something that I’ve been using for many years (first in Linux, then hacked onto Windows XP, and finally in Leopard/Snow Leopard). I just absolutely have to have that.

  Update: There are still a couple annoying things with the new setup. You can’t see the number of the desktop you’re currently on, like you did with earlier versions of OS X. Daniel Collin pointed me to an interesting thread on StackOverflow where people are discussing how to get access to desktop numbers. Give it a few more weeks. Also, when you restart the computer, Lion is smart enough to restore all the apps to their last state… except that they’re all opened in the first desktop, not in the one they were when the system restarted. How difficult would that have been? Here’s hoping it’s fixed in a patchupdate soon.

  The good news is that it’s possible to set up Lion that way. The bad news is that by default, it’s quite far from that. Bring up Mission Control and create by hand as many desktops as you want. Then go to System Settings | Keyboard | Keyboard Shortcuts and turn on one for each desktop. And for the love of god, please go to Mission Control settings and turn off “Automatically rearrange spaces based on most recent use”. Clearly Apple doesn’t think people want to go to a space directly, and instead prefer to browse them one at the time.

The next few changes just made my experience better, but they’re not absolutely musts:

• This might sound dumb, but Finder didn’t have a good way to easily browse my files. Instead, it has this weird “All My Files” view that jumbles together all your junk there. I have no idea who thought that was a good idea. Maybe Apple is trying to wean users from browsing around the file system. In any case, you can drag your home directory to the sidebar in Finder and that makes it much easier to browse. While you’re at it, turn off the “Hide extensions in files” dumb setting.
• Having used a Mac for several years, I’m much more sensitive to ugly UI elements. That’s why it’s so weird that, by default, Lion has the sidebar font in all programs just very slightly larger than the regular system font. Fortunately I wasn’t the only one bothered by that and it’s an easy fix.

That’s about it. Lion is not very nice and usable (i.e. looks like Snow Leopard). You have that weird “full screen” button on the top right of all windows, but that’s much better ignored (which funny that, was the feature Apple really pushed in their PR for Lion). I have no idea why anyone would want to use that other than the usual word processor that blocks out everything else. If I want to have crippled multitasking, I’ll just use the iPad.

Good things about Lion

So far, if all I’m going to do is disable new features so it looks like Snow Leopard, is there there any reason to upgrade to Lion? I surprised myself, but the answer is yes (although they’re all very, very minor).

• Resize a window in any corner and cursor feedback (finally, only 20 years late to the party).
• Perfect contact and calendar syncing with Google. I can’t tell you how much I appreciate that. I use Google as the backend for all my mail, calendar, and contacts. With Snow Leopard you could sync them, but you had to do some digging and mess around with the sync program. With Lion it works out of the box. Totally awesome. That alone makes it worth the upgrade.
• Much improved Mail UI: Better layout, better shortcuts, better conversation view, and, my favorite by far, finally an Archive command for Gmail. Archive doesn’t exactly do the same as archiving in Gmail, but it’s close enough. Finally I can have two different keyboard shortcuts: One for trashing an email and another one for archiving it.
• The jury is still out on how Lion restores the application state when you launch an app. I’ve been pleasantly surprised a couple of times, and annoyed a couple other times that I had to close a bunch of useless tabs. Maybe there’s a shortcut like Shift + Cmd + Q that quits and app without saving state? That’d be handy (OK, that one is not it :-) Oh wow, it’s Option + Cmd + Q! I love it when something makes sense like that and you can guess it. OK, so that makes this feature very cool.
• Slightly improved Safari (better download management). I really don’t see a reason to use Firefox or Chrome when you can use the preinstalled Safari. But then again, I can’t stand web UIs and I use native clients for lots of things.

Must-have apps

It’s actually quite refreshing to use the bare minimum number of extra apps beyond what comes with the OS. But there are some apps I just have to have in order to do anything. The main two are 1Password and Alfred. I can’t recommend them highly enough. They completely change how I work and make me ten times as productive (you’ve probably noticed by now that I’m not a mouse person).

After those two awesome super-apps, is the second tear of very useful ones: JustNotes, Things, and TextWrangler.

Probably Dropbox should be there somewhere, but for some reason, I still haven’t felt the need to use it heavily. I know some people put almost everything on Dropbox and can use across computers. Maybe it’s because I only have one that I haven’t felt the need for it too much. 1Password and Things both sync from the iPhone so it was really handy restoring all my data. I probably could have done the same thing with Dropbox.

Tomorrow I’ll post similar quick notes about Xcode 4. Those might not be quite as positive though.

For me this marked my fourth year as an indie developer. It’s not a huge milestone by any standard, but the fact that I’ve been going at it for this long and I’m not broke yet means it’s a sustainable business. Actually, as you know if you followed some of my numbers posts, this was the first year that income from my apps finally became (reasonably) profitable. Now, *that* is something worth celebrating!

Doing this kind of small-scale game development is exactly what I would do if I didn’t have to worry about money at all, so this is truly living the dream for me.

Goals

All is not sunshine and roses in Noel indie-land though. I accomplished some of my goals for this year, but missed others by a mile and a half:

I released a bunch of Flower Garden updates and ran a bunch of promotions that kept bringing revenue up. That went very well. Check.

Miguel and I also submitted Casey’s Contraptions to the IGF (with three hours to spare the day of the deadline). I’m very proud of that one. Even if we’re not selected as a finalist, the experience of submitting it and finally participating in the IGF was fantastic. Check.

Games shipped. Hmm…. That’s the total fail. The only new game I shipped this year was Lorax Garden, a very short project in collaboration with Oceanhouse Media, mixing their Dr. Seuss license with the flower technology I had already developed. I didn’t even manage to ship Casey’s before Christmas like I was hoping to do. I could make excuses but there’s no point. Real life happens and things go slower than planned (that topic is already brewing for a future post).

My goal for next year is to ship three new games, but always of the quality that I can be proud of. I’ll have to be very careful about design and scope to achieve that (I’m hoping that hanging out with Ian and Dave will rub off some of that genius they have for making awesome games on a crazy-short schedule).

Games From Within

I started my blog, Games From Within, exactly 7 years ago today. I guess that counts as my longest-running project. Some years it was sorely neglected with just a few posts, but this year I spent a significant amount of time on it, thanks in large part to #idevblogaday.

These were the most popular posts for this year (based on page views, which RSS readers make much harder to track):

• Making A Living (Barely) On The iPhone App Store (aka The Numbers Post)
• Data-Oriented Design (Or Why You Might Be Shooting Yourself in The Foot With OOP)
• The Const Nazi (This one is a total surprise that it made it this high up!)
• Making A Living (Comfortably) On The App Store (aka The Numbers Post #2)
• Prototyping: You’re (Probably) Doing It Wrong
• Google App Engine As Back End For iPhone Apps
• Increase Your App Ratings On The App Store
• GDC 2010: The Best of Both Worlds: Using UIKit with OpenGL

2011 should be an exciting year for me personally and for all indie game developers out there. Happy new year everybody!

New beginning

When my job position got terminated last summer, I decided I would take a break from working for big companies, and try to make a game on my own at home. I’ve been in the video game industry since the late nineties, I’ve written code for a few released PC and console AAA titles and probably as many canceled ones, and I wanted to do something different at least for a few months. Go back to the roots of game development, when one or two guys could create something in their garage or bedroom, without spending years and millions of dollars on it.

Platform choice

I’m a C# fan, I won’t deny it, I even explained why back in 2007. I also toyed with XNA each time a new version was released, and I like how straightforward it is to use. When the beta version of the tools to develop for the Windows Phone 7 (WP7 for short) became available, just at the right time for me, it seemed like the obvious choice for what I wanted to do. And developing for a brand new platform sounded exciting as well, even if it was perhaps a riskier bet than targeting well established markets. For those who don’t know much about WP7 development, I just want to highlight a few key points:

• Applications are written in Visual Studio using C#, and either XNA or Silverlight. This may come in the future, but at this point you are not allowed to mix them, and use the controls of Silverlight with the faster rendering of XNA, for example.
• In App Purchases are not supported yet.
• Programmable shaders are not available for WP7 (they obviously are for the PC and XBox360) in the current version of XNA. Instead, you have 5 predefined shaders with features that can be toggled on and off (such as fog or per pixel lighting). These shaders should cover most of the usual needs, but if you want something very specific that they don’t support, you’re out of luck (or have to fall back to multiple passes and alpha blending).
• Paid applications have a trial mode, that allows users to evaluate them before making a purchase. Unlike on XBox Live Indie Games (XBLIG), where the game just abruptly stops after 8 minutes, developers have a complete control over what they want to show in trial mode (for example, the first few levels of a game, with no time limit, or without the ability to save, etc). In theory, this means you shouldn’t have to make a free version of your game in addition to the paid one, but I’ll come back to this later.
• The certification requirement document is only 27 pages long, table of content and change history included.

The project

I wrote a few ideas on paper, but they all looked too ambitious for a first project. One thing in particular that I wanted to avoid was to require a lot of content, since I didn’t even know how I was going to find an artist yet. During a bike ride, I thought about using photos, and that’s how I decided to make a jigsaw puzzle game. Not super original, I know, there are several of those on the iPhone and iPad, but there was none on the WP7 since it wasn’t released yet :), and it looked like a good project of the right scope to keep things under control and learn the platform. For example, I had never worked with a touch screen device, and it was pretty obvious from the start that I was going to spend quite some time iterating on the user interface part of the game.  The game is called Jigsaw Guru, and you can go to http://www.fairyengine.com to see more screenshots and a video.

What went right

I actually already mentioned some of the things that went right in my opinion, but here is the full list:

• Working on a short project, without too much content to integrate, instead of picking another more ambitious and time consuming idea, was the right choice. My goal was to have Jigsaw Guru on the marketplace the day of the WP7 launch, I submitted it on 10/18 and it got approved on 10/23 (the update I submitted in December passed even faster than that), two weeks before the US launch and two days after the other territories started getting their phones. At times I still had more items on my to-do list than I would have liked, and I made a good push in the last 3 weeks to get everything wrapped up in time, but it never got too crazy.
• Knowing the tools beforehand, and using C# and XNA, definitely made me feel productive. The phone emulator was surprisingly stable in the beta, and the XNA forums were very helpful when I wasn’t sure about something. It’s also worth noting that the website used to submit bug reports allows everybody to see what other people have written, and vote on issues you think are important and should be fixed first.
• Garbage collection is the one thing that can hurt your framerate really bad when using XNA on XBox360 and WP7. But it’s not that hard to avoid: when I had a look at my memory usage late in the project, I only found two spots where I was creating some amount of garbage each frame (both related to strings). Basically what I do is each time the player goes from one screen to another, I load everything I need for the new screen, and I force a garbage collection. This gets rid of temporary objects that may have been created during the loading process, and objects from the previous screen that are not used anymore. After that, I don’t allocate anything, and the garbage collector never has to do any work.
• Finally: testing. Very few people tested my game while I was developing it, but my friend Alexis alone kept giving me more feedback than I thought I could handle. He never said anything was good just to make me happy, he reported every little detail he didn’t like, even and especially the ones I was aware of but never had time to fix (and maybe thought nobody would notice). Even if I sometimes felt he was nitpicking, this was exactly what I needed.

What went wrong

Developing for a new platform has its share of drawbacks, it’s just how it is. The final version of XNA 4.0 only came out mid-September, and before that I was working with the beta version. As mentioned before, it was pretty solid already, but there was no redistribution of the runtime. Which means you had to install all the tools to be able to just run the game, and you could only install them under Vista or Windows 7 because the phone emulator requires DirectX10, and some of my potential testers were still using Windows XP. So, even if what I was sending was a PC version of the game, they couldn’t run it on XP just because the phone emulator, which they didn’t need, requires a more recent operating system. To work around this problem, I made an XNA 3.1 PC version of Jigsaw Guru, but maintaining two versions side by side for several weeks and merging back and forth between them was not fun.

Coding for a device that wasn’t released yet also meant I could not test what I was doing on real hardware. I unsuccessfully tried to get a phone prototype, and basically the only way I found to run my game on a WP7 at the end of September was to go to a Microsoft event. Even there, I thought there would be phones locked to the tables, that developers could connect to their laptop and use for the whole day, but I was wrong: there was no such thing, and the 4-5 persons who already had a working application to test like me had to do it on the phone of the event’s organizer, when he wasn’t using it for something else. I was able to run my application twice for about 5 minutes each time, and fortunately everything seemed to be working fine, which is a testament of the reliability of the emulator.

When the game began to be really playable, with most of the screens that are in the final version, I started looking for an artist and a musician. I did it way too late, and I was lucky to find Aimee and Tim through the XNA forums, and that the time estimates they gave me just matched my own programming deadline. So, in the end everything worked out well, but even if I wanted to wait and be sure the UI elements were final before asking somebody to redo them, I believe I also waited just because I was more comfortable doing my programming tasks first, and that was a mistake.

Marketing was a difficult problem: I knew I needed to do some, but how? When Jigsaw Guru got approved, the WP7 wasn’t out yet in the US, and had just been released in a few countries of Europe and Asia, as well as Australia and New Zealand. Basically, nobody had that phone yet, and I couldn’t find any website reviewing its games. Even when I had a second look for the US launch, I only saw a couple of sites testing 2 or 3 of the official XBox Live games (that’s how they’re called even if they run on a phone), but nothing related to indie games. So, what ended up happening is I did nothing, and just hoped that because there weren’t too many applications on the marketplace yet (which is the reason for being a launch title, right?), people interested in jigsaw puzzle games would fine mine. Of course I was wrong, and the fact that the search in the Zune software didn’t seem to care about the keywords you enter when submitting your app, or couldn’t find my game when searching for ‘jigsaw’, didn’t help (this seems to be fixed now). I don’t know how other developers releasing WP7 games around the same time as me handled their marketing, but I would be curious to hear it, that question is still a mystery to me.

Downloads and sales

This could have been another paragraph in the “what went wrong” category, but I think this subject deserves its own section. Download and sale numbers for WP7 apps became available on Wednesday 12/08, and I don’t think anybody was thrilled. Don’t get me wrong: WP7 is a very young platform, there aren’t tens of millions of phones in circulation, sale expectations have to be low for now, and can certainly not be compared with those of competing platforms. No, what really surprised me is not the number of sales, but the number of downloads.

On the “top selling” tab of the Zune software (which is more likely based on downloads, like the Bing visual search), Jigsaw Guru has always been in the middle of the paid games from the puzzle & trivia category, the biggest category by far (about 45% of all games). Today for example, it’s 174th out of 363. How many downloads do you think this means on average? About 0.65 per day. This totally blows my mind, but is in line with a graph a developer made with the numbers from his 4 apps, that shows the relationship between the marketplace rank and the number of downloads.

One potential problem is it’s not obvious enough that lots of paid games support the free trial mode, and some players don’t know they can download them for free. But really, it all comes down to most players only checking the XBox Live and the free sections, and rarely visiting the paid one. Which is why although I said earlier that in theory, and thanks to the trial mode, you shouldn’t need to make a free version of your paid game, in practice it’s obvious this doesn’t work, and you have to do it. My friend Noel, who is an experienced iPhone developer, had actually told me I should release my game as a free, ad supported app; unfortunately, the ad SDK’s for XNA didn’t exist at launch and are still in their infancy, the one from Microsoft got released this month and only serves ads in the US, the other ones are either not finished or not stable yet.

So, what’s next? I’m submitting Jigsaw Guru Free (with the Microsoft ad SDK) this week, because as a developer, I still want people to play my game and hopefully have a good time with it. The two projects I started working on after Jigsaw Guru might follow the same path and be free apps from the start, whether it’s on the WP7 or another platform.

Most often, the advice stops there. So you get your initial sales spike and then sales go way down. What do you do then? Usually, developers release new features and updates. That’s great, but how do you get people to notice it. You need to establish some form of communication with your players.

Update Messages

The simplest form of communication is through the “What’s new” section in the update. You can use that section not just to list what features you added and what bugs you fixed, but also to let your players know about other things: plans for the future, other games to try, or even the URL for your Facebook group.

Credit goes to Igor for bringing up this idea and pointing out the URLs are even clickable in this field (but they aren’t in the app description).

Of course, if you’re like me and you update your apps only once in a while, this technique isn’t as effective. Right now my iPhone tells me I have 67 new updates available. I’m clearly not going to be reading through the release notes of each one.

In-Game News

A more direct way of reaching out to your players is to have some sort of in-game news system. At any point you can update a file in your web server with any news, and it is displayed in the game. It can be implemented in many different ways depending on “on your face” you want to be about it: a pop up that comes up when the user runs the game, a ticker that runs constantly across the bottom of the screen, or, what I did for Flower Garden, a news icon with a badge indicating how many unread items there are, that brings up the news page when you tap it.

Make sure players are able to click on URLs in your news messages so you can direct them to different web pages easily. More on that on a bit.

Emails

Update messages are only good for players who update their apps (ahem, ahem), and in-game news for active players who’re currently launching your apps. For maximum effect, you can send an email newsletter and that way you can also reach users who played the game at some point in the past, but aren’t currently playing it now. They’re the ones probably most interested in new updates and features, and chances are you can rekindle their interest in the game.

To do this, you should encourage users to register for your mailing list, or collect their emails with their consent in some other way. This was a technique I started using back in December of last year with great success.

I’m currently using Your Mailing List Provider as a means to delivering thousands and thousands of emails [1]. By the way, don’t miss a chance to join the Flower Garden mailing list :-)

Facebook

Similar to the mailing list approach, Facebook groups can be a very effective form of communication. An additional benefit is that friends of your players might see them participating in the page and might make them try out your game.

Case Study: Pocket Frogs Cross-Promotion

All that is fine in theory. How does it work in practice? I have been using all four forms of communication for a while, and I’m definitely seeing good bumps of sales and downloads with each update and each major communication.

Last week, Ian and Dave from Nimblebit and I, decided to set up a cross promotion between Pocket Frogs and Flower Garden.

I updated the in-game news and send out an email newsletter coinciding with the latest Flower Garden update telling the players that if they downloaded Pocket Frogs from within Flower Garden, they would be awarded 5 doses of fertilizer. Nimblebit awarded players a flower if they downloaded Flower Garden Free from within Pocket Frogs.

When you have over a million downloads in a week like Pocket Frog did, that kind of player communication is the equivalent of a nuclear cannon. The effects of the cross-promotion were obvious the instant the news went live:

As you can see, Flower Garden Free made it all the way to the number 56 in the iPhone Top Apps chart in the US! The effect even spread to the paid version of Flower Garden:

Pocket Frogs at the time was hovering at around #9 on the charts, so it was difficult to have much of an impact on that position without major numbers, but we suspect it might have hovered there a little longer because of the extra downloads from Flower Garden.

Here is what the downloads for Flower Garden Free looked like for the last month. The Pocket Frogs cross-promotion is quite noticeable:

All those downloads also translated into in-app sales through the Flower Shop. Here are the revenues for that time period:

One consequence I wasn’t expecting, but in retrospect I’m not that surprised about, is that the ratings for Flower Garden Free dropped by a whole star (from 4 to 3), with a large percentage of 1-star reviews. That’s because a lot of people who wouldn’t have downloaded Flower Garden otherwise did it anyway, didn’t like it, and deleted it right away.

To wrap things up on a better note, there was yet another side effect of the cross promotion. The Pocket Frogs link was using my LinkShare referral code. Sending all those users to the App Store to download a free game link resulted in about $200 in referral profit for the week.

Conclusion

Communicating with your players is more than just profitable: It’s crucial to the sustained success of your games. Make sure you try to engage with them in every way you can, keep them up to date with developments in your game, and don’t hesitate to run the occasional cross-promotion, especially with other games that are a good match for your target audience.

[1] If you decide to use them and wouldn’t mind using my referral code (WQHVUF), I can get a small percentage back.

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

Initially I dismissed it for me because I’m reasonably active: I either run or bike 5 or 6 days per week, and the rest of the days I go for a walk around the neighborhood. It was the combination of increased studies on the effects of sitting, some people in my social circle finally making the jump and raving about it, and me developing some problems in a hamstring that finally made me consider it more seriously. And trust me, if you’re a cyclist or a runner, the last thing you want to have is hamstring problems.

It turns out that my 5-mile morning runs weren’t making me immune to the dangers of sitting. It’s not how much exercise you get per day, but how long do you sit on a chair continuously. And no, buying an fancy, expensive chair might help with your back, but it’s not going to do one bit of good with all the other problems.

One of the many advantages of working from home is that I can try weird things that would be much more difficult in a regular workplace. I also have a track history of liking to experiment on myself [1], so it didn’t take much convincing to give this a try.

After some initial research, it appeared that the way to go was an adjustable-height desk. That way you can work standing, but you still have the flexibility to sit down whenever you need to. I also found out that apparently this is not all that uncommon in Europe. The only drawback is that adjustable standing desks are not easily available here in the US, and the ones that are out there are aimed at offices and big companies, with matching eye-popping price tags. Even though Flower Garden continues to do well, I wasn’t quite ready to plop down several thousand dollars on something I might end up hating.

So I decided to start cheap and work my way up from the bottom. First I had to decide if I even liked this whole working-while-standing thing. I wasn’t even sure I would be able to type! I thought about raising my desk with cinder blocks, but I would have to raise a lot and would make it very unstable. So instead, I created four stacks of books on top of my desk and put a board on top. Then I was able to put the keyboard, computer, and monitor on the board and give that a try.

Let me tell you: It was weird.

At first I didn’t know how to type. My fingers were constantly off to the side. It turns out my initial height was too low. You really want to have the keyboard at a height that puts a 90 degree bend on your elbows. That’s what they say about the sitting position, but somehow I can manage to have less. However, standing, I really needed that height.

Even once I adjust the height, the first day was kind of rough. After an hour, I was definitely feeling it in my feet. I think I did half a day the first day and I felt totally exhausted. All that running wasn’t helping that much standing at my desk apparently.

Fortunately things got better very quickly. In a few days, I was able to work for hours without much problem. I would find myself constantly shifting my weight between my feet and moving around a little bit. I was definitely liking that whole standing thing.

At this point I decided that the stack of books was too annoying, but I wasn’t quite ready for an expensive desk. So I picked up a Fredrik Ikea desk from Craigslist for $50. The nice thing about this desk is that it can be assembled so the top of the desk is almost at any height. You can’t change it on the fly, but at least it serves as a standing desk.

Finally I was able to work standing and be comfortable at the same time now that I had space for more than a mug along with the keyboard. The extra shelves on the desk were also very handy (one over the table top and one underneath).

After spending a couple of weeks with the desk, I decided that I definitely liked standing and it was something I wanted to continue doing long term. I felt more focused while standing, and my productivity was up. An unexpected side benefit was that when someone else comes into the room, they can walk right up to the desk and we can look at the monitor together, or look at some papers, much more easily than if it was a sitting desk.

However, it was also clear that I needed to switch things up a bit. Spending the whole day standing continued to be pretty tough on my feet, and it even made it so I didn’t want to work any longer than I had to. I really had to combine the standing with some hours of sitting down, which is probably a healthier thing to do anyway.

At this point I had two options: I could go full out and get a motorized adjustable desk, or I could get an adjustable draft chair which are tall enough to sit comfortably at a standing-height desk. Since I already had a nice office chair, and the Ikea desk was a bit wobbly set up like that, I decided to spend the money on the motorized desk.

Again, after a bunch of research, it seemed that one of the best options was to order a (very appropriately named), GeekDesk online. They have them in two sizes, Classic and Mini. It turns out I wanted something more in the middle (around 60" wide), so I ended up ordering the Mini frame and a desk top from Ikea for $80. It wasn’t cheap, but it was way cheaper than the alternatives and all the reviews and experiences I read were very positive.

It arrived very quickly and it was a breeze to assemble. I did have a scary moment that it looked like one of the wheels didn’t fit in the metal opening, but I eventually managed to coerce it. Hopefully this kind of manufacturing problems aren’t common.

I can only describe the final setup with one word: Awesome. The desk isn’t wobbly at all, and it takes just a few seconds to change heights with the push of a button. Not just that, but I can fine tune the height at any moment in tiny increments. And in the sitting position, I can put it low enough to make typing very comfortable (most desks are set up too high to type really comfortably for me).

My daily work routine has settled into working standing in the mornings, sitting for an hour or so after lunch, standing all afternoon, and then sitting in the evening I have have to do some work. With the wonderful weather here in Southern California, I’ll often take my sitting work time outside in the back patio in the shade. So all in all, I probably spend one or two hours sitting down at the desk.

Yes, it was a significant amount of money, but it’s something I’m using every day and it improves both my productivity and my health. Definitely worth it.

Standing desks have one downside though. This situation happens embarrassingly often. Good thing I work home alone!

[1] A few years ago I gave polyphasic sleep a try. It was actually really great for gaining extra hours, but eventually I gave it up because I was constantly out of sync with the rest of the world. I’d do it again if I were spending months alone in a research station in the Antarctica.

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.

I loved the sound of that! I’ve been an indie developer for a year and a half, and I’m seeing more and more people taking tha route. I think indie development is necessary for a healthy game development industry. Where else are people going to try weird ideas, experimental development techniques, an commercially unproven designs? I think it’s a sign of maturity that we’re seeing a need filled by independent development next to the Maddens and Worlds of Warcraft and other chart-toppers.

I think 2008 will go down as the year that indie games made it to the big time: Braid, Schizoid, and World of Goo are just the top of the iceberg. It showed that it was possible to become an indie developer and make a living from it. 2009 has to be the year that indie development really explodes, right? The trend is certainly there. I’m constantly hearing about people or even whole teams leaving large development houses and starting their own, small companies. These developers are not trying to become the next EA, but they want to keep things small, creative, and, above all, fun.

If the only path for indie game development were downloadable console games on XBLA and PSN, the future wouldn’t look so bright. I used to be really excited about those platforms, but the restrictive zeal of Microsoft and Sony, the dingy royalty deal on XBLA, plus the high-development costs required for most games in those platforms, makes them very difficult to develop for and make any money from them. More and more, I’m hearing of donwloadable console titles with budgets around a million dollars. A million dollars!! That’s “just” a tad bit out of my indie pocket range.

Fortunately there are other paths. We have the usual PC market, which seems to be on its way to being abandoned by the major players but leaves a void for indies. Some guys seem to be doing well there, especially if you consider the Mac and Linux markets in addition to Windows.

Then there’s Nintendo’s WiiWare, which seems surprisingly much more open than the Xbox360 or PS3. I don’t have any friends who are personally developing for WiiWare, but I hear the barriers of access are not insurmountable. I’d love to see some sales numbers though. Nintendo certainly has the name to attract players and developers. Maybe they need to open up their DS development a bit too. Bob would like that for sure!

And then we have our last, best hope for indie game development: The iPhone [1].

The iPhone seems to hit all the right marks: Hardware advanced enough that you can develop really interesting and good-looking games, yet simple enough that one or two people can create a top title. Very open (the SDK and tools are available for free to anyone!!) but with a very clear distribution channel.

Given the low prices of games (between $0.99 and $10) on the iPhone, not only is it possible to make great games with a team of two people, but actually having larger teams can make development much less profitable. I can’t imagine how EA or Maxis are making any money from their iPhone games if they put even just 10 or 20 people to work on them for a few months.

In order for indies to succeed in the app store, it’s important that we get enough visibility. Right now, the big money is on the top lists that Apple publishes which are unfortunately out of reach for most of us. A trend I’ve noticed lately is that big publishers are starting to elbow out indies out of the Top Ten charts. I hope that’s not a trend that continues much further.

I’m glad to see that the app store has related links when you browse a product, and also a variety of independent web sites that are appearing trying to sort the iWheat from the iChaff. It’s a start, but we need more initiatives along those lines. In the meanwhile, support your indie iPhone developers. Or at least go out of your way to learn a bit more about them. If you haven’t seen it already, check out the New Year’s App Blowout Sale and pick up Sneezies, Up There, and Mouse House. All three totally adorable, very polished games.

Happy New Year 2009 to everybody! I’m sure this year will bring a lot of surprises and interesting developments.

[1]Yes, I shamelessly stole that line from my favorite sci-fi show.

Starting iPhone development was a bit of a change since it required me to work exclusively under OSX and use a new IDE (XCode). I had talked to people who found the change very cumbersome and found the new environment got in their way, so I approached it with a bit of trepidation.

It’s An OS X World

With my new Macbook Pro under my arm (actually, it wasn’t new, I bought it used off Craigslist because I couldn’t afford a new one), I embarked on an adventure to this strange, new world of OS X development.

Some background is necessary here: I"m a minimalistic, no frills kind of guy when it comes to my preferences when working with computers (although now that I think about it, it probably applies to most other things in my life as well). The first thing I do with a new install of Windows is turn off all the GUI animations (don’t get me started on the search puppy dog!!), most of the sounds, all the auto-complete and auto-spellcheck features, and automatic upgrades. When I want the computer to do something, I’ll tell it to do so. Otherwise I want it to be quiet and responsive.

My ideal Visual Studio setup is also pretty similar: No fancy web startup page, no animations, no autocompletions by default (unless I press CTRL-Space), out with all the toolbars, just give me two text windows side by side and control everything from keyboard shortcuts (which I’m still using the ones from Visual C++ 6.0).

Needless to say, I was afraid of clashing with Mac OSX’s environment. I had a suspicious that it was full of eye candy, GUI frills, and required a mouse for everything. Not a good match.

There wasn’t as much of a learning curve as some getting-used-to. There are some Mac quirkiness that I just don’t get: The disembodied menu on the top of the screen, the lack of change of mouse cursor when you can resize a window, or not being able to automatically restore a file to its original location from the recycle bin.

But those are all relatively small things that don’t overshadow the fact that I just love this new environment. I used to like the Windows fonts, but after a week of using a Mac, I can’t go back to those tiny, jaggedy Windows fonts. Handling of multiple monitors is perfectly integrated and works like a charm. In general, things Just Work (TM).

Then there are the things that I love from my time in Linux that I can’t live without: Multiple desktops with Spaces, a decent command line shell, or being able to tweak settings directly in low-level config files.

And the thing that has changed how I work the most: Spotlight. No need for icons everywhere, or “Start | Programs” or anything. Just start typing what you want and there it is. It’s like the return of the command line on steroids. Between Spotlight, Firefox smart locaton bar, GMarks, and Ubiquity, I feel right at home. Now combine them all somehow and I’ll be in heaven!

But Wait, What About Windows?

I ended up falling in love with OS X so much, that I quickly moved to it as my primary environment at home for everything. Frankly, these days, it’s pretty easy for me to change environments since most of what I do is online. Just give me Firefox (or a good browser) and I’m there: GMail, Google Calendar, Google Reader, Google Docs (hmm… I sense a theme here), and a Wiki cover most of what I do on a daily basis.

For the rest of the apps, almost everything I need runs under OS X: good media visualizer (Preview), photograph organizer (Lightroom), image editor (The Gimp/Photoshop), audio editor (Audacity), music player (iTunes), and a few more odds and ends. OS X comes with some great utilities out of the box too, like Grab, Preview, or Activity Monitor.

Unfortunately, there are still a couple of things that I can only run under Windows. The main thing are games unfortunately, so I need to keep my Windows box around just for that. Although I just started playing World of Warcraft and it runs great on my Mac. Thanks Blizzard! Apart from that, every so often I need to do something in Visual Studio, or run some application I wrote in .Net. For that, I go about it in two different ways.

I can run it on the Windows box itself. Instead of keeping two sets of keyboards and mice (or a switch box), I used Synergy for a while. It was pretty cool being able to move the mouse cursor from one screen on the Mac to the screen on Windows and continue working there, and that might be a great solution if you’re working 50-50 on both platforms. In my case, it was more like 90-10 at the time (more like 99.9 to 0.1 now), so it felt a bit of a waste to have a full monitor dedicated to Windows. Instead, I decided to use Remote Desktop to control my Windows computer from the Mac. Amazingly enough, Microsoft wrote a Remote Desktop app for OS X that works like a charm, much better than some of the VNC programs I tried.

Whenever I don’t need to run something that is performance critical, I reach for Fusion. I’ve tried many products in the past that claim to run programs for another platform in your own computer: Wine, CrossOver Office, earlier versions of VMWare, but they’re always plagued by problems and incompatibilities. VMWare Fusion really surprised me by running anything I threw at it flawlessly, including Quicken (yes, I need to switch to Mint or Buxfer) and some hardware-accelerated 3D programs (those were a bit chuggy though, but they worked). And the coolest feature ever: Unity–I can run Windows apps in a window of their own directly on the Mac desktop. Totally awesome! On top of all that, I can have multiple snapshots, restore earlier states, and I can even run other operating systems like different versions of Linux. A geek’s true dream!

Some people will claim that I have drunk from the Apple kool-aid, and to a certain extent, they’re right. But I’d like to think I was swayed by many good reasons having to do with using the computer and being more productive, rather than Apple’s brainwashy, lifestyle marketing message. That and the smooth feel of the Macbook against the palm of my hands, its sleek profile, and sexy design. :-)

What about XCode and development? That’s another story for another day.

Since both Charles and I are tech guys, we knew we could implement our game idea without any problem and make it sing and dance at a silky-smooth 60 fps. But would it be fun? Now that we have these brand-new designer hats, finding that always elusive fun factor is a big concern. The idea of waiting for a couple of months before we could tell if our game idea was fun seemed too risky, so we tackled that problem first and head-on by prototyping.

We could start at the bottom, write some low-level input handling, some graphics rendering, a basic asset pipeline, and all the other usual suspects. The problem is that, even if we try to keep things as simple as possible, it would still be several weeks or even months before we can actually start implementing the game itself. And even when we do, we’ll always be running up against incomplete technology and having to spend time fleshing it out as we try to make a game come out of the other end.

Instead, we decided to start with a prototype. This isn’t supposed to be a “prototype” that eventually morphs into a shipping game, or a prototype that uses the same technology as the production code, or even a prototype that’s used to impress the big-wigs to squeeze some money out of them (ha!). No, all that stuff detracts from the ultimate goal of our prototype. Our approach was very similar to what Chris Hecker and Chaim Gingold described in their GDC presentation. We had the need to answer one very specific question: “Is our game idea fun?” And we wanted the answer as quickly and cheaply as possible. Everything else was secondary.

Prototyping period

And so we dove into a prototyping frenzy. For our first day, we set up shop at the E Street Cafe. We opened up the place, took over a table, hooked up gamepads to our laptops, and hacked away furiously until late in the evening, fueled all the while by cappuccinos, gourmet tea, and pastries [1]. Yum! By the end of the day, we had the basics of the game implemented and even some of the more advanced features. Heck, we even thought it was kind of fun, but that’s because we were tired and we had been staring at Charles’ horrible programmer art all day long. In all honesty, it really was a pretty sucky game, even if the enemy characters were wearing party hats. But hey, that was just end of day one.

Over the next few days, we had to take a break to deal with all the paperwork and logistics involved with setting up the new company and the office, but we resumed prototyping as soon as possible. The plan was to keep hammering away at the prototype until we saw it was clearly fun, or we decided it was hopeless and we had better think of something new (or go back and beg for our jobs back). Charles took it even further and swore not to shave his beard until the prototype was fun, much to his fiancee’s delight (seriously, the only thing the ladies think is hotter than a game programmer is a bearded game programmer).

A week later, things weren’t looking too hot. The game hadn’t gotten much beyond what we had done the first day. Sure, we had a bunch of advanced features in, but it didn’t really make it much more fun. Were we on the wrong path?

The major breakthroughs happened in the last few days. First of all, we removed a key feature that had been there since the very beginning. We really thought it was going to be key to the whole game, but it really made the game too easy and boring. As soon as we removed it, the feel of the game changed completely and things started to look up.

Then, as we were discussing some other advanced moves and features, the idea for a minor feature came up. Since the caffeine hadn’t kicked in yet and I didn’t have the energy to work on the next big feature, I implemented our little idea in about ten minutes. Charles saw it over my shoulder and he started laughing and begging me to check in the code. It was an instant hit! We ended up liking it so much that we decided to expand on with a few features, and before the end of the day, it’s clear that it’s going to become a main gameplay mechanic in the final game. That day we went home knowing we were nearing the end of the prototype face. Good thing because Charles’ beard was starting to look scary!

We tried about seven different captions, but none of them did the sprite justice.

One more day of tweaking the prototype and we officially called it done. We knew we had gotten there when we tweaked a small feature, fired up the game to see how it felt, and then spent 10-15 minutes going crazy with the controller because we were having too much fun. Another good sign was when we would start playing and then yell at each other to look at the crazy things we had just accomplished.

Finally, Charles was able to shave. Thank God.

The prototype

The prototype process was supposed to be as quick and cheap as possible. None of the code written was intended to be kept or extended to go into production code, and performance wasn’t an issue either. So, with that in mind, what did we use for developing our prototype?

C++ and Allegro. Yes, you read it right the first time. Let me say that again: C++ and Allegro.

With all the other choices available of higher-level languages and extensive game development libraries and frameworks, why on earth did we make that choice? Wouldn’t Python with PyGame or C# and the Game Studio Express have been better choices? The honest answer is that I don’t think either one of those options would have allowed us to get the prototype done any faster for several reasons:

• Small scope. The scope and size of the prototype was quite small, so there wasn’t much to be gained by using slightly higher-level language constructs or more complete libraries.

• Allegro. Even though it might seem like an odd choice and be behind the times, it’s precisely the old-school, fully procedural approach that makes Allegro so valuable. There are no frameworks, no enforced class hierarchies… heck, no classes or private members to get in the way. In Allegro, if you want to do something, you call the function and you’re done. Exactly what we needed for the prototype. In retrospect, SDL might have been a better choice since it would have allowed us to use a DirectX surface and do video capture more easily. But Allegro worked like a charm and we have nothing but good things to say about that experience [2].

• Proficiency. Both Charles and I are quite proficient at C++, so even if another language gave slightly faster development time, we more than made up for it by being very familiar with C++ and its libraries. For the prototype we allowed ourselves to use STL recklessly and with wanton disregard for memory access patterns and spurious allocations.  We also didn’t care about memory leaks at the end, so that helped get things up and running a lot faster.  Destructors?  Delete?  Free?  Cache coherency?  How do those equate to fun gameplay?!

It’s no secret that I’m an avid advocate of good software engineering practices for game development. As with anything, good software engineering practices have some very real and important benefits, but those benefits come with a cost. Because of the small scope of the prototype, and the fact that the code wasn’t going to survive more than a week or two, we decided to throw any software engineering practice that would slow us down in the least straight out the window!  Forget about accessors and private scoping; skip any unit tests; bye bye factories, loose coupling, and proper physical dependency management. Welcome to hackfest, check your engineering discipline at the door!

One of the things that made the prototype very successful for us was to concentrate on a single gameplay mechanic. We didn’t try to prototype the whole game, just the one bit we were most concerned about (and that was going to take 80% of the player’s time and attention). That allowed us to deal with a small subset of the game and iterate on it very quickly without getting bogged down by creeping features or dealing with a larger scope.

The prototype shamelessly used the worst programmer art imaginable (Charles + MS Paint == … you can imagine [edit: Charles] TOTALLY AWESOME SWEET). Yes, it looked horrible, but if the game was so much fun with those graphics, just imagine how it’s going to blow people away whenever we add some real art and animations.

Lessons learned

The most valuable lesson we learned was the value of constantly asking ourselves the questions “Is this fun?” and “What can I do now to make it more fun?“  That was actually really crucial. Having such a specific (even if subjective and nebulous) goal allowed us to remain in the right path. Sometimes it was tempting to add feature X or Y, but when we realized that it wouldn’t make the game any more fun, we quickly dropped it and moved to something else.

It’s important not to over-intellectualize the idea of “fun”, though. Sure, most of the fun comes from the choices the player makes and what happens as a result of those choices (even if the choice is to mash the buttons). But don’t underestimate the value of “fun” in having cool, flashy things on the screen, or to have the character jump with a nice ramp-up curve and land with some squishiness to give it that “just right” feel.

It was also very helpful to run the prototype by somebody else towards the end to make sure we weren’t finding it fun because we were simply delirious. Clearly, it has to be someone you can trust and who can understand what the prototype represents and not be put off by the stick figures. It was great to get confirmation from an outside source that it really was getting to be fun. We also got a bunch of feedback that made it a much tighter experience. A lot of it was pretty obvious, but we were too close to the game to be able to see it by ourselves.

As with most prototypes, it’s always very tempting to not throw it away and continue hammering at it until it looks like something that could be shipped. We didn’t really have a choice because of the technologies we went with (allegro is a fully cpu-based renderer), but we could feel the call of the dark side. It really was a good thing that we didn’t even try. Towards the end, the terrible hacked code we’d written was starting to slow our productivity. Code that bad builds up an “engineering debt” that you have to pay off sooner or later or you hit a wall.  Our particular wall came in the form of extending a pre-existing player action in what seemed like a trivial way.  Something like this would have literally taken about 5 minutes at the beginning of the prototype, but by the point we were at it would have taken closer to an hour. Heck, even having to go on for another week would have started to be painful. So in a way, the prototype came with a built-in self-destruct mechanism, which is a good thing because it discouraged us to continue working on it for too long.

Using existing technology is definitely the way to go. That way there’s very little “wasted” time getting up to speed. The fact that we were able to get most of the core mechanics of the game in the first day goes to show how useful is to hit the ground running instead of getting bogged down in how to load bitmaps or create a window.

Additionally, the procedural, non “framework-y”, non-object oriented approach of the API we chose made it much easier to bend to our will and make it work the way *we* wanted, and not the way somebody decided for us ahead of time. The fewer restrictions your prototyping API has, the easier it will be to do all the crazy things that come to mind during the prototyping phase.

The game

Unfortunately, we can’t really talk about the game right now. Just rest assured that we’re working on it at full steam and we’ll announce some details as soon as we can. Clearly, we’re not going to release the prototype since it has a good chance of scaring away any potential publishers in its current state. But if one day the game sells tons of units, maybe we’ll release the prototype as a “behind the scenes” feature so other people can have a glimpse at how things got started and they can laugh at our artistic skills.

Conclusion

There you have it. Now at least we can be confident that the game is going to be pretty fun. Sure, there are lots of aspects of the game that we haven’t prototyped, but we consider those to be lower risk and we’ll figure them as we go along. At least the core mechanic has proven to be fun. Now it’s just a matter of writing the production code and implementing it all. That simple. What could possibly go wrong? ;-)

[1] Money saving tip #1 for starving startups: If you have to pay for a 24-hour Internet connection in a coffee shop and you need to have several computers with Internet access, connect them with an ethernet cable and share the Internet connection from one of them. Ta-dah! :-)

[2] Actually, I’ve been wanting to create a movie of the prototype in action, but I haven’t been able to. It seems that Fraps doesn’t work because it’s not using a DirectX surface, and saving each frame is too slow. Anybody has any suggestions? Don’t get your hopes up though, we’re not uploading a movie of the prototype any time soon, we’re just saving it to show our grandchildren one day.

The computer was laughably primitive by today’s standards: Z80 4MHz CPU with 64KB of RAM. What made it stand out from other computers at the time was a whopping 16 simultaneous colors (as long as you gave up half your horizontal resolution), three-channel square wave sound generation, and 3” floppy disks. Cell phones these days are hundreds of times more powerful than that computer. Heck, the chip inside your microwave oven is probably more powerful!

What was it that caused love at first sight with that computer? Impressive as they were at the time, it wasn’t the technical specs that attracted me. It wasn’t the silly games either, even though those were fun for a few days. It was being able to give commands to the machine and have it execute them immediately.

The computer booted directly into a Basic interpreter. I started experimenting with a few PRINT statements, then moved to FOR loops, getting input and solving algebra problems as if by magic. I spent endless hours typing game listings that came in magazines (usually with a few printing errors, which made them so much more fun to get working correctly). I experimented with graphics, sounds, and animations.

Before I knew it, the Basic interpreter was too slow and bloated and I had to graduate to assembly. Programming became a bit slower (especially since for some reason I could only save the assembly onto tapes, not disks), but the programs became thousands of times faster. I was finally able to draw sprites without annoying flickering, use all available memory, and even overwrite part of the ROM jump table to squeeze in a few extra KB.

I was hooked.

That experience totally changed the rest of my life. It caused me to study computer engineering and computer science, and eventually to write games professionally (much to my parents’ dismay).

If that little, primitive computer had that effect on me, today’s dazzling multimedia computers with broadband Internet connection must have a hundred times that effect on today’s children, right? Quite the opposite.

Today’s computers might be a lot more powerful, but they’re also a lot more complicated. Windows is very large and intimidating to a newcomer. It doesn’t exactly scream “play with me, experiment!”. Instead, it is a very closed system. It discourages experimentation, and you’re in constant fear of disturbing any of the overly complex configurations (like the registry or system dlls), not to even mention dealing with viruses and other malware. Linux is much more transparent, but it’s still far from an inviting system to play and experiment with for newcomers to computers.

Another problem with modern computers is the lack of a programming language out of the box. Things are actually a bit better now than they were a few years ago. Microsoft offers a free express edition of Visual Studio. Python and other scripting languages are also free downloads, and they also have libraries for game development. Unfortunately none of those tools come pre-installed, which makes it hard to get started and even harder to share your results with other people. Also, a lot of free development tools and environments today are geared towards GUI programming, which is very different from the free-form, take-control-of-the-machine approach that you need not just for games, but to really learn about the machine. There really aren’t many better ways to permanently scare people away from programming than showing them something like this.

Web development is a bit better because it tends to be simpler, and once you have a web server set up, it’s easy to show the results to anybody with an Internet connection (which I hope is everybody these days). Unfortunately it’s not particularly well suited for something like games with the exception of things like Flash.

Although I’m sure that part of it is nostalgia, I’m clearly not the only one who feels this way. Computer science enrollment has been dropping dramatically in recent years and there seems to be a lack of interest in learning more about these machines that surround us, beyond how to use a browser and how to share videos with friends.

Really, when I look at things this way, I feel bad for kids growing up today. They’re missing out on a huge source of enjoyment that I had growing up as a kid. Of course, today there are other new frontiers to explore, and they have the Internet with all the new social aspects, but it’s not the same.

So, is the dream dead?

I have often wondered, isn’t there a platform out there that is more like the 8-bit computers were in their day? The closest parallel today is game consoles, except that they’re very closed and proprietary and they’re only intended to play games. Sony started making some progress along these lines with the Yaroze program for PSX and Linux for the Playstation 2. Unfortunately neither program was particularly successful for a variety of reasons, but it was a start.

A couple of days ago, in the keynote for GameFest, Microsoft announced that they’re taking things further on the Xbox 360 with Game Studio Express. They’re planning to open it up and allow everybody to develop games for it. Even better, the code will be mostly common between Windows and the Xbox 360, so it will be possible to do a lot of development on the PC and then move it over to the 360 relatively painlessly. How cool will it be for kids to write their own games running on the Xbox 360 and be able to show them off in their friends’ living room?

It seems that the only language available will be C#. At first I was disappointed as I was hoping it would work with C++. Then I realized it wasn’t such a bad idea. If anything, it would be better if it were something simpler, more like Dark Basic, that people with very little programming experience can quickly start messing around with. Game Studio Express is supposed to include several tools and APIs that allow you to program things at a really high level, so that might be good enough.

I’m very curious about the details, though. For instance, are we going to be able to get our hands dirty and write as much C# as we want, or are we going to be limited to a very strict framework? Is the link between the PC and the 360 something that they’re going to expose? In other words, will we be able to create other tools that use that functionality to create new types of content?

A really important question is whether anybody will be able to play content created by users, or will they have to have some special payment-based subscription. Having to pay to develop for the 360 is not ideal, but I don’t see it as an unsurmountable barrier. However, if users have to pay and be part of the developer program just to be able to play some user-generated content, that would come close to killing its usefulness. I hope that Microsoft learns some lessons from YouTube and Google Video and realize that the lower the barriers for people to browse the content, the more successful it is going to make the product. People have been able to share videos for a long time already, but it involved downloading them, getting a player that could decode them, and playing them back. Now it’s as simple as clicking on a link, and that’s why it has finally reached critical mass.

I’m definitely keeping a very close eye on this project, and I’ll try to give it a test drive as soon as I get a chance. It’s a bit ironic that with dozens of multi-million AAA titles out there, the reason I might end up buying an Xbox 360 is the chance to do play around with some sprites on the screen and re-create a bit of the old 8-bit days. The dream might indeed be back.

The underlying current at this year’s GDC was the transition to the next generation of platforms. The change was in the air. It wasn’t just the topic of the talks, but it was also underlying the questions asked, the technologies shown in the expo, and even the conversations at lunch. It influenced every activity and message. If it wasn’t because of what was said, it was because of what was left out, or what was put on hold “for a few more months.”

E3 is just around the corner, so we can expect to finally get the official announcements of Microsoft’s next-generation console, and maybe even Sony’s. That will mark the official transition into the next generation.

And this is not just another console generation transition. This time it’s bigger. Much bigger. Certainly much bigger than the PSX to PS2 console transition we went through five years ago. Maybe even of the same caliber as the transition from 2D to 3D that we saw 10 years ago. The changes that are about to happen affect more than the hardware we develop for. They’re going to affect how we develop games, how we organize ourselves, how we sell games, what type of games we make, and even how we think about games. Winds of change indeed.

These are the major changes I see coming.

Content generation

As the consoles become more powerful, we can create much more detailed environments, and players are going to expect that. Whereas it took someone a day to create a Doom 1 level that was roughly in a shippable state, now it takes someone several weeks to create just some of the geometry that is in a room in one of those levels. The team sizes, especially on the content creation side, are going to balloon, and soon teams numbering in the hundreds are going to be commonplace.

Large volumes of content aren’t just going to affect team sizes. We’re already struggling to deal with the amount of content we’re generating today, so we better get ready for the demands of tomorrow. A smooth, fast, robust, and efficient asset pipeline is going to be of prime importance. Probably more so than fancy tech and clever algorithms. The games that are going to stand out from the crowd from the point of view of visuals and polish are the ones with really good asset pipelines that allowed their content creators to iterate over and over and come up with something very close to what they were thinking. Tech-centered teams might have some impressive algorithms under the hood, but the resulting product is going to pale in comparison to their competitors.

The whole topic of asset pipelines is very dear to my heart. I previously wrote about the MechAssault asset pipeline, and I’ve changed my mind about several things since then. Adding the demands of next-generation content is going to make this topic even hotter.

From a technical point of view, we also have to consider the rebirth of procedural content. This is something we had considered in the previous console generation (and quickly dismissed), but this time it’s going to make much more of an impact. In a machine that can render a gorgeous scene that fully fits in memory, we’re going to need to have either an amazing streaming system, or great procedural content creation (or both!). Will Wright drove this point home in his talk about his new game, Spore.

Alternatively, maybe we’ll see a more clear distinction in what paths games take. Some games are trying to follow movies in the experience they offer: they are short (8-10 hours or less), full of new content, and giving players totally new experiences throughout the game. These are what I call “interactive experiences.” Then we have the “real” games, or toys. These are not a content showcase, but a game, with some rules and some variations, and lots of interaction with the player. This is the category of Sim City, Amplitude, or even sports or driving games. Games like Grand Theft Auto fall in an intermediate category because they straddle both types of games (mostly a toy sandbox with a story bolted on top). The point is, the more difficult or labor-intensive content creation becomes, the more we’re going to see this divide.

Development model

Next-generation games are going to need large number of people during production, but pre-production will still require only a small number of people. That’s the case today, but this trend will be exaggerated further.

Up until now, small companies with only one or two projects at once just put up with it and didn’t fully take advantage of everybody during pre-production. But will they be able to keep doing that now when they need to staff up to 100 people per project during production? If they staff up, how are they going to continue in business between projects? Does everybody need to grow to a size of 200-300 people to have multiple projects going on at once and smooth out the production spike needs?

One alternative that has been banded about for the last couple of years is the movie industry model. Game companies could do pre-production with a small number of people, and then assemble a team just for the duration of one project. There are some among us (especially from the UK) who will say that that’s already happening, just unofficially, with companies regularly laying people off after a game ships (see recent Oddworld news after completing Stranger’s Wrath).

Personally, I really dread this development model. Not only does it mean that we’ll lack a stable paycheck (and probably have even more emphasis on crunch periods), but it also means that the industry is going to cluster around a few central locations. In the US that will most certainly be Los Angeles, San Francisco, and maybe one other city. This is necessary to have a readily available talent pool, but it’s really a bummer for those of us who’d like to live elsewhere. Not like there are many companies in remote locations, but today you can choose to work in places like Maryland, North Carolina, Western Massachusetts, or Texas. Tomorrow we might not have that luxury.

Outsourcing went from being something that other industries talked about a few years ago, to something that we now accept as fairly common for art resources or cinematics. Outsourcing is a great way of flattening the curve of necessary resources, so I fully expect it to become the norm. Anything that can be outsourced will be. And a few things that can’t be will also be outsourced. For now that means cinematics, static geometry, some animations, music and some sound, and maybe some level layout.

Is outsourcing going to affect programming? I don’t think so right now. The closest thing we have to outsourcing is middleware, which is also a trend that is going to continue to grow. Especially if companies want to hit the ground running for a large production project, it makes total sense to use as much middleware as possible. Just look at how many developers are flocking to the Unreal Engine 3. It’s a very good set of technology and Epic managed to position itself in the right place at the right time (i.e. console generation transition).

Multiprocessors

This is undoubtedly going to be the biggest architecture change we’ve seen in a long while: multiple processors.

We all know that writing threaded programs is difficult. But this is something that goes beyond making your program thread-safe; it’s going to be a whole lot more than that. We have to deal with not just splitting the game into parallelizable parts, but we have to make sure those parts don’t interfere with each other, and that they access main memory in a controlled, efficient way. The gap between CPU and memory speeds continues to widen, and adding multiple processors to the mix isn’t going to help any. Games that ignore memory access patterns are going to crawl along in next-generation hardware.

Sony’s PS3 is going to take things even further. It’s going to use a cell processor with multiple cores, but each of the cores only has access to a very small amount of local memory. Not exactly the everyday programming model of the hardware we’re used to.

To be able to take full advantage of the new hardware, we’re going to have to change how we think about our programs. Take a snapshot of your game engine architecture, tilt your head 90 degrees, and that’s more how it’s going to look now. Data-driven architectures and service-oriented systems are going to dominate this new landscape.

Fortunately this is not just a bizarre architectural decision that console manufacturers pulled out of a hat. They are just leading the way as far as future architectures. More and more multiprocessors are becoming the norm on PCs, and both Intel and AMD have been busy at work for several years to take advantage of this trend. When you can’t make your processors faster, cheaper, and smaller, you need to start thinking of different directions to continue improving performance. Herb Sutter has been talking about it for a while now and he also sees it the inevitable future. So, as a programmer, don’t be afraid to dive in and get comfortable with this architecture. Multiprocessors are here to stay, and it’s going to be a valuable skill in the future.

Online focus

It seems that everybody is talking online this, online that. Especially Microsoft. Personally, I’m a bit scared (and skeptical) of this trend. Even though I enjoy the occasional multiplayer game (and I’m enjoying Guild Wars quite a bit right now), I certainly don’t want to make all my gaming experience be multiplayer. I do enjoy playing against the AI, or against somebody else sitting on my couch. I certainly don’t want to wait 10 or even 5 minutes to get everybody together before we can start a game, and I most certainly don’t want to hear eight-year-olds yelling while I’m trying to unwind by playing a quick game in the evening. I don’t want that on a PC game, and certainly not on a console game, which is supposed to provide a quick gaming experience.

I think the PC went through that phase about five years ago, when online gaming was new and exciting and every game had to have an online component, but it has reached a more mature position now. In the console realm, online play is still pretty new, so it keeps being pushed as a big marketing point. Xbox Live was apparently a big hit (certainly much bigger than I predicted back when it was announced), but it’s still only a tiny fraction of the market. Console manufacturers and publishers seem to think that broadband penetration is what’s preventing more people from jumping online. Have they considered that maybe most people don’t want to play online?

It always amazes me to see games whose multiplayer component is a completely different game from the single player one. They are two totally different experiences duct-taped together in one package, and usually one (or both) suffers for it. Wouldn’t it have been better to spend the resources in one of those areas and do it well? For example, the Grand Theft Auto series got it right. Sure, they could have done multiplayer with capture the flag, conquest modes, etc, but that’s not what the game is about.

So please, let’s not get drawn in by the hype and let’s keep the single player alive.

Conclusion

Times really are a-changing. The potential changes to the development model scare me. I hope things are not as grim as they seem right now and small game developers can stay afloat and not have to move to California to survive. On the other hand, I’m genuinely excited about the new technical challenges and figuring out how they’re going to affect the way we develop software. Bring on those multiprocessor machines!

A few weeks ago, Joel wrote an article with advice for college students looking to become programmers. It was good, solid advice overall, but it was a bit too general, and it didn’t apply very well to the games industry. I often get email from people looking to get their first job in the game industry asking me for advice. What are companies looking for in candidates for entry-level programming positions? How come it’s so difficult to land a job? I can’t answer for the industry as a whole, but I can certainly tell you what I am looking for when trying to fill an entry-level programmer position.

Specifically, I’m going to concentrate on the case of someone without any previous industry development experience applying to game companies for the first time, possibly straight out of college. At the end I’ll touch on people switching industries with previous experience in other software industries. If you’re already in the games industry, then you already have a pretty good idea how you got there, and that experience will carry you forward much more easily than someone trying to break in for the first time. Still, you should be able to meet all these requirements in spades for your next job interview, so you might want to read on anyway.

The type of job openings you’ll be looking for are usually referred to as junior programmer, entry-level programmer, associate programmer, or something similar. Sometimes it’ll be listed simply as programmer but they’ll specify that previous experience is not required.

What exactly am I looking for, then, in an entry-level programmer candidate? Here is what I’d like to see, roughly in order of importance.

Enthusiasm.

Maybe this goes without saying, but I figured I would put it as my number one item. If you aren’t extremely enthusiastic about developing games for the first time, you might as well look for something else. In a couple of years you’ll be extremely disappointed and will be thinking of switching industries anyway.

How do you show this enthusiasm of yours? Working on a project of your own is an excellent way of convincing potential employers that you really care about this stuff. Write some small games, participate in some open-source projects, make some mods, do whatever you want, but work on some game-related projects. I would recommend working on several small projects, and then try to work on one larger one to get exposure to several areas and get experience working on a large code base.

Make sure to bring up those projects in your resume and put them on your web page (yes, we do check web pages and google for people before bringing them in for an interview). In a way, they’re the closest thing you have to experience in the industry. Be ready to discuss your project, why you did things in certain ways, ask how other people deal with particular issues, etc.

Always learning.

You’re about to finish your college education. If you think you’re done learning, think again. You’ve just finished the base that allows you to continue learning. Especially in this always-changing industry, you will always be learning new things: new platforms, new APIs, new languages, new approaches, new styles, new everything. Don’t think for a moment you can learn a couple of things and then stick to them without learning anything new.

It’s great to be confident in your skills, but if I catch a whiff that the candidate is set in his ways and is not interested in learning anything new, it’s “hasta la vista, baby.”

So go out and learn new things. I always like to be reading a technical book on things directly applicable to what I do at work, and maybe some on things that are more off-the-wall. In addition, I recommend reading trade magazines (Game Developer Magazine, Software Development, C/C++ Users Journal, etc), conference journals (GDC, Siggraph, ACM), web sites (Gamasutra, Flipcode, GameDev.net), mailing lists (gd-algorithms, sweng-gamedev, gd-general), and just about anything you can get your hands on. Don’t be afraid to look at open source projects (Nebula Device, Crystal Space), figure out how they do things, and even participate in their development.

The book The Pragmatic Programmer recommends learning one new computer language every year. It might be a bit of overkill, but it’s certainly not a bad idea. Even if you’re not planning on using Smalltalk or Ruby, it can only broaden your skillset and give you new perspectives on things. Learn about garbage collection, dynamic languages, etc. Of course, make sure you have the basics covered and you have a good grasp of C and C++ before you branch into other languages.

Plays games.

Doh! If you’re going to be developing games, you better play games on a regular basis. You don’t have to be a hardcore player, but you should enjoy playing some games. Be ready to discuss your tastes in games, what you’re played recently, why you liked them, etc. It’s not like you’re going to be designing the games (after all, you’re applying for a programming position), but it’s good to have an idea of what you’re aiming for when you’re creating a game. Also, the more you enjoy playing games, the more of a reason you have to actually want to work on them.

In my time in the industry, I’ve only known one programmer who didn’t play any games (and he was extremely talented to boot), but he was certainly the exception to the rule. If you don’t like games, you better have a really good reason as you why you want to get in this business.

Skills.

Ah, yes. It finally had to come up. As an entry-level programmer, you’re expected to learn a lot on the job, but you need certain skills to be useful and productive from the very beginning. Hobbyist game programmers obsess about DirectX and OpenGL. That’s fine, but don’t worry too much about it. You’re not going to see a single line of those APIs unless you’re hired as a graphics specialist (unlikely for a junior-level position). The specific skills will depend on the exact job and company, but these are pretty universal given what typical junior programmers get to work on.

• Fluent in C++. Most game development (for PCs and game consoles) these days is done in C++, so you’d better be comfortable with the language. Knowing the syntax and compiling “Hello world” isn’t good enough. A class in college isn’t going to cut it either. The ideal candidate will have at least read Effective C++ and will have used C++ in some significant projects (either your own projects, or in some term projects at school). You should be able to discuss the order in which destructors are called for classes with inheritance, when you need to provide a copy constructor, or what const-correctness is and why is it a good idea. If not, hit the books right away.
• Basic 3D linear algebra. As an entry-level programmer, you’ll most likely work extensively on high-level game code at first. To do things effectively, you’ll need a good understanding of the fundamentals of 3D linear algebra. Make sure you know your dot and cross products, how to calculate them, but, most importantly, what they represent and when you should use them. You should be comfortable with relative coordinate systems, and matrices as transforms (I don’t care if you know the formula for a rotation matrix, just that you know how to use it). Calculating if an object in the world is within a certain distance from the player, and within a certain angle of its aiming direction, should be close to second nature. Review your linear algebra books from college or check out Mathematics for 3D Game Programming and Computer Graphics
• Software engineering. This is not a requirement for total entry-level positions, but it’s certainly a nice bonus. Unfortunately it’s not often emphasized (or even taught) in many schools, but being familiar with good software engineering practices is very important. Learn all you can about good object-oriented design, design patterns, encapsulation, unit testing, physical insulation, etc. There’s more to programming than knowing a language or API. This is difficult for people straight out of college, but it’s a huge bonus when you have it. Internships could help with this, but they’re not nearly as crucial for me as Joel says. I’d rather see an impressive set of home projects than a couple of summers working at IBM or Sun (on one hand I see a guy with lots of internal drive, and another one that needs to be told what to do and needs guidance). Having both would be awesome.
• Tools. I certainly don’t expect new programmers to be familiar with the exact tools we happen to use. However, the ideal candidate should be familiar with version control, should know how to use a debugger, etc.

Ability to get things done.

As an entry-level programmer, you’re going to be thrown in the water and you’re going to have to figure out a lot of things by yourself. Sure, you’ll hopefully get some supervision, and people will be able to answer a lot of your questions and work with you. But you’ll be expected to tackle something, learn about it, and get it done.

Here’s one that I completely agree with Joel: Make sure you get a degree, and do the best job you can with it. Sure, a degree doesn’t measure many things, but getting a good GPA means that you were able to stick with something for four years, even when things got tough or when you had to do things that you didn’t feel like working on. Working in games is not all fun (even if it’s all games), so making sure that people are not easily discouraged and can get things done is very important.

Another way of showing that is, as I said earlier, by working on projects on your spare time. That shows someone who went to the effort of creating something while learning something new. It doesn’t have to be a super-polished, finished game, but it should be more than a couple of classes that compile without errors and print “OK”.

Well-rounded education.

Knowing things outside of games is a good thing (knowing the detailed history of the Star Wars universe doesn’t really count). Taking and doing well in classes in a variety of topics in college is a good start. You may think that your South American archaeology class will never be of any relevance, but you’ll be surprised how things you learn there will come in useful in the most unexpected ways.

Make sure you do something beyond games. Take up a hobby of something totally unrelated. Some of the best candidates are art enthusiasts, practice sports seriously, are into oriental philosophy, or play the viola. I always ask about people’s hobbies during an interview. Usually the weaker candidates won’t have any hobbies or their only hobby is playing computer games.

I really think that if you’re going to dedicate yourself professionally to games, you need to have some interests in other areas. Also, being familiar with wildly different subjects allows people to approach problems from a completely different angle and come up with very creative solutions. Don’t discount the importance of a well-rounded education.

One thing you should not worry about at this point is specialization. If you have one in mind, that’s fine, and share it with your employer so you can plan a way to get there. But keep in mind that at first, breadth is more important than depth. It’ll be much better for you to learn as much as possible about game development in general. The brightest graphics guru who only knows about graphics will not be half as effective as he could be if he had broader experience developing games.

However, one specialty you can jump straight into is tools. Learn the APIs. Write some tools. Create an editor for an existing game. However, don’t think of tools as a temporary thing to pay your dues. Tools are an extremely important part of game development, now more than ever, so you can make a full career as a tools programmer.

How about people from other software industries with some years of experience? There’s a certain bias against them in the industry. On one hand, they’re not considered to have the right “experience,” and then they ask for too much money because they have several years in development already. You can bring a lot of experience, and a lot of it will be different. That’s very valuable, but the company needs to see that. Play that angle in your resume/interview. Explain how your skills can be invaluable to the company (and that also shows you’re familiar with the development process). Doing a game-related project on the side can go a long way to convince a company that your heart is in the right place.

If you only take one thing away from this article, this should be it: Always be looking to learn new things. Always read new books. Always try new things. Always be willing to listen to and try a different approach. Someone like that will quickly gain a huge amount of experience and become an invaluable member of the team, but the converse (someone with lots of experience not willing to learn anything new) is nearly useless in a rapidly-changing field.

Having said all that, I’m afraid we’re not currently looking for any entry-level positions at Sammy Studios. We might be hiring again this summer, so check back then. In the meanwhile, hit the books and sharpen up those skills.

This article was first published in the April 2004 issue of Game Developer Magazine. Printer-friendly format.

Introduction

After years of being almost completely technology-driven, the driving force behind games is finally swinging towards the game content itself: level design, models, sounds, story, cinematics, etc. Major technological leaps are not making enough of a difference to set games apart from each other. Game content will also continue getting larger and more complex. The amount of content going into AAA games seems to double every few years. Since there’s no hardware upgrade for the artists and designers themselves, content doesn’t get created any faster.

A successful game needs to provide top-notch content, and the best way to provide it is to optimize the content pipeline so that artists and designers can create, preview, add, and tweak new assets as easily and rapidly as possible.

The content pipeline is the path that all the game assets follow, from conception until they can be loaded in the game. Game assets include everything that is not code: models, textures, materials, sounds, animations, cinematics, scripts, etc. During their trip through the pipeline, assets might be converted, optimized, chopped to bits, or combined. In the end, the asset is in a format that will be shipped with the final version of the game.

The first issue to consider when defining the content pipeline is its efficiency. With large teams of artists and designers constantly creating and tweaking game content, the content pipeline becomes a critical path. A slight inefficiency in the pipeline, such as taking one full minute from the time a change is made to the time it can be seen in the game, can easily cost a company thousands of wasted man-hours during the course of a project. Alternatively, if the content creators don’t preview their work as frequently, the overall quality of the game will suffer.

The other main point to consider is robustness. The content pipeline is the jugular vein of a project: if it breaks it can quickly kill the whole project. You can’t afford to have 30 idle people waiting for the pipeline to be fixed, or working around it and consequently losing half their work. Whatever happens, the pipeline must always work correctly.

Bird’s-Eye View of the Pipeline

What does an asset pipeline look like? It depends on the project. On one extreme, in some projects the pipeline is minimal and informal: assets are exported from their tool and loaded directly in the game. While that might be sufficient for small games, it usually doesn’t hold up well in large projects: Where are the files stored so multiple people can work on them? How are assets for multiple platforms dealt with? How can the format of the resources be changed easily? How can any extra processing be applied to them?

On the other end of the spectrum, pipelines can be very deep and elaborate. Adding a new asset to the game requires going to the pipeline guru and asking him to add the new content, causing turnaround time to suffer significantly.

This article presents a general pipeline that many different game projects can adopt and modify to fit their needs. It is fairly lightweight and provides a quick turnaround time, yet it allows for any number of expensive steps to be performed on the assets along the way. This is the pipeline that we’re using at Day 1 Studios for our current Xbox project, MechAssault 2. A previous incarnation of this pipeline was used in MechAssault 1. This pipeline might be a good starting place if you’re just beginning a new project, or you can try to adapt some of the ideas that make sense for your current situation.

Figure 1. A partial view of the MechAssault 2 content pipeline (only models and textures shown).

Figure 1 shows the pipeline for some of the major types of assets in MechAssault 2. The following sections describe in detail each of the pipeline stages.

Source Assets

Source assets are those created by artists and designers, usually through some specialized tool (both in-house tools and off-the-shelf ones). A source asset is one that can be put into the pipeline and will be converted into the final asset without any human intervention. The key idea is that source assets should contain all the information necessary to add them to the game correctly. A material should have all its specular parameters specified, and a model should have all the flags in the weapon barrels so the game knows from what point to shoot projectiles. This is what will allow us to automate the pipeline later on.

The way source assets are created can vary significantly. Sometimes they are created through a set of different, very specialized tools (one for modeling, one for texture creation, one for specifying game information, one to lay out a level, etc). Other times, one large tool (often done as a plug-in in the model-editor program) can be used to create all the assets and export full levels.

Since the source assets contain all the information needed for the final assets in the game, we should treat them very carefully and protect them from being lost or accidentally overwritten. Using a version control program provides a centralized location for all assets, prevents people from overwriting each other’s work, and keeps a history of previous versions of each asset. Keep in mind that source asset files can sometimes be as large as several hundred megabytes each, so make sure your version control program is up to it and can also deal well with binary files.

Pre-rendered movies and sound are also game assets, but they’re often treated differently because of their huge size. They might have a slightly different path through the content pipeline: Maybe movies won’t be kept under version control, or maybe they will but only the most recent version will be kept in the database.

Intermediate Assets

Intermediate assets are exported directly from the source assets, usually with the tool they were created with. This requires a bit more plug-in work in the form of exporters if you’re dealing with off-the-shelf tools.

The intermediate assets are in a format that is very easy to read, parse, and extend without breaking backwards compatibility. These assets should contain all the information we could possibly want in the future, even if some of it gets discarded before the end. Loading performance is of no consequence at this point; we’ll leave that up to the final assets.

Plain text files are the perfect match for our requirements. In addition, XML is a particularly attractive option to structure those text files, especially if we need to represent information hierarchically. Doing so will also provide us with a whole range of tools and APIs to edit, parse, and transform files with minimal effort. If XML files are overkill for your needs, you can still use a simpler format like INI files or even write your own with minimal effort.

What is the purpose of having this intermediate asset format?

The main reason to have it is to provide a buffer between the source assets and the final ones. Final assets are optimized to load blazingly fast, but as a result, their format will often change and render previous versions unusable. In an ideal world, we would be able to efficiently re-export all source assets automatically into the new final asset format. Unfortunately, we don’t live in an ideal world, and that is often impractical. Many off-the-self tools used for modeling and texture creation are not easily and efficiently driven from the command line to batch re-export thousands of models at the time. The intermediate format is not likely to change much during the course of a project, so we can always use it as a starting point to generate our final assets.

Another reason for having this intermediate format is to defer some of the complex and time-consuming operations like mesh optimizations or lightmap generation until a later time instead of doing them at export time. Also, we often end up creating a set of final assets for each platform we’re dealing with. Without the intermediate format, artists would have to export a set of assets for each platform, ensure they’re in synch with each other, and wait while each set of assets is converted and optimized every time an asset is changed.

Last but not least, having an intermediate format provides an excellent point for debugging and experimentation for the programmers. Intermediate assets should be in a very easily readable format, so anybody can view the contents of the asset, and even make small modifications for testing and debugging purposes without having to re-export them.

For MechAssault 2 we’re exporting full models into one XML file: all the hierarchy information, meshes, vertex data, and materials are included into one large XML file. One of those files for a detailed model can easily be 3-4 MBytes.

As much as plain text is a really nice format to work with, exporting textures into text format would be overkill. In the case of textures, we export them into 32-bit tiff files with custom information in the comments field containing any information artists specified from within Photoshop: bit-depth, dithering, mip-mapping options, etc. The advantage of this format is that all the image is still there since it’s exported at full 32-bits (although soon we’ll have to worry about larger color channels!), and images can be examined with any program that displays tiff files. Again, mip-mapping, changing bit depths, and dithering are not cheap operations we want to do at load time, but we’ll postpone all that until later.

It can be very tempting to modify an intermediate asset directly for many reasons: a “quick” change right before a milestone, the change we’re trying to make is not exposed through the plug-in of the tool, etc. We did exactly that in MechAssault 1 and ended up regretting it. We were too pressed for time to provide good plug-ins for our custom material types, so artists would modify material parameters on the intermediate assets directly. Those parameters would get overwritten next time somebody else re-exported the model and would have to be re-entered by hand. If you absolutely must modify intermediate assets, then consider providing full re-importing capabilities back into your source assets; however, this is usually not a trivial task. For MechAssault 2 we’re sticking to only making changes in the source and providing much better plug-in support, and things are running much more smoothly.

Even though this intermediate format is very flexible, chances are there will come a time during a project when it will be necessary to break backwards compatibility. Don’t fight it; get ready for it instead. Make sure you have versioning as part of the format, and that you can easily run a script through all exported intermediate assets and convert them to the new format. Since you hopefully chose an easily parsed format such as XML, the conversion process should be almost painless.

Final Assets

The final assets have been highly optimized so they can be loaded and used as efficiently as possible in their target platform. The specific file format doesn’t have to be particularly robust or withstand many format changes since the final assets will be regenerated many times a day. The number one goal here is speed. Ideally, this resource should be a direct memory image of what it’ll be in when it’s loaded in the game, so that it can be loaded straight without any parsing. The standard warnings about optimizations also apply here: don’t blindly optimize everything, and spend your time in those assets where you’ll get the most benefit.

If you’re doing multiplatform development, you’ll probably want to have one set of final assets for every platform. That way Xbox textures can be in their own format, and PS2 textures can be packed and formatted differently. At Day 1 Studios, even though we were only developing for the Xbox, we have two sets of resources: one for the Xbox, used in the game, and one for the PC, used in our PC-based tools.

The type of operations done at this stage range from quick ones such as simple format changes, to somewhat expensive ones such as mip-map generation, dithering, or compression, to really time-consuming ones such as lightmap generation and mesh optimizations. At this point we don’t care too much about how long it takes to perform an operation, we just care about the final result and how optimized the final asset is. As a result of this step some assets could be split into different assets (for example, our model XML file is split into several smaller files containing vertex and index data), and sometimes multiple assets get combined into one larger asset (packing a set of textures into one larger texture).

At Day 1 Studios, this step is performed by a command-line conversion tool, which takes a set of intermediate assets and produces the final assets. The actual conversion happens through a set of conversion plug-ins implemented as DLLs, each of which takes care of converting a particular type of resource (identified by filename extension or a header on the file itself). Any resources not handled by the conversion plug-ins are just copied straight through without any modifications.

Be warned that doing a full resource conversion on all the assets of the game can be a very time-consuming operation. There can easily be hundreds of thousands of files, and each of them needs to be loaded, parsed, converted, and saved in the new format. This process can take up to several hours even with a fast CPU and a very fast hard drive. Minimizing this time will help with the overall turnaround time, so you might want to profile the conversion program to find any obvious bottlenecks. Other solutions include doing incremental conversions (only convert files that have changed since the last build), and doing distributed builds (have a farm of machines where each one takes care of converting a subset of the resources).

During this step we should also generate errors and warning messages as necessary. Sometimes an asset won’t meet the requirements to be converted successfully (for example, a texture might be marked as needing mip-maps but it has dimensions that are not a power of two). It’s much better to prevent invalid assets from making it this far down the pipeline by preventing them from being generated in the first place, but we should still be ready for them here. By keeping a log of all the failed conversions and all the warning messages, the art and design leads can quickly identify what the problems are and correct them for the next build.

If you have specific dependencies between resources that need to be enforced (for example, packing all the textures for a particular model together and the textures need to be converted before they’re packed), you might want to use an existing dependency-management tool such as make or jam.

Catalog Files

The final step of the pipeline consists in packing all the loose final asset files into larger catalog files. A catalog file is nothing more than a large file containing other files inside, possibly along with their names and hierarchy information.

The advantage of using catalog files are pretty obvious: reduced number of open/close file operations, enforced physical proximity between files, easier and more efficient distribution of assets, faster directory parsing, etc. Surprisingly, not all modern games provide catalog files with their assets (you can usually tell who the guilty parties are by the outrageously long load or install times!).

Using a standard catalog file format (such as .zip, .cab, or even .wad) is very convenient because there are already-made tools to create, load, and view them. On the other hand, you might not have as much control over them as you want (for example, to enforce a specific file alignment or ordering for optimal seeking performance on a DVD).

In this step, the final assets for each platform are packaged into separate files. You might want to have separate catalog files for each level, or have sound and music on a separate catalog file from the rest of the assets. Those strategies will depend on how you need to load resources in your game. Once these catalog files are created, they can be copied onto the network and everybody can copy them locally to their machines or work with them directly from the network if there’s enough bandwidth. The game and the tools should be able to read these files directly and load any of the resources inside transparently.

The Fast Path

Unfortunately, the process we’ve described so far isn’t exactly speedy. To make a change and see it in the game, we need to go through the following steps: modify a source asset, export the intermediate one, check it in version control, kick off a resource conversion, and wait for a few hours until new catalog files are ready. That doesn’t meet our earlier requirement of a fast turnaround time.

The solution is to provide a fast path into the tools and the game that bypasses all the time-consuming steps. In our case, we made it so both the tools and the game could load intermediate assets as well as the final assets (see Figure 1 again). All an artist has to do to see how their updated texture looks in the game is to export the intermediate asset, copy it on the directory where the game or tool expects to find it, and run the game. You can even provide a macro or a button that does all those steps at once, including launching the game to the correct level. The artists just make a change, push a button, and see their new assets in the game. It can’t get much easier than that.

How exactly is the local file loaded instead of the one residing in the catalog? That’s part of the magic of the file manager. As far as the tools and the game are concerned, they’re just opening a file like any other. However, our file manager gives local files priority over catalog files so they override any similar entries in a catalog file. Whenever the game attempts to open that file, the file manager redirects it to the local file. Otherwise it loads it from the catalog as usual.

Since we designed the intermediate format so it was easy to parse and modify, but not fast to load, isn’t that going to slow loading levels down to a crawl? It would if all the resources in the level were in the intermediate format. The idea is that only the assets that artists and designers are working with at the moment are going to be found locally in the intermediate format, so load times are only going to increase by a very small amount.

This approach also requires that the game and all the tools have code in them to load and parse assets in their intermediate formats. That is not a trivial amount of code, but chances are you’ve already written it to make it part of your conversion tool. However, you might want to strip this code out of the final shipped game, so separate it cleanly and surround it with conditional compilation statements so it’s easy to remove.

There is one important lesson we learned from using this fast load path: Make sure that your fast load path and your normal path (following the rest of the pipeline) both produce the same results; otherwise you’ll have some very disconcerted artists who are not sure why their assets look different after they check them in. In our case, we were using one library for texture conversion in the slow path and a different one in the fast path. The results were often similar, but sometimes different enough to raise a few questions. Whenever possible, use the same code in both paths.

Putting It All Together

Now that the whole pipeline is in place, we can finally start thinking about automating the process. It should be relatively straightforward to create a script to get the latest source or intermediate assets from source control, run the conversion process on all of them, and package them on the catalog files. Perl and Python are some good glue languages for that type of tasks. The most difficult aspect of the script is making it robust enough to deal with errors (network going down, version control server being down, etc), so take good care of that from the beginning. With such a script in place, we can run the resource build automatically once or twice a day, or on demand when new resources are needed.

The more we automate the content pipeline, the more important feedback becomes. People are not going to be watching every step of the pipeline, so we need to collect all the important information and deliver it to the people who care about it. In addition to gathering all errors and warnings, we might also want to collect other information, such as memory footprints, texture usage, or even some rough performance statistics. All that is best done as a final step to the resource build, running each of the levels in the game with the latest resource and executables. As a side benefit, it also serves as a very rough smoke test of the build.

Robustness was one of the goals of the pipeline from the very beginning. Part of it involves making sure that the conversion and packaging tools work flawlessly and report any errors correctly. The other part is making sure the game and the tools are never left in an unusable state because of bad resources. A good philosophy to maintain is that bad data should never break the game or tools; an artist or designer should never be able to crash the game. It might sound a bit radical, but it’s worth aiming for that goal. Any engineering time spent towards this will be paid back many times over as soon as assets start being added to the game at full speed. When loading a level, take the time to report any loading or initialization errors, disable the entities that had problems, and move on. In addition to that, it’s helpful to put some sort of ugly debugging model (a big pink lollipop in our case) in place of any entity that failed initialization.

Further Work on the Pipeline

Turnaround time is very good already, but we’d like to make it even shorter. We’d like the game to detect that some assets have changed and load them on the fly. This can be particularly beneficial for games without discrete levels where reaching specific locations is a time-consuming task.

A full resource build for MechAssault 2 can take up to an hour and a half. We’d like to further investigate the possibility of doing distributed builds. There are open-source, general frameworks for doing distributed operations that could be easily added to the process. We might also want to look into integration with the build systems such as Ant for added robustness.

Games are very different from each other and teams are organized differently, so content pipelines will vary significantly from project to project. It is important to identify the assets for a given game, what kind of operations will be done to them, who will be working on them, and at what stage of the development they will occur. Use whatever pipeline organization works best for your particular needs and automate as much of it as possible. The artists and designers in your team will thank you for it, and you’ll end up with a much better game in the end.