Home/Games I've Worked On

This page contains information about the games I've worked on.

Death By Solitaire Tableau View Death By Solitaire Win Screen Death By Solitaire 2020 (Windows)
Personal Unity project
Released: June 25, 2020
Link to ZIP'd folder with executable (17 MB): Download
Last updated: August 5, 2020 (fixed deal bug, game should be slightly easier to win)

Note: since I'm using the free version of Unity, the game will probably bring up a dialog saying it wants to access the Internet. This is just Unity's telemetry nonsense. You can deny the access and the game will still work.

You can download this game from the link above and play it yourself for free. Just un-ZIP the folder to your desktop; the executable is in the folder. I have no idea if it will run on your computer and your anti-virus software will likely complain when you run it. While I can assure you the program is harmless, don't take my word for it. Scan the folder with anti-virus software before running it, as you should do with all programs you download from the Intertubes.

Four years after retiring from the game industry (maybe three years, it's kind of a blur now), it seems my career burnout has finally subsided and I can now program as a hobby with no deadlines and no milestones. This project started when I thought I'd check out the latest version of Unity and saw the Shader Graph. I wanted to muck about with it and thought it would be fun to create a shader that turned a single quad into a two-sided object, lit on both sides and with different textures on each side. A playing card was the most obvious choice. I got that working and decided I should use it to make something. I'd written this game twice before on my 8-bit Atari many years ago (once in BASIC, once again in 6502 assembly language) so it seemed like a good candidate for 3-D treatment. Also, my mother was complaining that she didn't have any new games to play on her computer. She became my target audience.

This is a two-deck solitaire card game. It seems to be taught from parent to child and has many different names on the Internet (Weaver, Grandma's Game, etc). Everyone seems to describe different rules for dealing the cards. The version I've implemented is the one my mother taught me (and her mother taught her). The game is rather difficult to win; I've only won it twice since I wrote it. I therefore added scoring so you'd at least have some measure of success. Initially, the game seems mindless but as you play it you will see that there are many strategic decisions to be made stemming mostly from there being two of every card.

I wrote this using Unity's Universal Rendering Pipeline. I originally started with the High Definition Rendering Pipeline but that had trouble running on my parents' older computer (shame, it looked more photorealistic using HDRP and had better lighting). I thought about adding sound effects but my mother didn't want any. The game uses public domain art because I can't art. Took me about a month to write it because I kind of had to re-learn C# and Unity. Ha ha.

Anyway, the game is nothing special but it's the first lines of code I've written in years. Baby steps. :)

Atari Vault screenshot Atari Vault (Windows)
Code Mystics
Released: March 24 2016

Official website: Atari Vault on Steam
Publisher website: www.atari.com
Developer website: www.codemystics.com

This was actually my second "from scratch" Unity project (the previous one, written immediately before this one, ended up not seeing the light of day). My task was to write the front end and I chose to write the project in "The Unity Way", i.e., using the Unity editor to simplify layout work and animation. And it greatly did so.

This also marks the first time I had to write shaders, which meant learning how to write shaders followed almost immediately by learning how to rewrite shaders to make them DX9-compatible (using Pixel Shader 2.0 instead of 4.0).

Funny thing about Unity development: you always seem to get held up on issues that you would expect to be rudimentary to implement but turn out to be something Unity expects you to do in a very specific, poorly-documented way. Also, nobody else on the Unity forums ever seems to be having quite the same problem as you. Inevitably, you either wind up googling for hours to find a solution or ultimately solving the problem yourself. Often both.

I have to admit that Unity really did make the 3-D aspects of the front end a breeze to implement, although its handling of multiple game controllers leaves something to be desired.

Killer Instinct 2 logo Killer Instinct 2 Classic (Xbox One)
Code Mystics
Released: September 2014

Official website: www.xbox.com
Publisher website: www.microsoft.com
Developer website: www.codemystics.com

I was moved onto this project not long after Killer Instinct Classic to create the front end for it. This wasn't a lot of work since it was very similar to the front end I'd previously done, although it did need several changes.

The Bridge The Bridge (MAC, Linux)
Code Mystics
Released: May 2014

Official website: www.thebridgeisblackandwhite.com
Original Developer website: The Quantum Astrophysicists Guild
Developer website: www.codemystics.com

This project required conversion from XNA (a framework I had never worked with) to Unity (a framework I knew nothing about). Needless to say, it was definitely a learning experience. I began the initial porting over of the code and worked primarily on getting the rendering and controls to work. Later, other folks (George, Peter and Jeff) joined in to complete the game as their current projects ended. I was scheduled to start on Killer Instinct Classic and so I didn't work on this game to its completion.

Black Dragon Blitz screenshot Kickin It - Black Dragon Blitz (Web/HTML5)
Code Mystics
Released: April 2014

Play online: lol.disney.com (Doesn't like Chrome)
Developer website: www.codemystics.com

I worked on this project soon after Rail Runner. The levels in this game are enormous and were pieced together using various bitmaps arranged layer by layer in a Photoshop image file. I had to go into each one and manually add all the enemy spawn points, collision/platform geometry and the event triggers. It was brutally painstaking and time-consuming. I had to write the game as well. :)

This game could honestly have used more time to tune and polish it but the schedule was just too tight given that I had to do so much work on constructing the level data. It was kind of fun to write, though.

Killer Instinct logo Killer Instinct Classic (Xbox One)
Code Mystics
Released: November 2013

Official website: www.xbox.com
Publisher website: www.microsoft.com
Developer website: www.codemystics.com

I started working on this project after working on The Bridge and a couple of HTML5 games.

Killer Instinct Classic was packaged along with the new remake of Killer Instinct for the Xbox One and is a pixel-perfect emulation of two versions of the original arcade Killer Instinct game released in 1994. The emulation was handled by Code Mystics' FOCAL engine. I was responsible for writing the non-emulated front end and menus.

Rail Runner screenshot Mickey Mouse in Rail Runner (Web/HTML5)
Code Mystics
Released: July 2013

Play online: lol.disney.com
Developer website: www.codemystics.com

This was my first HTML5 game. Picking up JavaScript was easy enough. The levels in this game are all procedurally-generated. Other than that, this was a pretty basic project with no real bumps along the way.

Patchworkz logo Patchworkz (Android)
Code Mystics
Released: December 24, 2012

Google Play Store link: Free version
Google Play Store link: Full version
Developer website: www.codemystics.com
Publisher website: www.bigfishgames.com

This game was originally to be a port of the iOS version of the game. However, the code base was so unnecessarily massive and incomprehensible that I wound up rewriting it from scratch using the original art and sound assets (and fixed a few bugs that were in the original game, to boot). One of the more impressive aspects of the game is its ability to adapt to virtually any set of screen dimensions (rather than resort to letterboxing), a feature entirely attributable to Jeff, who master-minded the draw rules to pull it off. He also took care of re-creating the layouts for all the front end screens using those rules.

I wound up rewriting the entire game engine and front end code (using the original source only to discern the game rules and scoring). Peter and George dealt with the FOCAL abstraction code for Android. Peter also wrote the store purchasing code, while George handled the in-game ads and downloading.
Fix-It Felix Jr.screenshot Fix-It Felix Jr.screenshot Fix-It Felix Jr. (Arcade)
Code Mystics
Released: July 2012

Promotional product for Disney
Developer website: www.codemystics.com

Boy, did I love working on this game. :)

Disney had previously displayed a non-working mock-up of a Fix-It Felix Jr. arcade cabinet at E3. They wanted an actual retro-style Fix-It Felix Jr. game running on it. I was the lucky, lucky person who got to do that. My long-time friend and co-worker Ryan Slemko got to do the art. Jeff took care of establishing the technical limitations that would be imposed on the game based on the capabilities of 1980s hardware. He also created much of the audio for the game. This left me with working out the play mechanics and writing the game.

Since the movie hadn't been released yet, all I had to go on for design and gameplay was snippets of the game from the movie provided by Disney. It was apparent that certain liberties were taken with some parts, in that for several close-ups of the screen, the characters were given more real estate than was actually available. For example, the movie shows a lot more surface area on the roof of the building when Ralph is thrown off than would actually fit on the screen. I did manage to fit everything together and make it work, though.

I had to devise mechanics for the game that would satisfy both the studio and Rich Moore, the director of the movie. The game went through roughly four variations of the mechanics before it was good to go (in the first implementation, it was up to the player to stay on the window sills, i.e., you could fall off the building).

As a retro-game, Fix-It Felix Jr. is pretty acccurate. Jeff designed the colour palette to use only colours that would have been available to video hardware circa 1982, for example. There are aspects to the gameplay that do not formally suit an arcade game made in the 1980s; certain compromises had to be made to keep everyone happy. Voices could not be used in the game for legal reasons, so it was also decided that Fix-It Felix Jr. would not have been a big-name game back in 1982 and so its "budget" did not include any speech.

The game had essentially infinite levels with a difficulty cap (which is reached at level 10) but it was decided to implement a "crash" that would occur when the game tried to advance to level 40 (Disney was enamoured with the idea of a kill screen and saw this as a feature). The crash is an homage to Pac-Man and simulates a stack overflow due to an infinitely recursive function call, which overwrites video memory. Those who have played the game and reached this crash may have noticed that the characters that fill the screen consist of the movie's release date repeated over and over. I also decided to implement a fake memory test that appears both at startup and when the game "resets" after it "crashes".

The game, in its mock-up arcade cabinet, made its debut at Comic Con in 2012 (shown in this YouTube video). Initially, Disney made 10 or so cabinets that traveled around the United States leading up to the film's release. All told, Disney made approximately 50 cabinets, several of which are located at Disney Parks where you can play them.

This was the most fun and enjoyable project I've ever worked on. The primary reason for this is because it's the only game I've ever worked on where I got to actually see people playing the game and enjoying themselves.

Trivia: on the default high-score list, my initials ("DES") appear in 2nd place. My boss took first place. :)

Dreamwalker screen shot Dreamwalker (Nintendo DSiWare)
Code Mystics
Released: June 6, 2011

Official website: www.dreamwalkergame.com
Developer website: www.codemystics.com
Publisher website: www.codemystics.com

Dreamwalker is based on an original idea by Jeff, who also helped out with parts of the front end. This is actually the first game I worked on at Code Mystics. Development was temporarily suspended to complete Atari's Greatest Hits Vol. 1 and Vol. 2.

I worked on the framework, front end, and the game itself. As well, George wrote a nifty level editor for it.

Atari's Greatest Hits Vol. 2 - Box Art Atari's Greatest Hits Volume 2 (Nintendo DS)
Code Mystics
Released: March 8, 2011

Official website: Taken down
Developer website: www.codemystics.com
Publisher website: www.atari.com

This is the second Prometheus/FOCAL combination project released by Code Mystics. In addition to dealing with the front end, overall flow and related visuals, I also implemented a mark-up script and interpreter for several of the included game manuals, and dealt with the playback for the included Nolan Bushnell interview videos.

Atari's Greatest Hits Vol. 1 - Box Art Atari's Greatest Hits Volume 1 (Nintendo DS)
Code Mystics
Released: November 2, 2010

Official website: Taken down
Developer website: www.codemystics.com
Publisher website: www.atari.com

This was the first project released by Code Mystics that used the Prometheus framework (designed and written by myself) for dealing with the asset pipeline, localisation, overall application flow, front end and transitions. It also used the FOCAL framework (Flow-Optimised Code AnaLysis, designed and written by Jeff). Prometheus handled the overall menu flow, front end and transitions while FOCAL handled all game emulation. FOCAL was also used to implement several playable online game emulations for Atari such as Asteroids and Centipede, which can be found here.

My job on Volume 1 was to implement all the front end menus and related visual effects, as well as writing the included trivia game.

Monster Lab Monster Lab (Nintendo DS)
Backbone Entertainment
US release: November 4, 2008

Official website: Taken down
Developer website: Backbone Entertainment site is no more
Publisher website: www.eidos.com
Average review rating from Metacritic.com: 75%

I was brought on to help finish this project which, considering the vast number of mini-games and challenges in it, was a rather ambitious undertaking by Backbone. As it was being cross-developed on the Wii, Monster Lab consumed a good deal of the studio's workforce.

I was responsible for implementing three of the mini-games: Brain Toss, Astral Reach and Stitching. As far as I am aware, these are the only three mini-games that used any 3D at all (they're also the only mini-games that run at sixty frames per second.) Brain Toss was primarily 2D though I did choose to implement the catapult as a 3D object. Astral Reach and Stitching were both done entirely in 3D using procedurally-generated level data and geometry. Stitching was particularly fun to write because when a stitch closed, it pulled the skin geometry together in a convincing fashion, even going so far as to stretch the surrounding skin. Both 3D games took a week or less to implement fully in wireframe followed by a couple more weeks waiting for texture art and then polishing and tuning them. Brain Toss, the 2D game, took significantly longer to implement because nobody seemed to know how it was supposed to work.

This was pretty much the last project I worked on at Backbone Vancouver before Foundation 9 shut down the entire studio and I was consequently laid off.

Death Jr and the Science Fair of Doom Death Jr and the Science Fair of Doom (Nintendo DS)
Backbone Entertainment
US release: May 22, 2007

Official website: Taken down
Developer website: Backbone Entertainment site is no more
Publisher website: www.konami.com
Average review rating from MetaCritic.com: 47%

This project required the design and implementation of a 3D engine pretty much from the ground up. It was co-designed and written primarily by myself and Pierre Tardiff, and implemented on top of the NitroSDK and NitroSystem libraries. My part was to write most of the rendering systems, which included all the scene rendering, the animation system, the camera system and the trail and particle effects systems, all of which were carried over and used on the next project. The low scores on GameRankings and Metacritic reasonably reflect the multitude of managerial and organizational problems that plagued this project throughout its development.

Age of Empires: Age of Kings Age of Empires: Age of Kings (Nintendo DS)
Backbone Entertainment
US release: February 14, 2006

Official website: Taken down
Developer website: Backbone Entertainment site is no more
Publisher website: www.majescoent.com/
Average review rating from MetaCritic.com: 80%

For this project I ported our GBA library to the DS, updated all the documentation, and subsequently played a support role implementing changes, enhancements and bug fixes to the library and resource pipeline as the project went on. Most of my time was spent independently studying 3D rendering and animation on the DS and finding ways to work within its limitations.

Midway Arcade Treasures box art Midway Arcade Treasures: Extended Play (Sony PSP)
Digital Eclipse Software
US release: December 13, 2005

Official website: Taken down
Developer website: Backbone Entertainment site is no more
Publisher website: www.midway.com
Average review rating from MetaCritic.com: 63%

I was put on this project to help them get it done. Most of my time was spent getting sound effects streaming working properly for some of the games and speeding up the rendering for Wizard of Wor. Defender's scrolling landscape looked like hell because of the horrible latency with the PSP LCD display; once the landscape started scrolling it would simply disappear completely.

After trying a rather elaborate buffering/redraw algorithm to keep the terrain on screen for several frames, we discovered something interesting about LCD screens. As long as at least one of the color guns is completely saturated, the problem goes away. In the end we simply had to saturate the red gun on the terrain (which was already reddish brown anyway) and the problem was solved.

Atari Masterpieces Vol. 1 box art Atari Masterpieces Vol. 1 (N-Gage)
Digital Eclipse Software
US release: October 13, 2005

Official website: Taken down
Developer website: Backbone Entertainment site is no more
Publisher website: www.nokia.com

After Rayman, I was put to work helping out on this N-Gage project. While my job was primarily to get the front end done (menus, credits, unlockables), I also helped out here and there with emulation on Millipede and Red Baron. I also added some minor assistance to Atari Masterpieces Volume 2, implementing various bits of the front end.

Rayman: Hoodlum's Revenge box art Rayman: Hoodlum's Revenge (GBA)
Digital Eclipse Software
US release: March 30, 2005

Official website: Taken down
Developer website: Backbone Entertainment site is no more
Publisher website: www.ubisoft.com
Average review rating from MetaCritic.com: 61%

After Tron, I helped finish Rayman. Oddly enough, I never worked on the front end for this one. My time was spent implementing the Reflux boss battle.

Tron 2.0: Killer App box art Tron 2.0: Killer App (GBA)
Digital Eclipse Software
US release: October 19, 2004

Official website: Taken down
Developer website: Digital Eclipse site is no more
Publisher website: BV Interactive site is no more
Average review rating from MetaCritic.com: 68%

Given the time we had and the amount of features in the game, Tron 2.0: Killer App was a very large undertaking and many people were brought on to get it all done. John Kowalski joined up to write the 3D engine used for the tank and recognizer games, while Pierre Tardif worked on the light cycle game, virtually all the network code, many game objects, the boss battles, and several front end screens. Vernon Brooks handled all the emulation for the classic arcade versions of Tron and Discs of Tron. Throughout the project, other programmers helped out with various miscellaneous tasks as well.

My own tasks included library management, implementing the game/item database, several front end screens including the chip trading screen, all the cut scene scripting, most of the NPC objects and various other game objects, localized text and dialogue management, the security hack mini-game (which was designed by Luc Verhulst and myself), and the firewall mini-game (designed by Luc, Ryan Slemko and myself).

IGN had this to say about the game:

"It's pretty clear that the guys over at Digital Eclipse know what makes the Tron property "cool" because they've incorporated a ton of that cool factor in Tron 2.0: Killer App."

Gamespot had this to say (regarding an earlier preview version of the game):

"Tron 2.0: Killer App is shaping up to be a GBA game that has a little something for everyone. The isometric adventure feels like a solid experience with impressive visuals, while the minigames serve up an addictive batch of old-school gameplay that's always good to see."

This is the fourth GBA project I've worked on that uses our Dragon library, and the third one that uses Dragon's isometric engine module. I was about ready for something a little less isometric at this point.

Cat in the Hat box art Dr. Seuss' The Cat in the Hat (GBA)
Digital Eclipse Software
US release: November 4, 2003

Official website: Taken down
Developer website: Digital Eclipse site is no more
Publisher website: VU Games site is no more
Average review rating from MetaCritic.com: 40%

The Cat in the Hat was a project under development at Digital Eclipse while I was working on Spyro: Attack of the Rhynocs. Being tightly tied to a movie release, it was a game that absolutely had to be completed on time. I was temporarily brought over to spend a couple of weeks on this game creating the front end and menus for it. I thought I'd add some springy sprite scaling effects to the icons, since it seemed to fit in with the general wackiness of the rest of the game. I had to work fast, however, as I couldn't afford to spend much time away from Spyro. I sort of flip-flopped between the two projects as necessary. I'm pretty happy with the result. It was fun to work on.

Pierre, the lead programmer on Spyro, also spent a brief amount of time on this project, implementing the two boss enemies in the game. I think this ultimately helped us both with Spyro, since it got our heads out of "Spyro-space" long enough to give us a second wind when we returned to it, kind of like a mini-vacation.

Spyro: Attack of the Rhynocs box art USA: Spyro: Attack of the Rhynocs (GBA)
Europe: Spyro Adventure
Digital Eclipse Software
US release: October 28, 2003
European release: November 14, 2003

Official website: Taken down
Developer website: Digital Eclipse site is no more
Publisher website: Universal Interactive is no more
Average review rating from MetaCritic.com: 72%

When we began developing Spyro: Attack of the Rhynocs, I read the game design document and realized that it involved collecting 100 different objects (as opposed to 100 fireflies, or 100 fairies). While this was a good enhancement, the items were predominantly random and had no real function in the game. I think that, by the end of the game, there were about twenty-four items that you sort of just... had. Despite the design being already signed off, and development already started, I began pushing (fairly agressively) for the addition of quests. After several days of this, I was allowed to add quests to the game.

Designing the quests was difficult due to severe time constraints. I had to come up with entirely new objects to replace all the random objects and group them into nine quests. All the items in each quest had to be themed and make sense. I then had to design the quests themselves, place all the objects in the world, and document all of it. I had three days to do it all but somehow managed to get most of it done.

In the end, the effort was worth it. The game turned out well, though Universal did make us "dumb down" several puzzles to satisfy their target market (when you see the nine-square puzzles, you'll know what I mean).

GamePro had some really nice things to say about the game:

"This RPG-like twist ultimately becomes the game's best feature, easily outshining the repetitive platform-hopping segments." (a rather back-handed compliment, really)
"Tight, responsive controls seal the deal, making Attack of the Rhynocs the most enjoyable GBA Spyro title to date."

Aside from the design work, I also had the usual tasks of implementing the front end (including the journal), creating most of the puzzles and NPCs, and the 150 cut scene scripts (not to mention the cut scene script compiler and script engine). There was also the internal item database, dialogue sequencing, and on-going library maintenance.

As an aside, I really wanted to put Elora somewhere in the game, but our work load was simply too intense, and Elora unfortunately fell through the cracks. If we do another Spyro game, I'm going to push for Elora as a playable character. :)

Spyro: Season of Flame box art Spyro 2: Season of Flame (GBA)
Digital Eclipse Software
US release: September 24, 2002
European release: October 25, 2002

Official website: Taken down
Developer website: Digital Eclipse site is no more
Publisher website: Universal Interactive is no more
Average review rating from MetaCritic.com: 76%

After completing Spyro: Season of Ice, everyone took a much needed vacation, but work soon picked up again on the sequel. Many of us had been scouring the message boards for user feedback, and this resulted in a sizable list of changes and improvements, in addition to the list of improvements we had come up with ourselves. We originally wanted to make something more like an RPG, but time constraints gave us no choice but to stick with a formula similar to Season of Ice (we had about a month less time to complete this project than we had for Season of Ice, and fewer programmers as well.)

The time constraints were imposed because we were expected to reuse the isometric engine in the sequel. However, the isometric engine was a complete mess, in that it was almost entirely hard-coded for Season of Ice. Reusing the engine was risky business, since the original programmers who wrote it were no longer on the team. We made the hard decision to throw it all away, redesign it, and rewrite it from scratch. Thankfully, this turned out to be the correct decision, and despite months and months of long, hard hours of work on everyone's part, we managed to finish the game on schedule.

I was kept extremely busy on this project. Aside from creating the technical design, I was also responsible for making improvements to the library code, creating the resource and localization pipelines and tools, writing the front end, most of the in-game puzzles, some enemy AI, and many of the shared game-specific code modules. I also had to help out from time to time with the many changes required by Konami for the Japanese version of Season of Ice, which was being dealt with by two programmers from the Season of Ice team. Everyone else was similarly burdened, and because we chose to rewrite the isometric engine, it was necessary to work much harder on this project than on Season of Ice. All that work seems to have been worth it, as the game is receiving generally favourable reviews, from both game magazines and the players themselves.

Spyro: Season of Ice box art USA, Europe: Spyro: Season of Ice (GBA)
Japan: Spyro Advance
Digital Eclipse Software
US release: October 1, 2001
European release: November 16, 2001
Japan release: December 26, 2002

Official website (US/Europe): Taken down
Official website (Japan): Taken down
Developer website: Digital Eclipse site is no more
US/European Publisher website: Universal Interactive is no more
Japan Publisher website: www.konamistudio.com
Average review rating from MetaCritic.com: 74%
Spyro Advance (Japan) box art

When I first started working at Digital Eclipse, Season of Ice had already been in development for a few months. I was put on the Spyro team and given the task of designing and writing the bonus game that would be unlocked by collecting all the items in the game. Universal wanted a retro, arcade-style game based on the classic game Star Castle. The result was Dragonfly X, a mini-game I had a lot of fun creating, but appears to be universally hated by everyone. I'm not sure if they hate the game itself, or the way I implemented it, or both.

I didn't have a GBA devkit for the first couple of weeks, so I spent my time designing, writing and documenting a core library that included a localization pipeline for handling multiple languages. It was eventually incorporated into the game. While working on Dragonfly X, I created a primitive resource pipeline that was eventually expanded upon and improved for the sequel, Spyro 2: Season of Flame.

Towards the end of the project, I was also given the entire front end to write, including the atlas and gem tally screens, and all the menus. The last month of the project was a blur of 18-25 hour days for everyone on the team. It was the very first GBA game for the team, and many hard and fast lessons had to be learned along the way.

Gunmetal box art Gunmetal (PC)
Mad Genius Software
released August, 1998

I started working at Mad Genius immediately after leaving Radical Entertainment. The original plan was that I, along with a few other ex-Radical folks, would be working on a brand new RPG, but we ended up spending all our time helping with the completion of Gunmetal, a game with a great story, but with an appallingly ill-conceived technical design and terribly-written tools that had put them way over schedule. Imagine a level editor that doesn't even warn you about non-coplanar points on a quad. Now try to compute a working normal for a non-coplanar quad. You get the idea.

I didn't even get to do any programming on the project; all my time was spent fixing the level data, mostly by using a spreadsheet I created to compute 3D vectors and normals for steam jets that shot out of oddly-angled walls. I also had to use the aforementioned tools to help complete various levels of the game. I was a map-monkey.

The company ran into financial woes, and went belly-up about eight months after I started. The ex-Radical people (including myself) all bailed out and went to work for Starnet Communications for the next two years, doing database programming (which was fun for about two years). After leaving Starnet, I went to work for Digital Eclipse.

Powerplay '98 box art NHL Powerplay '98 (Playstation)
Radical Entertainment
released in Fall, 1997

Developer website: Radical Entertainment site is no more
Publisher website: Virgin Interactive is no more

This was the last game I worked on at Radical. The team was quite large and I was relegated to "cog in a machine" status. The rink surface in NHL Powerplay '96 looked like hell. It suffered from significant amounts of texture warping (a well-known issue with the Playstation). My job was to rewrite the rink surface rendering code.

I had an advantage, in that the rink surface was always the very first thing rendered, so I was able to write my code separately from the rest of the game's rendering code. This allowed me to make the rink surface many times larger in scale than the rest of the display components, resulting in less camera jitter. I obviously had to adjust my camera's distance to make the rink surface appear the same size as the rest of the arena geometry. My camera is much farther away.

I created a script that was parsed on the fly to generate the rink surface geometry using an appropriate level of detail based on the camera distance, and used flat-shaded polygons for all the rink surface lines and markings. I also added recursive geometry scaling, which would scale the geometry down by half, and halve the camera distance, cumulatively each time the camera zoomed out past a specific threshold. This allowed the camera to zoom out indefinitely without any clipping or fractional imprecision problems.

I left Radical not long after starting work on the next NHL Powerplay game.

Grid Runner box art Grid Runner (Playstation)
Radical Entertainment
released in 1996

Developer website: Radical Entertainment site is no more
Publisher website: Virgin Interactive is no more

This game marked a couple of personal milestones. It was my first experience with 3D graphics programming, and it was the first game I worked on that was simultaneously developed for multiple platforms (Playstation, Saturn, and PC). It was a major learning experience.

Because the game was being developed for multiple platforms, it was broken up into portable and platform-specific code modules. I was responsible for the Playstation-specific components, which included the front end and the entire rendering engine.

You won't see my name in the credits for this game. The political manoeuvering going on with this project was ruining it. This became so maddening that I had my name stricken from the credits, so frustrated was I. Despite the fact that this game ended up a complete train wreck, I still learned volumes from the experience, mostly about code design.

Oh, and R3000 assembly language was the most fun ever.

No box art exists. Eurit (Super Nintendo)
Radical Entertainment
never released

Developer website: Radical Entertainment site is no more

Eurit was being developed as an in-house project at Radical. I was given the task of writing the front end for it. I redesigned and rewrote the front end library I had created for the Sega Genesis, making it better than it had been. The front end turned out great, and some people said it was the most polished-looking game Radical had made up to that point. Another producer even used my opening Radical logo sequence (on the SNES) for a demo video of his Playstation title The Divide: Enemies Within. Hee hee.

Unfortunately, the SNES was nearing the end of its days, and Radical was unable to find an interested publisher, so the game eventually disappeared into the ether. Eurit was, however, resurrected in the form of a Playstation game called Grid Runner.

As an aside, the front end library I wrote for Eurit was adopted for use by the Exertainment team. They wrote the SNES software that interfaces with exercise bikes.

Pele II box art. Pele II (Sega Genesis)
Radical Entertainment
released 1995

Developer website: Radical Entertainment site is no more

This game marks the first time I ever got to work on a game console. Up until this point, I had been making games for the PC and Commodore 64. This was also my first project at Radical. I was responsible for writing the front end for this game.

I was given a "library" to use, but it consisted of three or four functions, and the sprite DMA stuff didn't even work. I threw it away and wrote my own library, which included task handling and other nifty tools for palette cycling and sequenced, non-linear motion. I felt quite at home programming on the Genesis, since I had already been doing 68000 assembly language programming for several years by that time.

For the roster screen, Accolade wanted "something better than just a screen full of numbers". The artist and I spent a lot of time on that, and eventually decided to play down the stats in favour of having a roster screen that looked and worked in an interesting way. The players are lined up on the field, in order of their position, and you can pick two players to swap. The players each step out of the line and run up or down the field to assume the other's position. It was really cool.

The game had a flaw, however, in that there was a relatively simple strategy for scoring, which worked no matter which two teams were playing. Bit of a disappointment, there. At the end of this project, the Eurit team invited me to join them and write their front end.

Stratego box art. Stratego (PC)
Mindspan Technologies
released 1991

Developer website: Mindspan Technologies is no more

After completing Mondu's Fight Palace, there was no project immediately available for me to work on. Being short on staff, and having liked my touch-up artwork, they gave me the task of doing all the touch-up artwork for Accolade's Stratego. This involved touching up all the pieces and boards, each for the CGA, VGA, and MCGA display modes supported at the time. It was a lot of painstaking work.

I left MindSpan shortly after finishing my work on Stratego. I stayed unemployed for a couple of years, and then got a job doing touch-screen bingo software that eventually led to us moving to Antigua and living there for four months. Much adventure was had in Antigua. After returning to Vancouver, I got a job at Radical Entertainment in February, 1994.

Mondu's Fight Palace box art. Mondu's Fight Palace (Commodore 64)
Mindspan Technologies
released 1990

Developer website: Mindspan Technologies is no more
Publisher website: www.Activision.com
Box Art: at GameFAQs

Working at MindSpan was tough. It was a very small company (only about 6 people in total) and working on a game there meant you did the whole thing by yourself. While an artist was typically assigned to each project, I did not get even that luxury when I was given this game to write. I had to write several custom tools as well.

I wrote sprite multiplexing code that enabled me to display 56 sprites on the screen at once. Each fighter is made up of 20 sprites (four across by five high), which proved a tad short-sighted when I realized I had no sprites left for the weapons that each fighter uses. I had no choice but to use background graphics for the weapons, which didn't look so hot.

All of the artwork came from the PC version of the same game, Tongue of the Fatman. It was all 256-colour source art and it all had to be converted down to three-colour sprites. Needless to say, there was a pantload of touch-up work that had to be done. All in all, though, it was a fun game to write.

DScroll demo screenshot D-Scroll screen hack (Amiga)
Personal project
Released: 1989

A long time ago (1988 or 1989) I saw a screen hack demo on the Amiga called A-Scroll that scrolled text up the screen but warped it horizontally. It was clearly written for PAL Amigas because it ran at only 30FPS on an NTSC Amiga. Regardless, neither I nor my Amiga friends could figure out how the hell the guy was doing this effect. We puzzled on it for many days.

One day, I was sitting in a restaurant having a coffee and A-Scroll crossed my mind again. For some reason, right at that moment, the entire solution as to how it was done just popped into my head all at once. Since I had my notebook with me I proceeded to design a demo screen that would illustrate this effect. The resulting code was a copper list fiesta.

The screenshot above is of an older version of the demo, before I added more visual effects and a large scroll-text along the bottom. It's the only version I can find. :(

DES-Tracker screenshot DES-Tracker (Amiga)
Personal project
Released: 1989

DES-Tracker was an Amiga library that you could use in your own programs to load, play and control tracker music. What set it apart from other tracker players at the time -- aside from being a formal Amiga library -- was it allowed you to specify start and end play positions based on play time rather than absolute song position. The library essentially simulated time while it parsed the music data until it reached the desired time. It even calculated what instrument sample was playing at the moment and where in the sample it would be at that point in time (this was necessary for keeping looped riffs in sync).

You can still find DES-Tracker on AmiNet sites.

Road Raider box art. Road Raider (Commodore 64)
Distinctive Software
released 1988

Screenshots: www.giantbomb.com

This was the first game I wrote entirely. I was working for Distinctive Software (later EA Canada), and the Commodore 64 version of this game was subcontracted to us by Grey Matter. I don't have much to say about this game, other than I was really happy with the way the car physics, tire wear, and homing missile physics turned out. The game was a lot of fun to work on, but everything else about the company just made me miserable. I also did the European version, which was released under the name Motor Massacre.

After Road Raider I started work on a Commodore 64 game called Thud Ridge but then left the company. That game apparently turned out so bad that none of the programmers after me wanted anything to do with it, and left my name in as the sole programming credit. Lovely.

DES-Tracker screenshot Envision (Atari 400/800/800XL/XE)
Personal project
Released: 1986
Published by ANTIC Magazine

Envision was my first project of any real scope and my first published work of any kind. Written in 100% 6502 assembly language (using SynAssembler), it ultimately supplanted the iconic InstEdit in ANTIC Magazine's software catalog. It took me approximately two years to write it, mostly because I had to learn 6502 assembly language as I went along.

I've created a page specifically for Envision elsewhere on this web site.

I also did miscellaneous work on the following games: