HN Explorer

Show HN: Server-rendered multiplayer games with Lua (no client code) (cleoselene.com)

85 points by brunovcosta ↗ HN
Hey folks — here’s a small experiment I hacked together over the weekend:

https://cleoselene.com/

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/

23 comments

[ 2.6 ms ] story [ 42.0 ms ] thread
[deleted]
(comment deleted)
ghxst
IMO eliminating as much client side authority as possible is a very good foundation for MMOs where the latency is acceptable or factored into all aspects of the game (looking at old school runescape as an example). Very cool project!
duduzeta
Cool!! I'm trying to test here, but other ships keep attacking me and I don't know how to shoot :s
cmrdporcupine
"We stream drawing primitives instead of heavy pixels or complex state objects."

This is cool ... but I suspect just pushing video frames like Stadia etc did is just as efficient these days and a lot less complicated to implement and no special client really needed. Decent compression, and hardware decode on almost every machine, hardware encode possible on the server side, and excellent browser support.

fionic
Cool! Besides the productizing or making a framework, I’m trying to understand if this is different than the elementary idea (which probably every game dev who worked on game networking has tinkered with) of sending inputs to the server and then sending player positions back to all the clients…? I think even smaller footprint would be position: two or three floats x,y(,z) instead of shapes too? Anyway this is always fine for very low latency environments where client side prediction, lag comp etc would not be required. Thanks for sharing, I might give it a try! sorry if I’m missing something.
kibbi
Interesting approach! I've thought about a similar method after reading about the PLATO platform.

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.)

allthatineed
BYOND/Space Station 13 is built upon this model.

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.)

Thaxll
"Impossible to Cheat"

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.

6r17
Cheating with AI will be possible even with server side rendering ; nvidia has released models able to learn to play - it's going to be very difficult to detect whether it's an AI or a human ; very impressive however
tnelsond4
Since you're doing this is rust, try experimenting to see what would happen if you did zstd compression using a dictionary on the data you're sending back and forth, it might give you a performance benefit.
aetherspawn
The latency is a little intense from Australia … but surprisingly not as bad as I thought it would be.

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…)

ingen0s
Might be the greatest thing I have seen made in like 10 years
emmelaich
Reminds me of the cave X11 games. For game play I'd suggest slowing it way down.
Matheus28
Client-server multiplayer games are already kind of a very specialized type of video playback if you squint a bit (you're transmitting entities rather than pixels).

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.

2001zhaozhao
> - Streaming game primitives instead of pixels, which should be much lighter - Server-side rendering makes cheating basically impossible

This doesn't work in 3D. Unless you have the server do the work of the GPU and compute occlusion, you'll end up sending data to the client that they shouldn't be able to have (e.g. location of players and other objects behind walls)

chasebrignac
Sick! And the game is fun too! I’m sending to my brother who is a junior game dev.