I’m that guy who invented the data-driven component/game object system that Unity and some other game engines are based on.
I led the development of games that were installed by literally a billion users at our studio of 20 that started in my spare bedroom.
I once remote-debugged SPU assembly on a devkit in Seattle from a Peruvian beach house over ISDN.
Every December I roll up my sleeves and do my part to help save Christmas.
Career Profile
In the three decades of my career, I’ve done everything from managing a game studio to steering architecture to creating scripting languages to crawling around under desks hooking up handmade patch cables. I’ve shipped games of all sizes with both custom engines and third party tech. I’ve been a core contributor to sustained releases of software-as-a-service for many years. I participate in open source and publish my own projects.
I am fundamentally motivated by just a few simple things:
- Collaborating with others to solve problems people actually care about
- Seeing creative people happily using my mundane work to build amazing works of art
- Having space to follow threads wherever they lead (this always pays off)
Read on to see how I have executed on this. 30 years is a long time, so here are some friendly shortcuts to the good stuff:
My Time At Unity
I can’t just list Unity as an “experience” item, not after 11 years, nearly half my career.
My time at Unity is special, bigger and different from anything else I’ve done.
I have held a variety of roles as the company evolved and grew up. Way back when I started, we were all simply “Software Developer”. (I liked that the best tbh.) I led teams, drove initiatives, worked directly for and with executives, defined technical strategy, collaborated in countless architectural steering decisions, and also did a huge amount of hands-on full-stack coding. Here are just a few highlights:
- Committed a huge number of PR’s for the Unity engine and editor, and supporting tooling and infrastructure.
- Drove codebase modularization efforts, improving maintainability and performance at scale.
- Owned the R&D training program, which grew out of my team’s onboarding program. We would bring new engineering hires from around the world to Copenhagen for a week of sessions and socializing.
- Owned coding standards and conventions, including full-repo reformat and CI enforcement.
- Built efficient test suites and frameworks.
- Was on the ground floor when DOTS was born, became a high level IC to focus on critical real-world analysis and feedback.
- Brought a mid-size internal production into our monorepo, focused on removing friction, got it in the hands of all developers.
At Unity I have learned what it takes to reliably produce big middleware, as a service, to millions of gamedevs and billions of end users. The tradeoffs involved in production speed, advancing technology, maintenance, and stability. The contradictory demands of a huge user base, and the enormous costs incurred when we fail to listen to them. The difficulty of coordinating development across orgs and countries and time zones and engineering cultures and backgrounds. It’s a mind-numbing amount of multi-dimensional complexity to manage, and it amazes me every day that, all things considered, we manage to keep on shipping.
Other Experience
I remember first walking into the old Bungie bunker, looking around and exclaiming “look at all that firepower”. This was a studio that was hyper focused and dripping with experience, success, and (very new for me) mad resources.
After a short onboarding through Halo I joined the top secret next project “Tiger”, which became Destiny. It was crazy ambitious and we were building out the world editor for it. Over and over we were asked “is it going to have undo please?” by people experienced with the old toolset. For details on this work see Grognok. I also worked on a variety of other tools and systems, but Grognok was the main event. I eventually took lead on it.
Also I was deeply engaged in studio-wide workflow discussions, infrastructure needs, improving branching strategies and developer efficiency. It was inevitable that I’d be the one migrating Bungie from Source Depot over to Perforce, retaining not only full history, but digging up the ancient SourceSafe and wiring up its history in there as well.
I left Bungie for our family move to Scandiland. Was prepared to work for a bank or whatever, but Joachim the CTO of Unity had been keeping in contact with me, and convinced me to hook up with him in Copenhagen.
Loose Cannon was an absolutely awesome and scrappy little startup game studio. Such amazingly creative people, so motivating to be supporting them with tools and tech. See Tornado Outbreak for details on my work there. I was one of the seniors building out core systems and tools, and so held a key role in steering the architecture of our engine.
LCS had a strong tradition of peer review on game code that they brought over from Sucker Punch. I optimized it by setting us up with an async review system for the “easy” changes, helped design and create the “prime review group” and some workflow tooling to ensure everything got reviewed and always had a prime reviewer involved.
As is my pattern, I ended up migrating us from Subversion to Perforce and administering it. Along with Jira, Confluence, Crucible/Fisheye. One interesting tool I created was a central P4 clientspec manager, to easily fix and align everyone’s workspaces at once. I brought this idea to Bungie and Unity as well.
I left Loose Cannon because the company was struggling, missing paychecks, and got pulled away by some people I knew at Bungie. It was bittersweet - I remember shedding tears after I made the decision and accepted the job.
I joined the small movement of big-game developers giving up a life of crunch and big budgets, aiming to ship games in months rather than years. Initially I was just a hired gun helping out on a project, but we managed to spin it into a Seattle game studio, a satellite for New York-based Oberon Media.
We shipped a long string of reasonably successful games. I directed and/or contributed to the Vista In-Box Games, Betrapped!, Scrubbles, Parker, and more. The studio grew to over 40 people at its peak, as Oberon spun up local publishing operations. And of course I ended up doing our version control and a lot of other IT infrastructure.
I dipped a toe into game analytics by creating the Stripmine data mining platform. It was fairly primitive, but I learned a huge amount from this, lessons that stay with me to this day. For example, I tend to be suspicious of “the data says” statements, unless I personally look into the chain of ownership and processing of “the data”.
The studio had some leadership churn and I eventually took it over and managed its >$2M P&L. I wasn’t particularly prepared for this at the time, and got moved back to dedicated technical leadership. It wasn’t until Unity that I finally gained the business perspective and maturity that I would have needed to run Oberon Games effectively. I left Oberon because I was pulled away by some people I knew who were starting up something new and exciting.
I joined GPG’s debut game fairly early, and found the team to be extremely skilled and hard core. Perfect for me. On my first day I blew them away by fixing the horrible build times they were having (ok, it was with a simple pch config fix that they had missed).
I was one of the seniors hammering away at the foundations of the game. While I had my hands in many parts of the codebase, my top focus was iteration times, just like at Sierra. See Dungeon Siege for details on my work there.
Separately, one general workflow problem worth mentioning was that we were on SourceSafe, which is well-known not to scale. I migrated the full repo, history and all, along with the team, over to Perforce. We never looked back, and my reward (?) was to become “the P4 guy” for the rest of my life.
After shipping, I took the lead on our next big project Supreme Commander. But I was burned out and looking for something new, so I moved on very early in the project. Ok…it was a ragequit. I had no plans after this. Also, something it took me a while to admit to myself - leading such a project was way over my head at the time.
GPG was absolute peak difficulty for me in its strange combination of tech, drama, design, personalities, and overtime. We were all just kids then, and I couldn’t be prouder of what we managed to accomplish.
Sierra was where I started my lifelong quest for faster iteration times.
I joined Gabriel Knight 3, a project that was already under way and struggling. There were many reasons for this, but among the most important was the time it took for new content, especially design, to be integrated, tested, and experimented with. To help address this, I built out scripting, data-driving, hot reloading, and in-game debug infrastructure.
At the same time, I moved into a tech leadership role, leading by example, but also deliberately steering the architecture towards stability, debuggability, and performance.
I left Sierra to work with the Cavedog people (now GPG) who had created one of my all-time favorite games, Total Annihilation.
iCat Commerce Online was a crash course in the web development world of the time, as there was a mad rush to figure out how to sell things online. I chose iCat because they had a cool location. This job was very out of band for me. Have not repeated that mistake since.
I was part of a small team doing Windows + Mac development for educational software using an in-house engine called Xplat. My main project here was Cosmic Geometry. I learned an early lesson regarding the cost of complexity.
This was a business where most of my time went into a macro-heavy Excel 4 spreadsheet I built and used to generate reports. I’d do a bunch of manual entry from raw data I’d get monthly, and turn it into pretty charts with macro assistance.
This got complex enough that Excel would max out Windows’s available object handles and need a reboot. (I got to play this sort of game again at Sierra with certain leaky DCC tooling.)
Sole developer assisting a research principal at a university research laboratory to build Eddy. I was part time because of college, and was just trying to learn how to build software. This was the first time I built something “big” on my own. I was completely self-driven, as the principal had no interest in software.
I hosted a fan site for New Model Army called “51st State” on my dev machine at the lab. You could get away with such things back then, in the days before NATs, when all you needed was a DNS mapping.
Mostly I copied blueprints (the old ammonia kind), played Minesweeper, and fetched ice cream for people.
Projects
Contributions across the board to the Unity engine and editor. To pick a few: memory management, type systems, serialization, asset management, platform GUI, assert/log, scripting integration and bindings. I also introduced the internally-infamous Entities.ForEach to Entities.
I created countless internal supporting tools - project launchers, Roslyn analyzers, multi-language formatters, test suites and runners, build tasks, tooling configs, git hooks, integration benchmarks, journaling analyzers.
Later on, I worked a few years in a deeply experienced internal production team where we used, prototyped, vetted, and helped to shape upcoming Unity technologies (particularly those inside DOTS).
Grognok was the world builder for Bungie’s Destiny. Built primarily with C#/WPF, and some Managed C++ to bridge the native simulation code. This is one of my favorite projects ever. I designed and implemented the core object system, messaging, undo/redo, versioning, Outliner, UI framework, serialization, and a hundred other things I’m forgetting.
We applied or built a lot of (at the time) edgy tech along the way - dependency injection, interface-first design, interceptors, MVVM, enumerables and observables, stateless coding. I called it “trivial safe multithreading”. It was a heavy .NET app where we didn’t worry much about GC and the thing ran buttery smooth, yo.
I also of course built a v3 component-based game object system (v2 was TA, v1 was DS). This one was “extremely C#”, highly dynamic, oriented towards authoring, and deeply integrated with our observable systems, undo/redo transactions, and serialization.
It’s fun to remember this project because of the unexpected uses of what we built. Two of my favorites:
-
We got some odd requests by artists related to presenting (hide the UI, go full screen..). It turned out that they were using Grognok for art reviews and presentations. The game wasn’t ready yet, and Grognok showed their work with high fidelity and performance.
-
We implemented a simple copy-paste-drag-drop system that happened to store as compact encoded plaintext. Later we found that artists were loading two copies of Grognok, using one as a personal gallery, the other for the actual world building, and a lot of drag-dropping between them. They also would copy things from Grognok they liked for reuse into OneNote, or email them to each other, and the deserializer would generally figure out how to let them paste the gobbledygook into their world.
I did some work on Halo tooling to cut my teeth at the studio. Mentioning it here because it was enough for a credit!
While Loose Cannon tried to get funding, I was loaned to PopCap to keep the home fires burning. I spent a month-ish helping them get their Awesomium-based Facebook integration for Bejeweled Blitz working for the socials. Fun, weird, scripty work at a cool company.
Cartoony fun tornado destruction game with Katamari-esque gameplay launched on PS3, 360, and Wii, plus PC for dev work. This was my first real console title! Metascore 62-71 depending on platform. Tornado Outbreak unfortunately suffered from publisher drama which hurt the game. Still, I absolutely loved this project and our little studio - we had a lot of fun and did solid work.
A few things I recall building are the memory system, Lua integration and gamecode framework, a remote debugging/livecode tool, and audio (Wwise) layout and integration. And of course I built a native/script component-based gameobject system, though being greenfield it was a much cleaner and simpler v2 versus the system I built for DS.
All of this had to work well and fit in memory on all the consoles - the Wii made that most difficult of course. I also learned the joy of meeting platform certification requirements on three platforms at once.
A further note on the livecode tool Fuse - this is one of my favorite things I’ve ever done. Because I chose Lua for our gamecode language, and running Lua code involves dumping text into the runtime, it was easy to build a tool that ran on Windows, connected to device with a socket, and hot reload gamecode. On all platforms, including the little Wii, thinking of an idea in-game and trying it out live took milliseconds and retained all existing state. I configured my Lua gaming framework to keep this as safe as possible. Also, because it’s easy to have Fuse shoot a bunch of injected code over upon connect, this was an easy way to debug live game state, by having the Lua on the other side report back watched variables etc. Loved this work.
I led the studio’s effort to build the “in-box” games that launched with Vista: Mahjong, Purble Place, Chess, and Minesweeper, plus the card games Solitaire, Spider Solitaire, FreeCell, and Hearts.
Building games to be bundled with a Microsoft OS is unlike any gamedev experience I’ve ever had - extreme requirements for regional/political/language correctness, accessibility (hearing/seeing impairment), security, and original code/IP ownership guarantees. Plus the craziness of trying to dev against alpha tech and virtual build labs as an outside contractor with zero access to source. I used to call it “debugging through a keyhole”.
Our games managed to survive past Vista into Windows 7, which meant that we shipped to well over a billion users!
A sequel to Inspector Parker, this time in Flash, with isometric layout, and a Minesweeper mechanic. I honestly can’t remember what I did on this title, but I remember spending a lot of time close to the screen checking pixel offsets.
This was a “bustamovelike” and our first experience with Flash. I did a variety of protoyping and game coding tasks. I also wrote a game host with some weak custom DRM for the Flash component so we could distribute it as a standalone game, which we reused in a few other titles. Scrubbles had a checkered development with starts and stops and design churn, but I’m super proud of this very silly game.
My first casual game! Inspector Parker was a deductive 2D puzzle game, already in production when I joined to help finish it. It sold well enough for us to get funded to launch a real game studio.
Parker was built in Macromedia Director and programmed in Lingo, shipped both standalone and in-web using the aging Shockwave plugin. I did random production tasks - integrating art and sound, fixing bugs, whatever was needed. Using a commercial engine was a super foreign experience for me, and I quickly learned the joy of finding bugs in someone else’s closed source tech.
This was our first and last game built in Director.
This was an $8 million “3D Diablo with a pack mule and no loading screens” and, hey, we almost earned money on it! Metascore 86.
I built the game object system, content database, file system, save/load game, mid-layer multiplayer, script engine, resource compiler, event handling and state management, parameterized content, build system, mod system, and much of the debugging infrastructure and random utilities we had.
For the game object system, we were dealing with a “very C++” problem: the rigidity of static class hierarchies crashing into the reality of a fast-changing game that is trying to find the fun. Reconfiguring behaviors for game objects usually required a recompile after a risky class reorg, and the codebase was therefore evolving towards mega base classes. This inspired me to invent a data-driven script+native component system, which was so successful for us that I presented it as a talk at GDC. Another aid to iteration speed was my custom “skrit” language that built on ideas from GK3’s “sheep” language, particularly async/await, but also added high performance automatic native binding via fubi.
A further note on skrit and fubi: because every script function was dllexported, and new dll’s could simply export in the same way to be visible to script, we accidentally had a deeply moddable game. Some big mods were made by the community on top of this setup, and they weren’t limited to building solely in skrit because of the binding setup. Another fun accident was seeing our testers somehow writing skrit to do in-game fuzz-test automation of the world streamer.
DS had an extremely challenging design to implement for the PC’s of that era, especially because threading was sort of “new” at the time on PCs. We used to joke that we were solving impossible problems every (16-hour) day. I’m also quite proud of the infinite continuous world system we built for it, which had an architecture that permitted full skrit-based pcontent init and other game logic to run safely in the background.
Fun fact: my implementation of cheat code superchunky, which hugely cranked the multiplier for exploding gibs fx, and which I forgot to obfuscate in the binary, caused the game’s rating to switch to ‘mature’. Ridiculous IMO! Anyway, they had to put stickers on all the boxes that were already printed, while we rushed out a patch.
This is the adventure game that killed adventure gaming! There was a 3D engine explosion going on in the industry at the time, and we learned hard, expensive lessons about how to transition from 2D to 3D. Metascore 80.
I was the technical lead for GK3, which shipped with ~400,000 total lines of code after three years in development. We wrote it primarily in C++ and script, with a little bit of assembly. Its 3D renderer “GEngine” was derived from the one that shipped with Sierra’s SWAT 3. I designed and built GK3’s game engine core, file system, save/load game, custom “Sheep” script engine, resource compiler, event handling, actor facial expressions, in-game development tools, debugging infrastructure, and random utilities. I may have used New Model Army cover art in the game debug tooling.
One more word on the scripting engine - it needed to support choreographing and synchronizing sequences across many frames, so I invented a “wait” system that was a primitive form of the async/await pattern that we know and love today. It worked so well that I built a more advanced version into Dungeon Siege.
A web-based e-commerce storefront server. ~200,000 total lines of code, twelve months in development, written in C, C++, Java, MSSQL, and ICL/HTML.
I led the project, and designed the architecture, databases, merchant and host web applications, managed the engineering implementation and blah blah, this was a boring project during the internet bubble and I never think about it.
A high school-level 3D educational title for the retail market. ~380,000 total lines of code, twelve months in development, written in C++, Windows + Mac. Windows targeted Win3.11 and Win95, relying on MFC and Win32s to make it “work”.
This was my first professional project. I did the 3D environmental menu, user interface tool classes, MFC dialogs, porting to and from the Mac, and doing the Windows builds.
A robotic control and data collection/analysis system for a pulsed eddy current research project, ~45,000 total lines of code, two years in dev part-time, written in C++/OWL. Sole developer. Designed and implemented the virtual instrumentation library, robotic control code, and sexy graphical interface for demos to investors.
Publications, Lectures, Media
Note: this section is missing links and files. Workin on it!
Game Developers Conference Europe, London, 2003
This lecture was the inspiration for many game engines. Notably, the Unity game engine has a data-driven and scriptable component-based game object architecture and serialization system that was directly derived from this talk, including many of its core API’s.
Over the years, GameObjects+Components has gone from fun original idea, to common practice, to tired and often scorned. ECS, which has been gaining traction recently, was supposedly originally inspired in part by my work, at least according to the wikis.
I was the section editor for the “General Programming” section.
This was derived from my Gem from Game Programming Gems I. I invented a neat and cheap way to expose C++ functions to a scripting language. The usual methods require macros or postprocessors or IDL’s or manual registration or other horrors. My method was to simply tag the function to be dllexported, then at runtime walk the exports and un-mangle the C++ names to extract the argument types. Neat and cheap, the best combo.
Contributor of 3 gems: “An Automatic Singleton Utility”, “A Generic Handle-Based Resource Manager”, and “A Generic Function Binding Interface”. This last one led to my FuBi talk at GDC the following year.