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

My first week off the iDevBlogADay rotation and I miss my usual Friday post. Go me. We’ve kind of hit a period where a lot of work is getting done, but an ever growing mountain of work is coming up on the horizon. Polishing a game is hard. Polishing an online turn-based strategy game is really hard. The simplest things take 3-4 more extra steps to do whenever you incorporate a server into your game’s architecture. Noted. Turn around times are my biggest hurdle due to the larger scope of the game and Xcode’s stupid way of managing resources. Left to it’s own devices, it doesn’t copy new bits every time, so a work around is to essentially ‘touch’ the root folder to have every resource re-copied on every compile. The downside? Long deployment times due to a huge number of assets. To help mitigate this I wrote in some asset hotloading into the engine so  I can iterate on UI a lot faster. It was definitely worth the day of implementation.

And now, I’m starting to see the value of unit-tests even though I’m not doing them yet. In prior games, the code base was small enough, the turn-around time so quick, and the permutations of input so limited, that it was the same amount of time, if not quicker, to simply run the game, test the UI or mechanic, and fix it. But now, the actual game logic complexity is growing so much that whenever I’m met with a new thing to implement or test I get a sense of dread of how many turns it takes to setup a game board, execute the test, and when it inevitably fails, debug it and try again. I don’t think it’s too late for me to start doing unit-tests, so I think I’ll get that going. The game’s setup I think lends itself well to unit-testing since all the game logic happens separate from the visuals. I don’t think it’ll be completely necessary for me unit-test the visual stuff (due to the nature of the thing), but having just a few unit tests covering the game logic will really help test those obscure edge cases that would be a pain to test manually, as well as help stop regression (which is already happening)

Now I’ve tried doing unit-tests before in older game projects and hated it. Why? Because I didn’t get the sense that I was  getting much benefit from it versus my old way of just running the game. it just seemed like an exercise in typing more code.  It’s interesting to note, that a lot of the advice one hears from devs about the more mundane tasks of game development (hot loading, unit-tests, asset pipelines) become this ‘awesome thing’ that saves the day when you finally hit a point in your development cycle that would tangibly benefit from it. Academically, I was told repeatedly to write unit-tests. In the “real world”, I saw no explicit need for it, until now. So I guess the takeaway is don’t blindly follow other devs’ mantras unless you can see where it makes sense, but be knowledgeable and aware of them. In the case of unit-tests, it didn’t start making sense until last week when I was seeing how much time I was spending “playtesting” the game for bugs and such. Experience is the best teacher as they say.

I’ve been making a ton of progress on Outwitters lately. Although when I step back and look I still see a mountain of work left to do. But I *do* feel like I’m whittling away slowly at it. All of the core gameplay has been implemented for local play. Online play works in a non user-friendly manner and is still missing a few bells and whistles to make it stand apart from the typical affair. I always recognize this stage of development as when the game starts transforming from a toy/prototype/hobby into a commercial-ready product. Most of the ‘fun parts’ of game development are behind me (Although I’ve saved a few for the rainy days ahead), and now it’s about focusing on all the less glamorous parts of making it a usable, marketable  game. Things like player preferences, profiles, UI, first-run initializations, etc are rising up on my to do lists these days. Oh, and lots of testing/debugging. Very much your typical software development role. At a glance, very similar to any given dev job in the business world. Only thing is my object models have cannons, health points, and spells instead of accounts, transactions, and employee data :).

One thing that has constantly surprised me is the amount of data we’re dealing with this game compared to Tilt to Live. It’s immense. A quick file count shows there’s about 3500 files in our ‘data’ folder, which contains images, sounds, maps, and animations. The tools I wrote work on game data in kind of a ‘macro’ view, where editing one, it goes ahead and updates all affected files throughout the project to maintain links and references. Without our tools/scripts it literally would’ve been impossible to iterate on anything. Sometimes it’s aggravating having to go in and ‘fix’ a tool or update it to reflect a new data format change where it’s sometimes easier to just edit that *one* file. But by constantly having the mentality of trying to keep human hands out of the asset pipeline beyond the actual drawing and designing, I’m always reminded it’s worth it when I launch 2 scripts, and come back 2 minutes later and all assets are packaged, sized, meta-data generated, and placed in the xcode project directory ready to be deployed.

I also suppose this is my last iDevBlogADay post, or at least until the new incarnation takes place. With or without iDevBlogADay I’ll be keeping to this bi-weekly schedule as best as I can. Hopefully, after Outwitters is released I can write up a bit more useful content beyond just a dev diary :).

Wow, Friday almost flew right past me. I’ve been working on Outwitters practically non-stop. A lot of the major ‘components’, as I like to think of them, have been figured out and implemented in some sort of fashion. Now I have to make this big herculean effort to get it all integrated and seamless:

  • 1v1 and 2v2 pass-n-play
  • A couple of teams and their animations and unique powers
  • The ever crazy complicated (implementation-wise) UI
  • Asynchronous play using Google App Engine

Aside from team animations/powers, all those things exist in kind of their own isolated ‘prototypes’ in one way or another, and now I’m trying to get it all under one “roof”.  Our 1v1 and 2v2 pass-n-play are fully functional. We’ve had a few playtests of the 2v2 game mode with family and friends and it’s been a sigh of relief to see them genuinely enjoying themselves. Sometimes, you don’t have to look at the actual game to see if the player is ‘getting it’, just looking at their laughing faces as they all play against each other is vindication enough that you’re on the right track. The bigger task at hand his trying to make this game as close to engaging as possible in the asynchronous model as it is when in a small group of players. Realistically, we’ll never achieve that, but it’s something to shoot for.

In other news, I got my standing desk in the beginning of this week and I’ve just finished my first week of ‘standing’ while I work with my new desk. I tried it out first for a week with a small glass-top high breakfast table and liked it enough to invest in an actual standing desk. Of course, I’d like to sit in the evenings so having something adjustable is extremely handy. Noel Lllopis had mentioned his foray into this work style a while back, so I took his and several other dev’s recommendations and went with a GeekDesk, and I’m loving it. With just a couple of weeks of doing it, my back doesn’t feel completely owned every morning when I wake up (I have a bad sitting posture). I find that whenever I’m brainstorming, or thinking about a problem I tend to pace around the room or go to my whiteboard to draw stuff up. While standing, this feels a lot more natural and I tend to move around a bit more during the day. Another plus, is during the mornings I’m finding I’m a little more focused on getting through some of the less enjoyable parts of the job like managing money, bug hunting, etc.

Unfortunately, I don’t have much else to share at the moment other than Outwitters is shaping up to be pretty freaking cool. Only time will tell if we’ll be alone in that opinion.


Keep in mind, a lot of the rambling below is in the context of me being neck-deep in working on Outwitters, which is a strategy board game. I’m constantly thinking of ways to present games, their systems, and their objectives to people. Notice I said people, not gamers, or casual gamers. Sometimes I even look around my own environment and question “why the designer wrote that message the way they did”. Sometimes it’s obvious they gave little thought to the message and scribbled it on some printer paper for all to see on their store front. Sometimes it’s spot on and even clever. Other times, I question their decisions:

I’m constantly always surprised by how confusing traffics symbols can be. When your speeding down a new stretch of highway at 70mph you don’t really have a “2nd try” at figuring out what a sign means. Sure, the locals all know that this exit sign is mis-labeled or too close to the actual exit to realistically act upon it, but I’d argue those signs should be made with an emphasis on new people to the area.

The Mistaken Non-Gamer

In any case, I think about this habitually, but sometimes I wonder if it’s even making a difference to a certain segment of the potential audience. I can really only speak from personal anecdotes, but I’m starting to think reaching out to the “non-gamer” crowd is less about how well your UI is designed and more about how socially engaging it is. I will use my mother’s gaming habits, for lack of a better example.

She will not play a new game on her own accord. She does not seek them out, and the usual ‘marketing venues’ one would use to garner an audience for an iOS game completely bypass her and her demographic. I can hand her a game, but she will ‘demand’ that I tell and show her how to play it. If I walk away, she’ll lose interest. If I stay, she won’t bother with tutorials or help menus and simply ask what to do next. For her, games are social experiences and she has to be ‘introduced’ to a game by another physical person who already knows the rules. But once she does understand the game, she’s no less engaged or competitive than a ‘typical’ gamer. Am I crazy in thinking there’s a large segment of the audience like this that is incorrectly labelled as a ‘non-gamer’?

No amount of well though-out UI design, tutorials, or marketing will capture this kind of person. Is this why Nintendo struck gold with the Wii since the vast majority of their mega hits were multiplayer-centric wii games? Were they able to tap the “non-gamer” market by selling an experience that was championed by the gaming enthusiasts who brought home these devices to their curious “non-gaming” family members?

The “Gamer”

Then there’s the typical, mainstream view of a gamer. He/She isn’t afraid of new systems or paradigms. In fact, they seem to be curious and love trying out novel ideas, and don’t require another person to introduce them into the game. When something confuses them, they don’t throw up their controller in frustration, or look to a friend to get an answer immediately. They fiddle with the controls, dig through the menus, and sometimes even go online to find an answer. To them, a well designed UI means something and there’s a tangible benefit in reducing the friction to learning how to play the game.

I imagine they have their limits though, present them with a genre they feel they don’t care for and with a ruleset that takes a little more than a minute to understand and they’ll probably walk away from an experience that might’ve actually been pretty fun. Or, hell, get a console gamer to try to install, setup, and play a PC game and you’ll see what I mean, all before they even get to run the game.

Then there are hardcore gamers who just love the idea of solving problems. Games in themselves largely revolve around this fact, and anything inside or outside the game’s fiction is a problem waiting to be solved. This sometimes borderlines on ‘geekiness’.  Picture the guy that will tinker with his computer for hours to get a game to work. No amount of rules, or depth will deter them from at least trying to get involved in a game they see as potentially enjoyable.

These kind of gamers can introduce games to “non-gamers”, and the great social experience that results is better for it.

Now Back To Design…

For the iOS platform, who do you design for? It seems trying to come up with clever ways to engage the mistaken non-gamers through tutorials and UI won’t help them directly as they depend on social interactions to guide them through a game. Think of new players playing a board game for the first time with family or friends and how that interaction ensues. This is where they get most of their information. Yet, if you design with the ‘non-gamer’ in mind, you’re helping the actual gaming crowd gain easier access to your game, which hopefully will result in them being the person that introduces this game to their friends and families. In a weird way, you’re designing systems and interactions to help someone become a living tutorial for your game.

Does this mean if you wish to target the “main stream”, and as a result, the widest audience, that you should be designing games with social interactions being the core of the experience? It seems a good number of the recent iOS successes are building off of this idea. Given the pressure in most gaming enthusiast circles to always have some sort of solo experience built in, do you even bother with it knowing that most of your “non-gaming” audience doesn’t even care for it? For example, is a single-player mode for Monopoly really necessary? I could never envision my family or friends playing on their own, but put them in a room together and it’s usually a great time.

It’s all interesting stuff to think about as I look at how Outwitters is shaping up to be versus how we originally envisioned it so many months ago. The social experience I think is absolute key in making a game like this widely approachable.



Tomorrow (June 18th) marks the first year anniversary of me becoming a full-time independent game developer. Wow did the time fly by fast! Over the course of the past year I helped launch Tilt to Live HD, Lite, a couple of major gametype updates to Tilt to Live for free, a paid Viva la Turret update, and finally released a multiplayer co-op mode for both our games. When I think about it that way, it’s definitely been a busy year. I sometimes forget how much content we added to Tilt to Live and Tilt to Live HD, and sometimes I think to myself “man, it’s been almost a year and all we’ve done is 1 game…”.

I don’t think I could think of a more full-filling career than a independently creative one as this. I set my own hours (admittedly probably too many hours), I take days off when I feel I need to or want to. And one of the most fundamental changes I’ve noticed over the months was how I’ve lost track of holidays and weekends. Now that I wake up to go to work (rolling out of bed, freshening up, and walking into the next bedroom) eager and excited for today’s challenges and problems, I’ve found I don’t even care what day it is anymore. In school, and in previous jobs, it was always hard to not think of or be reminded of the next upcoming weekend or holiday. It’s as if people’s lives revolved around them. While I still look forward to weekends because most activities with friends and family tends to be on those days, but I guess I don’t have such a severe case of the “Mondays” as I use to :).

Looking back, if someone was wanting to go the full-time indie path with iOS in mind, what would I tell them?

Don’t chase the fads

If you’re trying to ‘one-up’ a current trendsetter, you’re not ever going to be the trendsetter. Everyone knows about Angry Birds, but you’ll never get that kind of mindshare trying to out-do Angry Birds. It seems to ring somewhat true the iOS market rewards games that bring a bit of something new to the table or ‘best of class’. Games that are top of mind that bucked the trend and did their own thing would be Pocket Frogs (talk about being a trendsetter :P), Casey’s Contraptions (this game fits so well with the iPad, it’s hard to see it not succeed), and Tiny Wings (bird themes aside).

If you have an idea that is a really interesting twist of a current game genre, or a game idea that you haven’t seen executed with much success on the app store you should probably try giving it a go. If the game flops, you’re in the same position as someone who made a ‘trendy’ game and flopped. If it succeeds, you own that niche and the rewards, emotionally and financially, can be great. With that said, don’t be different for the sake of being different. Anyone can look at Tilt to Live and see the obvious influence of Geometry Wars in it. What made it stand out? It used the device’s novel hardware to the fullest, had a non-typical art style for that genre and Geometry Wars wasn’t on the app store yet (phew). Outwitters is the same deal. There are plenty of turn-based strategy games out there already. We just haven’t seen one with our particular brand of humor and art style with a focus on simplifying the strategy element rather than trying to make it artificially deep with tons of units/choices. The takeaway is make the game that you want to make and think could succeed, not the game that the top 10 charts are telling you are currently succeeding.

Shipping a game is half the battle, and I’m not talking about marketing

Marketing and promotion aside, the iOS market has a very different set of expectations when it comes to games. The PC/Console market is very ‘packaged goods’ and ‘pay once’ oriented. We started out with that mentality thinking we would ship and move on. Yet, we’ve submitted probably over 10 updates to Tilt to Live alone, the vast majority of them adding major pieces of content and actually changing the game. The Tilt to Live at launch is no more, and Tilt to Live of today is a rather different game. We added multiplayer in Tilt to Live a year after release. People expect that their games change, and for the better. When scheduling time for a game development cycle, the ‘ship date’ is far from the end of that product’s life cycle. Pocket God is the poster child of embracing this kind of thinking.

The challenge for the developer is trying to find a way to make this sustainable. I think developers are starting to catch on that there is an audience willing to pay for the extra content, so that they can fund even more content for the games that they like. If you’ve got something on the app store people are liking and clinging to, give them more of it! We added a bunch of free content to Tilt to Live, but before moving on we wanted to give players a chance to experience one more idea we had in our heads, but without funding it just didn’t seem feasible so we charged for it. Despite all the flak from the vocal minority, it was successful. Successful enough for us to take the time to update that new gametype with it’s own Co-op mode as a free update. Free updates helps build endearment towards the developer, but it’s a two-way street. Let your customers help support you as well, it is a business after all.

Your first, second, third, or even fourth game won’t “succeed”

It’s hard to speak to this point because I got extremely lucky with Tilt to Live being our first iOS game and also being a decently successful game that allowed me to launch my full-time indie career. But with getting to know other devs in the community, and watching their trials and triumphs, there seemed to be one common factor between the ones that did “succeed”, and it’s not giving up. As cliche as it sounds, it’s hard to overstate that trait. I’ve seen several times throughout the year, a dev that stuck to their guns and eventually one of their games hit a sweet spot and became successful. The ‘overnight success’ I think is a myth that the media tends to give too much credit to and is easy to fall in love with. If you look at the history of just about any of the top selling games on iOS, you’ll find more often than not this person or team has been doing this for years prior, and sometimes in complete obscurity, like us. I’ve had communications with some devs over the months after they launched their first or second game, and then slowly disappeared from the community after those games weren’t break out ‘hits’. I was on about a month long dev cycle for each gametype update on Tilt to Live. I actually believe that had we released each one of those game types as stand alone games, the only one that would have any chance of success on its own would probably be Viva la Turret. So I tend to think of those other gametypes as our small ‘failures’ in a way as they never really became more popular than Classic or Code Red, but we were sheltered from disappointment because they were a ‘side dish’ to the main Tilt to Live game. Not everything will stick, you have to try hard to stay motivated through the ‘low times’.


So here’s to hopefully another wonderful year of the indie life!

It’s been a rather busy last couple of weeks. I’ve actually had a few coding sessions at night, and that hasn’t happened in months. Been having a blast working on Outwitters and we’ve been play testing maps on a weekly basis.

In other news, Craig and Gavin, of Retro Dreamer fame, recently released their Velocispider iphone/ipad game. If you haven’t checked it out by now, then you’re missing out on some good old-school arcade fun. What’s impressive is how quickly that game came together :). I believe they had mentioned it was about a month of development? Man I wish we could crank out quality games that fast. Maybe we’ll try that after Outwitters to help ease us into something less ambitious.

Back in Outwitters land, I just recently got sprite animation implemented into the framework. Having the characters comes to life on the gameboard is pretty exciting. I still need to write a state machine to manage the different animations for the characters, and that’ll take some effort.  Speaking of state machines, one of the initial problems I had to solve was how to implement Outwitters’ core game logic.

In a traditionally academic solution, I initially just wrote a state machine that has the different states of gameplay and transition functions to drive the game forward. On my first run through, the game was working but it was extremely painful adding new rules, tweaking rules, or removing rules to the game. It became a huge mess. I could see writing a ‘graph-based’ state machine would be really complex in the long run. I started to see if there was anything written on turn-based games architecture, and I came across this really helpful post on stackoverflow.com. It described a really elegant way to express game rules without having to couple them with specific ‘states’ of the game in a sequential order.

I took the advice of that post and re-wrote the game using the Command pattern described. It’s been a big win for me thus far in not only implementing the prototype, but helping to quickly iterate on game rules over play sessions. Instead of thinking of all the ways a game state can transition I became more focused on the discrete actions a player can make in a game and thinking of all the conditions that need to be valid (or invalid) in order for that action to be legal. This became much more flexible when iterating, as the logic for actions was isolated to single actions, and changes to them didn’t ripple throughout the whole game’s ruleset. Some of the more complicated conditions for actions were a bit challenging, but far more readable than if I had written it the ‘old way’.

Another nice thing that comes out of this design is the ease of serializing actions and game states. Instead of pulling in a bunch of random data from within the game to create a coherent picture of the game, I ended up creating a single class that encapsulates the status of the game. It’s fairly lightweight, and gave me the added benefit of having a central object to query for information about the game. Adding asynchronous play and saving the game to disk were very straightforward.

I have gone with a component-oriented design for the game objects in my framework. So render components are attached to lightweight gameobjects, and any other special functionality is wrapped inside another component and attached as well. In the past, game logic was usually decentralized throughout the components, as the games tended to be more open-ended with very little structure enforcing the flow of the game (for instance, platformers, and even Tilt to Live). I almost went that route again for Outwitters, but the design used to enforce the rules of the game were at odds with the decentralized component design I was accustomed to. Fortunately, the way things panned out was my components ended up being the ‘View’ and ‘Controllers’ of an MVC model, and the central game state object being the model. When the model changes, events are sent out to my components to update health huds, change character colors, etc. It can get pretty verbose at times, but I’ve loved the fact that the game logic is isolated from how things are positioned on the screen or rendered. It’s helped debugging a great deal.

In the end, the command pattern I’m using for the game rules is still in essence a state-machine, it’s just organized in a very different manner than the common “updatestate(), getNextState()” mentality.

About two weeks ago I mentioned I was looking into using the open source library, gameswf to integrate into our little 2D engine for iOS. I was at the point where I needed a UI solution for Outwitters, and I had a few options:

  1. Keep doing what I was doing with Tilt to Live and create the UI by handing coding everything and procedurally animating it
  2. Create a UI editor to help automate some of the UI features I had created in Tilt to Live
  3. Look into gameswf and see if I could go for the whole she-bang and just use Flash for the UI.

I’m happy to report the gameswf seems to be doing just dandy on iOS. When researching, I was hearing a lot of complaints on performance and compatibility (it’s only compatible with actionscript 2.0), and if you’re using a lot of complicated vector shapes you can bog down the FPS. Well reading the post date on a lot of those articles I found that some were pre-dating the 3GS! So in the end, I just put aside a week to mess around with gameswf on an ipad 2 and try to convert some of the ‘hand coded UI’ in our prototype to using flash.

Exhibit A

Just a disclaimer, all that you see in this video is a work-in-progress and extremely early. It was mostly a mock up to play around with the UI.

So in the video you see the main menu with the Outwitters logo, some buttons, a blue blade, and a background illustration being animated. This is entirely made in flash with pngs and some static text as buttons (just a full screen swf). As I press a map to load a pop up blinks into existance asking if I want to resume a previous game or not. This pop up doesn’t have any external bitmaps or pngs in it, it was made as vector shape rectangle with curved corners and some static text (which actually are bitmaps, but this is handled internally in gameswf). And finally, the mock up game board screen you see a flashy banner come across the screen announcing the player’s turn and shimmering, and then pulling away when the player taps the screen.

The animations weren’t anything too special as my flash skills are pretty horrible these days, but hopefully one can see that in the right hands this can be an incredibly useful tool to making games look that much prettier and be more engaging.

The best thing that’ll come out of this, is now the artist, Adam, has a large amount of creative control of how the UI will look and feel. Before it was heavily on the programmer side to make things work, and the fidelity suffered for it.

The Downside

Now for the things that might be problematic going forward:


Nothing has changed about this as far as I know, but images are required to be sized at powers of 2. When your working with the lower level api’s this isn’t a limitation that is difficult to overcome because you have so much control over what’s being loaded and how it’s organized in memory (for example, texture atlases). With gameswf, images are handled internally and they do 1 of two things:

  1. If the image is a non-power of 2 size, it will be resampled into a power 2 size using a software-based resizing algorithm. This can be a rather expensive performance hit if you don’t take this into account. The side effect as well is images that go down this pathway end up being rather blurry
  2. If the image’s height and width are a power of 2 then it uses the image directly.

My current solution? Just making image sizes a power of 2 before importing them into the Flash library. Yea it’s a lot of wasted space, but given how the UI functions currently, they aren’t long-lived objects so the memory is freed shortly after the user dismisses the screen or moves on. Of course, in the actual gameplay screen any flash-based UI elements have to be optimized. Sprite sheets aren’t exactly feasible in the traditional sense, but you can emulate sprite sheet functionality in flash by creating a movie clip that is masked differently on each of it’s frames. It’s tedious, but I imagine if you’re needing the extra memory savings this could be the way to go. There are a few other memory saving techniques I haven’t explored, like shared libraries that might provide some benefit as well.

In any case, if you’re targeting really low hardware (3G and below), you’ll most likely run into memory issues. The iPad 2 handled it just fine, but I imagine once I get down to the 3GS model and iPad 1 I’ll have to tighten my belt on the memory usage a bit, but it certainly seems doable.


I had spent about a week coming up with a small body of photoshop scripts in conjunction with TexturePacker to help streamline our process for creating assets at different native resolutions. The upshot is we have the assets. The downside is now they can’t be used as-is. I don’t have a ‘swf generator’ to generate iphone, retina, and ipad resolution swfs. So right now it’s looking like it’ll be a completely manual process of us creating separate swfs for each platform/resolution. Of course, if our swfs were 100% vector graphics, this wouldn’t be an issue :).

I’ve pondered some possible solutions, but haven’t experimented with any yet. One idea I had after browsing some of the source was using the ‘scaling’ feature of gameswf to scale the rendering of swfs, but inside the actual flash files do some actionscript magic to display the correctly sized graphics in the UI. Not sure how much tedium this would save in the long run without some sort of automated way to do this. On one hand, Adam or I would be laying out 3 individual flash files to be used. On the other, we’d be laying out a single flash file but then I would be scripting the resolution changes in the file itself. I would have to come up with some sort of ‘utility’ style movie clips in the flash library to help with this, but maybe it could work better than managing 3 files for every UI screen?


Given the tests I’ve done so far, there’s nothing there that has lead me to believe that doing a commercial quality game on the iphone/ipad with gameswf isn’t possible. In fact, I’m sure it’s probably been done by now and it just hasn’t been talked about? Which is kind of strange, considering how awesome it is. But maybe that’s just me geeking out. This isn’t so much as a concrete downside as it is more of an ‘unknown’. My concern is once we’ve got a lot of in-engine animations/particles running how will it fair with a flash player running the UI. The other caveat is Outwitters lends itself really well to this type of setup as it’s not a very fact paced game. So this solution might only be feasible for particular types of games (in the same way that using UIKit and CoreGraphics instead of OpenGL is feasible for some types of games). I guess only time will tell.

The Upside

Some of the positives of using gameswf particularly:

Lazy loading of images

When a bitmap is being rendered inside gameswf, the texture isn’t sent to openGL until the first time it is drawn. It’s a nice thing to know. We can kind of ‘stuff’ our flash files with image assets and not worry about them taking up tons of memory at runtime as long as we don’t render it all at once. This is useful for HUDs that are themed, in our case, by team colors, shapes, and logos. A point of caution is the the image *isn’t* unloaded from memory (even if you call an unloadMovie() from ActionScript on an externally loaded flash file).

Auto-rotation support seems feasible

Prior to this development I haven’t really considered doing anything too extravagant with support for auto-rotate. If we did support it, it would simply switch to the correct orientation and be done with it. But now it seems pretty trivial to have the UI do a fun but subtle animation as it stretches, squashes, or moves over to accomodate the different screen real-estate. It’ll be a ‘nice touch’ if we get that working.

It isn’t an all-or-nothing setup

Giving the sample project of gameswf for iOS a quick look it seemed at first that running flash was an all-or-nothing deal. It was initializing in the main method and pretty much took over how things were rendered onto the screen. This part was time consuming but after experimenting around with it a few days, I got gameswf to play nice with my already established framework for game screens and UI. Each screen in our game is just a subclass of a ‘Screen’ class that houses ui widgets and any logic particular to that screen. I was able to refactor a few things, and now I have just a subclass called ‘FlashUIScreen’ that takes in a flash file name and a ‘controller’ class as constructor parameters. It now functions and renders identically to anything I previously did. The point being, that if the need arose for something to render in-engine (perhaps using game assets already in memory for some sort HUD) I can still fall back to my previous method of hand coding UI. Hopefully that will be the rare exception than the norm.

Some Things To Know

It’s been a quick 2 weeks since I decided to investigate it and there’s still a few things left to answer, but currently I’m moving forward with the assumption we’ll be using gameswf for this project, and that is a fun thought to entertain :). For anyone else that is curious on getting gameswf up and running here are just some things I ran into while working with it:

If you’re loading separate movie swf files you’ll need a separate gameswf::player instance. I first went with the approach of having a single player and calling load_file() on anything I needed to render because I didn’t completely understand the relationship between a player and a gameswf::movie isntance. But the player tends to house the actionscript VM for a “root movie”, so loading 2 movies from a single player gave me some wonky actionscript behavior.

If you delete all the gameswf::player instances at any point in time, the library goes through a ‘complete clean up’ phase of gameswf. This game me some issues when I would transition from a main menu to an all OpenGL view (no flash UI) so the swf players were delete, and when I went back to a flash-based menu the app would crash with an EXC_BAD_ACCESS error. I got around this by instantiating a single gameswf::player instance that didn’t load any files and is held in my singleton service-based class. It’s only ever deleted when the app shuts down.

Getting the GL state setup correctly was probably the most time consuming part. The library worked great in isolation, but when combined with the framework I was working with, there were all sorts of states I had to track down in order to render a flash file and still be able to render openGL correctly right after. Below is just the snippet of the code I wrapped around a flash movie’s display() method.

Somethings to note, it likes a blank projection matrix (had to reset it to an identity matrix) and you have to disable a few client states in order to render flash properly. Once, you leave the display() method you need reset your gl color, blend functions, and possibly any other states you have may used with the assumption that they are enabled:

const int w = GetDisplayWidth();
const int h = GetDisplayHeight();

_movie->set_display_viewport(0, 0, w, h);

SetGLColor(1, 1, 1, 1);


And with that, I’m off to do some more work on Outwitters. Adam and I just played a few games over lunch and I actually WON. Mark this day, for this is the first day I didn’t get completely rolled in my own game.