Ticking things off

It has been about two and a half weeks since we started our meetings and using Wunderlist heavily. Tonight was actually our third meeting so we have been doing meetings for only two weeks. In these two and a half weeks with Wunderlist we have completed just over 50 task items.

While that doesn’t say much without knowing just exactly what those tasks were, it does mean we have been making much more progress than we did before. Basically, though, on average we have been completing 3 tasks a day to move us closer to a release. For me as a task-oriented programmer that is really exciting.

Some of the tasks have been really simple and only take a few minutes, such as changing text in a button. Other things have been rather complex. One of those single tasks for Matt was building the power up selection in the Character Builder, which consisted of a number of elements. I’m pretty sure that took him a few hours.

Node JS

nodejsNow the juicy bit for a programmer. I talked last week about how Game Center has been utterly disappointing. So disappointing that we were basically unable to actually use it. I looked at a few products. None of the paid products were at all interesting to me. They were either way over priced for what we needed or just were not able to do what we needed. What we need is basically a simple server that just manages match-making and allows clients to communicate with each other.

Two of the products I looked at had potential. The first was usergrid. It is a pretty full-functional BaaS system. Unfortunately I could never get it to install. Following their step-by-step instructions I kept running into error and error. I would fix one error and then run into another. I finally gave up and just deleted it and moved on. It may be a great system, maybe they will fix all those errors, I don’t know. It also requires a JRE to function, which I am not keen on. I pretty much hate Java apps for no other reason than I hate them.

The second product was deployd. Deployd is written in nodejs. I looked at it and like what I saw, but could not find any examples of a realtime gaming. Even simple examples. The documentation says you can do it, but all the examples are very simple things like a todo list, microblogging, etc. It does have User authentication but is, well, vague as to implementing security. I may go back and dig into it deeper since it at least has an admin UI for the data. It’s not exactly an easy to use one if you have a lot of records/documents, but it would be possible to work with the data.

Deployd did, however, point me to the idea of using nodejs to build something. I had heard about nodejs before, seen examples of how to us it and was always intrigued at how simple it seemed to be to work with. So, with that in mind I decided to see how hard it would be to build a simple proxy server that would allow clients to match up and communicate with each other.

Roughly 100 lines of nodejs/javascript code later, I had a working multiplayer server that performed (simple) match making and passed communication between the clients. I also discovered how easy it was to work with a MongoDB from nodejs. I won’t go into detail yet since I am not using it for data storage yet, but I will say it is stupid simple. Getting MongoDB itself setup is much more difficult, but that is another story.

Basically, the nodejs application opens a socket and waits for connections. When a socket connects and sends a “find match” message it checks if there is an existing client waiting to be matched up. If so it pairs them up in a “room” and lets them start talking to each other. If one is not waiting, then the client looking to play is marked as the one waiting to play.

This will be completely useless in a larger system where we might have 30-40 people trying to match up at the same time. For that matter it wouldn’t even work to have one person trying to play the Taco Shop deck and another trying to play the American Diner deck. A little bit of code and I would have a working system for that too. Either way, right now it works and does what I need.

Deployd looks like I will have to do essentially the same thing when it comes to live multiplayer support so it’s not like I am wasting my time. From what I can tell deployd is primarily geared towards quickly creating an API to database system. Which makes all those API calls public by default. I would have to find a way to basically invert that and disable all those API calls. Not saying that isn’t the right way to go, as I mentioned above I will still look into it more closely.

I certainly like the idea of using something that is actively maintained rather than building something completely from scratch. And by the way, a bonus to doing something like this instead of Game Center is that we don’t have to put our devices in Sandbox mode (thus breaking other games we actually play).


  • Lots and lots and lots of updates to the Character Builder.
    • Updated nearly all character element images.
    • Removed a few elements that we decided were not useful.
    • Updated all the skin tone colors.
    • Updated all the hair / face paint colors.
  • We now use in-memory cache in the character builder to improve performance with all the rendering and re-rendering of images as they move back and forth between element sections.
  • Clear the disk-cache automatically when a new version number is detected. We were having problems with us forgetting to clear cache manually and the wrong images showing up after an update.
  • When playing multiplayer games your character image is now shared to the other player so they can see what you designed for yourself.
  • Can actually play multiplayer. Server is currently running on my Linode instance, which costs a whopping $10/mo. Go checkout Linode if you haven’t before.
Week 15 : Daniel