I came in late on Guns of Icarus Online, well over a year after the start of development, focusing primarily on last-mile UI/UX issues. In particular, I took over ownership of several parts of the client, adding voice chat capabilities and designing and implementing the server list, map vote and party systems. I also worked on server-side functionality that impacted UX, including matchmaking, asset caching and match flow.
I was also responsible for both resolving bugs in, and improving the performance of, our PhysX package, used in server-side simulation. PhysX, of course, is a highly optimized C++ library, but we were consuming it from .NET code, requiring some concessions as to our consumption. I both hardened the interaction between these packages, and grossly improved performance of mesh collider creation.
I also, as part of a performance improvement, successfully merged two Unity projects into one, retaining all asset and shader references while the assets were copied into one project. That doesn’t sound like much on paper, but in practice, believe me, it was a small nightmare, and one that even Unity would claim is either extremely difficult or impossible.
Also, as a weekend project, I created both a test GUI client and a headless load tester using Forms. This allowed us to quickly simulate hundreds of connections and actions from a single machine, functionality that had not yet existed for the project. This reused code from our main client, thanks to Unity’s support of C#.
This project represented my first attempt at leading a team through the development cycle. The team consisted of myself, two part-time game design interns and a level designer. While the team grew in size towards the end, this team represents those responsible for a majority of the work. I was responsible for implementing most, if not all, of the game’s functionality as well.
Lasting a little over a year, this project was met with moderate success on launch, thanks in no small part to being one of the launch titles for the Steam Mac client. As part of our Steam integration project, I developed our internal solution as middleware that could be sold to other vendors. This was done by exposing Steam’s C++ API in C# via SWIG, then creating a more accessible façade that could be easily consumed by Unity. Over time, this package has grown to support P2P networking and voice chat.
It was then my responsibility to port the game to iPhone solo. Taking over a year, we worked with our publisher, Chillingo, to ship this game for the recently-released iPad Retina, as well as iPhones down to the 3GS. This precipitated the development of a Unity-consumable API for performing In App Purchases, which involved the use of Objective C.
A collaboration with HoliMoli! Media, Florafolio was my first iPhone project. At the time, it came out with support for the first iPhone scrolling at 60fps, no small feat given the processing power of the first iPhone and iPod Touch. Focus was given to quick identification in the field, and as such we allow users to search by name or by plant attribute (color, shape, etc.)
The database is edited via a web portal written in CakePHP that creates a SQLite file, which can be used to update the app at any time with new plants and content. This allowed the creative team to quickly add content from anywhere.
This project sounded like it was going to be just another, run-of-the-mill web development gig, but turned into something significantly more interesting.
The client was very adamant that they wanted the homes resolved to particular neighborhoods in Rochester, information that was not readily available. What was available, however, was the GPS coordinates of the properties. Using Google Earth, we were able to create boundaries for the various neighborhoods in the KML format, and utilize this information when properties were added to automatically resolve the neighborhood.
This project also mandated the created on a daily scraper application, that would convert information available from a local RETS server for fast lookups in our own site. This scraper had to be robust enough to last well after the end of the project (and I’m very proud to say it has been up for over two years with no maintenance required.)
This was also my first project using Django, having previously preferred Drupal. I’ve never looked back.