That’s really cool =)… Like the idea of extending DF’s adventure mode like that and offering optional sharing… Yea, I think perf will be an interesting thing to deal with, it’s not too bad, but I’m trying not to write myself into a hole by keeping an eye on it. The tricky part is not yet being very sure how good the strategies I’m working on are. There’s three things I’ve got to worry about: 1) time to run a world tick 2) memory consumption of running the sim 3) size of update on world tick as all the players need to get the update… At the moment I’m using websockets, not certain if that’s going to cause a big bottleneck either, it’s a really nice way to send an update, but can I update 100 people with a big update on the world tick is definitely a concern. If anyone knows any neat tricks that would be cool =)… There could be some nice caching strategy that I’m not aware of…

For example is it a good idea instead to have the websocket sending out a heartbeat + secret player info and then have the client hit a cached endpoint for general game state.

for websockets @U0524B4UW is your guy

how bit are your state updates going to be @folcon?

sounds like something which will need benchmarking... but if latency isn't a concern then a cached state endpoint is probably a good solution which scales easily

Hmm, well it’s tricky to answer, I don’t yet know how bad this can get. Latency is a concern, but at the moment game updates only need to come down the wire every 5 seconds which is a lot of time, I expect this might eventually go down to around 2 or 1 second with 0.5 being the lowest. So that gives a lot of wiggle room. (ie split the update into public and private, send the private over websocket and send the public to a easily cacheable resource, not certain what, cloudfront? or maybe a thin nginx instance serving the update as files from it’s local system) On the other hand payload sizes (pre-split) can vary a lot and this is hard to benchmark because adding some new functionality could balloon the payload size while it’s being iterated on and then as it becomes mature it could slowly shrink down. For example, my initial payloads were gigantic (1 to 2 mb), so I reduced that by sending deltas and using transit, I’ve had to subsequently roll back the delta’s for now, but I’m wondering if using something like a datascript db will make this a lot better. (my delta’s are datascript transaction updates) Currently they grow from around 1kb slowly upwards… So yes, this splitting caching thing could be a terrible idea =)… But if it’s going to be useful it has to support an actively being developed application…

if you use your API as a cloudfront origin and give every update a distinct url then you can keep the logic simple (i.e. serialized within your process/api) and you only need to send the update url down the websocket... in local dev your client can hit your local api process directly, in prod you arrange for the client to hit the cloudfront cache which passes through to your api when necessary

Ok, that’s a really nice approach that I can probably put together relatively quickly. Send a private update + a public token, you can call a get api endpoint to get the game-state from the token, which could be as simple as a timestamp when the last update occurred =)…