The Ever Daunting To-Do List

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.

4 Responses

  1. spineless anon Says:

    As a TDD fan myself just wanted to point out that blindly writing tests isn’t necessarily TDD. “Proper” TDD also drives your design. It also lends itself to uncovering code smells. For example, if you’re finding some part of code hard to test it could indicate a problem.

    I’m not expert at TDD but the better I get at it the more I like it. One big problem with the concept of TDD is that it sounds simple but it’s actually pretty hard to master.

    At any rate, just my 2 cents.

  2. Alex Says:

    @spineless I agree certainly. I appear to have lucked out in some cases in terms of writing unit tests for the different actions a player can perform as the code was designed to have each action be as independent as possible to begin with. But it’s already helping in allowing me to test the mundane stuff without having to run the game. Although admittedly, setting up unit testing was a huge pain *after* the project has started as opposed to dealing with it at the start.

  3. Stephen Says:

    This is exactly where we are with RoboHero, and we haven’t even started implementing online turn based modes yet. The polishing and debugging and “turning the game into a market ready product” phases are very tiring and tedious. Especially after many many months of development already.

    Why are you going with Google’s App Engine instead of the iOS 5 gamecenter turn-based sdk? Or are you planning on doing that once it comes out?

    We haven’t even begun to tackle this issue yet, so I’m curious what the best approach will be. Especially since our games are going to play very similar.

  4. Alex Says:

    @Stephen The reason we’re using Google App Engine instead of iOS 5 is mostly a timing/install base issue. by the time Outwitters is out, non-iOS 5 devices will still be at large, and with a game that depends on having the most users possible, we’d rather not lose that segment. Can’t say we’ll ever implement the game center version. Really depends on how high the demand is. As long as people are notified it’s their ‘turn’ it seems they wouldn’t care if it came from GC or a custom implementation?

Leave a Comment