Comment by mathgladiator | Hacker News Reader

Comment by mathgladiator | Hacker News Reader

Parent Full thread

I'm working on the complex UIs now, and it is a challenge. Fortunately, I can focus on gaming designs which is less complicated.

I think the key thing here is figuring out how the UI can be made mostly declarative and a stateless function of the state. I'm drawing some inspiration from

https://flutter.dev/docs/development/data-and-backend/state-...

and the challenge is the polish to make products great. My strategy is that I'm going to make a UI editor so I can make faster progress on designing the board game UI and then build a minimal set of controls to do data binding. The key is to get into the fight about what is the polish needed, and what reasonable escape hatches are needed.

> I wonder if there's some aspect of board games that pushes one towards that line of thinking.

There is, they are exceptionally complicated!!! SO COMPLICATED! The key is the implicit state machine between all the players, and you just can't quickly model it with traditional tools and databases. All it takes is a single card or game piece (which changes rules) to invalidate EVERYTHING. Games are exceptionally messy!

It seems like you could get most, if not all the way, there with an "isomorphic" Redux store on client and server side, along with a custom Redux middleware (very easy to write and well-documented) that reads actions from and writes actions to whatever connection you have set up. That way, your initial "giant json object" on the client is just the current store state and your "streaming updates" are just redux action objects going over the wire. You'd probably want some extra metadata attached to the objects (e.g., a uuid field and an ack field containing the last action's uuid) and youd have to deal with all of the usual synchronization problems in your middleware, but you'd have a solid starting point, at least.

Yep. As an example, see this pair of posts from 2017 on a distributed VR app with Redux actions over the network:

http://jimpurbrick.com/2017/01/04/vr-redux/

http://jimpurbrick.com/2017/07/04/react-vr-redux-revisited/

If your game has limited number (say, < 10) participants per game board, then concurrent updates to shared state etc can be solved with a traditional game state hosting server model. But if that number is higher say 100+ then you need a sharded distributed setup. That's when things get really tricky if you don't keep things simple.

So, like all engineers, I imagine that my products that I ship will reach massive levels of scale. Such massive level of scale that I need to use elastic compute, so I should expect processes to come and go.

Thus, my processes clearly has to sustain 100k+ connections. And, at a moment's notice, I should expect the process to go "poof". Maybe someone is going to do a kernel upgrade or someone decided to unplug a machine, I don't know!

Having operated with the above assumptions, I found it hard to be wise to avoid that and then invented a programming language that would operate in a modern cloud environment.

I need better hobbies, or not... who knows.

the real world is messy, games are a way of identifying the messiness (and then provoking one user to be upset at how the developers chose to model the messy world)

Reply on news.ycombinator.com