Message from: SW4GN3R
I’d also like to note here that the team has been working tirelessly on infrastructure improvements to ensure that transaction issues aren’t related to Star Atlas specifically. There’s still room to improve, but dramatic improvements have been made, and many more are in the process of being implemented (Starcomm v2, StarFrame, IronForge, etc.). Setting that aside for the moment, we need to solve for exogenous variables outside of our control (i.e. network congestion and priority fees).
There are several potential avenues ahead of us, including:
- Apollo (likely rebranding) / AtlasNet — ATMTA’s Solana clone/fork, which we’ve been leveraging for internal program testing
- SVM/L2 solutions
- MagicBlock
- Sonic
- Moving to a new layer 1
- Game logic changes to reduce transactions
I’m going to come back to Apollo. So, starting off with some of the SVM alternatives, I’ll note there are some interesting products out there. And there very well could be a short term implementation of one or several of these solutions. However, the downsides consist of additional reliance on third party solutions, as well as a general lack of true decentralization. Referring back to my comments about our core philosophy, it’s imperative to us that Star Atlas can operate long into the future, without the requirement for ATMTA to provide and maintain the infrastructure (years away).
Considering a new blockchain protocol, particularly for SAGE, lacks any real viability. Given the considerable number of programs we have already deployed, and inconsistencies or incompatibility with base language, data structures, and general code logic would imply a complete re-write of every one of the programs we’ve created for SAGE. Years of work. And realistically, we would be moving away from the blockchain that has already captured significant mindshare and market share, alongside the interest of countless developers that can be targeted to build applications supporting the Star Atlas ecosystem. Solana is also a network that has arguably been the most stress tested and battle hardened. Any other network achieving comparable levels of success would likely succumb to the same pitfalls, and challenges for our players, that Solana is presenting to us now. Sure, ATMTA could receive a substantial grant to transition, but it would set us back years. And again, we’re still moving away from a clear winner.
I’ve seen a number of requests to make changes to game logic to reduce the number of transactions, similar to what we did with SDU mechanics. On this, all I can say is that I’m strongly opposed to making changes to game design simply because we have a short term technology limitation or challenge. Gameplay is the cornerstone of Star Atlas. If we make the game terrible just to reduce costs, we’re never going to succeed. That’s not to say that we won’t make changes to game design over time, but I certainly do not want those decisions to be a result of protocol choice. The game needs to be fun, and needs to match what game design wants to see. Period.
Which finally leads us to Apollo. And to be honest, we weren’t prepared to fully reveal any details about it. Dan is currently working on the addendum I referenced during the year-end Town Hall, and details are soon to be released. Apollo in it’s most basic form, as it presently exists, is already functional. It’s a fully centralized layer 1 purpose-built for Star Atlas testing. Meaning it already runs the exact same programs that we deploy on Solana mainnet, just in a private version of Solana for us. The future of Apollo could very well be a fully decentralized network, synchronous with Solana, optimized for Star Atlas. We have a significant opportunity in front of us given we already have a decentralized organization generating cash flows from gameplay — the Star Atlas DAO. Meaning we have an avenue to compensate validators on Apollo.
Discord message link – https://discord.com/channels/789226204980707409/799478132993425429/1327130439567282247