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.

Matchmaking

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.