Hey folks — here’s a small experiment I hacked together over the weekend:
In short, it’s a way to build multiplayer games with no client-side game logic. Everything is rendered on the server, and the game itself is written as simple Lua scripts.
I built this to explore a few gamedev ideas I’ve been thinking about while working on Abstra: - Writing multiplayer games as if they were single-player (no client/server complexity) - Streaming game primitives instead of pixels, which should be much lighter - Server-side rendering makes cheating basically impossible - Game secrets never leave the server
This isn’t meant to be a commercial project — it’s just for fun and experimentation for now.
If you want to try it out, grab a few friends and play here: https://cleoselene.com/astro-maze/
When playing astro‑maze, the delay is noticeable, and in a 2D action game such delays are especially apparent. Games that don’t rely on tight real‑time input might perform better. (I'm connecting from Europe, though.)
If you add support for drawing from images (such as spritesheets or tilesheets) in the future, and the client stores those images and sounds locally, the entire screen could be drawn from these assets, so no pixel data would need to be transferred, only commands like "draw tile 56 at position (x, y)."
(By the way, opening abstra.io in a German-language browser leads to https://www.abstra.io/deundefined which shows a 404 error.)
I think this is inevitable unless I add some optimism/interpolation in the client
Also, thanks for the feedback! I will fix the Abstra landing page
try https://www.abstra.io/en instead
My approach lives in some place between video streaming and data streaming in terms of performance
It's not intended to be faster than a proper client that brings a lot of logic and information that diminish the amount of information required to be transfered
My proof of concept is more about: Can my dev exp be much better without relying on the video streaming approach? (which is havier)
This method of multiplayer you propose is inferior in basically every way: you can't do client-side prediction to make inputs feel smoother, and non-trivial scenes will surely take up more bandwidth than just transmitting entity deltas.
Let me tell you that there is cheating in cloud rendering solution ( Stadia, AWS Luna ect ... )
So 100% there is cheating in your solution.
It's trivial to read the screen.
Especially with today's computer vision
The cheating I'm more protected (just as stadia, etc..) is regarded to client/code exploitation
which we don't have to worry about in this approach
Sprite sheets are png with ztxt blocks with meta/frame info and a list of drawing operations to be done to construct vsprites based on any runtime server side operations done on the sprites.
There is limited client coding via popup Web view windows and a few js apis back to the client but nothing you can build too much off of.
(SS14 brings this model to an open source c# framework called The Robust Engine but has some limitations related to maintainer power tripping over who should be allowed to use their open source project.)
Thank you for the reference!
It was playable.
I wonder if you can use speculative execution to play the game a few frames ahead and then the client picks what to display based on user input, or something like that.
Each frame is 16ms, so you’d have to work ahead 6 frames to conquer the nominal latency of around 100ms, which may actually be 200ms round trip.
(In that case, something like Haskell would be a good candidate to build a DSL to build the decision tree to send to the JS client…)
https://bymuno.com/post/rollback
If you were able to make it, it would be kind of a Hail Mary moment for making easy server games without the latency.
https://github.com/skorotkiewicz/proximity-explorer
I will definitively follow that!