One of the issues with game development that’s become more apparent over the years was dealing with splitting time between new game development and bug fixes/maintenance. When we first released games, they were¬†much simpler, and as a result had less bugs to deal with. You could spend the majority of your time working on new features.

Nowadays, our games have become so large that as the solo developer, even I can’t keep everything in my head straight on how certain systems were implemented. More importantly, after a certain amount of games, my time working on ‘newer projects’ as shrunk to a point where it starts to impede on progress.

That is the price you pay I suppose for running mobile multiplayer games. I’m finding things far more stable on the PC side of things. While there are issues I wish to address on PC for SFT, mobile stuff such as Outwitters/SFT become quite the chore as the OS’s they run on change so fast and drastically that it can potentially totally break those games. Just this month I spent a decent chunk of time updating Outwitters to get it to a point where it should be “fine” for at least the next year? That’s how tenuous some of the services and OS features are on mobile. And games like Gauntlet’s Revenge on Android has some store issues that, in order to fix, would require more toiling away with updates that simply wouldn’t be worth it. I think it may be our first game we will have to discontinue and remove from the ¬†Google Play Store ūüôĀ .


UGameplayStatics::CreatePlayer(World, Index,bSpawnActor) (Docs).

When creating a custom game mode it wasn’t clear in the documentation how ones goes about:

  1. Spawning a playercontroller
  2. Spawning a pawn
  3. assigning both to each other
  4. and possessing the pawn with the controller

So I basically did it all manually inside InitGame(). This cropped up some unwieldy UI focusing bugs. Once I replaced it with a call to CreatePlayer() things started working as intended. Hope this helps anyone who’s starting out in UE4¬†with C++.

With each game release I’ve noticed I’ve¬†committed less and less time to writing the ‘fun bits’ and more time spent trying to mitigate complexity and find ways to make as many things as testable as possible. I guess that’s the nature of the beast once you go beyond your average ‘asteroids’ clone. With the recent announcement of SFT getting asynchronous play in the coming months, I’ve been scoping¬†out my dev schedule for what needs to happen to make it reality, and the only issue that I keep circling back to is “how the hell do I make all of this testable/bug free”. Sure, I could write the async¬†frontend and backend and just do some “dry runs” on a few VM clients, but I’d lose sleep knowing full well that wouldn’t cover even half the potential bugs or edge cases. I use to reserve testing for server-side components, core game logic, but our games have grown to a level of complexity that I can’t ignore the UI/animation layer anymore in regards to testability.

The core logic of the game is fairly well unit tested. But the UI/animation layer on top of it has less than ideal integration testing. That layer has tiny bits of interface logic that has grown quite complex despite most of it not really touching the actual game state. It has¬†sufficed for now, but it’s increasingly clear that it needs to get refactored, maybe in some cases re-done for easier integration testing if I want to move the game from “real time only” to “real time, async, and seamlessly transition between the two”.¬†On top of that, I just recently moved SFT to Unity 5.x which has cropped up a lot of bugs on the UI layer, and are increasingly hard to hunt down. Adding in integration testing after the fact is definitely not the best way to go,¬†but I’ve gotta make do. The show must go on!

Early on in the development of SFT I had concerns about how I was going to do text rendering on the cards in such a way that things stay readable regardless of resolution, while keeping fonts looking nice. I ran into aliasing issues as well as pixelation, since all the fonts being rendered were simply bitmap textures on top of cards that are flipping, rotating, and¬†scaling in 3D space. I had read about SDF (signed distance fields) font assets for text¬†rendering and was¬†wanting to get something implemented for SFT’s cards. But alas, I had to temper my eagerness to “learn something new and cool” and focus on getting the game done.

So in the end,¬†I opted to use Unity’s built-in font rendering, along with NGUI’s nice text layout and rendering tools,¬†and¬† tuned the distance¬†of cards from the camera in the different UI screens¬†to make sure everything stayed “more or less” readable¬†in as many cases as possible on as many resolutions as possible. This worked well for the rest of production and I think we have a very shippable solution for card¬†text¬†in SFT.

A couple of weeks ago I ran across this Unity asset called Text Mesh Pro. It had SDF font rendering! I poked around with it for a bit as it was a very easy library to just drop in and start rendering text in the game:

Screen Shot 2016-02-12 at 7.08.15 PM


The top number is rendered with Text Mesh Pro. The bottom with a combination of Unity fonts + NGUI UILabels. The difference is stark.¬†Now in practice, I think most wouldn’t even notice. The UI in SFT was minimized to the best of our ability to make sure the limitations of the fonts didn’t draw attention to themselves. Sure enough, it was hard to tell in SFT unless you were looking and had both builds side by side.¬†It was a definite improvement, but I think in future projects using SDF¬†fonts will make me less weary of using thin or very large¬†typography. Even if the visuals aren’t miles ahead, the big win here is memory savings.¬†Instead of having huge font atlases with 200pt fonts to keep things crisp, a single small SDF atlas is all that’s needed for any point size, and in the case of the TMP asset, any style.

This is one of the things Unity gets right. The font rendering asset that Digital Native Studios put together represents probably hundreds of man hours. I simply couldn’t justify that kind of time for our game on just text rendering,¬†despite it being arguably an important part of a card game. If I wanted to do that for any piece of “core” technology in any given game, we’d be measuring our development time in years, not months. Sadly, we can’t afford that kind of time.¬†Instead, I made use of the tools we had at the time (which¬†were good for the most part), and alter the game’s aesthetic to match with what we were capable of. Being able to go and drop in a new library for font rendering and immediately benefit from it after 20 minutes of work + a few bucks vs hundreds of hours is impressive. Hats off to the¬†developer behind this nice little tool!

Taking the “conflict” out of shared roles:

We opted to do a ‘ranked preference’ for role selection in SFT. Instead of players joining/leaving and selecting anywhere from 1-3 players to control and then having more UI flow when conflicts arise, or a character is left unselected, or a few other scenarios, we simply take everyone’s¬†preference list and the game deals out character roles based on them. If there’s a “tie” (for instance two or more have captain as their first choice) it’ll be random who¬†gets it.¬†This means:

  1. One UI (simpler implementation)
  2. No timing based conflicts or resolutions to manage
  3. More control over how players are distributed.

The core reasoning behind going for this system was also due to the game always has 4 valid characters. You can’t play SFT without one of the roles. If a player drops mid-game, the host takes over that player’s role.¬†The key¬†influence for this system was from Evolve. A fine game I might add that I¬†think deserves way more credit than it has received.

Finally got another card ability animation implemented into SFT:

The¬†method and architecture I’m using for¬†driving game logic I think has served me well for the past few years. I shipped Outwitters on the basics, and expanded the gameplay “engine” for SFT, which allowed for real-time multiplayer (albeit in sometimes hokey ways). The drawback is I haven’t found a good way to untangle it from the animation layer. It’s all 100% unit-testable, but when it comes to driving user input visuals for card play, it’s still a mess of:

  1. Play this animation clip when a user clicks.
  2. At this point in time, run this action to apply changes to the game state
  3. Then run this bunch of code to update UI, send state machine changes to animation FSMs, and send out any other misc events
  4. Then either:
    1. wait some arbitrary amount of time to submit another “action”.
    2. Have some hook in either an FSM or animation clip, to call back to a method to submit another “action”.
  5. And proceed to pull hair out at all the other permutations of that flow should the user wish to back out of the “happy path”.

This makes for a very difficult setting to collaborate on animations. Ideally it’d be nice to just have the artist create some canned animations that I can just use and then time them to¬†game logic when needed on a separate queue/thread.¬†In practice this doesn’t work because a lot of card animations are spline-based. Furthermore, the splines are dynamic since cards could be in any number of states, locations, or orientation at any given time when a user decides to click them. This makes the process of “animating” abilities such as the above¬†really time consuming. The alternatives:

  1. creating a ton of animations for each possibility (lol, no).
  2. Or a less ‘fluid’ look where cards simply don’t move¬†as you’d expect, but do slightly strange arcs since it’s the same canned animation regardless of angle, position in hand or inventory slot.

I think in retrospect I needed to spend some extra time, maybe a week or more, coming up with a better pipeline or workflow to allow for easier iteration on card¬†animations. My first hunch is maybe trying to make some sort of ‘building block’ animation library for cards. So for complex sequences they’d simply just be queued up series of fundamental animations in cards, and then I can easily just interlace¬†calls to PlayAnimation() and SubmitActions() and treat them almost identically in code as opposed to the one-off hacks for each ability that currently exists. But even that process is rife with a lot of edge cases due to the dynamic nature of how players interact with cards, and ultimately would still require some programmer help to get things looking right.

For the moment, card animations in SFT are created by:

  1. The artist creates a fully animated mock up in Unity using the tools they know. Artist now exits stage right.
  2. I then painstakingly try to mimic that entire flow (and very often other user flows not captured in the 1 one-off mock up) using a combination of animation clips, splines, FSMs, and procedural animation via code.
  3. Give up trying to replicate the mock up when enough time has gone by and I realize I have to move on.

I’m able to capture the majority of the mock up’s “essence”, but a lot of the subtleties of the animation that artists are actually good at creating are lost due to lack of time and lack of flexibility.¬†Maybe next go around if we’re doing another card based¬†project I’ll¬†be able to have another go at this.

This week I’ve got a lot done in the way of Steam integration, save files, automated builds, some better randomization for galaxy generation, as well as some much needed bug fixes to make online play smoother. Got a lot done but not much on the visual side of things. But hey:

Nice to be one step closer to a shipping product

Nice to be one step closer to a shipping product

Got basic¬†Steamworks apis integrated as well. Pretty painless with the library for Unity.¬†I was hoping to get steam invitations working this week to make play testing a bit easier but it looks like it’ll require a pretty extensive test environment that I simply haven’t setup yet. So I’ll be sticking to our current matchmaking system until then.¬†I’m going to need a few virtual machines running different steam clients to get full end-to-end testing on the lobby functionality.¬†The testing and development environments for multiplayer games always¬†have been a bit cumbersome compared to their single player counterparts.Alpha main menu

Bugs bugs bugs

I’ve taken the effort to get a decent suite of unit tests for Space Food Truck using Unity’s Test Tools. In the past, they’ve kind of lingered once some basic¬†functionality was implemented but never really maintained, or even worse didn’t have any (see:¬†Tilt to Live Series). In Outwitters, I had a small suite of client-side tests to validate some unit abilities¬†but never really maintained much of them after several content updates. Meanwhile, the Outwitters back-end has an extensive suite of unit tests. They have been¬†utter life-savers. The extra time spent writing thorough tests would quickly pay for itself¬†just in stopping regression when updating the server-side logic.

Taking that lesson I wanted to apply it to Space Food Truck. The game logic itself is largely covered in the unit tests.¬†Again, extra effort, but it’s bought me great flexibility when trying gameplay experiments, tweaking or fixing gameplay rules. I can quickly go in, change some gameplay rules or abilities,¬†have decent confidence I didn’t break anything fundamental to the logic of the game. That’s great for sleep. But¬†SFT gameplay kind of lends itself more easily to unit testing. For one, a lot of the architecture for the gameplay is a highly modified version of Outwitters core code. It’s a bit harder to do with an action-based game when a lot of your logic can heavily¬†rely¬†on simply collisions and collision detection (systems Unity handles internally and hard to test end-to-end).

The bugs I’m running into now are, unsurprisingly, anything that isn’t unit tested. Go figure. This is largely visual and UI bugs. A lot of times the underlying logic is happily chugging along and fully validated but the UI tripped over itself and has no clue WTF to do anymore. Getting UI and gameplay prefabs testable is an even larger effort (integration and automated UI testing) that I simply haven’t taken the time to do so. Part of the reasoning stems from time constraints (bad argument, I know) and also we’re¬†using quite a few pieces of middleware to drive the visual aspects of Space Food Truck. Getting those isolated and into a testable form isn’t easy (especially if some don’t come with source).


Took a bit of¬†time earlier this week to get a planet montage of some planets from Space Food Truck. Far from fellow indie Colin Walsh’s¬†epic scale of Drifter’s “grand tour” video, but still fun to look at nonetheless.¬†Looking to get more lobby UI working next week as well more graceful handling of less than ideal online environments. So far I’m on schedule with the sprints I’ve planned. Wonder how long that’ll last…


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 ( 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:

[code] 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:

[code] –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 Pretty simple. Uploading it is pretty straightforward to if you use the –url option with “ 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 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 ¬†, 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 (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 :).