Hi all, I'm Rob Middleton, the creator of this site. Very cool to see it pop up here!
The tech stack is Nodejs, MongoDB, Redis, Socket.io, and React + Redux on the frontend.
It's actually been a pet project for a long time (6+ years) but I've been taking it more seriously since Jan 2020.
Fun fact: the original was built with Backbone.js and CoffeeScript.
Happy to answer some questions and please let me know your feedback too.
Thanks for making "open world" board/card games. Open world in the sense that an interaction order is not enforced, where you can place the chips anywhere you like, whenever you like, leaving it up to the players to enforce the rules through either common sense or another communication channel.
I remember back in the Google Wave days I created a connect four game where no turns were enforced, and you could take out the chips of the opponent if you saw that they cheated. A Google engineer was a bit irritated by that, she expected that it was turn based and pointed it out as a flaw.
Maybe you could add a feature which shakes the entire table so that the cards/boards end up in a state where continuing doesn't make much sense, like when you push away the board IRL because you noticed that you lost.
Thanks for building this! As a hobby game designer, I've been wanting something like this for a long time. I'll be digging into the docs[0] to see if I can prototype one of my card game concepts.
I've also just added PlayingCards.io to my website[1] of multiplayer games that require no user accounts :)
just the other day I was wondering what happened to older Javascript frameworks like Backbone.
Can you elaborate why you moved from Backbone to React / Redux? As of what I recall, Backbone was extremely stable and a lot of companies used it in very heavy web apps as well.
Since, the 2D board games of the type on your site doesn't seem to require heavy front-end lifting (I might be completely wrong here), I'm curious to know the reason behind switching to a newer technology which is still riding the hype wave.
Thanks. And of course, the site is very nice. Will be sharing it with my colleagues for our Friday online hangouts!
Good question. Both Backbone and React provide a way to build UI components. React Components are way easier for:
1. Having nested DOM elements in your components. Backbone really wanted you to just have one element per component, and then use jQuery to add children as needed.
2. Adding event handlers and other HTML attributes. JSX syntax means you can basically write HTML in your JS file. Backbone made you add event handlers manually.
3. Nested components. React lets the parent simply specify what children it wants and React automatically creates/reuses/destroys component instances for you. This was all manual in Backbone.
The bigger advantage though, is how the state is typically organized in React apps.
In Backbone, app state was sprinkled throughout the component hierarchy, and often you would have do event spaghetti up and down the hierarchy to update some state held by another component.
Typical React apps use a state container like Redux, the UI is "projected" from the state, and components just send changes to the state, aka "unidirectional data flow".
That said, React is not the best for games. Maintaining 60 fps can be difficult and we've done some fairly heavy optimization to try to keep it smooth.
Hello! Love the website. I'm 100% going to use it in the future! However, if you use inspect element you can easily see the suit of the card before its flipped.
Well, they can also just drag around community cards and recall everyone's cards, so I'm not sure you'll want to use this page at all if you're worried that "people will ruin anything."
Totally true. However, doing those things is totally obvious while looking at the cards is invisible and not detectable. Anyone I would play with I would trust enough not to just ruin the entire thing just to be mean but I'm not sure I'd trust them enough to not look at the cards.
Looks great. It probably doesn't matter for something like this, but what algorithm are you using for card shuffling? Note that if you use a 32-bit random seed, you only reach about 4 x 10^9 of the 8 x 10^67 different ways a pack of cards can be shuffled - a tiny tiny tiny fraction.
Trying to work out how many bits the seed has, but it depends on the browsers implementation of Math.random() - in theory could be anything but apparently its usually Xorshift128+, which as far as I can tell has a 128 bit seed. So all good? Although I'm not sure where the 128 bits for the seed come from.
I'm intrigued by why all these example shuffling algorithms are based on swapping cards in-place.
The first algorithm that would occur to me would be take a pile of 52 cards, and repeatedly pick cards randomly to place into a new pile that eventually has 52 cards.
Though I suppose that's the kind of thing that's trivial to program in scripting languages with arrays that are easy to remove a middle item from, and less so in a classic algorithmic language like C.
It's surprisingly easy to write an incorrect shuffling algorithm, and end up with a subset of permutations or a very skewed distribution.
(in fact, there's both obvious and interesting information preserved by a single riffle shuffle... which is why you need to shuffle multiple times in real life. It would be cool if the site emulated a riffle shuffle, so you'd need to shuffle seven-ish times to get close to a uniformly random permutation.)
But that's what I mean -- swapping seems indeed suprisingly easy to write incorrectly, just as you say.
But just randomly picking from a pile seems pretty easy to write correctly. No? And if you have an off-by-one error, your deck of 52 cards gets turned into 51, so it's not like you won't catch it...
Maintaining a "pile" of not-yet-selected items, and randomly removing elements from it, turns your shuffle from an O(n) algorithm into an O(n^2) one (unless you go out of your way to use a more sophisticated data structure than either an array or a linked list).
It's not likely to matter much if you're only shuffling 52 cards, but if you're writing a general-purpose shuffle algorithm, there's no reason to needlessly make it inefficient.
You don't actually need two arrays to implement your idea. Since the combined size will be constant, just one array with an index indicating the split is enough.
When moving cards from one side to the other a lot of elements will have to be moved around. But for small n it should be much faster than using linked lists. And also relatively easy to implement in C.
The shifting of elements when inserting can be avoided by only swapping two positions. (ABXDEFC instead of ABXCDEF, when inserting X into ABCDEF). But by then you have just reinvented Fisher-Yates.
So the swapping in some of these algoritms is basically an implementation of your idea.
> The first algorithm that would occur to me would be take a pile of 52 cards, and repeatedly pick cards randomly to place into a new pile that eventually has 52 cards.
This is a perfect description of the Fisher–Yates shuffle – the standard you should reach for when shuffling, and what the latter article suggested, too.
Of course, as a technical implementation detail, instead of having two actual arrays, you can use one array and swap within it to get the effect of two arrays, except in one for performance.
I've used this a lot with my team for our remote "happy hour" since pandemic started. It's been a great way to interact and blow off some steam. I'm surprised that there isn't baseline templates for blackjack, poker, spades, and other common card games although the site makes it easy to save configurations once you have something that works. Highly recommended!
Nice site. During the quarantine a lot of game which you can play with your friends over internet appeared, so I created a site to make it easier to find them: https://playwithfriends.link/
I'll also add this site later today.
If everyone has build/played similar games, let me know.
The best thing is how you can import card data as a CSV.
I’ve been prototyping a card game with it and have a few command line scripts to go from an Indesign deck to a fully working play-testable game in under a minute.
This is really great. I love how flexible it is - I think BYO video chat / turn management is a fine tradeoff to make. Wish I knew about it a year ago!
Just digging through the HTML and jS source, it appears to be fairly standard HTML with some ReactJS+Firebase on the frontend. It's communicating via Socket.io which implies the backend is running the reference nodejs server:
We use Firebase for Auth and file storage only. Game updates are sent through Socket.io in order to have better control over them, and also Firebase charges per update which is a lot for games.
Tabletop Simulator has pretty much every card and board game you can think of as a fanmade mod. There's also a scripting system and official virtual versions of commerical games that use the scripts to automate parts of the game like setup.
Wow, and board games! At the beginning of the pandemic, my son was obsessed with chess but wanted to invent his own variants like horde or crazyhouse. Instead of buying several chess sets, I whipped together something like this but with only one board option and no collab. I wish I had known about this sooner!
When I was looking to buy pieces for a custom Onitama set I made, I discovered the universe of "fairy chess pieces," or non-standard pieces with different moves or powers. The classic one is the Amazon, which is a combination Queen and Knight (hard to google "amazon chess piece," of course...), but there's also the Empress, the Elephant, the Camel... With easier access to 3D printing, there's now a whole world of these.
I may have missed this but is there a way for certain players to look at their own cards without other players seeing them. This would be great for certain games where players are dealt a hand and permitted to examine it privately.
I've been wanting to build and play on a "open world" deck of cards game.
Now I now I can play without creating it first and I won't have to waste my time creating kt only to find out later that someone else had already done it.
You can put a stack in a card holder if you edit the table via the toolbox/briefcase icon and add the relevant widget. Then you can move a stack by dragging the corner handle (the number)
One of my long term untouched toy app project ideas has been basically this, but strictly limited to local Bluetooth connectivity in face to face settings. For when you don't have a deck, or don't have a table, or just feel like gadget overdose.
I think this could actually be a feature. In a real game, the players self-enforce the turns, and when someone gets distracted and plays out of turn, it's hilarious to banter while setting things straight again. Of course that would need the videocall part.
A few years back there was this great platform for playing Magic: The Gathering, which didn't enforce anything at all and it was still great. Even did a few tournaments using it.
As long as all the moves are logged, you can enforce the rules by yelling at people.
Magic does have the problem that sometimes, in specific edge cases, players can disagree about what should happen based on the rules. It's hard to come to consensus via the yelling at people protocol.
If the author is here: it's easy to accidentally flip a card while trying to move it. Consider making flip be a more complex gesture, like a connect-click/long-press menu or a pop up confirmation.
The tech stack is Nodejs, MongoDB, Redis, Socket.io, and React + Redux on the frontend.
It's actually been a pet project for a long time (6+ years) but I've been taking it more seriously since Jan 2020. Fun fact: the original was built with Backbone.js and CoffeeScript.
Happy to answer some questions and please let me know your feedback too.
And follow us on Twitter for updates: https://twitter.com/playingcardsio