Mission Mumbling

 Wow, 2 weeks went by in the blink of an eye. My intention when writing the previous post was to blog once every weekend, but that didn't happen. It seems writing about competing priorities and the intricacies of trying to balance real life with a game dev passion on the side somehow manifested it to be true. Okay, that's a joke obviously, the truth is the other way around; that blog post was based on real life, and clearly I wasn't kidding, because I just did not get a chance to blog last weekend, and I'm barely able to squeeze in this post today. I don't really have a topic planned out, so we'll do this one live, I guess.


I like to start new chapters and endeavors in my life with something of a mission statement, although I'm probably overloading the term to include a bunch of similar but technically distinct concepts, such as design pillars, goals, priorities, etc. If you like to binge-watch GDC talks and indie devlogs like I do, you'll have a pretty good idea of what I'm talking about. A mission statement is usually a short paragraph or so highlighting some high-level core values, but it usually lacks meaningful specificity when it comes to large organizations with complex offerings and internal workings. When I was in university, I attended a talk by David Hitz, co-founder and former executive of NetApp, now retired, in which he explained the role of the company's mission statement in growing from a small, scrappy startup to a major corporation. He basically said while the mission statement doesn't have the capacity to say much about how a large organization operates, it can say something about what it won't do. I think that's an interesting perspective, and it sort of makes sense in the context of a lot of familiar game dev concepts, such as design pillars. It's quite common when developing games to employ different systems and approaches to manage scope such that when hard decisions need to be made, it can be done so in service of the greater vision for the project. That optional sick online multiplayer mode may sound really cool to have, but if it's going to add a year of development time to a primarily single-player game, you have to think really hard about putting it in. Similarly, the role of a CEO is generally to "steer the ship" by making such decisions in a consistent, centralized manner.

 

One of the main reasons Slug Games went nowhere in the course of a year is that I didn't really have a mission statement, or at least one grounded in reality. Game development was something I occasionally did on and off as a hobby apart from my day job, and when I suddenly found myself without a day job, I wasn't really sure how to fill the void. My first instinct was to try to find a new job as quickly as possible, and for about a week following my layoff, I spent quite a bit of time applying for jobs. However, my wife was scheduled to immigrate from abroad shortly after, and she had several legitimate concerns. For starters, she wasn't sure how easy it would be to adjust to life in a new country, particularly when it came to finding a job, so she really wanted me to put more time and focus on helping her find work first. Second, she figured this time with both of us out of work could potentially be the best opportunity to explore our area, travel to new places, and just generally take time off to relax before putting everything into our new jobs. And lastly, while we had known each other for years and legally married abroad, up until that point, it had been a long-distance relationship, and we had only been together a few times. The longest amount of time we had spent living together was something like 2 months when I took a research internship in China to be with her. If I'm being totally honest, I think part of her was still unsure about our marriage and whether we would really go the distance, and so I think she saw us spending a few months together without work obligations as a way of verifying that we had made the right choice to get married. I understood and appreciated all of those concerns, and so I dropped the job search after that initial week. That suddenly left me without well-defined career plans, and in that absence, I sort of stumbled on Slug Games as a default option. It only felt natural that in order to keep my programming skills fresh and make productive use of my time while not looking for work, I should just pursue this side passion in my free time. As my birthday approached a few short months later, my wife asked me what I would like, and not being too materialistic myself, I decided what I really wanted was to register the Slug Games domain, and so that was my birthday gift.


Slug Games fell into my lap at least as much as I decided to create it, and so it was born without a laser focus. When my wife would ask me what my goals were, I would kind of just lump everything in with the kitchen sink. I wanted to create an engine, but also games, but also content creation suites, but also online services that could be integrated into games developed with other engines, and so on. The problem was that I had never done any of these things before, so I was starting from scratch having to read books, do basic research, make quick prototypes, etc. I joined my first couple of game jams and made some decent little games, but jams only take you so far. Being a beginner is something I can overcome with time and effort, but as it turns out, one of the most challenging aspects of getting married is that one is no longer the only person speaking for one's own time. I mean, I guess we could debate what exactly marriage entails, as I'm sure many couples have a more individualistic framework, but at least for us, I believe that we are halves of a whole, and sometimes what one half says or does dictates that the other must follow in service of the greater union. Going back to the role of CEO, our marriage is kind of like a partnership without a CEO. There is no single decision-maker. We just have to kind of work out our differences and come to a consensus through compromise. Well, being in the early stages of our marriage and especially of real married life together in the same country, we were really rough at this. My wife got a job fairly soon after immigrating, and having given up the job search momentarily, I felt extremely unmotivated to go back to work. Part of it was that I just didn't enjoy my previous job, which is something I'll come back to in a future post. I was also just getting started on Slug Games, and it felt so unnatural to quit. However, as an unemployed house husband with a working wife, many of the traditional home-making duties fell on me. Granted, we were living in a studio apartment at the time, so it's not exactly like I was Cinderella, but I had to get used to doing a bunch more cooking, cleaning, buying groceries, etc. than I was used to from my days as a bachelor. I used to be a huge slob when living alone, so it was a big adjustment. Also, it was common for my wife to want something or feel like we were missing something from our life. This included all kinds of things that just never crossed my mind, anything from new bedding to special-purpose kitchen appliances, and so it fell on me to figure out what to buy for my wife's needs. She also had much more of a desire to travel than I did at that time. I wanted to work on Slug Games, but she wanted to visit new parks, hiking trails, states, and restaurants. All of these things just became a colossal wall of distractions that made it so I rarely had more than an hour of continuous time to work on Slug Games.

 

I also went a little too against the grain when it came to language and framework choice. My jam games and other prototypes were programmed in Java with JavaFX, which was not only an unusual choice for games in general, but JavaFX itself seemed to have a dwindling community with dwindling corporate support from Oracle. It has since essentially been spun off to the open-source community, which is probably a good thing for its long-term prospects, but also wasn't really a sign of it being in the right place for game dev usage. A lot of things were really rough around the edges, such as how transparency worked across different platforms, and also the GUI layout editor thing (I can't remember what it was called), which seemed to get stuck in weird states depending on order of operations. I chose those technologies for what I thought were good reasons. I wanted to reach the large population of enterprise Java programmers with a set of game development tools in their native language, plus I loved that JavaFX was just built into the language and unencumbered by extra licenses and integration challenges and whatnot. There were also numerous other standard Java libraries which I intended to make use of around MIDI and DTLS. I had a vision of a game engine that would make it easier to deploy, scale, and maintain online services for smaller indie developers than mainstream technologies, without significant additional cost. The Java platform seemed to provide a lot of the base functionality I was looking for, but as I got deeper and deeper into implementation of some of these things, I realized more and more just how valuable low-level access to OS interfaces is in the development of games and other systems. Game devs typically pick on Java for things like garbage collection pauses, but really, that was not a major concern of mine for the modest games I was trying to implement. Instead, what ended up being a bear was the ironic "Write Once, Debug Everywhere" reality that set in. Core Java and the mainstream frameworks around it such as Spring and Java EE may have improved in this regard over the years, but some of the less favored parts of the ecosystem haven't. When you need to edit the Windows registry to enable MIDI playback using supposedly standard libraries, or when the ability to click and drag a semi-transparent window in JavaFX is present on all platforms except Mac OSX, and there's really nothing you can do short of finding hacky workarounds or modifying the language source directly, it doesn't lend itself well to practical game development. I gave the status quo too much credit. I tried to defy the widely held notion that Java just wasn't cut out for game development. It couldn't be that the industry hadn't explored all its options, I imagined; inertia must be the main reason why game development hasn't catered to the masses of Java programmers! Well, it didn't really turn out that way. To be fair, there's not that much inherently wrong with Java as a language, and some decent games are implemented in Java. You may have heard one called Minecraft. But by and large, the few examples are implemented with wrappers over OpenGL or even underlying frameworks and engines implemented in C/C++. At that point, there's very little incentive to build an engine up from scratch in pure standard Java, as opposed to just implementing a Java wrapper or Java-based scripting interface over another engine. As such, Java now feels like a distinctly user-space focused ecosystem. I know Java has been used for lower-level system projects before, such as JavaOS, but I wonder if the reason so many of those projects are defunct is that the idea of a pure Java environment sounds better than it is in practice. It seemed super cool to me that I might be able to write GUI code that worked on the desktop and port that directly to Android, but now that just sounds like more of a nightmare than using the native platform APIs, and it's not exactly a nightmare that others hadn't been through or that I was unaware of going into my projects. I just tried to smash my way through regardless, because I didn't really have my priorities straight. I was working more on a pointless proof-of-concept than an actual product.


Although I could probably still ramble on about dozens of other little ways in which Slug Games lacked focused, this post is already quite long, and the point is really that I was unemployed and experimenting with things I thought interesting, rather than really working to make the business work. The scope of what I had imagined was massive, while my ability to see it through in a timely manner was even more limited than my worst projections. So what is the fix going forward? Well, I could define a mission statement, but the thing is, I'm now more aware of the fact that Slug Games is not my day job, and so any realistic mission statement would have to start with an acknowledgement that it's not my highest priority and likely won't be for quite some time. I don't have a deadline for making money or having a working product, and I'm not going to spend my whole paternity leave working on Slug Games instead of caring for my first child, etc. I know "don't quit your day job" is a game dev cliche, but I hope that this long post helps really hammer the point home for people who are maybe just starting out and haven't really learned that lesson yet. Game projects are big with generally pretty miserable financial prospects, so I just don't have the same outlook as I did when I started Slug Games. Instead, I'm just going to keep working at it on the side until I'm blessed enough to see it become something more.


Furthermore, in working on projects and doing all the research I've done over the years, I've come to the realization that I'm just not as enamored with the development of games themselves as much as the underlying game engine technology. It took me a long time to realize this in a very roundabout way, but now that I have, I am refocusing my efforts on game engine development. Not only that, but I am specifically interested in providing education to others who are interested in learning how game engines work. Basically, I want to help provide knowledge and working examples to my young self and others like him, who have often found themselves wanting to know how engines like Unity and Unreal work on the inside, but don't know exactly what that entails. While there are many more and higher-quality books, open-source projects, and other resources now than there were when I was growing up, the reality is that games are highly complex systems with inter-connected, multi-disciplinary pieces, and there are still very few sources that aggregate all of the relevant information. Most are focused on specific disciplines or subsystems and are geared more towards higher-level academics vs. just getting an understanding of how all the basics come together. I don't expect the world to necessarily agree with me on my value proposition, but I'm also doing it as much for me as for the market, and just seeing how things go. The closest thing to what I imagine is The Cherno's game engine series on YouTube, which has definitely blossomed into something special, but I also don't think he's necessarily limiting the "badassness" of his Hazel engine for the sake of its educational value. The feeling that I get is that he ultimately wants to implement as many professional-level features as possible and make the engine reasonably competitive with the likes of Unity, Unreal, and Godot, albeit with more limited scope and generality. I'm explicitly focusing on giving beginners the ability to churn out playable content with basic primitives and lower fidelity 3D assets for the sake of teaching beginner programmers how games work, and in doing so, hopefully enable them to make their own optimizations and enhance their own personal game code. I think he's at least keeping that in mind with his work, but I don't think it's his top priority.


With that, I have what I'll affectionately term my mission mumbling. I'm not committed enough to provide a mission statement at this time, and that's okay. I'm still figuring out what the new Slug Games is and how it'll fit into my life. For example, I've been refreshing my linear algebra knowledge and started implementing a math library as the basis for the engine a few weeks ago, so my plan was to blog about it last week, but work and other competing priorities just took me in another direction. I even spent this whole weekend refreshing my old development desktop with a new OS (I've been using another laptop for quite some time but suddenly found myself needing a separate system), and that sent me down this rabbit hole of updating things on GitHub, moving the project to a new cross-platform build system, etc. All of that put actually finishing up the math library and demoing it on the back burner. That's okay, I'll get to it in due time. That's how mission mumbling works.

Comments