3 ms·

https://easel.games https://easel.games A programming language which lets you code multiplayer games like singleplayer games. Every program written in Easel is

https://easel.games https://easel.games A programming language which lets you code multiplayer games like singleplayer games. Every program written in Easel is guaranteed deterministic and snapshottable, which is how it can automatically make your game multiplayer automatically using rollback netcode. My hope is that teenagers who makes games in Scratch might like to make games in Easel because it means they can make games they can play with their friends, without having to deploy a server or learn anything about networking on synchronization. People can literally make a multiplayer game on their first day of coding. Currently been working on adding tilemaps.

Madmallard 19d ago
What I don't understand about your idea is that netcode as far as I understand is way more complex than you make it seem. The netcode for something like a MOBA or MMORPG is drastically different than the netcode for a much simpler turn-based game. They have elaborate synchronization mechanisms to make the illusion not break-down in various ways due to latency. And then even for simple turn-based games, there has to be elaborate fully-decided like state diagrams for all the various types of disconnect and latency states so that gameplay doesn't desynch or hitch in awkward ways.
- bashfighter 19d ago
  [flagged]
- BSTRhino 19d ago
  Yes, I spent quite a few years building and iterating on some quite elaborate mechanisms to handle latency too: https://easel.games/docs/learn/multiplayer/rollback-netcode https://easel.games/docs/learn/multiplayer/rollback-netcode - it’s taken a lot of continual playtesting to discover and address many issues. The multiplayer architecture is rollback netcode, which I think is great because it performs client-side prediction by running your full game simulation step forward on the full game state and not some subset or stripped-down version of the simulation or state. It’s the most accurate client-side prediction model you can have. Then it achieves eventual state synchronisation by rolling back and rerunning your code when there is a prediction error. It performs automatic rubberbanding to smooth over the error corrections. All the bodies get rubberbanded, so as long as you attach your sprites to bodies (which is what you would normally do), the rubberbanding is automatic. Rollback netcode is underutilised because it’s difficult to implement on other game engines. It requires your entire codebase and all your dependencies to be deterministic and snapshotable, and so if you’re using another engine like Unity or Godot, it won’t meet these requirements because it wasn’t designed for this. Products like Photon Quantum for Unity get around this by reimplementing all the systems like physics, RNGs and even just ArrayLists in their own deterministic manner. But you have to follow all these rules about writing your code in a multiplayer safe way and there are all these traps to avoid. Putting the rollback netcode into the programming language means it always works 100% of the time and you can’t make a mistake, which means even a beginner programmer on their first day can make a multiplayer game. That was my ultimate goal and I think it is true that if someone who is an experienced programmer wants to hand-code a specialised rollback netcode implementation for their game then they might be able to do a better job on their game. But the defaults are really good when the rollback netcode is in the language itself and I’ve had teenagers make multiplayer games that they play with their whole class and they’ve all had a lot of fun, and that’s the main thing.
  - bel8 18d ago
    this is great! congratulations. one question I have is: since even rng has to be locally predictable won't things like lootboxes be hackable by reverse-engineering local executable? maybe for these cases the game could implement an API call to the server to fetch lootbox result?
    - BSTRhino 18d ago
      Yes, that's true, we could add an API to let the server generate the random number so it is unpredictable, I can consider that for a future update :)

Madmallard 19d ago

What I don't understand about your idea is that netcode as far as I understand is way more complex than you make it seem. The netcode for something like a MOBA or MMORPG is drastically different than the netcode for a much simpler turn-based game. They have elaborate synchronization mechanisms to make the illusion not break-down in various ways due to latency. And then even for simple turn-based games, there has to be elaborate fully-decided like state diagrams for all the various types of disconnect and latency states so that gameplay doesn't desynch or hitch in awkward ways.

bashfighter 19d ago
[flagged]
BSTRhino 19d ago
Yes, I spent quite a few years building and iterating on some quite elaborate mechanisms to handle latency too: https://easel.games/docs/learn/multiplayer/rollback-netcode https://easel.games/docs/learn/multiplayer/rollback-netcode - it’s taken a lot of continual playtesting to discover and address many issues. The multiplayer architecture is rollback netcode, which I think is great because it performs client-side prediction by running your full game simulation step forward on the full game state and not some subset or stripped-down version of the simulation or state. It’s the most accurate client-side prediction model you can have. Then it achieves eventual state synchronisation by rolling back and rerunning your code when there is a prediction error. It performs automatic rubberbanding to smooth over the error corrections. All the bodies get rubberbanded, so as long as you attach your sprites to bodies (which is what you would normally do), the rubberbanding is automatic. Rollback netcode is underutilised because it’s difficult to implement on other game engines. It requires your entire codebase and all your dependencies to be deterministic and snapshotable, and so if you’re using another engine like Unity or Godot, it won’t meet these requirements because it wasn’t designed for this. Products like Photon Quantum for Unity get around this by reimplementing all the systems like physics, RNGs and even just ArrayLists in their own deterministic manner. But you have to follow all these rules about writing your code in a multiplayer safe way and there are all these traps to avoid. Putting the rollback netcode into the programming language means it always works 100% of the time and you can’t make a mistake, which means even a beginner programmer on their first day can make a multiplayer game. That was my ultimate goal and I think it is true that if someone who is an experienced programmer wants to hand-code a specialised rollback netcode implementation for their game then they might be able to do a better job on their game. But the defaults are really good when the rollback netcode is in the language itself and I’ve had teenagers make multiplayer games that they play with their whole class and they’ve all had a lot of fun, and that’s the main thing.
- bel8 18d ago
  this is great! congratulations. one question I have is: since even rng has to be locally predictable won't things like lootboxes be hackable by reverse-engineering local executable? maybe for these cases the game could implement an API call to the server to fetch lootbox result?
  - BSTRhino 18d ago
    Yes, that's true, we could add an API to let the server generate the random number so it is unpredictable, I can consider that for a future update :)