This is the final part of my posts on the history of Boardz. I’m going to talk about the artwork and the server.
The artwork for Boardz was one of the most time consuming parts of the project. I made the wrong decision early on that I wanted to do all the work myself, including the art. I found a few pieces of free artwork on places like wikimedia commons, and bought some 3D models on TurboSquid, but the rest of the artwork was either drawn by myself, or generated on the fly procedurally. My approach to a lot of this was pretty unusual I think, mainly because I was trying to find the best solution that was within my limited artistic abilities. As an example, I knew I couldn’t model 3D chess pieces, so I bought a set of Staunton 3DSMax files, even though I was rendering the board in 2D, using OpenGL. To get the 3D look, I rendered the pieces in Max, then I took screenshots of the renderings and used them as sprites in the game. This worked pretty well, and I think my Staunton 3D set is one of the best looking sets on the App Store – it’s easy to see the pieces, without the 3D look making it hard to follow the game, and it looks very traditional. I followed a similar approach for other games such as Go, and did some rudimentary modelling for pieces in Shogi – the ‘squashed pyramid’ shape of Shogi pieces was just about within my modelling ability. The 3D pieces were in some ways easier to do because of this approach. The 2D sets were much harder. Although I could find free imagery for sets, I didn’t particularly like the quality of these images. I spent a lot of time fiddling with individual pixels in photoshop, playing with blending modes, and sharpening/softening images. I also spent endless hours tweaking filtering and rendering code to build up a 2D graphic on the screen that I liked. Fitting a full set of Shogi pieces onto a 320 pixel screen is particularly challenging – the Kanji characters in their full versions are very detailed and hard to see at that screen size, not to mention the large capture area required, and the 9×9 board. For that reason, I offered an optional reduced set of pieces with just the first character of the pair displayed – quite a common approach in the literature for shogi (newspaper columns often use a reduced set to document tournament games). I later realized that I could have easily generated Kanji characters at any resolution by simply firing up Word and typing them in, but this was much later in the project when I worked on the iPad version.
As I mentioned, I chose to draw all the artwork using OpenGL ES. For a 2D game, this is somewhat unusual, but for me it was a natural fit because I’m a 3D graphics programmer and most comfortable with 3D API’s. Had I employed an artist to generate all the 2D artwork, and made use of the 2D graphics API’s I suspect I would have completed the project sooner, and with less difficulty. Doing all the graphics myself meant I needed to work out how to handle animation, as well as combining iPhone 2D elements with my 3D renderer. All that aside, for future projects I will still draw everything using OpenGL, but also generate all 2D user interface elements in the same renderer. It’s really the only way to get a cross-platform game up and running without having to port all of the code.
With the pieces sorted out, I needed to draw the boards. This part was a little easier, and involved finding some woodwork art, and writing some code to draw the lines onto the boards procedurally. Being able to draw any size/shape of board in this way made it easy to offer different sizes of Go Board, and alternative games such as Mini Shogi. For the most part the wood textures looked good, although on later versions I dialled back all the wood a bit and added a nice green felt texture for the backdrop. I also added some small touches, such as fake shadows on the pieces, and scaling, etc. to give the illusion that the pieces were being lifted up/put down.
Before Boardz, I’d never written any web based code at all. Sure, I’d ran the odd sample ASPX demo and tweaked a little PHP code here and there, but apart from that I didn’t have the first clue about how to implement a server for a turn-based game. After a lot of research, I came to the conclusion that I wanted to do a RESTful API, with very minimal web front end; since everything would be communicated through the iPhone client. Installing and setting up a Linux server on a web host quickly convinced me that it was going to take a lot of maintenance, so I began looking around for easier solutions. At the time, Microsoft’s REST story was not complete and difficult to understand, and I was nervous about maintaining and hosting IIS on a server – not to mention my total lack of experience with SQL Server. At that point I discovered Rails, the web framework that runs on Ruby. The nice thing about Rails is the way it abstracts the database from you, and makes it easy to build an app without writing SQL statements or managing the database. For someone like me it was perfect, and after a few tutorials I was convinced it was going to work well. At the time, I decided to leave the deployment problem until later on, but I eventually found Heroku and didn’t look back. Heroku is a cloud host which makes it easy to deploy Rails apps; it’s one of the best pieces of software technology I’ve ever used – it’s trivial to get a Rails app running in the cloud, initially even for free. You don’t have to worry about packaging up your app for deployment, you just push your git branch up to their server and a few moments later you are live.
The problems I had with the server mostly came down to my lack of experience. I had some issues with my assumptions about how the Ruby language worked which bit me for a long time, and some problems with synchronising moves being made by the clients. It took a while to get the authentication working with HTTPS too – installing an HTTPS certificate on a website and communicating securely is a bit confusing when you first set it up; and you have to be careful to get it right! Getting the client to work with the secure connection also turned out to be very tricky due to the state of the SSL browser support in the phone – which was improved by newer versions of iOS and became a non-issue over time. To this day, the only real problems I get from users using Boardz are with the authentication/login. Mostly these are just problems with firewalls, etc., but in future I’ll try really hard to make the authentication use OpenID/Facebook/Google, etc. and remove myself from the equation entirely.
One amusing part of the server design was how to send end user emails upon registration. I worried about this for quite some time before using the Heroku Sendmail addon. My concern was that I’d run out of email budget for new registrations! I planned ahead, but never needed this functionality, since the app doesn’t create more than 10-20 emails per day…
Push notification support on Heroku was also pretty simple, due to the APN on Rails plugin, but it did add cost to the server, since I found I needed a worker thread to process game status and batch up the push notifications. I have a worker that does this every minute or so and sends out ‘it’s your turn’ messages for the games. In all, the Heroku server costs me around $60 a month to run, and I’m delighted with how it has performed – I haven’t had a single problem or outage in the two years it has been running.