Ease comes after

While some people have been thriving, not everyone has been finding Easel easy to learn. Here is why that is and what we are doing about it.

Also keep reading to find out what's new in Easel in June 2026!

info

Easel is a programming language that makes your game multiplayer automatically! Intrigued? Visit our home page to learn more.

Simple vs Easy

One of the most famous talks in computer science is Simple Made Easy by Rich Hickey, the creator of the programming language Clojure. In it, he explains that, "simple" and "easy" are not the same thing. He refers to the word origins of the two words:

• "Simple" comes from the word "simplex" meaning "one fold". As opposed to "complex" which means "many folds".
• "Easy" comes from the word "adjacens" meaning "lie near".

When something is "easy", it means that it is lies near to something you already know. It is familiar. When something is "simple", it has nothing to do with what you already know or don't know. Your code can be a tangled mess like the those wired earbuds in your pocket, or it can be ordered concentric hexagons like web of a spider. In either case, simple or complex is a property of the thing itself, not of your knowledge of it.

We want too much for things to be easy when we should want them to be simple, because for things to be easy they have to be familiar, and that means they cannot be much better than what we have now.

Easel is different

Some people are trying Easel and finding it difficult. Why is that?

It's because it's different, which makes it unfamiliar.

But Easel is different for good reason. We are trying to innovate on the way games are made. This is not always immediately apparent when you start using Easel - it is difficult to see the forest from the trees. However, every now and again someone will come along and leave us a comment like this one:

I’ve been making notes for a few years now about all the best patterns and principles for designing complex systems and your language + engine more or less hits all the right notes. Declarative state and reactivity, lexical lifetimes and ownership, etc. Really curious how you set it all up and what prior art was your primary inspiration.

This person gets it! In our experience, Easel's differences let you express more sophisticated ideas with less code. Moving Easel closer to what people are familiar with would lose what makes Easel powerful. Unfortunately, this means people have to learn new ways of thinking when coming to Easel, and that is not easy.

The ease in Easel comes after you have learned its ways, not before. But once you get there, you'll be delighted. The other day we had the nicest quote from one of our Easel users, who said:

I keep being pleasantly surprised by how composable everything is, and how possible/easy it is to abstract things out

This is what we want for everyone who uses Easel - to reach the moment where you realize what it is all for. What can we do to get more people to this point faster?

Can we make Easel easier?

Our belief is that Easel cannot be made easier without it becoming less simple. This is almost a self-fulfilling prophecy - if there were a way to make Easel easier without losing its simplicity, we would have done it already.

As an example of this, let's look at what a standard entity looks like in Easel:

pub fn hero.Hero([owner]) {
    use body=this
    let radius=1
    Body(pos=@(0, 0))
    ImageSprite(@hero.svg)
    PolygonCollider(shape=Circle(radius=), category=Category:Default)
}

This is 7 lines of code! Maybe you could inline the let radius and make it 6 lines. So 6-7 lines! 6-7! That's at least 6-7 things a beginner must learn. They just want to do 1 thing, why do they need to learn 6-7 things? Can we reduce this number? Can we remove some of these lines and make it easier for beginners to get started?

Let's take the line use body=this. Is it really necessary?

info

If you are not familiar, use body=this says that this Hero has their own body.

Sometimes an entity does not have its own body. For example, if our Hero picks up a Shield, the Shield entity would be attached to the Hero's body, and so it would say use body=hero instead of use body=this because the Shield has no body of its own.

When you're making a basic game, an entity almost always has their own body. This can make use body=this seem like nothing but an unnecessary stumbling block for beginners. Why do I have to type this? What is this for? What is use? What is a body? What is this? Why? Why? Whyyyyyyyy?

We are literally making the programming language, we have infinite power to make it do whatever we want, so why not remove one extra stumbling block for beginners? We could make the language assume use body=this until told otherwise, for example. Advanced programmers would have to undo it when they wanted to do something more advanced, but just like they tell autocorrect "no, thanks for the help but this time I didn't want to type 'duck'", they could learn to do that, right?

We don't do this because, once you start making sophisticated games, it is very common for one Easel body to be made of many entities. Unlike other game engines, in Easel an entity is not an object, it is a lifespan. Every little transient thing a hero does might be a short-lived entity: jumping, charging up their fireball, patting their dog etc. Making use body=this implicit makes life easier for beginners, but harder for advanced programmers. It lowers the ceiling of what Easel is capable of, and we don't want to do that.

Another way to look at it is, to make use body=this implicit, we would need to add an exception to the rule where body does not work like everything else. This makes Easel less consistent and less simple. If we have to choose between simple and easy, we choose simple.

Teaching idiomatic Easel

If we cannot move the mountain Easel closer to the people, our only choice is to help bring people closer to Easel. To this end, we have created a completely new set of tutorials that have a much greater focus on teaching idiomatic Easel.

Idiomatic means that you are not just learning about how Easel works, you're also learning how you should work. Particularly, you are learning the patterns that ye olde Easel programmers of yore discovered in the land before time, so you can avoid retreading the same mistakes they made and get straight to the good harvest.

For example, every beginner simply has to learn the 6-7 lines for a standard entity by rote. Like learning the times tables or "mitochondria is the powerhouse of the cell". Later on, when the young Padawan becomes the Master, they will know when the rules can be bent or broken. You have the high ground? Who invented that rule anyway? The Jedi Council? Pfft. I know better.

There are now three new tutorials that teach idiomatic Easel, replacing the previous two.

A new Quickstart

The new Quickstart tutorial can be completed in around 15 minutes, whereas the previous tutorial was 1-2 hours. Some people come to Easel with an idea already in mind for a game they want to make, and they don't want a gentle meander through the forests of the language, they want a crash course uploaded directly into their neural cavities. When you are in a hurry, sometimes the mere length of the initial tutorial makes Easel seem more difficult than it really is.

While the new quickstart tutorial is short, learners still see maybe 70% of the most important features of Easel in those 15 minutes, even if they might not absorb all of it at the time.

In-depth tutorials

After the quickstart, there is a new pair of tutorials designed to be completed in succession.

• The Astroblast tutorial takes 1-2 hours and makes a complete multiplayer game. Unlike before, it doesn't just show you the steps to make the game, it includes lessons on common tasks (like handling events), gives names to common patterns (like systems), and refers directly to Easel's fundamental programming paradigms (like reactive programming) by name. It actively tries to teach you idiomatic Easel.

• The Mechanics tutorial takes 4-6 hours and makes Astroblast a lot more sophisticated, but only by adding very common game mechanics that you might use yourself, like rounds, abilities, upgrades, powerups and leaderboards. Previously, without being shown that Easel was capable of these things, beginners might not have even realized they were even possible. This greatly lifts the ceiling of what beginners can achieve with Easel.

Additionally, the Astroblast tutorial now uses the high-quality free assets from Kenney, demonstrating that you can make a professional-looking game with Easel from the very beginning. We highly recommend more people check out Kenney's assets - it is an excellent resource for all game developers!

Thinking in Easel

For programmers who are already familiar with Easel, we have created a new section of the documentation called Thinking in Easel. This is designed to be a collection of the idiomatic patterns used to solve common problems that Easel programmers face. The tutorials also continuously link back to this new section for those precocious beginners with an appetite to know more.

Compiling this section required naming the idioms. For example, systems is the name we are giving to the pattern where functions add ongoing behavior to an entity. It didn't have a name before, which made it difficult to teach.

Try it!

If you are not too busy scrolling FaceTwitter right now, consider giving the new tutorials a test drive, starting with the Quickstart!

June 2026 updates

This is the more boring administrative section of the blog post where we keep you up-to-date with the latest changes to Easel.

Breaking changes

• No more implicit use for function parameters. Previously it was as if every function parameter was declared with use implicitly, and this could cause unexpected bugs. This has been removed in edition=16. See No Implicit use for more information.

• Duplicate function parameters is now an error in edition=17. This could waste your time as a developer as you might not realize you even have a duplicate parameter, See No Duplicate Function Parameters for more information.

All new Easel projects will begin on edition=17 with both these changes. All previous editions of Easel are always supported forever, so don't feel the need to upgrade your existing projects.

If you wrote your project entirely yourself (and did not remix it off, say Acolyte Fight which uses a lot of implicit use), chances are you can just update to edition=17 and your project will work fine without any changes.

Parties

Previously, the party system would create unique copy your game for just the invited players, meaning all persistent data (preferences and accumulators) would not transfer over.

Now, parties are more like a matchmaking criteria on the game, meaning any persistent data they make in the party persists into the real game. This means they can rank up leaderboards with their friends, and unlock abilities together, and it won't all be lost when they leave the party.

We imagine this would be great if you are playing a game like Overcooked on Easel, where you only want to play with your invited friends, but still want to see how you compare with the global rankings of each level.

If you die in the matrix, do you die in real life? Yes, if by "matrix" you mean party, by "real life" you mean an Easel game, and by "die" you mean rank up the leaderboard.

Graphics

• Spark now has an acceleration parameter, which can be used to give sparks gravity.
• Previously, the texture atlas would reuse an image when the actual size and the size on the texture atlas was within a factor of 2, but this has now been changed to approximately 1.25. This will particularly make anti-aliasing sharper for text and vector images.

Physics

• Previously if a Line had a bigger cap than it has length, then the physics engine would ignore it the cap. But now it works as expected. Low-key no cap.
• The new Category:Default lets you use physics without having to declare a category upfront, letting you get started faster.

Editor improvements

• The game canvas now no longer gets cut off by the "Exit Preview Bar" when in preview mode. What you see in preview will match what you see when you publish your game.
• Pressing Ctrl+S will save your file, the same as clicking the Save button
• Importing a zip file into the editor will cause it to be automatically unzipped, making it easier to import asset packs into Easel

Other

• Preference data per user can now be up to 1 MB (was 128 KB). This gives you more headroom and less worry about losing data.
• When publishing a game, a URL segment can now be up to 80 characters long (was 30).

Thanks for being here!

Thank you for your continued support of Easel!

• If you haven't yet, try out Duck Mim's game Duck's Farm, a little farming simulator made with Easel!