Games?

[burdges]

We expect parachains/parathreads can deliver respectable performance for dedicated applications, we need some demonstration applications that require more parachain blockspace than these little distributed finance things. It's clear games provide an obvious direction, but which games played sound fun with a distributed database?

We need randomness for games which requires that game developers learn to use verifiable random functions (VRFs). I've given one talk around fun VRF usages and envision giving more.

Could world building games achieve much? I suppose many need too much storage, but if the world expires after 24 hours then they could operate by UTXO using previous blocks as world segments. Is it reasonable to only permit world segments to update infrequently so that each update occupies a whole block, maybe via some off chain state channel? If so, there exist open source minecraft games one could fork, but one should explore and simplify the game rules.

I suppose Illuminati clone or other collectable card games sound like both easy VRF based randomness, minimal on-chain data but still far too much for our compeditors, and world building, but Illuminati itself runs into copyright issues. Could on-chain governance make the cards?

I've been quite impressed by Cheapass Games so maybe their card games could provide a source of inspiration.

[alxs]

We've been getting quite a few game-related applications lately. See:

• https://github.com/w3f/Open-Grants-Program/blob/master/applications/newomega.md (#243)
• https://github.com/w3f/Open-Grants-Program/blob/master/applications/dotmog.md (#265)
• https://github.com/w3f/Open-Grants-Program/blob/master/applications/mobile-game-framework.md (#46)
• https://github.com/w3f/Open-Grants-Program/blob/master/applications/saito-game-protocol-and-engine.md (#73)
• https://github.com/w3f/Open-Grants-Program/blob/master/applications/SubGame_Network.md (#134)
• https://github.com/web3gamesofficial/Open-Grants-Program/blob/master/applications/web3games.md (#415)
• https://github.com/w3f/Open-Grants-Program/blob/master/applications/bit_country.md (#78, #305)

[Zombieliu]

Yes, Web3Games provides game solutions based on Substrate. We also have related sample games and even recorded videos.

https://drive.google.com/file/d/167bwKm7SyP95FR5SMhNZGQ-R5Tv39NTZ/view?usp=sharing

[Noc2]

Also, see https://bit.country/ or https://github.com/bit-country

[GamePowerDev]

Hi @burdges, great topic and your talk regarding VRF usage was very interesting.

Our team at GamePower (https://gamepower.network) is approaching the issue from a different angle. We know the distributed ledger plays a big part in defi applications and for many of those it works perfectly. However, for gaming we believe relying 100% on the blockchain right now is a mistake (until there is more advancements in the tech).

For example a turn-based card game may work just fine using the current blockchain tech we have now, but an open world online game that requires a much heavier workload would suffer currently if it depended on the blockchain to handle authoritative logic.

I believe what we need now are decentralized authoritative game servers that also run as light clients for whatever underlying chain it is built on. This way any long-term data such as game saves, high scores, user's inventory or NFTs can be written to the decentralized database... but all core game logic that requires near instant processing should be executed by these decentralized authoritative game servers.

Think of it as how substrate works. You can swap in a WASM runtime and give the node totally new logic. These decentralized game servers should work the same way. When a user starts an online gaming match the following things would happen:

Rough Idea

• User sends a request to the blockchain asking to start game named "Frogger"
• The blockchain checks for any game server peers that have capacity to host the game
• The selected game server loads the "Frogger" game logic (almost like a substrate node loads a new WASM runtime)
• The blockchain sends the user a connection to the game server so that they can connect.
• The blockchain also sends 2 other (fishermen) game servers the connection.
• The "fishermen" game servers load the same "Frogger" runtime and can validate the logic of the running game match as it is being played in headless mode.

This is obviously a very rough idea.. but what this allows is for anyone to run a game server as long as their computer can run the games in headless mode. A game server can also be randomly selected as a "fisherman" and their job would just be to load the game runtime, connect to the proper game server peer and make sure the game is running as it should.

What I described is almost the way validators and fishermen work on the relay chain.. but without the need for the blockchain to store every minor detail of gameplay. As long as a game server can load a new game runtime on the fly... it can host, validate and serve game logic.

[burdges]

Appears you're describing a "state channel" between the user and game server. We've never explored state channels ourselves because parachains should provide fast cheap transactions, but sub-block latency obviously remains state channel functionality. I think state channels do not require fishermen per se. I know some employ a monitoring service, but game use cases avoid this requirement provided users stay engaged.

We could start a separate discussion about what state channel designs sound relevant for polkadot projects, making Ink<->parathread transitions nice, monitoring via XCMP-like watermark tricks, when forwarding matters, etc. You'll find many academic papers designing state channels, so maybe start with SoK: Off The Chain Transactions. Stephanie Roos already chats with us about unrealted topics. Patrick McCorry @stonecoldpat https://stonecoldpat.github.io/ has a company https://www.pisa.watch/ doing state channel work.

---

Substrate itself is "turn based" aka blocks. In particular, you cannot extract randomness from Polkadot in less than 6 second intervals, slower really, so game designs should take this into consideration. It's doable to employ relay chain randomness only when selecting game servers or building a starting map configuration though, so automated players only get surprised initially.

Also related, OpenConflict: preventing real-time map hacks in online games by Elie Bursztein, Mike Hamburg, Jocelyn Lagarenne, and Dan Boneh

There are crazy anti-cheating measures used by serious game tournaments that land outside our scope, so be prepared for some criticism there eventually, but oh well..

[Noc2]

Just to share some links: Regarding state channels and substrate, see cChannel and cApps-substrate. And regarding randomness potentially the following is interesting https://github.com/Cardinal-Cryptography/substrate/tree/randomness-beacon based on this grant application.

[burdges]

I'd suggest folks think about doing a collectable card game engine. Ideas: I'd think few-party games could be played largely off-chain via a state channel, but on-chain games could perhaps be more open world and on-going. Is an open world card game fun? Illuminati style maybe? I suppose de facto game card rules would be expanded via governance, but maybe more thought be placed into this after an initial design gets done.

[stonecoldpat]

Just to chip in a bit. I wrote a paper a few years ago about our experience building a game of battleship in a state channel (IC3 bootcamp project): https://fc19.ifca.ai/wtsc/Battleship.pdf

The main issue is guaranteeing that game continues if the counterparty aborts. e.g. how do you finish the game? You just end up having to run it on-chain and it is a pretty annoying grieving factor. Since then, i've never really been convinced that gaming in a channel is a good idea, its better for expressive routing conditions.

I know there is also a team at Consensys called Magmo https://github.com/magmo/force-move-protocol that still believes in gaming via state channels. They might be a useful contact point to advise on such a project.

[burdges]

An open world card game sounds tricky too. Imagine players build a dungeon from cards they draw, like monster or trap cards, and also explore other players' dungeons. If explorers can do permanent damage to dungeons, then must dungeon owners return all the time for repairs? If not, then what can explorers actually do that's fun?

Also, can any card game be fun unless players frequently restart from a position of relative equality? It's possible a dungeon could heal itself from most damage, but your goal could be collapsing another players dungeon, so they restart.

Are collectable card games fun? I never played them, well actually I always mocked them, but they maybe solved this relative equality issue, meaning the game ends, but they keep their deck.

I found http://www.argentumage.com/community.html and https://arcmage.org or https://github.com/wtactics/arcmage or http://wtactics.org/ via https://gamedev.stackexchange.com/questions/9595/are-there-any-open-source-ccg-projects by googling "open source collectable card game"

[Noc2]

Are collectable card games fun? I never played them, well actually I always mocked them, but they maybe solved this relative equality issue, meaning the game ends, but they keep their deck.

Yes, they are (big magic the gathering fan) ;-)

[EdwardAThomson]

Somehow I missed this thread when it first popped up. I've spent a lot of time over the last year and half digging through any project with at least a half claim to decentralized gaming. There has been more progress than many suspect. The two main problems have been a lack of marketing and a lack of funding. Ok, a third main issue is too many people defaulting to the Ethereum computation model of trying to force everything into a smart contract which is really unnecessary.

State Channels

A state channel approach can certainly work for something that feels almost real-time and perhaps with some R&D then decentralized games will be real-time. The main point being that the logic runs off-chain and only some sort of settling happens on-chain. The role of fishermen is unnecessary when all players run a 'game node', of course if players don't want that hassle (they sacrifice trustlessness for convenience) then certainly it is something to consider.

A channel approach will work for low N, i.e. 10 and perhaps at a stretch 30. Beyond that, more R&D is definitely needed. So this works for deathmatch style games but not yet appropriate for open world.

There is already a working Battleships game: "XayaShips".

It's pretty close to real-time but the game mechanics are rather simple.

Interestingly, the Xaya team applied for a grant at the end of 2019 and managed to work on and complete the first of three proposed milestones. Their tech was recently ported to Polygon which is competing for gaming teams, which is proof of the agnosticism of the upper layers of their tech stack (where the innovation actually is).

Recently, I came across FragColor (ping @sinkingsugar) who are building part of their tech stack on Substrate and may even be a good grant candidate. I already made an intro to Surag (just FYI). Their general approach is going down the same path of taking the bulk of computation off-chain and having 'lazy checking': i.e. game play can be real-time but the finality will lag behind and I'd even guess it is done in batches. So it will be somewhat reminiscent of a channel.

Open World

For turn-based, this is already 'solved'.

Examples: Dark Forest, Nine Chronicles, Taurion (still in production), SoccerManagerElite (still in production), Conflict.Eth (alpha).

Basically, as Jeff suggested. It is already possible to have a decentralized turn-based game with thousands of players but trying to make such games real-time requires further R&D, but I think it is possible.

Some comments on the respective approaches:

• Dark Forest - the game logic on-chain but they use the xDai sidechain and are by far the largest user of gas. There is an off-chain component in the form of ZK-snark computation for unveiling the map (iirc). This is neat, but the ZKS part is not my favourite. I do feel that a modification to the Open Conflict technique (see Jeff's post) would be better.
• Nine Chronicles - they have a simple game where the combat is based on an RNG pulled from the chain (fully deterministic and non-interactive). The RNG is a reply to a transaction, it's not passive. Their stack is fully in C# although I could convince them to bridge to Kusama/ Polkadot later.
• Taurion / SME - the technique here is to store actions on-chain but for computation to be done offchain by 'game nodes'. The technique is actually one I described to Bill and Bruno in a private w3f repo that I don't have access to. Long story short: RMRK uses a similar technique.
• Conflict - is heavily smart contract based like Dark Forest but still in the early days.

Card Games

To be honest, there are too many card games in the blockchain world. They can definitely be fun for those who enjoy them, but they don't appeal to everyone. Further to this, most of the card games we see in Ethereum are lazy in their approach to technology: everything is centralized, except the NFTs themselves. For me, that feels contrary to the spirit of Web 3.0.

Of course, they can be decentralized too. :-)

[darkfriend77]

I agree that card games and other turn-based games might not be a technical novel achievement, but providing a solid solution for state channels for up to N=10 players in substrate would allow to get a lot of game concepts up and running in the substrate ecosystem.

It's one thing to make a blockchain game and another to have it compete on the market with non-blockchain games, so focusing on the games where we can provide solutions that can compete with nonblockchain games seems more valuable for the ecosystem.

For DOTMog, we need state channels for the duels, which will be turn-based for now^^. So we will work on such a solution. Already with state channels, I see a lot of challenges even for a turn-based game.

Maybe a good start would be to start a group to work out some solutions that solve basic requirements concerning state channels, otherwise, a lot of the games will just drop back to the centralized off-chain game server, allowing them to use both worlds power, which is very tempting.

• Hidding player Informations (hidden cards), but still preventing malicious gameplay.
• Handling rage quitting players
• Handling randomness
• Light client vs. full client

Maybe having state channels add up an arbitrary party could solve some of the challenges. Not sure but in a state channel with only a few players, a team-up on malicious game nodes might open an attack vector.

[EdwardAThomson]

Yeah, I think Xaya's solution should do some of what you are looking for although I'm not at the correct dev level to verify that. I dare say that their Xaya won't perfectly cover everything you want to do, so some R&D still needed. I'm sure you could have a conversation with the team, happy to do an intro although they are generally freely chatting over in the DGA. While that group is not Substrate-only, it is focused on fully decentralized games. One option is to create a working group there, since this is really a very general problem for decentralized games and some teams have worked on solutions already,

But I wouldn't be against creating a channel on Element (or whatever) for Polkadot/ Substrate game builders. :-)

[Noc2]

@darkfriend: Fyi: We recently followed-up with Celer. They promised to continue to work on cChannel and cApps-substrate later this year. Apart from this https://perun.network/ is close to finishing their first grant: https://github.com/w3f/Grant-Milestone-Delivery/pull/235 + https://github.com/w3f/Grant-Milestone-Delivery/pull/236 and so far it looks quite promising. So we are probably going to continue to work with them. I could put you in contact with the team or feel free to ping them on github.

[stechu]

How about DarkForest?

[web3cryptowallet]

Hi, I develop dApps gamedev platform https://twitter.com/Web3Wallet

[Noc2]

I’m closing the issue, since by now we have quite a few teams focused on games that are close on launching their parachains.