Holochain Forum

A Distributed Cocreated Card Game

In this Post I would like to share some of my thoughts, to hopefully provoke some of yours. The topic is, how a decentralized cocreated collecting card game could look like. As reference points of existing games I use Magic the Gathering and Hearthstone. But those serve only as examples, you do not need to know, to be part of the conversation.

The Holochain architecture inspired to think about a variety of applications and aside of all these how-to-save-the-world-ideas also ideas like: Why not just make a games. Someone built a decentralized Chess Happ and there has been a discussion about decentralized Fortnite and probably much more. But my impression is that card games with their in a sense incrementally increasing, modular rule sets, that are printed on the cards, are an especially suitable genre. To explain why I would like to start with a small detour into two card games that I am familiar with.

MTG and Hearthstone
[spoiler]
The mother of collecting card games is probably Magic the Gathering. In Magic players alternatingly take turns, in which they play cards into the game, which they can use to attack the opponent in order to reduce their life total to 0 and win the game. When about 20 years later Hearthstone went the step to the digital, those basic elements stayed the same. However, this step not only brought along some downsides and challenges but also opened up new designspace. An unavoidable downside was that some players liked the special feeling of holding physical cards, that one can touch, smell, and whatever you did with your Magic cards. The Hearthstone developers did a good job of graphically retain as much of the feeling of real cards, but in a computer game this is only possible to some degree. An example of a challenge is the following: In Magic there basic game mechainic is a stack when any player plays some effect, it is virtually put on a stack, on which both players may react, by putting more effects on the stack until both are fine and the effects are resolved top to bottom, until a player wants to play more effects or the stack empties, and the game procedes into the next phase of a turn. This offers a lot of potential back and forth, that is in practice rarely used. Instead a player mostly just plays his turn and when the other player wants to intervene they say stop, or return to the point where they wanted to do so. If one had copied this baic mechanic into a computer game, and there are multiple instances that did so, it results in an back and forth of klicking „no i do not want to do anything now“-Buttons, that can make a game quite lengthy. What Hearthstone did whith this challenge was abandoning the idea of actively interveneing during the opponents turn. Instead players can play their own turn uninterrupted, but with a time limit, which was one thing, that boosted up the experience of the game. In addition, to retain some of the coolness of messing up your opponents turn and leading them into traps, they added Secret cards, which are played face down and have a certain trigger, to resolve an effect during the enemies turn, without requiring an action of the other player.

Most importantly, however, the tranistion into a computer game also brought new opportunities. For example random effects, that browse through all existing cards (e.g. „Summon a random 3-cost Beast“) are a frequently used design option wich players associate with fun. The extensive generation of many tokens and copies of cards is another feature that would have been very cumbersome in a physical card game. There also exist cards that recast all effects of certain kind, that happened since the start of the game. In a physical game this would require to prophilactically take notes about all these events. On top of that recently a card entered the game, that analyses the state of the board and deploys its own Algorithm (presumeably a fixed pre-trained neuronal Network AI) to offer the player „the perfect card“ in that situation. The design space that opened up by this transition to a computer game is a big part of what made Hearthstone so successful.
[/spoiler]

In this same thinking the step from a centralized to a decentralized computer card game is big and brings along problems, challenges and opportunities.

Problems and Challenges

In this section I mention and count through some Challenges I realized, some of which might be unavoidable problems, similar to the lack of physical touch in the past section.

At first it is worth mentioning, that a single game is played between two players, that can easily connect peer to peer. And if one wants to stick to a central game development that releases the game as well as updates, not much would need to change, to use a framework like Holochain. For the following rather easy challenges I can see a solution already.

[spoiler]
First of all let us consider challenges, that arise with the part of the game, where you basically manage your account and card collection. Afterwards we will look into the challenges during one duell between two players.

Instead of clients connecting to the server, they connect to peers directly. Here some decentralized match making tool needs to be deployed, which is not a trivial thing (C1), but also not a thing, that players have present during their experience of the game. For this solutions exist.

Furthermore in these collecting card games usually not all cards are available from the beginning, instead they need to be earned, collected or bought. Without a central server saving the progress of each account, it has to be stored locally. This offers the ability to hack ones game to unlock all the content and thereby reduce the fun of the game (C2). This can be prevented by the usage of currencies (or current-sees in the Arthur Brock sense of the word). For example with every game played (or won, or every game that took at least this long…) the player can earn some currency, that is cryptographically countersigned by its opponent, who does not loose currency, it is not zero-sum, but instead only testifies, that the game took place. But also actions you take that effect your account only, like spending a currency to buy packs of new cards, can be shared in the DHT for data integrity. For things like opening a pack of random cards a provable random function can be used. All these things need to be implemented differently, than with a central game, but Holochain is well equipped for that, and the player won’t realize the difference.

During a single duel, where two opponents meet, similar tools are required, if for example a player draws a random card from his or her deck. I won’t count this as a seperate challenge.
A new one however is, if the players loose connection to each other (C3). The game should not end in a draw (nor both win or both loose), because then players could cut their connection on purpose right before they would loose. In this case an indirect connection over peers in their DHT neighbourhood (or the DHT neighbourhood of the games hash) is required. This however might in any case be the easier way to implement e.g. drawing random cards from your deck. For every duel one or several peers are chosen to play the server.
[/spoiler]

We can go further and transcend a central game development. How would a game look like, that is decentrally cocreated by its players?

If we would require the players to build everything … we would be done. That is not what we want.

The other extreme is constituting all the rules, leaving the players only with visual customization. Definetly something that enhances their personal playing experience, but also something, that is theoretically possible with centralized games already. Where I see the sweet spot, that makes card games especially suitable for this is, that the game comes with a general set of rules, that is unchanged, and on top of that cards extend those rules with their card texts. This offers an opportunity, to let the major part of the game be created by the players. The general rules of the game would be constituted by us, the central game designers, in a way that they are intended to remain unchanged over the course of time. Then it would be released onto the public, which can expand the game by creating cards on their own.
Thus instead of centrally released new expansions the players (or more precisely, those types of players, who enjoy and shine at those activities) would introduce new cards, and thereby keep the game experience fresh. It is an activity, that many card game enthusiasts do already without ever seeing implementation. And it reminds me of the many fan developed maps of Super Mario Maker. Furthermore this states an invitation to the players, to make the game ‘their game’ (one point Mark Rosewater a Magic game designer states as critical for good game design, in a presentation called ‘Twenty years, twenty lessons learned’.

This idea opens a door widely for a new type of game. But how should that work out? Lets go to the more serious challenges. There are technical and authorizational problems.

Technical Challenges
[spoiler]
The players not only need to think of a new card, but also implement it correctly. Suppose those cards, that are not correctly implemented will be simply seen as „bad card designs“, and therefore soon sorted out, by some mechanisms we think about in another section. To support this one could flag cards that do not work as intended, and report the but to the creator, to fix. There still is a big problem: (C4) With the endless design space, it is likely, that the program code that implements card A perfectly fine, causes some bugs in the interaction with card B. How should this collision be a) detected and b) resolved? If the framework is too rigid (something like every card has a number of points depending on its cost, that can be spend on predefined and therefore non-conflicting effects or stats the card has, and thats it) the result would be the equivalent of a game that just has a lot of boring cards, of which most are never played.

Can we have a framework for possible card creation, that leaves open enough space for effects, that have never been thought of, by us, while at the same time being rigid enough to prevent these collisions? Maybe the general game rules, like the structure of the players turns, can be chosen in a way, that prevents some conflicts from the card implementation. Similar to how the chose of hearthstone, that cards can be played only during ones own turns prevented the turmoil of the back-and-forth do nothings.

Or do we alternatively try to resolve bugs between conflicting cards in some other manner?
[/spoiler]

Authorizational Challenges
[spoiler]
It would not be a fun game to play, if players could simply create their own overpowered cards and play with them to win every game. Thus some curation is required, before a card fully enters the game, whatever that means. And even more, similar to conflicts in the program code of cards, two cards developed by different people might be fun on their own, but be unbearably, brokenly strong in combination. In such cases curation is needed to remove cards from the game again, or at least make sure, that overpowered combinations of cards are not available in the same game format.

How could that happen (C5)?

Such a curation can be done by other players, who serve as neutral judges or referees and can be rewarded for this activity. In the Game League of Legends there was a time, when the conviction of players, that have been reported for intolerable social behavior was outsourced to the player community similarily in an institution called the Tribunal.

The description so far suggests, that there is some global consensus about which cards are a part of the game and which are not. Such a consensus would reeintroduce the problems that come along with a global consensus and that people in the blockchain world are familiar with (C6). In especially it would need to find a way to deal with a sybil attack.
Another even more innovative road would be to solve this without a consensus. In such a game every player could have their own state of the game, including which cards exist. Why should it be forbidden to play a card, that both players are fine with? This however introduces a big problem. When do the players decide which cards they are fine with? When a match between two opponents is assigned, do they first need to look through every card of their opponents deck and say yes to it? That is not only annoying, but also looses the fun component of not knowing what your opponents strategy is. If on the other hand you need to publish a list of all the cards you agree to, and get an opponent assigned on that basis, how do you even get the chance of allowing cards, someone somewhere created, that you do not know (C7)?
To me this looks like the most interesting approach I have thought of so far:
When you are looking for an opponent, you open an invitation, that includes a list of the cards that you want to play in that match. Before, you do so, you not only need to create your own deck, but also a list of cards you accept as „cards that exist in your game“. The matchmaking algorithm will then only assign to you opponents that play only cards, that you accepted. Suggestions for this list of cards are offered to you on the basis of what other players are playing (or wishing to play). In the sense of „If you say Yes to this cards, there are X more possible opponents you could connect to“. If you create your own cards (an additional kickstarter might be required, but…) and want to play with them, this makes them appear in the suggestion list for other players. By the way, browsing through possible new cards to accept, while searching for an opponent with the matchmaking algorithm not only increases their chance of finding opponents, it also gives the players something enjoyable to do instead of just waiting.
[/spoiler]

So thats it. My thoughts on distributed collecting card games. Just wanted to put them out there, in case of the unlikely event that someone wants to jump on it. Any thoughts welcome.

3 Likes

@Marvin thanks a lot for writing up all those ideas about Holo card games. We know a growing group of people who are thinking about decentralized/distributed economic games where people can try out different systems to see how they might work. Not quite the same as what you are thinking about (not card games) but your ideas are great food for thought!

Thanks for your reply.
That is something quite different, that I am interested in as well :slight_smile:
would you introduce me to that group?

Unfortunately, they’re not very organized yet. Some of them are chatting in Mastodon. If it looks like anything is getting organized, I will ping you in a PM here.

But here’s some chat posts from one of the devs. You’ll need to click “show more” annoyingly often to read it.

More: https://banana.dog/users/yaaps/statuses/103047093150886279

Which says this https://ehiad.org/blog/000004 is the design for the game you want.

Hi. I’m the author of yaaps and ehiad.org. I’ll post an intro as soon as I’ve had a chance to digest the developer sources, but I wanted to make myself available here first

The collectible card game engine has been back burner for me for a couple years. I have most of the seventh edition Magic cards, which is when I discovered the genre, but I quickly realized that I was never going to be able to backfill my collection or keep up with new releases

Also, I’ve played a number of mobile games where card acquisition is a thinly veiled mechanism. These are generally free to play, expensive to do well, and all but unregulated

So a couple years ago, I shared part of the engine design for a distributed CCG with a friend and more recently posted that to a blog. I was thinking of blockchain at the time, but the engine only requires a proof for consensus when simulating artificial scarcity as a game mechanic. I’m much more interested in situations where transaction chains can fork, so that players who want to separate from a group can do so and keep access to their creative efforts. I’ve been looking at constructions where that’s possible, and (in many situations) it’s also possible to merge, which is really exciting

That blog only describes the storage layer. I’ve also designed a data layer that provides capability negotiation with the object layer to support operation or state-based CRDTs. The object layer can be any implementation of the actor pattern idiomatic to the programming language that provides the necessary interfaces

A lot of software uses some variant of MVC (model, view, controller) pattern. That above is the model in a Model, Capability, Actor pattern. Actors and capabilities are both present as models. As long as there is at least one actor and the capabilities of creating and assigning capabilities are present, the system can be bootstrapped

I’m bootstrapping with ActivityPub as my core vocabulary because of the installed base and syntactic sugar for crud operations and social activities. In this context, a game is a service actor and a game engine is a service actor with a capability to spawn games

This operates on a server with connected clients, because federation is easier to launch a community and onboard new people than peer to peer technologies, but the goal is to iterate towards simpler server deployments by keeping additional functionality out of the core protocol so that communities approach a 1:1 ratio of clients to servers over time

The social, economic, and political considerations are similarly engineered to provide building blocks for robust networks that are conducive to personal autonomy, economically supportive of those providing labor, and resistant to capture by capital

2 Likes

Cool to see some very detailed ideas. Let me know if you get started on any hApp design or code.

1 Like

Thanks all for the posts here! So interesting for them to come right now!

Just this weekend I posted an idea in another forum around thinking about how a card game around based on regenerative agriculture, REA accounting and cooperative play could be started. It is also inspired by MTG (with tweaks like making lifeflow indicators replace mana) but also by games like “race for the galaxy” and “Pandemic”. The cooperative structure of the game is from pandemic where basically humanity is in a race against time to halt the outbreak of disease and players cooperate to stop it. This is similar thinking but it is not against disease as much as it is navigating ecological state collapse.

Here is the first rough (very rough) draft of that:

I was a little reluctant to share about it before because I was worried it might start moving and I don’t think I can spin another plate. But since a bunch of things started popping up in the context I thought I might as well throw it out the for people to possibly get inspired by even if I can’t engage to the degree I would desire to. I’d love to hear some feedback from people that are into REA on their thoughts on if this could contribute to learning. @bhaugen, @pospi, @ThomasMiller

It would be great to create a sort of generic card game basis on Holochain from which we are able to create many types of games with different mechanics. In case someone didn’t know, there is actually a basic generic starting point for building games on Holochain that was created by @wollum for a devcamp here:

In case anyone is looking to start prototyping something fun :slight_smile:

2 Likes

I feel like @dellams would be interested in this thread too.

Hey Viktor thanks for sharing your game idea it looks amazing! Probably my generic-game-holochain repo is poorly named. It should really be two-player-turn-based-perfect-information-game-holochain. I really like your idea of creating a generic card game framework (or at least multi-player-random-hidden-information-game-holochain :stuck_out_tongue_closed_eyes: ) as multiple people have expressed interest in this.

The key will be to have all players to privately commit a source of entropy at the beginning of the game and publish a public proof. This is in order to replicate the shuffling of a regular deck of cards. Each round players could reveal additional entropy which determines the next draw in a way that could not be predicted by any of the players (without collusion). The rest would just be using the cards to mutate the game state machine.

I really wish I had the time to take this on. Maybe another dev camp…

1 Like

Note that this does not deal with the collectible/ownership nature of the cards. Y’all probably going to need a blockchain for that.

Hey players,

I feel a lot of resonance in this thread with a game concept I’ve been working on for a while. It’s called Castalia, a gamified cocreative knowledge network that has a card element to it.

1 Like

Im amazed by the amount of interest in this :smiley:
Thanks for sharing your projects.

I like the idea of that multi-player-random-hidden-information-game-holochain.

Yes, if cards should be tradeable (like with MtG), you might want to do it with a global consensus I suppose. If you can only collect them, but they never leave your account (like in Hearthstone) things are a little easier. Although I don’t see, why a global consensus (/a blockchain) should be neccessary in any case. If I give a card to you, that can be treated the same way as a transaction in a MC-system. So only the two of us involved and the DHT backing it up, so that I don’t delete that entry afterwards. Or am I missing something?
The question is how should new instances of cards come into the game?

1 Like

Of potential interest: https://medium.com/tezoscommons/a-digital-collectible-card-game-coming-soon-to-tezos-ddd939f3b119

More theory in the concept paper: https://coa.se/static/images/coase_inc_motivation_philosophy.pdf

1 Like