Eykar Resources Concept
Or how to represent things that travel through space and time on StarkNet
Introduction: wtf is Eykar?
It's a game building on StarkNet where everything happens on an infinite map not stored anywhere but perfectly described by algorithms. It means that if a player decides to go fishing at a specific location, the (smart)contract can very easily verify that it was indeed in the middle of a deep ocean full of fish.
It's a strategy game where players control colonies that they can use to conquer new territories, extract resources, train troops and attack each other. All of these game mechanics may seem perfectly normal to you, but there’s a trick. In fact all these actions represent a single generic interaction with the contract.
Eykar is just a grid covered with virtual resources where each player fights to get the most on his plots
This interaction is a transfer of resources on the grid into the future.
The whole point of the game is to create rules so that the big brains understand which transfers allow them to enrich themselves with the resources of others.
How to represent those resources and transfers?
Part 1: naive approach
At first we thought that to represent resources stored at specific coordinates of the map …we could simply make a storage function that associates resources with these coordinates. To move them in space we would first replace the resources associated with the start coordinates with empty values and then secondly add the original values to the end coordinate. Finally, to move them in time we could use a bot to delay the second step and wait a certain amount of time before calling our contract.
You’ve probably noticed this already, but there are quite a few issues with this solution:
- That’s a lot of writing: replacing a felt by 0 is not free
- We have to put in place incentives for someone (a bot) to come and update our data later
- We do not know the future conditions of the network: if it is congested does our time flow more slowly or should we subsidize fees for the bot?
- We would have to manage a permission system to allow the bot's callback to run only at the right time (oh no, more writing!)
Part 2: Why do we even bother with resources?
After questioning our future as cairo developers, we had an idea. Imagine a technique that allows us to pay less fees during transfers, which supports sending resources in the future in a pure and predictive way, which is more flexible and has a somewhat lame name.
That’s exactly what we did.
Let me introduce you to the concept of Convoys and Conveyables
The idea is simple: remove resources from storage and make transfers Eykar’s first class citizens. We no longer call them transfers but convoys to emphasize on the delay required. And resources? Well they are now conveyables because everything that fits in a convoy is a conveyable, be it resources, starknet socks or even a means of travel like a boat.
Each coordinates is associated with a linked list of convoys id. Each convoy id is itself associated with 3 things:
- an owner
- an availability date
- its content (a list of conveyables)
The use of linked list makes it easy to remove or add a convoy to a coordinate. Travel in time and space becomes relatively inexpensive, but above all it becomes pure and sure. If the availability field tells you your convoy will be available on such a date, then from that date you can use it, and it will be up to you to decide how much you are willing to pay in blockchain fees to do so.
To implement this in cairo you will have to use the usual tricks to represent lists in @storage_var. To represent a list, associate an index with a value, and store the list size. To represent a chained list, associate an index with another index. If the last one is zero, you are at the end of your chained list.
Our implementation is available here: https://github.com/age-of-eykar/contract/blob/master/contracts/convoys/library.cairo
This is still work in progress
In addition to this concept of convoys, we added various associated metrics. By reading the contents of a convoy you can give it a score in terms of strength, resistance, ability to move, etc. Thanks to these metrics, there is no longer any need to interact with the conveyables directly. Say you want to attack a particular building with a part of your army. You can take one of your convoys and split it into two output convoys (like UTXOs on bitcoin). The first is sent back to the starting plot and its availability is instantaneous, the second is sent to the destination plot with an availability depending on its speed score and the distance between the two plots. You can then fight with the enemy convoys already present on target plot (if they are still there when the availability threshold has been reached).
What's next?
My friend Louis is currently working on the concept of what we call “smart path proofs”. The point is to be able to calculate the availability threshold in a smarter way than simply by multiplying the distance in a straight line by the speed of the convoy. One can imagine that the player could provide specific points from a particular route allowing him to go faster thanks to equipment that is part of his convoy (for example a boat could be necessary to cross a body of water and certain types of boats would make it faster).
For my part, I am interested in the means of intercepting a convoy. Since we know which path a convoy takes, it is quite possible to allow a player present in the right place at the right time to engage in combat with it.
Another point we want to optimize is the splitting of a set of conveyables. Is there a data structure we could use to limit the overwriting? The linked list is not perfectly adapted since we would have to pay quite a lot in some specific cases. We are currently using normal lists so feel free to make suggestions.
Conclusion
Building on StarkNet is cool. I hope this sharing of ideas will be useful to you. If you have any suggestions or questions, don’t hesitate to ask them in the comments, on the StarkNet discord (tag me, my username is th0rgal#8470) or directly on Eykar’s.
