My vision for Eykar UX

My good friend Louis and I started developing Age of Eykar just under a year ago. I think we took the worst possible approach to creating a good game. Instead of thinking of a good game design and then dealing with the technical constraints to build it, we looked those constraints straight in the eye and asked ourselves what fun things we could build with them. This is how we ended up creating an infinite on-chain world (a thread is coming), a system to manage the temporal movement of resources on this world, combat algorithms, and many other things which were perhaps not necessary.

The thing is, we really enjoyed doing these things, and now we want the project to work. So it’s time to get serious again. To have a good game, using stylish technologies doesn’t help much. What we need is a good gameplay and a great UX. That’s what I’m going to talk about today.

How can we improve user experience of on chain games?

Having a game on chain has two big benefits:

• Players can be guaranteed that the game will not stop or be completely transformed.
• The game is open by default, anyone can build on it and this opens the door to interoperability.

But these benefits come at a cost: the worst UX ever. Imagine asking your players to create an account on an exchange and follow a KYC to buy tokens that they will be able to send at their own expense to a first wallet used to send them again via a bridge to a second L2 wallet they have created (taking care to write down the 24 words of their seed safely), all this in order to pay and sign a transaction every few seconds.

Let’s be realistic, if it stays like this we will be alone on our super cool infinite world.

I want users to be able to buy an Eykar App on the App Store, like any other mobile game, to create an account that can be recovered by email, and to immediately start interacting without waiting or signing a transaction every few seconds. And I want that without compromising security.

The question is: how do we get there?

On StarkNet we have a great advantage over competitors: account abstraction. This thing solves almost every problem in the universe. Instead of being managed by a key pair, transactions are managed by a smart contract, which can for example only be called by a certain key pair.

A few bricks have been developed on top of this concept, and we just have to position them correctly to build the best user experience of the so-called web3. I have selected 3 of them:

• The ability to pay for someone else’s transactions.
• Delegating transactions signature to different session keys.
• MultiCall (merge multiple transactions in a single one).

Here is how we can use those.

Onboarding with a mobile app

I’m a big fan of Progressive Web Apps, these websites that you can install like application on many devices and that can leverage native application features, but I have to admit that most users don’t know them and would have an easier time installing a real native game. That's why our plan is to wrap the Eykar website in a native application.

Eykar Web App: designed for mobile

This application would manage a StarkNet wallet and sign transactions. It would have to be paid for via the AppStore because the money collected would subsidize the first transactions of the users through the "pay for someone else's transactions" feature. We could work on a simple way to “top up” the account when the base funds have all been spent (hopefully with Starknet’s low fees that wouldn’t happen too soon).

In the same fashion, we could take advantage of the session keys to allow an existing StarkNet user to synchronise his Eykar colonies from his mobile app with his computer browser's extension. This would involve authorizing a particular key pair to carry out transactions relating only to Eykar on his behalf, but only for a certain time, for example. This way the user could use a mobile application sharing eykar things with his main wallet, without having to sacrifice his security by writing his precious recovery words in the application for example.

Optimistic updates: the most elegant way to reduce signatures

Even through a mobile wallet, transactions are a hassle. Using session keys could make it possible to stop asking the user to sign each transaction, but this would not be great for security and you would still have to wait for each action to be validated.

Imagine being able to interact with the game instantly: minting a colony, splitting its human convoy in 4 convoys, send one far away, extend the colony with another, and merge the 2 remaining. Instead of creating a transaction each time, they would be stored in the application’s cache and their result assumed. At the end of the game session, the user would confirm a single transaction: a MultiCall of all previous ones. These are what Francesco call Optimistic Updates, and they have many advantages over sending multiple transactions (even through a session key):

• It's faster: you don't need to wait for a tx to be performed, you assume it will.
• It's more secure: you still sign a transaction, but this tx doesn't delegate some ownership right over your wallet, it only approves the transactions you performed.
• It's cheaper. For storage you only pay once even if you wrote multiple times to the same location. For computation, fees are sublinear, which means the bigger your transaction is, the less you pay per instruction.

Unfortunately, they also have some downsides:

• If there is a single conflicting transaction that happens while you assumed the results of your various transactions, you need to restart from that point.
• Time does not pass while you assume transactions are correct. If you sent a convoy which should take 10min to be spendable again at the beginning of your session, you will need to wait 10min after ending your session, even if this session lasted one hour.
• Most applications are built using blockchain data directly. They will need to be modified to include a cache of assumed actions.

These are not such terrible points, but they need to be taken into account when building our applications.

To conclude

User experience is a barrier to the adoption of on-chain gaming. Fortunately, StarkNet is giving us weapons, and by trying to make gamers’ life easier, we might also make it cheaper and more secure. Reading this article again I think there is still a lot to explore with MultiCall and the role of wallets. As transactions become more complex, the possibilities for optimization seem endless. Imagine a wallet that could decode multicalls, reorder and modify the underlying transactions to limit fees. I’m curious to hear your thoughts.

Thanks to Ismael from Argent, Francesco from ApiBara and Sylve from Briq for their help and ideas.