Oh my word. This game is my current single player obsession. Loved the new X-Com? Loved FTL? Love RPG’s and the that “one more turn” feeling? I found it hard to stop playing. It came out of left field for me (but that’s how it always feels if their marketing is doing its job right?). I’m not a huge fan of “medieval”  or “dark and grim” themed games. But the art style in Darkest Dungeon is amazing and I quickly became a fan. Also the narrator in the game was a great touch. The lines he delivers builds a great sense of atmosphere and immersion. So much so that I found myself thinking about the narration outside the game:

Ya, it’s quickly accumulating hours on my steam account over these past several weeks:

Screen Shot 2015-08-06 at 2.44.55 AM

Where have the hours gone?


Wow, it’s been a while. Figured passing another milestone is worth at least some sort of update. Looking back at my 1 year milestone has been amusing. My initial thought was that almost all the points brought up 4 years ago would no longer apply. A lot of the insights back then are strangely still quite applicable. So what’s happened in the 4 years since? On a more personal level, I’ve improved my eating and exercising habits to stay healthier. If I want to be at this for many more years to come, letting my health deteriorate while I work isn’t the wisest decision. On the games front: I’ve helped ship 4 games across 8 SKUs not including at least 5 pieces of DLC across those games, with a 5th game currently in production. Not too bad in terms of productive output.

On the satisfaction front, not much has changed, which is great! Each day I look forward to working on something cool or improving something we’ve made. The “case of the Mondays” is still a fading memory. While most of what I said back then I think still applies, I figured I could address some of the changes that have occurred in the past 4 years in regards to iOS indie game development. I think for anyone that is starting out in this market they’ll find some useful info below and hopefully avoid the mistakes I made.

On Gaming Trends

So this is a quirky one. Quickly on the topic of cloning:

Cloning has come to the forefront over the years in some pockets of the indie scene, particularly on mobile. There are some infamous examples  where the act of cloning or doing what most call “a fast follow” has paid off handsomely. Still, the numbers seem to imply that it’s not a winning strategy and you aren’t going to be winning any friends in the indie scene either.

Now back to trends in the general sense. I still maintain that chasing trends on the app store isn’t something you should do. But here’s the caveat: don’t be oblivious to them. You could find yourself caught in what feels like a fad and is in fact a huge tidal shift. The prominent example is the App Store’s shift away from premium games to free-to-play games. Over three years ago, I made the mistake of not taking that shift seriously enough thinking paid games would simply co-exist along-side f2p. I was so wrong. Paid games still exist on the app store, but it’d be hard to argue that they haven’t been negatively impacted by the pervasive free-to-play culture on some level. I think my stubbornness to understand f2p hurt our game’s chances for success, more specifically Outwitters.

In regards to game design trends, I think if you’ve correctly identified a genre of games that are popular or becoming popular, you’d be doing yourself a disservice to not investigate further. Why is it popular? Is it simply 1 game bucking the trend or are there more examples? If there are more, what do you think makes those games connect with such a large audience? And last of all, can you use that to your advantage for any game you make next (read: not clone)? I’ve made the mistake over the years of turning my nose up at some games or genres of games without really taking the time to understand what makes them tick.

It took me a while, but I was able to expand my definition of “play” and what makes “good gameplay” to include modes of play that are outside my usual experience. For example, one of those modes being meditative play. If you want to know more about modes of play I’d recommend listening to this episode of Designer Notes. That podcast helped solidify my own thoughts on why people chose to play certain games that before I wouldn’t even classify as “games”. Armed with a broader understanding of “play” it’s become easier to look at games that are trending and not immediately dismiss them as a fluke or accident, but look at them as possibly hitting upon an underserved niche that most designers wouldn’t even look to design for.

On Shipping Games, Updates, and Fan Service

The idea of free updates is a fading one to be honest. Yet I’ve still seen it marketed as a headlining item in several paid mobile games over the years. My previous post from 4 years ago alluded to this same reality, but in more vague terms. If you’re in the business of making games for a living, and you’re not sitting on mountains of cash you seriously need some minimal business case for doing free updates (beyond bug fixes). If you’re promising free content updates to those that pay for your game, you’re making a pretty big gamble on the app store. Here are some of the most likely reasons to do so:

  1. Your content updates are so cheap and quick, that it’s negligible to do so whether you break even or not. You use it as a marketing tool.
  2. You’re banking on a success to where the revenue will go way beyond “breaking even” that it’ll cover the cost of any content you release as free updates.
  3. You’ve got content ready to go or very close to being finished but didn’t make it into the release of the game, so putting it into updates isn’t a big hurdle
  4. You’re making a huge mistake.

#1 is tenuous at best, because in the past 4 years I haven’t really seen anyone “turn around” a paid game’s trajectory via cheap and quick updates. #3 is kind of a subset of #4. Just because you’ve finished some content that didn’t make it into the shipping game doesn’t mean it has zero value, despite what the vocal minority will tell you. Over the years I think I may have become a bit more hard lined on this: Embrace your fans that adore and actually support you. If you have a thousands of players who haven’t paid a cent and would riot at the idea of spending money on your games, don’t lose sleep over them. I use to. The only time that makes sense is if a) you’re serving ads b) and you don’t have thousands, but millions of players.

Your Benchmark for Success Shouldn’t Be “Break Even”

If a business sets it’s goals only ever to just break even, it’ll never have the resources to grow, improve, or more importantly weather any troubled waters in the future. If you’re truly “breaking even” then you’re 1 mistake or botched launched away from complete failure as a company and it’s back to your “day job” with you. Four years ago I stressed that your first, second, third, or even fourth game won’t succeed. I can’t stress that enough. I think Daniel Cook of Lost Garden says it best:

 When I talk about probabilities in game development, I’m by no means saying that success is all due to luck. Instead, it is merely acknowledging that even when you do everything you possibly can there are still huge risk factors that are out of your direct control. You might as well plan for only a small chance of success with an individual game.

I think the above thinking may apply to mobile even more so than other platforms. For anyone starting out, hell, anyone struggling in the indie game business, they should give that article a thorough read. Even if you don’t agree with his underlying conclusion (freemium being more stable long term), the economic realities of game development are hard to ignore. This is probably the hardest lesson I’ve learned over these past few years, and I’m still learning.

When budgeting a game, I tend to restrict the budget by a lot. Eventually I’ll get to the “minimal” game I’d be “satisfied” making, and then the data suggests you should take that and slash it by 90% more in order to hope to achieve any sort of benchmark for success. It then becomes extremely tempting to wave away the facts and just tell yourself “it’ll work out in the end” and barrel ahead. There’s no shortage of “by the skin of our teeth” success stories in the indie scene, which might perpetuate the myth that all you need to do is make a great game, and it’ll work out. A great game is a great game, but if your budget outstrips the size of the potential target audience, there’s no amount of “greatness” in that game that’ll save it or your company. The essential takeaway is: be mindful of where your time and money are going in regards to developing your game, and don’t let either (especially time) spiral out of control.

Are Things Better.. Or Worse?

That’s a tough one. For anyone that hangs in mobile indie circles, there’s a lot of doom and gloom these past several months in regards to the health of the app store and its future for indies. It’s undoubtedly harder to make a dent on mobile these days than when we entered the market over 5 years ago. The average revenue per game for us and many others have gone down over the years. Even the most well known publications in the mobile space are feeling the squeeze. It’s forced me to look beyond iOS. The smallest and easiest jump was to Android. It’s a tougher market to make revenue from, but as time goes on, every bit has helped. I’m taking that a step further with our next game, Space Food Truck, and targeting yet another platform in addition to our usual fare. Having talked to many fellow indies over the years, and having followed the scene for longer than I’ve been in it, when things start looking rough, the indies that are able to take the changes in stride instead of clinging to any one particular platform usually are the ones that stay in business. Any particular platform owes me nothing.

I think my mindset has definitely changed over the years in regards to platforms. Starting out I saw mobile as a way to “get a start” in the indie game business with the ultimate goal of being on multiple platforms. Somewhere along the way it became “the destination” in my head. It was easy to look at our successes and think “yep, it should stay about the same.” But taking the long view it was clear that staying exclusive to one platform didn’t make sense. The last couple of years was a wake up call to how quickly things could change on any given platform. Expanding to different platforms takes effort. It doesn’t happen on it’s own and you have to plan for it. I didn’t initially and it cost me extra time in porting and sub-optimal release schedules. It is not solely a technology problem. Marketing, PR, networking, advertising all need consideration.

If my goal is to make great games and reach as many people as possible with them, platform is mostly irrelevant. So while the app store might be harder to scrape a living off of, I think these days there are more opportunities than ever to sell your game. Consoles have become more attainable for a small indie team, Steam has become more accessible, iOS and android devices are more powerful than ever, crowdfunding can help lower costs, and engines like Unity and Unreal make it easier than ever to have your game run on all of those platforms. So if you’re just starting out as an indie and are dead serious about making a game, your choices are many. Don’t get caught with all your eggs in one basket.



As a game designer, one of things I try to avoid is creating disposable experiences. As any creative, if you’re making it for an audience, you don’t want it to be forgotten shortly after it’s introduction. Designing for longevity can be taken in two ways:

  1. You’re design is centered around story, atmosphere, characters, with less focus on mechanics. Mechanics are simply a vessel to get through an experience you’ve authored.
  2. You’ve designed the mechanics that can be seen in their fullest from minute one, and are deep and relevant enough to have replay value in and of themselves even in hour 300 of the game.

Neither is inherently wrong or right for mobile games, and both have their challenges. Getting longevity out of #1 puts you on the “content treadmill”. The amount of time you put into making a longer game vastly outweighs the length in which someone will experience it. This isn’t necessarily a bad thing, because if you’ve got the time and money, you can make some really awesome content. This problem of ‘length’ is more immediately solvable because the solution is throwing more content into the game (more levels, puzzles, characters, chapters, etc). Getting longevity out of #2 is an interesting prospect. Relatively, it can be dirt cheap to get a lot of fun playing hours out of a mechanically driven game based on a very clever premise that has depth to it. The gameplay itself becomes the content rather than the window dressing around the gameplay. Now the problem here is cost can be extremely high or almost zero, and it’s hard to judge which way it’ll fall. Approach #2 tends to have a very hit-or-miss R&D phase. You can spend days, weeks, or months trying to hone in on a deep new gameplay experience, but it could lead to a lot of dead ends. The costs of creating a new, interesting, and long-lasting game mechanic is very front-loaded and success isn’t guaranteed. But if you hit success, you’ll end up with a game that has a longevity that dwarfs any content-based game. That said, there are a lot of low-hanging fruits in the mobile space for mechanically simple but deep or satisfying games. As an aside, approach #1 is far easier to schedule for, while trying to schedule things in approach #2 tends to be an exercise in futility, at least in my experience.

The content-based approach I tend to see in a lot of  modern single player PC/console experiences. Mechanics aren’t king in this arena, but story, aesthetic, atmosphere generally are. Depending on your audience and environment people will play in, one approach can only get you only so far vs another in terms of player engagement vs development dollars spent. In the mobile space, atmosphere is hard to come by when you have to take into account that several of your players will not be playing in an ‘intimate’ setting with your game. They’ll be outside, half paying attention due to kids running around, waiting at a store/dentist/office/meeting, or even worse, playing your game on mute (talk about an atmosphere killer!). You can create a game oozing with story and atmosphere, but I feel it will be lost on these players.

That’s not to say a mobile game can’t be centered on story and atmosphere, but that niche (hah, I strangely regard it as a niche in the mobile space) is something you have to target and work hard to bring that message across when marketing your game. Having an audience and following that is detached from the top X charts I think is rather important in succeeding in this approach. On the other side of the coin, if you’re designing a mobile game with an engaging and simple mechanic, no player can ignore that. It’s fundamental to the experience of the game regardless of time, place, and whether or not their device is muted.

My personal preference, when designing mobile games, has always been to favor #2 above all else. Story, atmosphere, and aesthetic I almost relegate to the point of ‘polish’. How much polish you put in a game is limited by time and money. Game mechanics don’t really follow the same cost curve when it comes to production values, and that’s extremely important for any indie that’s on a budget to realize. With that said, favoring the 2nd approach definitely colors which kind of games I generally focus on designing. A lot of them end up in the arcade/action genre, some strategy, others some wonky mix or something new. Very few of them are designed to be level-based, character-centric, plot driven, or even puzzle oriented. I recognize some designers take a very character, level, or plot driven approach. Just one look at the games that came out of Double Fine’s Amnesia Fortnight illustrates that diversity in approaches. But I’d make the argument that the more atmospheric/experiential ones, while they may be applauded by the press will have an uphill battle on the mobile space, but that’s another argument for another day :).



I’ve been playing a fair number of board games lately. It’s interesting because the design of those games I feel are a whole different world compared to modern video game designs. In a way, I feel board games are a ‘purer’ game design in some aspects. You’re not tied down in presentation, cut-scenes, and other spectacle, and all you have to work with is a few widgets and a compelling rule set. If that rule set is boring, your players will never play again. Meanwhile, I feel I’ve played video games that hang purely on presentation, cut-scenes and spectacle in order to keep the player going. Arguments for whether this is a good or bad thing can wait for a later post.

Unfortunately, the vast majority of board games are multiplayer, so it might be seen as a bit easier to come up with really interesting rule sets because of the human element. In a single player game, where your AI is extremely limited, trying to force ‘interesting choices’ is a bit more of a dark art, but not unheard of (see Pandemic, Arkham Horror, etc). A lot of modern video games seem to have this arbitrary requirement that they must work with a single player, and as a result it seems the design tends to limit itself to what is possible in that context. Granted, this is the reality of the known market, so single player demand won’t go away. Although deep down I feel the multiplayer/social market is far wider, deeper, and more diverse than what we’re currently aiming for. The sorry excuse for games people tend to call ‘social games’ I think is only scratching the surface of what’s possible in the digital realm. Also I think the idea of having to segment out a whole area of games as ‘social games’ is amusing in my mind considering that I can’t remember a time when games weren’t social. The sad part is it’s starting to get a negative connotation, but I digress.

One interesting thing that has come to mind as of late is how board game design is becoming informed by player sensibilities. Video game developers and designers struggle for weeks and months trying to perfect the UI, tutorial, and imagery to make it easier for the player to manipulate the game and rule set. They do this in hopes that they’ll grab a larger audience, bring in new people to the fold, etc. This all works to an extent, and is sometimes all that is needed to bring a game from ‘obscurity’ to mainstream acceptance.

Yet, sometimes the rule sets themselves don’t allow for certain players to play and enjoy the game no matter how approachable the graphics are, how intuitive the UI is, or how easy to follow the tutorial is. It sounds so obvious when spoken, but I was never conscious of it while playing video games (multiplayer or single player). But when I started playing more board games I noticed how the social dynamics and temperaments of people deeply influenced the overall enjoyment of the game for the group.

The more popular games in my circle have been cooperative games or team games. Games that allowed players to work together tended to be the favorites, even among the ‘gamer’ friends. Some games have mechanics that allow the momentum of a game to swing favorably to one player and unfavorably to another. Sometimes the outcome is even unclear to both players involved, but the intent was always seen as a ‘mean’ thing. For example, having a player pluck a card from another player’s hand at random was hardly ever a happy moment for both. Other mechanics where players draw ‘action’ cards that do unfavorable things to the group or a particular player (what I like to usually call ‘bullshit’ cards) tended to be met with general hostility. If you take the analogous of this in video games you see this kind of design come up all the time. A player hits a power up and another player is arbitrarily punished (ie blue shell in mario kart), another player ‘unlocks’ an ability that leads them onto a slippery slope of dominance against sometimes an entire opposing team (see kill-streak awards in Call of Duty).

Now, is this a good or bad thing? In certain groups the competitiveness and ‘bully-mechanics’ can be seen as fun and hilarious at times, but I’ve heard comments from a few that don’t like the idea of “pillaging a player’s deck of cards” if that target player is their 6 year old son, or wife :). Given that the husband/wife and family demographic is a huge one, it seems there is a ripe opportunity there to take the lessons learned from  board game designers about player interactions and sensibilities and apply that to our own video games.

That’s probably the most non-sensical post title I’ve every come up with. Anyway, just wanted to  do a quick update post on Outwitters. I’ve got a few longer-form entries in the works but I’m letting them cook a little bit before posting. There’s a lot of moving parts right now in trying to get this game looking presentable, and all at different stages of completion. Over the next couple of weeks I’m focusing on getting this thing ‘feature complete’ so we can start iterating on the stuff we want to touch up on.

I just recently did an overhaul of our replay system. Before, you could only watch the previous round (1 turn for 1v1 or 3 turns for 2v2), and it required you to press replay to see it. The benefits:

  • Smaller data footprint
  • Simplified replay UI. The replay was short enough that there didn’t need to be anything beyond ‘play replay’.
  • Quicker access to the games. You either watched the replay if you truly cared about the game or if the game was still in the early stages you just played your turn and moved on

So those were nice things to have. But then we started having a lot of conversations between players and us that they wanted to see more info on how the game played out, and there was a desire from several that wanted the replay to automatically play when you loaded the game so you could regain the context of where you were in that particular game. I think it came down to personal preference as to whether a player wanted opt-in or opt-out replays, but we sided on the more ‘invested’ players who always wanted to know what’s up with their current game. We even noticed some players didn’t realize there was a replay function until we actually told them. In the end, defaulting to having the replays auto-load seemed like a nice compromise to allow the hardcore to keep tabs of the game and for new players to become familar with the functionality.

On the topic of data footprint size, I wasn’t concerned that much because our game state data is tiny to begin with, so that was kind of a weak plus. So expanding to ‘full game’ replays wasn’t a big data size hurdle. Now, with the UI that became a much more complicated affair, both technically and design-wise. We were moving from a simple, single button to a full-fledged UI with a tool bar and other data to display. I hated the feeling of that. But I think we were able to keep it looking simple enough (despite the crazy technical details in the background to keep it all running smoothly), so I was happy with how it worked in the end:


It’s always amazing to me how an outcome can look so simple but the details are so complex behind the scenes. If this was a single player game, then changing data format is not a significant matter. But given how online-centric Outwitters is, changing replay formats has huge implications to the game’s protocol with our servers. So adding this ‘full game replay’ functionality affected client side gameplay code, UI code, and backend server code. Phew.



I’ve been slacking lately on the blog unfortunately. In any case, Outwitters is still chugging along as I chip away at a large to-do list. We’re still not feature-complete, which is a bit disappointing. Yet, the core game is playing more smoothly than I predicted it would be at this stage so that’s a plus. We’ve started adding a few more testers into our pool to get more feedback from new players as well as get the matchmaking ironed out.


So one of the ‘big’ features I’m really liking is the matchmaking we’ve created. It’s no Halo, but I think it’s turning out great for a mobile game. A quick rundown of what it’ll do:

  • When you first start out you play a few ‘placement’ matches. This is done to try to get a decent read on your skill level before throwing you into a league.
  • When you finish your placement matches you are put into a league. The leagues all have silly names, but they range from the low-level casual player skills to the high level competitive skill range.
  • When in a league you are competing not against everyone in the world, but only a small subset of players in a single ‘division’. This has some nice benefits in encouraging players to do better. Being ranked 40 instead of 40 million is a slightly better feeling I imagine.
  • As you play, your rank goes up and down on that division. If you start doing really poorly you may be moved to a lower league to find better suited opponents. If you are stomping people left and right it’ll push up to a more difficult league.

For anyone that has played Starcraft 2, it’s not all that dissimilar to their system. Couple of things started to arise when we started to have a few more people join up. One issue was the algorithm for placement. I think it’s too aggressive right now and it catapults people into really high leagues with barely any wins. I think I’m going to be redoing the placement league point calculations.

Secondly, the match finder has two somewhat opposing goals. The first goal is to find someone of a similar skill level to you. The second goal is to find a match quickly. When your player base is sparse, the ‘quick’ goal tends to prevail more and more than the skill level goal. The steps it does to find a game are pretty straightforward:

  1. Look for someone within your skill range
  2. If it didn’t find a game, expand our skill range and look again
  3. Screw it! Find *ANY* game and join it.

and theoretically if the userbase is sufficiently large there should be a diverse set of games waiting for players to join, so it should balance out. But I can’t assume Outwitters is going to have a huge player base :). The 3rd step is what fulfills the “quick” goal. The problem is when the game is just launched, lots of players are joining but their skill levels haven’t settled yet, so match finding will rarely find ‘similar players’ at the beginning and always fall to the 3rd step. This will lead to some frustrating games for the lower skilled players. Right now I’m planning on adding a time constraint to step 3. It will look for any game that has been waiting for a player for at least X days. That way when a large influx of players start playing, this will help increase the ‘waiting pool’ to search through in steps 1 and 2. The downside is you may get more matches where you are waiting for someone to join in the early days of the game, but someone will eventually join.

Asset Pipeline Lessons

At one point I would have called our work flow a pipeline. Now it’s more like a laundry hamper where I’m throwing a bunch of assets into folders, sorting them, running scripts on *some* of them and not others, and *then* manually going through the ‘broken’ assets and fixing them (more on this later). When I initially designed a lot of our scripts, it was with in-game assets in mind. So the artist didn’t need access to them after-the-fact. But we’ve gotten to the point where we use these scripts to generate assets for UI layouts that are done in flash. So the artist does need the output in a timely manner so he can keep working. And on top of that, the flexibility to only generate the assets that he needs at that time. The system I setup was designed with an ‘all or nothing’ mentality. Seeing that I didn’t care when the scripts were done and didn’t expect them to be needed in a hurry, a lot of the build processes are very rigid and just blast through our entire asset library re-generating things from scratch.

I’ve done a lot of tweaks/hacks and config file augmentations to support some of the things we need it for on a daily basis. But I’m just taking it as a lesson learned and when we start our next project I’ll have a better understanding of what our asset build process should be capable of.

In regards to ‘fixing’ broken assets, I was having some issues with tga and png files being corrupted. I run a windows VM on a mac. There are some cmdline tools that are windows only that I use to process our images. Since the VM sees my Mac’s asset folder as a network share it can gain access to them without any tedious file copying. The problem is accessing the mac folders is very slow. And I guess some of these build tools don’t like that and end up corrupting some of our files. I had to revert to tedious file copying to copy stuff into the VM-only directories and got a massive speed boost on the processing and no more corrupted tga or png files. Hurray! Kind of.


I’ve been slow on the blog updates lately mostly because the times I use to write were taken up with me being out of town. Just got back from an awesome weekend trip at MLG Orlando. For those that don’t follow that area of gaming, MLG stands for Major League Gaming, and is essentially a league for professional gamers to compete in. Starcraft 2 has taken off in a big way in the MLG, considering only a little over a year ago MLG was pretty much dominated by Halo and Call of Duty. Seems the SC2 crowd is dwarfing the other competitive games at the show. So gooo SC2!


Taking a picture with pro sc2 gamer EG's Chris 'HuK' Loranger. Happy after coming off another win in the tourney I'm sure.

Anyway, to relate this to indie development one idea that struck me was how similar those involved in sc2 competitive play are to indie devs themselves. Most likely other professionally played games are like this as well, but I can’t speak for them directly. Even more interesting is the fascinating stories of those that don’t compete directly but are community figures and support the community in other ways. Casters such as Sean ‘Day[9]’ Plott, Nicolas ‘Tasteless’ Plott, Dan ‘Artosis’ Stemkoski now make a living off of their passions in a career path that barely existed 5-10 years ago. They now all often commentate pro matches and serve as hosts to Starcraft events around the world. It’s one thing for pro gamers to make a living playing games professionally. Pro gaming was on the ‘fringes’ years ago, but is becoming more viable these days. But to think that people such as casters, and even popular gamers who stream their gaming sessions (such as Steve ‘Destiny’ Bonnell) are now doing these things full time is mind-blowing. I would almost call that the epitome of the ‘American Dream’. Taking your passion and then pursuing it to the point where your passion becomes your means of living, even if a there’s no obvious or immediate way to make a living off your passion. Indie devs certainly fall in that category, but it’s a tad easier to swallow that a developer makes a tangible product and then sells it, which is more in line with a standard small business lifecycle these days. These guys, they are the product. Pretty fascinating to think that their careers revolve around a single video game! Now I say almost ‘American Dream only because half these casters don’t even reside in the US, they live in South Korea and are apparently loving it. Getting to travel the world, attend global tournaments, doing what you love? That’s a win in my book.

In other news, Outwitters is still deep in development. Finally got the universal build up and running but the iPhone version is still rough around the edges. Hopefully after things start to stabilize we can start testing with a wider group of testers. I had a game with Adam earlier this week that I was certain I would win, only to lose…yet again. Maybe one of these days it’ll click with me and I won’t appear to be strategically retarded.

Oh, It’ll Be Out By….

Hmm, even now as I look back on what’s been done on Outwitters, I’ve learned a *ton* of new things in regards to game development. I’m not too excited about having only 1 game to release this year (if we even make *that*). Hell, we even planned on having 2 games a year. The take-away from that is game development is not an assembly line process. Going into Outwitters I:

  1. Never coded a turn-based strategy game before
  2. Never worked on an asynchronous game before
  3. Never worked with Google App Engine
  4. Didn’t use unit testing prior to this game
  5. Never worked with push notifications
  6. Never worked fully in C++ in a commercial project before
  7. Knew little of JSON and it’s benefits
  8. Hadn’t used Actionscript to the capacity that I am now
  9. Haven’t touched Python since freshmen year of college (omg I love python again)
  10. …and several others

Looking at just that list above, which isn’t even scratching the surface, it was dumb to think I could predict *any* sort of release date prior to starting this project. Unless you’re phoning it in game after game, or the game has a very small scope, or you just have many years of broad experience working on several different kinds of games, platforms, and genres, scheduling is almost silly to think about. Having only been doing this for a couple years, I’m far from the “broad experience” category. There are a few constants in game dev, such as getting your boiler plate code, foundation, or engine ready to go, or a super basic prototype up and running, but beyond that it’s just a hazy mess for me at the moment.

The great thing is now I know a decent amount of everything on that list. If we were to do another asynchronous TBS game for iOS, scheduling would be far less hazy. But that’s the dilemma. I sure as hell won’t want to dive into another “Outwitters”-like project after this for a while. I get excited about new games and new ideas (most involving multiplayer to boot). I’m interested in things I haven’t tried before, and as a result, they’ll always be difficult to estimate length of development, but the challenge is what makes it fun for me. Even if we were to revisit a previous game and make a follow-up, I would want to add or change something about it that would make it unique, because that game is already a “solved problem” and is pretty much just grunt work from start to finish with little thought involved.

Outwitters Battle Report

This week I finished up implementing custom games into Outwitters. Outwitters was designed to be played with friends, so it’s kind of weird having this feature come online so late in the game. Our Leagues and Ladders system works with 1v1, but we wanted to make sure to have 2 vs 2 in there as well so you can still take on the world with a buddy. Things are always more fun with a friend in tow :). Custom games are just a way for players to create their own games with their own settings. They can choose who is in the game, who is on what team, and the map. The league system tends to take over a lot of those choices to make things a bit more ‘standard’. Wins and losses don’t count in custom games, so it’s a nice place to try out strategies or just play with friends casually.

Speaking of leagues, the matchmaking and ranking system is finally online as well. It’s not too interesting to look at yet since the player numbers are still very low. At least not my profile, since i have zero points and can’t win a game to save my life. I’m apparently strategically challenged when it comes to these games. Probably explains my horrible performance in Starcraft 2. I tend to be impatient and like to throw my army away like lambs to the slaughter when the engagement heavily favors the opponent instead of me. Oh well, there’s always Battlefield :D.

This following post is probably going to be useful to an extremely niche audience: anyone developing a multi-user iOS app that has a GAE backend. I’m currently working on Outwitters and debugging turn-based games on the local dev server (dev_appserver.py) is really quick and painless. The problem arises from the nature the game. It’s a multiplayer game, and as such, requires multiple users to function. You can only go so far with creating ‘mock user’ accounts, and fake data populating your local server. With each build I always find some sort of issue that the alpha testers stumble across that may not be server-related but the gamestate that the “production” server is holding is something I want to grab and debug with locally. Wouldn’t that be nice?

So when you run a local dev server the command is pretty simple:


dev_appserver.py pathToCode


Not bad. Now if you want to access it on your machine you simply do an http request to localhost:8080. The problem comes in when you’re developing for a mobile device. The dev server is no longer at localhost but on some local LAN IP. That’s a pretty easy fix too:


dev_appserver.py –address 192.168.1.x pathToCode

Now in your iOS app you can send requests to a local server. We’re in business, awesome! So you want to download the data from your hosted application over at appengine.google.com? Pretty simple. Uploading it is pretty straightforward to if you use the –url option with “appcfg.py upload_data”.

Now this is where I ran into problems, and I couldn’t find a clear cut answer as to why uploading data to my local dev server was simply not working. It would ask for credentials, and no matter what I put, it would fail. Hopeless. I used all sorts of combinations of my local address and ports for the –url flag for appcfg.py and tried countless combinations of any of my known logins for both appengine and my local dev machine. I then decided to go back to basics, and follow their instructions exactly. I downloaded the production data as documented. Then I launched a clean dev server with no command line options. It worked as advertised! I had all the data frolicking about inside my dev server, but I couldn’t access it with any of my iOS devices. Without the address option, the dev server would launch with localhost as being it’s address, and no other device could connect to it.

So after banging my head on the keyboard for a couple hours, and not being able to find any answers as to why upload_data only works to a local dev server if you’re running on localhost, I found a round-about way of getting production data into my own iOS friendly dev server:

  1. Download the data as per the documentation
  2. Now launch  dev_appserver.py, but this time declare a datastore path as a command line argument. This is the –datastore_path= option. Also run it with a –default_partition of “” (empty string), to mirror production’s data.
  3. Now that you have a dev server running on localhost with a defined datastore file, upload your data to your dev server with appcfg.py (by using the –url option pointed to localhost).
  4. Once uploaded you can now shut down that server.
  5. Now run a dev_appserver with the commands that you usually run with (the –address flag), but add a –datastore_path pointing to the datastore file you used in step 2.
  6. W0ot!
A lot more cumbersome than just doing a simple download/upload routine to test stuff locally. Of course, I may be missing something entirely as I’m still relatively new to GAE, and there may be a way to do this with a local dev server that is running on an actual LAN ip instead of localhost, but I haven’t been able to find it. Hopefully this will prove useful to those using GAE for their iOS apps as well, or they’ve found a better way to do this and can leave a comment :).

We’re still balancing Outwitters gameplay. When thinking about changing, removing, or adding gameplay I try to keep two aspects in mind, choices and unpredictability. I’ll speak to the choices aspect today, as I’m still trying to grapple with that whole unpredictability thing in a turn-based perfect-knowledge setting. When we set out to create Outwitters, we wanted to make a simplified strategy game. One where players can easily pick it up much in the same way they pick up an iOS arcade game. The reality of the situation is this has become extremely difficult to achieve. I have a strong hunch it’s harder to do in our game due to the context in which our players are using strategy. It is essentially a “war” game. Players do battle with each other over vivid, colorful venues with fun-looking characters. The overall goal is simple: Destroy the opponent’s base. But the way in which you achieve this goal can be complex. If we make the choices too few and too simple (ie, with the arcade game mentality) the game itself becomes uninteresting very quickly even with a human component on the other side. Just about every “enhancement” to the gameplay we think of adds complexity to the game rules or mechanics. It adds “potential” fun to the initiated, but raises the barrier to the uninitiated. I feel there could be a strategy game idea out there that isn’t centered around battles/violence that could exhibit arcade-style ease-of-play but still have an interesting depth to it.

The Scrambler overtakes enemy units and makes them change to your team

An example of making player choices too simplified can be found in an earlier build of Outwitters. In Outwitters each player has a team of characters to choose from. Each team shares 5 of the same units (just different looks), but 1 unique unit to that particular team. Each turn a player has the choice to move, attack, or add a new unit to the game board based on points the player can spend per turn. In an effort to simplify the game, we made the cost of adding a unit to the board the same for each unit. Every unit cost the same, even the unique ones. We thought removing the barrier to learn how much each unit costs helped make the game rules easier to digest, and also focused more on what units you chose to spawn (strategy) rather than trying to manage your points. We found a couple of issues with this approach.

Firstly, this limited the effectiveness of any particular unit. We couldn’t make any unit be greatly powered in one particular aspect, especially the unique units, because they would instantly become the dominant strategy. Since every unit “cost” the same to acquire, the units had to be somewhat similar in damage and range capabilities. Secondly, because no unit had no obvious advantage over another, newer players floundered in picking the “correct” unit to add to the game board for a particular strategic situation. When players became experienced with the game, they understood the nuances of each unit and started using them more effectively to gain that little edge they needed to get the jump on another experienced player. The problem with this? You had to become “experienced” to have a decent understanding of the unit choices.

Bombshell is able to do splash damage to several tiles at once

So we decided  to change a couple of things. Our original idea for Outwitters was for players to choose their favorite teams not just on aesthetic choices, but strategic ones as well. The current state of the game was heavily in the ‘aesthetic’ camp for team choices. We made the unique unit for each team cost twice as much, and also made them much more powerful. This had a positive effect in that it made unit choices much clearer and focused for newer players. This extended even beyond the unit choice screen and into the overall playing strategy of the game. Before this change, I’d see new players just do random moves because they really can’t see how their actions would effect the game beyond a couple of moves. Introducing, for simplicity’s sake, a “hero” unit, players began to focus their strategies around that unit’s strength. It’s what we wanted to begin with! Players clung to their hero units because:

  • It cost a lot. The loss of a “hero” unit was painful.
  • That hero unit’s actions clearly implied how it’d effect the game. If a hero unit could do 2-3 times as much damage, or transport waves of units across an entire map, or take over enemy armies *easily*, the player can easily make the connection and think, “hey, this is an easy way to attack the enemy’s base and win”. Before this change I felt like the answer to attack an opponent’s base was far less clear for inexperienced players.
Giving players that super strong unit gave them a focal point. Sometimes it may not be the most ideal strategic focus, but it’s a start for newer players. The downside? I feel that we  gave up some elegance in the game rules in favor of depth. The very thing I cited earlier where just adding more rules generally makes a strategy game more “interesting”. But on the up side, the choices a player makes is now clearer. It’s been a difficult task to try to simultaneously minimize the number of choices a player can make,  make those choices relevant and clear, and to maintain strategic depth to the game.

Mobi can "launch" units towards the enemy base by sucking them in and spitting them out