My development philosophy

DSPACE has an incredibly large roadmap (which still mostly exists in my head instead of /docs/roadmap), and there are so many exciting pieces I can’t wait to build. In the short term, though, it’s essential to prioritize and focus on the most important tasks first. I fully expect to get the order wrong sometimes, and I’ll definitely make some poor design choices I have to fix later, but I think it’s important to share a rough version of my development philosophy to help manage the public’s expectations.

Embracing the 80/20 rule

I strongly believe in the 80/20 rule, also known as the Pareto principle, which states that 80% of a software project can be completed in 20% of the total time. This principle highlights the importance of focusing on progress rather than perfection. The goal is to reach a point where the software is usable, and then move on to the next task. This approach is especially relevant for solo developers who don’t have unlimited time to work on their projects.

In my case, DSPACE is a passion project that I work on in my free time, alongside my day job. Despite the limited time I have, I am proud of the progress I have made so far. You can see a record of my accomplishments in the changelog, which would not have been possible without the help of DALL-E and ChatGPT.

Priority is a function of severity

The crypto industry has seen examples where software bugs have resulted in millions of dollars in losses. In the long run, blockchain integration is crucial for the success of DSPACE. As we move in that direction, the standards for quality and scrutiny will become much higher. However, we are not there yet. Indeed, at this stage, the stakes are incredibly low. All the game data is stored locally in localStorage and cookies. There’s no actual money involved, fiat or otherwise. I’m hoping to make the local-only version of the game a casual sandbox environment where both developers and players alike can experiment and manipulate game data as they see fit (you can literally edit most game state directly from Developer Settings in your browser).

A lot of games spend an incredible amount of effort on anti-cheat mechanisms and code obfuscation, but I’m not sure that’s the right approach for DSPACE. The version of the game that’ll actually matter (in a weird, esoteric way) will be the one that’s implemented on the blockchain. Assuming there are no bugs or vulnerabilities in the smart contracts, anti-cheat is by definition a solved problem because it turns game state into a state machine with EVM-enforced cooldowns and item requirements. Of course, this is easier said than done, and the smart contracts will likely have bugs in early iterations, but that’s a separate challenge that won’t be entirely solved by the techniques described in this blog post.

The more severe the risk of bad things happening, the more I’ll need to emphasize code quality, testing, and audits. Conversely, For a local-only game with no real-world consequences, it wouldn’t make sense to invest a lot of time in these areas. Historically, many AAA games included cheats, like GTA: San Andreas and Age of Empires II, and it was up to the player whether they wanted to “ruin” the game experience for themselves by choosing to cheat. I have a similar approach with DSPACE. If you want to give yourself a trillion dUSD, go right ahead! If you want to exploit an infinite money glitch that I still haven’t gotten around to patching up, you have my blessing.

The flywheel effect

This is subject to change, but I’ve found that monthly content releases work well with my schedule, and I’ll probably also gravitate toward bigger functionality updates (new features, better UIs, AI integration) on a quarterly basis, like the upcoming v2 release.

Long term, I want to take advantage of something known as the flywheel effect. A flywheel is a spinning wheel that stores kinetic energy, and you can apply torque to add more energy to the system and remove it with an inverse torque. This concept is often spun (pun intended) in a very businessy sense, but I’m really trying to approach it from first principles. I’m a solo contributor to a project with a day job and limited capital to deploy. I’m choosing to do this in a way where I don’t store (or even see!) private user data, which also means instrumenting and measuring things like user engagement, churn, and other typical metrics is difficult. This pushes me to instead rely on the public/private key architecture Ethereum wallets provide, such that users can store their own data either on- or off-chain with optional privacy features. Plus, transactions on the blockchain are monetized with gas, which is user-provided, so I basically get a globally available database managed for me for free minus the cost to deploy the smart contract: no need to worry about hosting or renting a database myself. And this makes sense for DSPACE, an idle game, because the time between noteworthy events (finishing a process or waiting for a cooldown) is high enough to justify keeping data on-chain. Given these properties, assuming I continue to keep my server costs low, I have basically infinite runway, as long as I’m able to hold onto a day job to cover living expenses.

Lack of visibility into churn is a huge problem, but as long as the “reactivation” (regaining a user who was previously lost to churn) process is easy and frictionless, and I’m upfront about the perpetual WIP status of the game, I think I can pull things off without shooting myself in the foot. Returning back to the flywheel analogy, low ongoing costs means less energy leaving the system, and any positive contribution I can make adds energy back into the system. Long term, if I build systems that incentivize user-generated content (and, eventually, code) for the game, this adds energy with little to no contribution from me and can lead to growth orders of magnitude greater than what I could achieve on my own.

This set of constraints certainly makes the road to true impact much longer, but I think it’s the right approach. I’m a huge fan of the hyperstructure model, which I discussed in my previous post as well. The goal is to build something vibrant and alive that’s bigger than yourself, something on a scale so grand that it’s impossible to do alone or even with traditional capitalist institutions. This something is what I’m going to try to create for space exploration. Our sense of scale is really calibrated by what we can interact with locally, but there’s a gigantic universe out there with many more orders of magnitude more potential, and it’s still mostly inaccessible to us. Let’s change that.