Porting existing video games to new platforms is often a matter of simply transplanting each title as accurately as possible. I worked as a lead programmer on a handful of these, but they were gated behind NDA’s.

Creating brand new adaptations of existing video games, though, was far less restrictive.

Video game developers and publishers were typically concerned with creating a new entry for their IP that was consistent with previous releases. Given platform and budget limitations, capturing the spirit of the gameplay was the main focus, with plenty of freedom in other areas.

This proved particularly true for Capybara Games’ adaptation of Mercenaries 2, which I worked on as lead designer and programmer.

To begin preproduction, I played through the original release of Mercenaries while pouring over a plethora of reference materials supplied to the team by Pandemic. The series’ goal-oriented destruction using a variety of armaments was quite different from typical run ‘n’ gun titles on mobile, so I aimed for something less arcade-ish with our adaptation.

Due to severe platform limitations, this proved quite challenging.

First, it was impossible to reliably capture multiple inputs at once on most mobile devices. This made interacting while navigating extremely problematic, so I implemented a rather drastic solution: auto-firing. Based on the equipped weapon’s range, the player character automatically fired at any enemies that got close. This created a dynamic of strafing and leading opponents, bringing our prototype closer to the console game’s moment-to-moment action.

With auto-fire in place, a single key was designating for context-sensitive actions such as picking up weapons, taking cover, using explosives, and interacting with the environment.

Cover was not a major element of the console titles, but it added some variety to our combat. Pressing the action-key next to sandbags or other obstructions made the player character hunker down, avoiding all damage coming in from the opposite direction. This allowed us to create manual-targeting sections — initiated by using the arrow keys while in cover, which also doubled as the mechanism for using turrets — that relied on properly timing attacks between reloads.

Environmental destruction proved much trickier to implement. Targeting explosives such as grenades and air strikes was initiated with the action key, pausing the game while displaying a scrolling reticule. However, our initial tests with decals and partially-damaged tiles proved too demanding for mobile devices and didn’t do a great job of duplicating the physics-based havoc of the console games.

In the end, I came up with a simple solution that gave all destructible elements a pristine and an annihilated version. The pristine version appeared in a top-layer that was partially removed following an attack. This moment was largely masked by large explosions, smoke, and screen-shaking, with the annihilated version coming into view once the visual effects played out.

The publisher proved generally amicable to limiting the scope of our project, going so far as to as to greenlight our game taking place after the events of the console version. This organically removed the need to include all factions and locations, and led me to write a new storyline that focused on varied mission goals. These often culminated in bombastic vehicle sections — the last pillar of the Mercenaries experience — replicating the most memorable set-pieces of the console version.

Games based on movies typically needed to coincide with a big-screen release. This meant that delays were never an option, and plenty of guesswork was necessary as there were no finalized references. Moreover, the audience expected to relive some of the moments of the movie, so the game tended to follow the script pretty closely.

While working as a gameplay programmer on Pixar’s Cars, I was responsible for implementing various gameplay modifiers on basic driving to mimic the protagonist’s journey in the film. Namely, I created and polished missions that had Lightning McQueen collecting precious bolts, shepherding lost tractors, outpacing the local punks, and helping to pave a damaged road.

Despite being a mobile port, racing was a crucial part of the IP so I made sure to playtest and tweak the placement of all checkpoints, AI waypoints, and overall difficulty. As a lot of the tracks looped in on themselves, I also tried to minimize rubber-banding — artificially slowing down or speeding up AI racers based on their proximity to the player — as any unnatural movement could be quite visible.

To accomplish this, the max speed and acceleration of AI opponents was set relatively high, but their “handling” varied based on placement in the race. If they were ahead of the player, handling would introduce errors in the turning calculation making them drift off the road. However, if they were behind the player, they’d race optimally without ever crashing into obstacles.

Both movie and TV properties tended to have no clear set geography, commonly relying on their locales being in close but vague proximity. Solidifying these was something important to the design of various types of games, but brand managers were often reluctant to commit to anything that could contradict future developments.

One way I got around this was to make layouts as abstract as possible. While leading the development of Jimmy Two-Shoes for Silverbirch Studios, I designed the world map in such a way that each area floated on its own parallax layer. These could automatically scroll into view, giving a sense of a cohesive town without “locking in” the locations themselves.

Unlike movie properties, Jimmy Two-Shoes didn’t need to follow a season of episodes very closely. Instead, the goal was to convey the setting and characters in side stories that could be played alongside the show.

There was no clear, unifying activity in the cartoon that could serve as the basis for gameplay, so we decided to go with a more narrative-driven approach reminiscent of classic adventure games. This allowed us to more accurately convey the personalities and motivations of the show’s cast, creating goals based around conversations and item-collecting in locations that could be reused.

To achieve this, I wrote a basic scripting language that populated each area with objects and NPC’s, giving them unique behaviours based on player-progression. Goals and puzzles were very simple and explicitly spelled out to accommodate for a young audience, while minigames provided additional gameplay variety. To best connect with the IP, the minigames were based on the protagonist’s antics in the show such as ghost-hunting and performing a rhythm-based dance routine.

As with movie licenses, all text for Jimmy Two-Shoes had to be manually approved by multiple parties. However, even as our copy was finalized, changes could be made by the showrunners. Thankfully, my scripting language made most adjustments trivial to implement, and the build process automated their integration while prepping for localization.

Games based on toys and other licenses were generally the least problematic to develop. There was rarely a solid narrative to follow, and mechanics were fairly open-ended. Publishers were primarily concerned with cross-promoting their brand by reaching out to a new audience while capitalizing on existing fans.

Jada Toys’ Chub City was a good example of this. I worked as a lead programmer and designer on the game, creating multiple game modes to best capture the IP’s urban aesthetic.

My first task was to create a grafitti-minigame based on running through a neighbourhood and tagging buildings while collecting bonus items. The buildings, collectibles, obstacles, jump boosts, and graffiti hotspots were all procedurally generated to accommodate replayability and high-score challenges. This system — and some of its assets — were then reused to create a simplified skateboarding game atop the buildings themselves.

The team was somewhat concerned with brand owners greenlighting elements such as spray-painting and dangerous skateboarding, but both were greenlit without any change requests.

Work on miscellaneous other brands followed much the same pattern as Chub City.

While leading the development of a mobile ESPN title, I focused on implementing three different sports found on the broadcasting network: baseball, basketball, and hockey. Since platform and budget limitations prevented us from fully capturing each discipline, the team aimed to replicate various skill-competitions from their all-star games: a homerun derby, a 3-point challenge, and a 1-on-1 shootout.

All three game modes were approved, and the only guiding mandate we received was to steer clear of any disparaging or controversial elements.