3 ms·

I'm no fan of React, and I'm building a new back-end and front-end that is probably heretical to... well.. everything. What I have found is that if you have re

I'm no fan of React, and I'm building a new back-end and front-end that is probably heretical to... well.. everything. What I have found is that if you have reactivity from your back-end, then front-end reactivity is... easy. My focus is on board games, but the idea generalized pretty well. As an example, my dumb chat room: https://github.com/mathgladiator/adama-lang/blob/master/demo/html/chat.html#L90 https://github.com/mathgladiator/adama-lang/blob/master/demo... I really need to focus on this, but I believe what we are seeing is an interesting adversarial game between client and server. For instance, if you build your server with a strong API, then clients are going to build tremendous complexity. My personal bet is that we need a streaming protocol such that applications look more like X11.

deleted 5y ago
[deleted]
tekstar 5y ago
Looks like you're trying to reinvent some wheels there. No harm in doing so but just so you know, React (or my preference, a tinier version called Preact) would let you update new chat contents without blowing away all the other InnerHTML content. The way you're doing it now will result in a flicker, and mess with things like highlighted text will unhighlighted when replaced. And that's just with the basic dumping of the chat text into a DOM innerHTML. I'm pretty sure what you're doing there would also be susceptible to XSS without additional filtering.
- mathgladiator 5y ago
  Wait til I tell you about the custom UI system I'm building with canvas. http://www.adama-lang.org/blog/ui-flow-with-adama http://www.adama-lang.org/blog/ui-flow-with-adama
  - tekstar 5y ago
    Nice blog post! I read the whole thing. I'm working on something with multiplayer using an unbounded queue of command events, so I learnt a few things about that situation. If you have any posts that elaborate on the typical infrastructure events from running that in production, I'd love to read it as you obviously put a lot of effort into your blog posts.
    - mathgladiator 5y ago
      This is entirely new infrastructure, and I don't have data yet since this is a side project. I am biasing towards relying on a connected socket for all state management which is fair for board games (and, I do believe more generally given how connected the world is becoming). There are tremendous problems with using WebSockets in production, but they can be overcome with a decent protocol design as you have a number of failure modes to contend with. I'm in the process of publishing a paper for a conference that will share some of the architecture of my production learnings.
      - tekstar 5y ago
        sent you an email, I'd be interested in reading that paper once it's available! Cheers
sunsetSamurai 5y ago
Hi, what type of board games are you working? I wanna create a makruk game server and don't even know where to start
- mathgladiator 5y ago
  A number of games, but my favorite that I have a working back-end for is Battlestar Galactica ( https://boardgamegeek.com/boardgame/37111/battlestar-galactica-board-game https://boardgamegeek.com/boardgame/37111/battlestar-galacti... ), and it is complicated. I'm currently designing my own deck builder similar to Dominion. My advice would be to use first make a game without the network, and just have hotseat. Once you have a hotseat game, then the question is how to pull the state out of the client and then be shared between two computers. The complications arise during the failure modes of the network, and how transactions play between multiple play. Chess is a fairly simple game to get started with (I'm not sure how makruk compares), but modern eurogames tend have a lot of rules that can be changed by pieces or cards. These get... very complicated.
tshaddox 5y ago
There is an SPA pattern (perhaps sometimes called "offline-first") where your client application code does all reads and writes data against a local database, then another bit of client code is responsible for syncing this local database with the server's database. The local database could be IndexedDB, or localStorage, or even some bespoke DBMS. In some sense the client app would be running on one node in a replica set. Indeed, one could go even further and try streaming the UI state itself from the server, so that the client is something like an X11 client. The obvious downsides of this are 1) the server needs to store the session state and 2) it's fairly intolerant of connection interruptions, but for something like an interactive game these are probably not deal-breakers.

deleted 5y ago

[deleted]

tekstar 5y ago

Looks like you're trying to reinvent some wheels there. No harm in doing so but just so you know, React (or my preference, a tinier version called Preact) would let you update new chat contents without blowing away all the other InnerHTML content. The way you're doing it now will result in a flicker, and mess with things like highlighted text will unhighlighted when replaced. And that's just with the basic dumping of the chat text into a DOM innerHTML. I'm pretty sure what you're doing there would also be susceptible to XSS without additional filtering.

mathgladiator 5y ago
Wait til I tell you about the custom UI system I'm building with canvas. http://www.adama-lang.org/blog/ui-flow-with-adama http://www.adama-lang.org/blog/ui-flow-with-adama
- tekstar 5y ago
  Nice blog post! I read the whole thing. I'm working on something with multiplayer using an unbounded queue of command events, so I learnt a few things about that situation. If you have any posts that elaborate on the typical infrastructure events from running that in production, I'd love to read it as you obviously put a lot of effort into your blog posts.
  - mathgladiator 5y ago
    This is entirely new infrastructure, and I don't have data yet since this is a side project. I am biasing towards relying on a connected socket for all state management which is fair for board games (and, I do believe more generally given how connected the world is becoming). There are tremendous problems with using WebSockets in production, but they can be overcome with a decent protocol design as you have a number of failure modes to contend with. I'm in the process of publishing a paper for a conference that will share some of the architecture of my production learnings.
    - tekstar 5y ago
      sent you an email, I'd be interested in reading that paper once it's available! Cheers

sunsetSamurai 5y ago

Hi, what type of board games are you working? I wanna create a makruk game server and don't even know where to start

mathgladiator 5y ago
A number of games, but my favorite that I have a working back-end for is Battlestar Galactica ( https://boardgamegeek.com/boardgame/37111/battlestar-galactica-board-game https://boardgamegeek.com/boardgame/37111/battlestar-galacti... ), and it is complicated. I'm currently designing my own deck builder similar to Dominion. My advice would be to use first make a game without the network, and just have hotseat. Once you have a hotseat game, then the question is how to pull the state out of the client and then be shared between two computers. The complications arise during the failure modes of the network, and how transactions play between multiple play. Chess is a fairly simple game to get started with (I'm not sure how makruk compares), but modern eurogames tend have a lot of rules that can be changed by pieces or cards. These get... very complicated.

tshaddox 5y ago

There is an SPA pattern (perhaps sometimes called "offline-first") where your client application code does all reads and writes data against a local database, then another bit of client code is responsible for syncing this local database with the server's database. The local database could be IndexedDB, or localStorage, or even some bespoke DBMS. In some sense the client app would be running on one node in a replica set. Indeed, one could go even further and try streaming the UI state itself from the server, so that the client is something like an X11 client. The obvious downsides of this are 1) the server needs to store the session state and 2) it's fairly intolerant of connection interruptions, but for something like an interactive game these are probably not deal-breakers.