[META] Gaming

[moul]

Let's create a space for discussing all things GNO+Gaming!

The use of gaming and smart contracts is already a growing trend, and we anticipate that this trend will continue to increase in the future.

Gaming will be an official incentivized topic of Game of Realms / Phase 2 (#390). Anyone is welcomed to start exploring now.

[moul]

On a personal note, I plan to work on a Tic Tac Toe demo realm, with a focus on improving my own mental picture of everything that will make sense for gaming on gno in general.

Pre-start feeling:

• async match request
• async match steps
• leaderboard
• shuffle/random
• season management & match allocation
• ways to "verify" from an external contract, i.e., for token-gated access
• markdown UI (Proposal: extend markdown rendering #439, feat: add a ‘lib/demo/ui’ package #527)
• "NFT" generation? dynamic?

Edit: super WIP -> #613

[grepsuzette]

Cool! A tic tac toe would be interesting indeed.
Speaking of spaces, why not opening an IRC channel somewhere for devs?
I often feel like asking small questions, but Discord is too chaotic and heavy.

For example, a question I have:

Can a realm state be modified concurrently by more than 1 tx?

If Alice and Bob execute a tx at the same time, competing to change a list in the same leaf of an avl.Tree is one tx guaranteed to run AFTER the other one is finished?

[thehowl]

One of the ideas I had in the past few weeks was that of trying to do an implementation of chess as a gno smart contract. At least a version of it as async, ie. correspondence chess, could be implemented without too much trouble, though having it with normal time-controls might be slightly harder. I might try giving it a shot especially if there is a sample tic-tac-toe to base myself on :)

[moul]

@thehowl I'm excited to try it out!

@grepsuzette By the way, would you be interested in joining us for the next office hour to discuss it?

We just opened a new repo where you’ll be able to find the list of upcoming events soon:
https://github.com/gnolang/meetings

[moul]

Can a realm state be modified concurrently by more than 1 tx?

No, it's not currently possible. Transactions (TXs) can arrive concurrently on different validators, which initiates the first round of consensus to determine the order of TXs. After that, TXs are executed sequentially. While we may consider implementing more concurrency features in the future, we will ensure to add all the necessary locking strategies to safely manage them.

[zivkovicmilos]

Can a realm state be modified concurrently by more than 1 tx?

No, it's not currently possible. Transactions (TXs) can arrive concurrently on different validators, which initiates the first round of consensus to determine the order of TXs. After that, TXs are executed sequentially. While we may consider implementing more concurrency features in the future, we will ensure to add all the necessary locking strategies to safely manage them.

Sort of unrelated to this, but I found it interesting how Solana solved this problem of concurrent transactions (it's about the only part of Solana I actually like 🙃), and it's the key to how they can claim thousands of tps (even though in reality they don't nearly have the throughput).

Solana transactions hold additional metadata information that describes how a transaction will modify state. You don't have this moment with Ethereum, where you don't know how your state transition is going to play out unless you run it first. Solana transactions tell you exactly what they modify and how, and based on this information that you have upfront before putting the transactions to the runtime you can schedule them and run them concurrently without an issue. It's powerful because you can now concurrently execute reads, and shuffle in writes as needed.

You can learn more about it here, just thought it was cool to mention this if we are not bound by sequential txn execution like Ethereum