BSTRhino

I’ve been making a programming language with automatic multiplayer for the past four years. This month I added compile time data import to the programming language. I thought it was a feature with some interesting trade offs and thought you might be interested.

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.

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.

A programming language that makes your game multiplayer automatically! It integrates rollback netcode into the programming language itself, guaranteeing that whatever you code is deterministic and can be snapshotted and rolled back. Then it integrates the networking and server automatically so you can just code your game like a singleplayer game and it'll be multiplayer automatically! I've been working on this for four years now.

A game programming language that makes your game multiplayer automatically. This month I’ve been developing the tutorials so it’s easier to learn.

I'm the creator of Easel, a game programming language with automatic multiplayer. I've been trying to figure out what to do with the feedback that people have been finding it difficult, and this has been my analysis and my response to the situation. Maybe some of you might find this interesting?

We could have potentially used Fusion for this had it existed, but I don't know if we would. We didn't have to support 12 different languages, only 2.

Still working on my programming language which makes your game multiplayer automatically. Currently working on improving the tutorials. When writing the tutorials I followed the "focus on the action" principle from Diataxis (https://diataxis.fr/tutorials/) perhaps too much. Easel is a unique language in a number of ways and it really does actually have to be taught, so I'm trying to make it do a better job of that.

A reactive programming language for games! Properties signal when they change and you can register blocks that tell the engine how to use that property, not just once but every time it changes. It’s a more declarative way of making games which I think is lots more productive.

I’ve been working on this for four years, it’s been a big project!

1. The people who really love Easel right now are teenagers who have mastered Scratch and are looking for more. Expert game devs who come from Unity or other programming languages find it’s missing some capability they really want and tend to get frustrated right now. I’ve been solving so many issues every month, like we got multiple cameras the other month for example, but there’s so much left. If I made a standalone version now, no one would buy it because it doesn’t yet do what they need, and if you did I would probably be refunding you quite soon. We might need another 6-12 months to be ready for experts. Sign up to the mailing list and we can keep you updated.

2. I would be willing to go as far as source available to licensees but there’s are some practical issues with fully open source. First, it makes it easier to cheat at all Easel games. Easel is client authoritative for certain things. Why? So I can keep the server costs within what I can actually afford because I am one person. Maybe once I can afford 30 servers we can make it all server authoritative and I won’t worry about this anymore. Second, I expect a net decrease in my productivity if I have to argue and defend my code, and become the BDFL to the open internet all the time in an open source environment. I’ve been really really productive just working by myself.

I ask because yes, I have put in a great deal of time and effort into the programming language design, and to me, I think that is the greater achievement, more than the automatic multiplayer. But the benefits of automatic multiplayer are easy for the general population to understand and the improvements programming language design is hard to convey and so people don’t normally get it. The fact that you can see what I’ve been trying to do so quickly shows you must be coming from a place which has developed that discernment for you.

While there are many inspirations, like I love coding using React for example, my primary inspiration is the last game I made, I released all the modding tools along with them and lots of non-coders loved it. The modding was JSON, which might sound primitive, but it was actually a hierarchical declarative domain specific language and it seemed to really work for people intuitively.

Easel was born from me spending 2 years trying to make an imperative programming language in a similar shape as that declarative one. I wanted it to be just as easy, but infinitely more powerful. It took a lot of iteration to merge the declarative and imperative styles into one language. There is so much to it - lexical lifetimes and ownership, reactivity like you noticed, but also weaving in concurrency and asynchronous programming seamlessly took time as well.

I really wish this is more the part of Easel that would stand out and be talked about more because I think it’s the coolest part.