In the fall of 2010, I left 2XL and did a bit of traveling. It was great to take some time away from the keyboard, but it wasn’t long before I was drawn back to game development. I’ve joined up with Enemy Airship and am now working on Shadow Physics.

Here’s a video of Scott and Steve (Enemy Airship founders) presenting the game at the Tokyo Game Show “Sense of Wonder” night in 2009:

In the spring and summer of 2010 I worked at 2XL Games as a programmer on the team porting 2XL Supercross and Trophylite Rally from iPhone/iPod to PC. Along with the varied work that is inherent when porting a game from one platform to another, one of my jobs was to create a front end launcher application that would interface with a billing system created by 2XL Asia (our counterpart in Seoul, South Korea). Users who got 2XL Supercross and Trophylite Rally demos pre-installed on various devices could opt to upgrade from the default trial game and the launcher application that I created would handle unlocking the full game. I also modified our PC configuration app to support localization. Here are a couple videos of 2XL Supercross and Trophylite Rally (sorry, no PC videos available just yet):

From 2008 to 2010 I worked at Coin App as Lead Programmer on “Max Blastronaut.” My main duties were creating Coin App’s in-house game engine as well as programming physics, AI, rendering, user interface, and gameplay. In September of 2009, the game won 2nd place in Microsoft’s Dream Build Play game development competition. More info is available at Coin App’s website and the official Max Blastronaut website. Here’s a video of some gameplay:

From 2006 to 2008 I worked at 2XL Games on the Xbox 360/PS3 title “Baja: Edge of Control.” During my time there I wore many hats and earned artist, outsource lead, and additional programming production credits. It was a great project to work on, and I learned an incredible amount from an amazing group of people. Baja was published by THQ in September of 2008. Here’s a little glimpse at some gameplay:

A Trophy Kart model created for Baja.

- 14,000 tris, 1024×1024 diffuse, normal, spec, effects
- Video captured as 3DS Max preview (real-time) using DX9 shader

One of the final touches in an offroad racing game with hundreds of miles of tracks was the task of putting in all the fences, banners, cones, haybales, barriers, tires, and other various objects that sit on the side of the roads. At 2XL, we called them “track-side objects,” or “TSOs” for short. To keep things simple, we built similar objects inside of the same footprint. For example, we had several sets of orange net fencing used as road-side dressing, all in varying condition. One was perfect and new, one had a single side sagging, another sagged in the middle, and so on.

To save time, the artist who was placing literally thousands of these orange netting fences would shift-clone a single version of a single version of the fence to use as a size and positioning stand-in. Then, when done, our exporter would save out a file pointing to thousands of references of that single object. This is where I came in (well, aside from being one of the guys who was placing those thousands of objects).

All the level artists agreed that shipping the game with 2000 of the exact same orange net fence lining a track was not a visually appealing option and would take away from the overall realistic nature of the game. So, I wrote a tool that would post-process our exported level files and randomize a given object according to the desire of a given artist.

A user of the “Random TSO Generator” could tell the application what object they wished to randomize, as well as the objects that would be involved in the randomization and their given probabilities, and the application would re-process the exported level file.

One challenge we faced at 2XL was assigning, organizing, and tracking art assets made by our external art outsourcing partner. How do we specify what we want from our outsource partner? How and where is it all stored? How do we keep track of everything from the early specs given to the outsource studio through several revisions and through to a final product?

Our solution to this set of problems was an application created in-house that would integrate with Microsoft Project, a database (SQL), version control/tracking (SVN), and traditional email. Thus, our producer could enter tasks in Microsoft Project, artists in our studio could assign the specifications such as poly count and texture budget for a future asset or give feedback on a previously submitted asset, outsource artists could view specs or reference photos and read feedback from artists in our studio, and all parties involved were emailed updates when an important change occurred. This whole system was based around a single application that we called the 2XL Asset Manager.

I jumped into work on Asset Manager just a few weeks after its inception and took over the task of getting core functionality up and running as well as documenting the application for local and outsource artists. The image below is the main window of Asset Manager where a great deal of information was accessible within a single click. Users could select given asset types that they wanted to “watch,” thus improving the signal to noise ratio and allowing a user to subscribe to only the areas of the game on which they were working (e.g. Vehicle artists won’t care about updates from environment art tasks, and vice-versa). Also, clicking any given level or vehicle class resulted in a background SQL query of the assets in that section, listing completion status, assignment details, as well as check-in and reference history. New updates were presented as clickable (web-style) links in the lower left-hand status window, giving the user quick access to anything that changed since the last time they used the system.

Clicking on any of the individual results from the main list display of the previous window would take a user to the next screen, visible below, with a detailed view of a given asset. Here, local (supervising) artists had priviledges to update specs, upload concept art or reference images, and correspond with outsource artists via a notes pane. Similarly, outsource artists could read asset specs, download reference images, and post any questions to supervising artists if they were in need of assisstance. Any change, be it from supervisor or outsource artist, would trigger an email update for all parties who had subscribed to the given asset. This allowed our producer and outsource management to follow along with the process of asset creation without clicking into every single asset to read its notes during the process. Even those who were not fluent in the Asset Manager could stay informed, as we lowered the barrier to entry down to the level of being able to read email.

Managing the actual asset data was a key focus as well. Our goals were to have versioning capability and an easy-to-understand visual interface. What we came up with was the following screen which connected to our internal SVN server and seemlessly notified the outsource artist what files they had changed (shown in bold green), and allowed them to create batches they could upload when they left work for the evening. This was due to the nature of the large files (the primary culprits were photoshop source art files), many of which were 100MB or more having to be transmitted via a secure VPN connection from the outsource studio in China to our studio in the United States. Using the check-in functionality of Asset Manager, an artist could click through the work they had done for the day on one or more assets, create a “batch,” click “submit batch” and let the system upload and process everything overnight. Again, this would notify via email all relevant parties when the files had successfully transfered and checked-in to our SVN server.

There are many features that I have left out of this description for the sake of brevity. But, suffice it to say the Asset Manager was an interesting task for me at 2XL. I was constantly taking feedback from our outsource studio as well as my local co-workers to improve and refine the system, releasing new updates regularly via an automated update system that I developed. The capabilities of the system as a whole were really quite impressive, given the fact that I was the only developer actively maintaining it and it was only a side project (as the first year of my stay at 2XL was under the title of “Artist”)!