Project & Development Update #18
March 1, 2023
Good afternoon, pilots!
Did you know February is the shortest month of the year? Crazy coincidence, considering this is the shortest update of the year as well. Something something causation...correlation, who really knows?
Anyway, let's get to it. 
🔹 Progress
(AI + machine learning stuff)
- Set up backend for belt generator
- Created a frontend for the belt generator
- Created script to compile average spam/trust scores for server users
- Documentation AI chat bot (info on this next update!)
(Developer nice-to-haves + cleanup)
- Migrated contract tooling and tests from Truffle to Foundry
- Cleaned up the frontend repo and removed artifacts from old map versions
- Created subgraph version that does not depend on eth_calls
- Adapted all contracts to use a consistent fixed point representation
- Adjusted the game contracts to take advantage of the diamond pattern
- Reorganized the contracts repository to group contracts by feature for scalability
- Adjusted the content of the events emitted by our contracts to make queries simpler
(New stuff)
- Expanded session key support into a modular auth system
- Added delegate.cash support through the modular auth system
- Added batching capabilities for all game functionality
- Adjusted the game to allow travel to any map coordinates, not just belts/outposts
- Adjusted the game’s banking system to allow direct payments from in-game balance
- Added contract URI setter to the ships token to allow for easier royalty changes from the DAO
- Completed experimental 3D models of the Citadel and the Brig
- Completed animations for Atlas Industrial, Vermillion Dynamics, Quark Robotics, and Order of the Black Dawn
- Completed several more Officer ships
- Completed 80x80 (interceptors/frigates) ship revamps
- Drafted, wrote, and revised End-Game Vision for the Citadel
- Secured the Twitter gold check for @0xCitadel Twitter account.
♦️ End-Game Vision
Given that we're handing over ultimate control of the project to the community upon launching, we felt it was important to clearly communicate the vision for The Citadel that we're most excited about. While we've clobbered you all to bits with documentation about the launch version of the game, this article is more of an exploration of what's possible after launch.
Rather than a list of empty promises from founders, this is meant to be a living document that will grow and evolve over time as a reflection of our shared vision for the project. As such, we'd love your guys thoughts and feedback!
End-game covers a number of topics, including:
- The quality and character of the world we envision
- The open architecture that can make it possible
- How we imagine all the pieces could fit together
- How to find balance in governing in and over worlds
- A better map to help us along the way
🔸 Session Keys
What are they?
Briefly, a session key is an optional burner wallet that can act on behalf of another wallet for a short period of time, with steep limitations on the actions that it can perform. More technically, a session key is a temporary wallet controlled by the client, accompanied by a contract that gives it limited access to funding and limited ability to call other contracts. Frankly, a session key is a convenient way to play the game without having to sign a transaction for every action.
Why are they important?
To put it lightly, the user experience of onchain games needs some love. Although we've made every effort to make playing the Citadel as smooth and efficient as possible, our virtual world comes with a cost; players need to sign transactions for every in-game action that triggers an event. Doing this securely requires interfacing with players’ wallets, which inevitably results in opening a popup or a separate window for confirmation. This undermines focus and destroys all suspension of disbelief.
Session keys solve this problem without jeopardizing security. They eliminate the need for players to sign every transaction, while ensuring the security of their true wallet and game assets.
How are they used?
Our model for implementation is similar to how websites keep you logged in for a period of time after you sign in. Players will have the option to create a temporary, configurable, session-based wallet that acts as a delegate. For the duration of the session, the delegate wallet will automatically sign the transactions necessary for in-game actions on behalf of the player. The result is a relatively seamless playing experience, more like the one that we expect from proper games.
🔸 The Next Audit Batch
As a part of our ongoing partnership with Macro, we receive a guaranteed 2 weeks of audit time every other month. In the future, we expect to use this time for new game features and community contributions. This month, we are using this time for contract improvements that we believe will make the game more immersive and easier to build out.
Freedom of Travel
Originally, our travel system required players to pick a destination (asteroid belt, outpost, etc.) before initiating travel. At the time, we saw this as a decent protective measure for preventing accidental travels and a nice optimization for checking whether a ship had arrived at a destination. However, as we began to shift our focus to polish and immersion, destination-only travel started to feel more like a roadblock for strategy and a detriment to player experience. To fix this, we’ve adjusted the travel system to allow ships to go anywhere within the map. We hope that this will give rise to interesting new strategies and make the map feel more realistic.
Modular auth system
It should be no secret that we’re planning to launch with support for session keys. As we were building out that support, we realized that we had the opportunity to implement a more general, more modular auth system, so we figured we’d give it a go. As it turns out, we were actually onto something, and with this new system, it was trivial to keep support for session keys, while adding support for delegate.cash and a transaction batching system for improved UX when managing multiple ships.
The diamond pattern
From the moment we started work on the game contracts (circa Nov 2021), we’ve been keenly aware of the Ethereum contract size limit. At the time, there were several solutions, but tooling only existed for one: standard upgradeable contracts that call each other. Of course, we went with the option that had the tooling and split the game logic over several contracts. This worked fairly well, but involved a lot of overhead in coordinating communication between different pieces of the game.
Since then, the diamond pattern has gained significant support and popularity, to the point where it would have been the natural choice for the game implementation. In the spirit of keeping things clean and up to date, we have adjusted the game to use the diamond pattern. The result is a cleaner division of features, more efficient communication between features, a more scalable game contract, a smaller access control surface area, and a better developer experience.
Query-friendly events
Previously, our subgraph handlers mainly used events as triggers and often made calls to the game contract to retrieve the actual data associated with an action. This kept event data slim and slightly more gas-efficient, but made the subgraph harder to index and more error-prone. After a lot of internal discussion, we have decided that it makes more sense to make events more self-sufficient as records of actions, given that the increase in gas usage is offset by the increase in gas-efficiency from the diamond pattern. The result is that gas usage for all functionality will remain the same, the subgraph implementation will become simpler, indexing will become faster, and events will become more self-contained.
In-game banking
Before we implemented in-game banking, players were expected to claim their ore before using it for travel or upgrades. While we still believe that this would have been a decent user experience, we knew from the beginning that it could be smoother. With in-game banking, players may use their unclaimed ore balance to pay for travel and upgrades, without the extra claim transaction. This makes the experience just a little bit better by saving players some gas, inconvenience, and time.
Onchain player profiles
Initially, we were planning to launch with an off-chain implementation of player profiles. However, having stuff onchain is a little bit more rad, so we created a system of contracts for storing player profiles and managing access-gated packs of profile information (e.g., profile images by achievement). This keeps player profiles persistent and keeps the logic for gating access onchain.
Ships contract URI setter
While we were working on the Proposal Builder, we noticed that the process for adjusting the core team’s royalty split was more complicated than it needed to be. Adjusting the split required changing the ships contract’s URI, which required an upgrade to the ships contract on both networks. While this would have been bearable through the proposal builder, it would have also required the community to carefully review the proposal code to ensure that the upgraded implementation wasn’t malicious. To avoid all of this hassle, we added a contract URI setter function to the ships contract that only the DAO can call.
Ownable ships contract
It turns out that some marketplaces are lame, and only partially support configuration through onchain contract URIs.
Instead, they require that the token contract lists an address as its owner, and that the owner signs off on some
configuration through their website. To address this, we have added an owner field to the ships contract so that the
core team can fill out the initial configuration for those marketplaces. After the configuration is set, and before
launch, the owner field will be set to the DAO’s address and put under the DAO’s control.
🔹 FOGDAO Podcast Episode ft. Heimdal
Our resident spreadsheet romancer, Heimdall, recently made an appearance FOGDAO podcast, alongside our friends at Curio and Playmint. If you're interested in a deep-dive into onchain games, we highly recommend listening.
🔹 Update #17 Team Q&A Recording
Our recording of the previous team Q&A has been published for those interested. We've embedded topics and key points
as chapters for your convenience. 
🔹 Animated Backgrounds
In our previous update, we shared previews for the completed pilot avatars and backgrounds. As we were working to create the systems that will allow players to unlock and access the avatars, we realized we could do a little something extra to indulge the collector (again, not trader) inside all of us.
This time around, we're sharing a sneak peek into an idea we’re considering:
animated backgrounds. 
🔹 Zel'Adun Revamp
Here is a comparison photo to showcase the revamped style of the Zel'Adun ships. It's taken a while to get these dialed in, but we're quite satisfied with the end result!
This visual upgrade has been applied to the frigates and interceptors from all manufacturers.
🔹 Update Cycles
Moving forward, we're going to experiment with shifting our project update cycle from 4 weeks to 6 weeks.
We believe that by allowing more time in between updates, we’ll be able to more effectively schedule when each section is written, so that it does not impact our work on the project. If this pans out, our update writing process will become healthier, more productive, and more efficient.
This means the next project updates will be delivered on April 15th, followed by June 1st, and so on.
🔹 Nemesis Arrives
We'd like to officially welcome one of the core team artists into the community! For the past year, Nemesis has been working tirelessly behind the scenes to deliver top tier pixel spaceships. We love the spaceships, we love the man, and we're excited for you guys to meet him.
P.S. Since FOGDAO was so kind as to generate this immaculate rendition of our beloved Heimdall,
we've decided to solidify it as a server emoji in all of its memetic glory.
Here's to you, Heimdall-GPT! 