Project & Development Update #20

July 1, 2023

Good morning, pilots.

It's that time of the every other month and a half ish again.

Let's dive in.

Progress

• Moved office into Citadel HQ 3.0
• Moved Flam Sanct and The Learner to LA
• Transitioned The Learner and PhyzixTeacher from part-time to full-time
• Traveled to Europe for Autonomous Worlds Summit
• Presented "Automatic Indexing with Codemods" at AW Summit
• Held team offsite after the conference to discuss long term project plans
• Finished final drafts of economic article series: "Designing an Open Game Economy" (to be released in 4 parts)
• Designed crude ore, ship cargo, equipment cycles, and world tick game mechanic updates
• Researched preliminary framework for in-game corporations
• Added dedicated UI and UX designers to the team
• Discussed player governed games on the Doubl3Tap podcast
• Refined 20+ ship sprites and animations
• Tested animations for avatars
• Prepared scripts and infrastructure for internal playtest
• Started work on graph CLI fork with automatic aggregate generation
• Died with multiple characters in Diablo 4 Hardcore
• Kept the team extremely hydrated by consuming 243 gallons of water

✦ Story Time

What started as a casual weekend project to prove a point rapidly evolved into a filthy casual side project that spanned countless weekends and has since consumed our lives, turning into our full-time careers.

We want to take a second to exit the whirlwind and recenter with y'all on our goals for the project and the problems that we’ve overcome throughout the development process. We hope you’ll enjoy this little story time experience.

What we think matters

If you couldn't already tell, we're somewhat excited about the potential for onchain worlds.

Over the last 18 months, we’ve watched project after project in the onchain game category get exploited, die economically, ship with UI/UX that inflicts onchain PTSD, halt development, fundamentally fall flat in being engaging, or some combination of the above. So right now, it seems like the most important thing is to just get the basics right.

We've always been adamant since the beginning that at launch, the game will need to:

• Feel and play like a modern game product. (don't suck)
• Survive long enough to be able to test and iterate on design assumptions.
• Stay focused on shipping a compelling onchain experience with production-ready tech instead of getting distracted by tackling perceived technical hurdles with novel but immature infrastructure solutions.
• Don't compromise the main benefits of decentralization with security shortcuts or "path to decentralization" centralization. (don't be a larp)

As far as we can tell, nobody has succeeded at this yet, and even nailing any two out of these four would be a first for the space.

While it's taken (and continues to take...) a lot of time, effort, and whatever's left of our collective sanity, we believe we can deliver on all four.

What we're aiming for

Of course, we were never very good at sticking with the basics. Internally, we've shifted from talking about shipping a "Minimum Viable Game" to a "Minimum Compelling World". The idea with The Citadel was always that we would provide a robust foundation for the community to build on top of, but we want to make sure we're launching with enough stuff on that foundation to inspire players to care about the world.

Rather than a blank canvas acting as the foundation of the world (whose closest living relative would resemble an unmoderated Minecraft server on creative mode), our aim is to strike a sensible balance: a curated world that is open enough for players to leave their mark, yet cohesive enough for them to quickly become immersed and invested. To quote Raph Koster, "a sandbox alone is not enough."

What we've encountered along the way

It turns out this is all rather ambitious, so we'd like to highlight some of the problems we've run into and what we've learned along the way:

• GUI, GUI, and GUI
  • Ah, yes, the GUI... Fleet's attempt to solo queue the GUI design was valiant, but inconsistent due to his other responsibilities within the project.
  • To raise our throughput and overcome this, we've brought several dedicated UI and UX folks onto the team.
  • While the amount of research and interview time in finding the right people was a slowdown, working with veteran UI/UX designers with actual game industry experience has greatly increased our rate of progression.
  • Working with our new UI/UX friends has led to significant changes in the existing UI and revealed opportunities to improve aspects of the game design itself.
  • We're obviously pretty bad at estimating, but we're pretty confident that this has cut a few numbers off the launch timeline... probably?
• Revisiting Game Design
  • Our anchor for game design was to ship the systems we felt necessary for a "minimum viable game". This meant in-world mechanics that provided a meaningful canvas for players to expand horizontally and vertically without significant debt.
  • As we worked with the new UI/UX people, we got a lot of new questions, some of which we had never considered.
  • In answering these questions, we learned more about our blind spots and the shortcomings of specific core mechanics. We spent the last few months revising these systems to make them more robust and scalable.
  • Still, it was scary to think that after that much time and thought, we still had missed essential parts of the player experience. This made it clear that we needed to make some adjustments to our development process.
• Iteration and Playtest Strategy
  • Improving the GUI and getting an outside perspective drove home to us how important the testing, feedback, and iteration loop is for game development. Of course, we knew this to some degree, but our overall approach didn’t prioritize it enough.
  • Reflecting on our original plans, we concluded that our playtest approach was immature in practice and stemmed from a period when the project was much more nascent.
  • Now, instead of trying to deliver one perfect version at the end, we're aiming to push quick, unpolished versions internally and to test them intensively.
  • This way, we can quickly find issues and improvements at a lower cost.
  • We're applying this same logic to our community playtest plans.
  • Now, we're going to host multiple iterative playtest sessions over a longer time horizon, as no game gets it perfect the first time around.
  • Your involvement in shaping the minimum compelling world, fleshing out mechanics, and refining the GUI is the best path to discovering the answer to "wen launch."
  • Unfortunately, we still can't answer "wen playtest" either, lol.

✦ Re: Autonomous Worlds Summit

In our last project update, we mentioned that we would be attending the Autonomous Worlds Summit and promised to share the highlights. For those of you who skimmed that section, the Autonomous Worlds Summit was an intentionally small conference designed to spark conversation between teams building onchain games.

Takeaways

Our hope in attending was that we would be exposed to new and conflicting ideas about onchain games and connect with other teams in the space. We’re happy to share that both of those things happened, and that the conference was well worth the time.

Some of our most interesting observations were:

• Onchain game developers are now spending an increasing amount of time talking about worlds, world design, and the implications of permanence. Although, there do seem to be relatively few onchain persistent world projects — most are taking the zero sum game route.
• There are a ton of smart people working on tooling. None of it is production ready right now, but the development experience for onchain games is on the verge of improving drastically.
• People hate Polygon, until you mention decentralized sequencers. We believe that decentralized sequencing is essential, but this was a good prompt to update our notes on networks. Additionally, it was validating to have confirmation that decentralized sequencing is still not mature in rollups, and to know that our investment in smooth state migration was worth it.
• Immutable contracts vs. upgradable contracts managed by governance is still a hotly debated topic. Our minds weren’t changed by any of our discussions on it, but it was surprising to learn that many (most?) teams are against mutability, and interesting to hear their reasoning.
• Almost everyone in attendance had encountered similar technical issues while building games. It was nice to have unifying pain points, and it made us confident that solutions are on their way.

Presentation

As a part of the conference, we got the opportunity to give a brief presentation. We figured that it was only natural that the presenter be the team member who was most active in our server. As you all know, this is The Architect

Instead of presenting on another onchain game, we decided to do a technical talk on a potential strategy for automatic indexing. If you enjoy the talk or have any questions about it, please ping The Architect at least 5 times.

Watch the talk here

Some pictures from the event! The team may or may not be present, who knows.

✦ Game Design Changes

Over the past six months, we've spent a lot of our "free" time brainstorming game additions we'd like to contribute after launch. As we were hashing out economic implications for each of them, we noticed a problematic theme: they weren’t viable because of instant mining claims via transport ships.

(For those still hiding under the bed from the whitepaper; transport ships enabled miners to claim ore without needing to return to an outpost, provided they were willing to pay a higher fee to marauders.)

We believe that this is because instant travel violates the game physics and because transport ships are too efficient and automated of a mechanic. Regardless of the reason why, it became clear that the transport ship mechanic was harming the scalability of the game.

So, for this section, we'll give a short overview of the replacement system and share a sample of our internal design diagrams.

Part 1: Rest in Piss, Transport Ships

When considering a system to replace transport ships, our requirements were that the solution:

• Must make sense with the physics of travel
• Must expand the set of player decisions (and with it, the skill gap)
• Must be economically compatible with a majority of our game expansion goals
• Must not fundamentally change the game's narrative

What we came up with was a combination of two systems: Crude Ore + Minerals and Ship Cargo

Asteroid belts now consist of various types of crude ore rather than the original eight named ore types. Each type of crude contains a different composition of these original eight resources, now called "minerals."

Minerals and crude are tangible resources. Unlike the ore token, they occupy space at a specific location and only exist within the game world (not tokenized). Crude can be used for fuel, but at significantly lower efficiency than the ore token. All ships, including marauders, will eventually have to return to an outpost to trade their crude or refine it into minerals.

Each outpost will offer the ore token in exchange for minerals.

In addition, each ship will now have a cargo hold, which determines the volume of resources that it is able to carry. This means both miners and marauders will have to consider the volume of crude that they're accumulating to decide when to return to outposts.

While this may be a simple change, we've already experienced its impact on expanding the canvas for the game's scalability. We expect that these systems will serve as a meaningful kernel for community builders, making an even larger difference for players.

Part 2: Cycles & World Tick

The central constraint of the cargo system is that players have to worry about exceeding their ship's cargo capacity. However, this introduced something of a problem with the original system since there was no good way to get feedback on how much crude a ship would be taking onboard until after claiming.

The other issue with the original system was that imposing a limited cargo capacity meant that miners couldn’t mine as long, and thus would have shorter sessions on average. This was a problem because in the original mining system, you would incur a fixed amount of risk per session while receiving time based rewards. By forcing shorter sessions via limited cargo capacity, we were effectively unbalancing risk/reward tradeoffs. To fix this, we wanted to move to a system where both reward and risk were time based.

We named the solution we came up with "cycles": short, periodic, automatic outcomes while mining or roaming. Coincidentally, cycles lined up with an idea for a periodic tick that we were planning to implement as a part of another feature, so we decided to go for it.

The result is that miners and marauders can now see the types of crude that they have accumulated at the end of each equipment cycle (~5 mins). This creates more regular feedback and allows them to make more informed decisions as their cargo fills. Risk for miners is now based on time instead of a fixed amount of risk per claim. Miners who choose to evade taxes are now taking a small risk each cycle, instead of a large risk at the time they claim.

Instead of implementing cycles directly, we decided to make them a dependent of a generalized “world tick”, which combines a tick id, timestamp, and large random. Our hope is that this will make it straightforward to build other features that require periodic updates, without having to worry about timing, oracles, or syncing.

✦ Animation and Sprite Refinement Continues…

You know how this works. We show you the goods, and you tell us what you think.

Don't worry, it's alright that you skipped all of the text sections, it's not like you'll get pruned or anything.

✦ Doubl3Tap Podcast

We recently joined @jacl_e9 and @awettermann on their Doubl3Tap Podcast to discuss player governed virtual worlds. We really enjoyed the conversation, and we hope to make a return appearance in the future! We'll link the recording so you can check it out if you're interested.

Listen here!

✦ Citadel Gaming House + Office v3

After our return from the Autonomous Worlds Summit and a few months of planning, we’re stoked to share that we've finally settled into our permanent office!

Now, Flam Sanct, The Learner, and myself have somehow moved in together and converted the majority of our house into a giant dedicated workspace for the team. The move also coincided with The Learner's completion of his master's degree and transition to a full-time position. A few weeks later, PhyzixTeacher (Ex-Teacher? Phyz-ex-teacher??) followed suit, quit his job, and went all in on Citadel.

It’s wild to look back through project updates and observe the transformation. The Citadel team has gone from fully remote in different states, to us operating out of half a bedroom, to an "office" that was meant to be a small bedroom, to now, with a whole house functioning as the team’s dedicated workspace.

If it wasn't clear, the vibes are good, our work is full of passion, we enjoy living together, and we're stoked to be working together in person. We’re more productive than ever, and the margaritas are indeed flowing.

Bonus Team War Room Dox