This is awesome. It's great to see a lot of projects coming out in this area.
I've been working on a similar project for over a year now. It's essentially this exact concept turned into an entire platform for designing/creating board games and then publishing the game so others can play it directly on the platform. Think of heroku or squarespace for board games.
I have a very rough, working prototype of the editor and game engine. There is a ton left to do (I could write pages about what I'd like to implement/improve). But, I'm at least finally getting somewhere with it.
At the risk of utterly destroying my server... for anyone who is interested, I have a demo site for the game editor prototype. A game can be test played from the editor by clicking "game play tester" in the upper-left menu. There are no docs or anything. But there are several games already implemented on the demo server.
Please be kind to the demo server. I just threw it up to show a few people -- it's not robust at all.
I would love feedback! My e-mail is dwaltrip77@gmail.com.
Note: the interface for editing the "Game UI" is going to be completely redone so that it uses the same type of visual programming code-blocks as found in the "Core Logic" editing interface. Right now the game UI code format is simply javascript that becomes a react.js render function.
Looks very interesting! I don't completely understand how to use it (and I guess not everything works yet?), but the UI looks nice, and it looks like it has some really cool features.
I once had visions of a "code-blocks" interface like you're doing, but you've certainly gotten a lot farther than me on that front. I'd love to find out more about what you're doing and if any of my code can help (will send you an email). I don't actually have time to work on this project seriously, so I'm happy to share whatever experience I've gained so that it doesn't go to waste :).
Unfortunately I have not written any docs or tutorials yet... With the demo, what you are seeing is an editor designed for creating board games of all types. It does involve some programming, although I tried to make that aspect easier with the "code-blocks" visual programming tool (if you click the </> symbol next to any code, that opens the code-blocks editor).
When I launch the full working initial version, I will have a bunch of guides, tutorials, and documentation.
As of right now, I've been focusing only on multiplayer games.
But that is an interesting idea.. it probably wouldn't be super hard to generalize the engine and game specification format to enable single-player games. That's definitely something I will keep in mind for later.
By deck building, you mean that there would be information carried between games, such as one's personal decks that they have already built?
I haven't yet built any features to allow storing player data outside of individual games, but that does seem a very useful thing that fits nicely with the goals of platform. I would have to think about what that might look like. Thanks for asking!
I think he meant Deck building is like magic the gathering. You gain cards each round and use that to your advantage. Also another popular deck building game is dominion online..
This is making me want to try to implement a Hearthstone prototype in it to see if it's feasible. I've been dying to implement a copy-on-write Hearthstone simulator. Although this seems to tie the game logic with the protocol quite tightly, which hopefully is fixable or can be worked around; one of the designs I worked on with my simulator was a pluggable game state protocol to allow separation of a game state server that dispatches the gamestate data from the simulator itself that could then be implemented in any language. Incidentally, this allowed our Hearthstone replayer (written in React: https://github.com/HearthSim/Joust) to connect to "real" games and be a live client, in a way that is eerily similar to this project's showcase.
Just wanted to say thanks for the links to your docs. Games like Michael Brough's (Imbroglio, 868-HACK) and Hoplite have really shifted my videogame-playing interest to turn-based stuff lately, and being a bored dev I'm naturally thinking about what's possible with these frameworks. I'm grateful for devs like you who take the time to write about the stuff you've learned. We're all learning and it's so much more fun to find documentation of how similar stuff has been implemented. Seems like it more seamlessly syncs up with the excitement and motivation when you find something like Boardgame.io. Anyway I really appreciate it!
Thanks for the kind words! I've been passionate about the tech and data science aspect of video games forever and I'm super lucky to have had the opportunity to built a company out of it. HearthSim is a labour of love :)
I do play hearthstone casually, but I really miss the MTG mechanic where the defender decides on which minions damage is distributed by blocking with minions that did not attack the previous turn (or have taunt, so it can attack and block at the same time)
It would be an interesting experiment to replace the hearthstone mechanic with the MTG mechanic to see if it ends up with more interesting tactical situations.
I was so excited to see this. A year ago I tried to distill a bunch of popular board games down to discrete rules that could be dropped into a generalized framework. I wanted game designers to be able to quickly model and prototype games. I also was interested in games where the players get to evolve the rules over time.
However, it ended up being way harder than I expected. In fact, I tabled it indefinitely because I started to believe that it was just intractable. (That is, trying to conceptualize a game into a discrete rule set is often a lot more work than just implementing it in code.)
I'm glad to see others trying to tackle this. But, I hope they try to implement games that are significantly more complex and sophisticated than tic-tac-toe though. The current code is so simplistic that I can't imagine that it will help much. That is, if I used it, I'd still have to custom-code 99% of the logic. But, at least it's a start.
It's tempting to take the "abstract all the things" approach when you take a swing at board games. I started down that path, wanted the ability to implement any variation, and it was much more difficult to contain even if just focusing on the card-based "board game" genre.
I think if one truly took this approach to the logical end, they would end up creating their own specialized board game programming language.
> I think if one truly took this approach to the logical end, they would end up creating their own specialized board game programming language.
That's what I was planning on saying. A set of discrete rules detailed enough to represent most board games would end up looking a lot like an interpreted programming language.
Was totally expecting this to be a plug for firebase (google's realtime database) but it actually comes with a koa server using websockets. Seems to be built with redux under the hood. No fancy conflict resolution and does syncing by serializing entire app state and sending it to each client after each move.
why are you glad, because google bought them? rewind to before the acquisition and there was a lot of positive sentiment towards things built using firebase.
I am intrigued, but is this an improvement over existing game-as-a-state machine languages? I'm thinking of Stanford's Game Definition Language [1] and AI-ai's Modular Game Language [2].
This is excellent. That's the approach we have taken with the Qbix Platform, taking care of all the syncing and realtime updates and offline notifications and user accounts so you can just throw some tools on a page, make a new type of stream or tool (such as Chess/game) and it just works across all devices.
There is a lot that goes into this - for instance offline notifications must be delivered to each user's preferred endpoints (in app notifications if they installed cordova app, sms and email fallbacks if they didn't), you need to fill templates, enforce access control (can I see a guy's last name or a particular game / chat / etc?)
If you look at https://qbix.com/platform/features you will see we went with Streams and Messages rather than syncing data structures. This allows us to reason about explicit "moves in a game" or other changes and whether they are authorized or not per Stream.
In short - I am happy to see others adopting similar goals. Most of what I have seen til now has been syncing static data structures.
At the risk of being another shameless plug this is a subject i've dedicated a good chunk of time to over the last 4 years in a project to simulate mechanics of CCG / TCG card games. The goal is to give the user only what a table and paper game would provide. https://untap.in
It's all in browser, supports up to 6 player multiplayer card games, BYO cards (user uploads card images). YES you can spectate games if you want to have a look.
This has been a growing industry, i have noticed in the last 4 years people like the idea of being in control of their game, playing on the mistakes their opponents make and having the skill to think about the game with out the computer doing the work for you like in most digital card/boardgames from today.
Untap.in is a personal project, has about 100k registered users and 1600 daily active, its a big community. All of this is being serviced by a sole dev (myself) in my free time. The likes of these frameworks should make it extremely easy to get board games through prototype and playable, its a great thing.
Shameless plug, but at my company we had a similar set of requirements (game synced between browsers in real time), but for poker instead of a board game (https://oddslingers.com)! We tried a bunch of different solutions, and ended up writing a pure functional, declarative, animations framework for redux called redux time: https://github.com/Monadical-SAS/redux-time.
It does similar things like server-time-synced animations across multiple browsers, except the state is all managed by the backend.
this is great, the docs/tutorial are pretty clear as well. shameless plug: I made a js library [0] for creating and playing board games a while ago. It allows you to focus on gameplay and logic without worrying about the user interface so much. It allows you to create games like chess [1] and simulations like game of life [2] pretty easily.
I've been playing around with coming up with my own system like this for awhile. If you've saved me a bunch of time, then thank you. I design a lot of simple board games, and I need something to make translating them into video game form quicker and easier.
It looks like it uses sockets under the hood for client server communication -- are there reasons it could not be used in a game with much quicker state updates, like the plane game that was posted here earlier last week (think FPS MMO in the browser)?
I'm pretty sure websocket is fifo with delivery guarantees and as far as I'm aware cannot be used in the same manner as UDP. I haven't played around with WebRTC, but that might be an option.
Airmash uses two websockets and accepts updates from whichever arrives first. It's still fifo, but if one experiences fragmentation the other might be fine.
It's an interesting design and I wonder how well it works.
Wow that multiple TCP connection trick is very interesting. Each additional idle connection would theoretically be capable of firing off a single packet instantly with no congestion control getting in the way. I'm getting flashbacks of services that would allow multiple pending HTTP long-polling requests at once, so the server could push faster than the round trip time.
I wonder what the ideal number of connections would be. It could certainly be 2 of course; I've never thought about this problem before.
Valve mentioned that in practice packets are dropped about 5% of the time, so two connections might theoretically reduce that to 5%^2, or 0.25%. Meaning out of every 1,000 seconds of playtime, only 2 seconds would be disrupted rather than 50s.
It seems unlikely to be as clear-cut as this, since two connections from the same host to the same endpoint will probably use the same route to get there. So why would using two connections avoid retransmission? But it's worth checking whether it works.
It can be worse than that since TCP/IP will do exp backoff depending on your packet loss. Which is awesome for file transfers but pretty awful for real-time data.
There's a great article way back about X-Wing vs Tie Fighter and all the pain they went through with TCP/IP[1].
I don't. The only reason I heard about it was because I happened to be playing when the dev hopped on and started messing with people. Someone asked him about architecture and they said they use two websockets to prevent congestion.
I'm skeptical about the design, but the only way to know whether it's effective is to measure it.
Carmack's great breakthroughs came from trying every logical possibility and then sticking with the ones that worked. There were dozens of dead Quake designs that no one knows about, e.g. beam trees.
One mistake I made in the early days was to go around asking people what to do or how to design something. The truth is, no one really knows the best way to design anything. The only thing you can do is think of possibilities, try them, and ruthlessly measure whether they're effective. Often the most effective designs come from unexpected combinations, which is why this dual websocket idea is worth taking seriously.
One nice property is that if it does work, it only costs 2x bandwidth. Realtime games' bandwidth grows as O(n^2) with the number of players (e.g. 90 players need updates about all 89 other players plus themselves). So doubling the bandwidth isn't a huge cost.
Sometimes, turns are repeated. E.g. if a square is clicked and marked 0, then the next square that is clicked is also marked 0. Only happens sometimes though and I have only produced it on the first turn. I'm not sure what the cause is.
It is much easier as a Google employee to publish open source projects under Google's copyright rather than getting them to grant the copyright to you.
To have Google give you (the Google employee) full copyright of projects you work on while at Google, you need to go through a committee[0] that reviews the project to make sure it doesn't collide with some other project Google already is working on. As this is really hard to do for many projects, it's easier to just let Google keep copyright ownership of it and have it opensource under them.
That guy who blasted Google on HN a while back (not the memo guy) said that since new management has come in over the last few years, 20% time is as good as dead. I couldn't find a link, sorry.
Guessing these were made in an employees 20% time or something similar, they felt it would be useful to publish them but not take flak when it has bugs or they don’t actually support it.
This is really cool. I'm working on a mobile app [1] that lets you play social games with your friends over video chat. We built it in React Native and I was envisioning creating something like this to build our games.
We havn't gotten there but are exploring other services for the backend like Nakama [2] and Colyseus [3]. Right now we are just using Firebase for the multiplayer sync and building raw RN components with no library essentially and that's been working pretty good.
I'm gonna look into this library some more, looks promising :)
Very cool! I have a site been building for earlier stages of prototyping: http://www.iterary.com/ with the idea you might use it during excel designs, etc. Still working on better integrations with excel/google sheets.
I'm not a gamer or a game developer, but this is absolutely brilliant. Very clean API and I'm sure a lot to be done with this features-wise. Best of luck!
I'd love to explore how this framework can be applied to Nakama (https://github.com/heroiclabs/nakama). I'll see if I can find some time to experiment with it over Christmas.
This looks pretty interesting. Could Nakama be used to build a federated, decentralized application (let's say, game world) where each user self-hosts on his own Docker instance?
The way Nakama is designed right now would not lend itself well to a decentralized game world right now. There's another project of ours which will address what you have in mind but not until the new year.
are there any provisions for multiplayer games that have player-specific knowledge? like cards or tiles that other players can't see? right now all game state is sent over the wire every time... would you just only send pertinent data to each player on their turn?
I became curious about this, there is of course game semantics but that's not what you're looking for. I found a couple of interesting references about using categories to study game theory which I'm going to add to my reading list, Game Theory from the Category Theory Point of View [0] and Towards Compositional Game Theory [1].
I'd love to see the client-side state extended so that this could be a framework for decentralized turn-based games, without using a centralized server.
One concrete cause of
centralization in today's Internet is a
difference in programming costs between
a closed centralized solution and an
open decentralized one. Let's say we're
writing a tic-tac-toe app. In the
centralized design, the game board is one
data structure. Your score and mine are
two variables. You'll be done in a couple
of hours.
As an open decentralized
solution, you're building a federated
system. You need a standard protocol for
communicating tic-tac-toe moves. Maybe
you should work through the IETF to
write an RFC for OTTTP: the Open Tic-Tac-Toe
Protocol. You might be done in 2018. When
solving a problem the wrong way takes
two hours, and solving it the right way
takes two years, it's going to get solved
the wrong way.
I've been working on a similar project for over a year now. It's essentially this exact concept turned into an entire platform for designing/creating board games and then publishing the game so others can play it directly on the platform. Think of heroku or squarespace for board games.
I have a very rough, working prototype of the editor and game engine. There is a ton left to do (I could write pages about what I'd like to implement/improve). But, I'm at least finally getting somewhere with it.
At the risk of utterly destroying my server... for anyone who is interested, I have a demo site for the game editor prototype. A game can be test played from the editor by clicking "game play tester" in the upper-left menu. There are no docs or anything. But there are several games already implemented on the demo server.
Please be kind to the demo server. I just threw it up to show a few people -- it's not robust at all.I would love feedback! My e-mail is dwaltrip77@gmail.com.
Note: the interface for editing the "Game UI" is going to be completely redone so that it uses the same type of visual programming code-blocks as found in the "Core Logic" editing interface. Right now the game UI code format is simply javascript that becomes a react.js render function.