From Open Source Maintainer to Game Developer
Join me in my misadventures of inserting myself into an industry I know nothing about.
Created on January 10, 2022.
From its inception on December 30th, 2019, my most popular open source project accrued about 330 stars on GitHub by the end of 2021. Said project is a collection of packages for the Unity game engine, including super-fast math for common use cases, and parallelization of pathfinding. These packages fill some feature gaps in Unity's new toolchain, and so I have never considered them to be anything more than stopgaps; however, people apparently use my code in production.
How do I know this?
While the vast majority of those using my code are students and hobbyists, who occasionally chat with me on Discord, game studios have contacted me for consultations and contract work. This has been an unexpected, albeit welcome outcome. It is not only through open source that I have been able to sustain myself (after having quit corporate in 2019), but the connections I've made along the way have been invaluable.
One particular connection has become my business partner! He has taken responsibility for the art direction of our first collaboration, based on a concept I pitched in 2021. If you want to be a game developer, you have to assess your limitations. I would consider myself artistically deficient, so I've partnered with someone who knows about art, lighting, atmosphere, etc. He's also shipped a number of games. As long as you stay committed, seek common understanding, and maintain mutual respect, odds are that collaboration will bear fruit, even if it's just learning from another person.
The most humbling aspect of my having become a game developer is just how long it has taken. No doubt, I could have independently created and shipped a plethora of unoriginal clones by now (which is actually a great way to learn), but I'm fixated on genre-mixing, and a level of complexity that was, previously, beyond my capabilities. My background in building distributed systems, much of which at Boeing, did not translate as well as I had hoped to game development.
To put it another way, I did not scope my game ideas to what I could realistically achieve, at least, by myself.
In retrospect, the "safe" route would have been far easier than what I did. As a distributed systems engineer, I could have leveraged my experience at a game studio in need of netcoders—easily. That would have been my foot in the door to other areas of game development, besides supporting multiplayer, or online payment systems. The network folks who support games are, in fact, game developers. If you're interested in this industry and have a desirable skill, I highly recommend finding a team that will take a chance on you, instead of going it alone. Teams have valuable knowledge and insights that can fast-track your career growth.
What's done is done, however, and the current project I'm focused on, while ambitious, is (with help) scoped for me. It's not only through sobering acknowledgment of my limitations, and the subsequent decision to collaborate, that I have reconciled my differences with scope. There is also the matter of realizing that many patterns and rules of thumb, once useful to me for distributed systems, get in the way of game logic.
Software engineering "best practices" are context-dependent at best, and dogmatic at worst.
All that said, the biggest point of contention for me, and has been since before I got into game development, is my infatuation with novel technology. When I had started filling those gaps in Unity's new toolchain, Unity DOTS, I (wrongly) assumed two things would have occurred by the time of this writing:
- Unity ECS would no longer be experimental.
- Unity would have officially filled the aforementioned gaps (and others).
Oh, how wrong I was. I am a lone developer who wants to make games, not tools (isn't that the point of using a game engine?). As such, I can't justify filling every gap with respect to Unity ECS. The entity-component-system pattern, in my view, is the most architecturally sensible approach for the domain of game development, but Unity's implementation needs more time in the oven. Right now, there are dedicated teams of engineers improving it, and I have high hopes for their deliberation.
As such, I have satisfied my high-performance needs with the other, and production-ready, pillars of Unity's data-oriented toolchain: the Burst compiler, and work-stealing jobs. The game I'm developing depends on these innovations to alleviate heavy CPU-bound tasks, which a game of lesser scope and complexity would probably not be subject to. This is a happy concession that has proved itself with, for example, the sheer speed of the procedural map generation.
Here's another thing: try to avoid procedural map generation. As an indie game developer, I have begun to reinvent the organization chart: one person could feasibly spend years just doing procgen for a single game. The same goes for making water look and behave like water, multiplayer, concept art, 3D character modeling, texture art, etc. One person can only do so much, so that is also why I must purchase licensing for some code and other assets to finish my game in a reasonable amount of time. There is other art and music I must commission, to capture my vision.
And I can't forget that I'm dependent on open source software, too!