https://easel.games/blog/atom.xml

Subcameras for parallax effects, TextSpark and other particles, and more! Keep reading to learn what is new with Easel this month.

Easel is a 2D game engine which makes your game multiplayer automatically! Intrigued? Visit our home page to learn more.

The biggest update this month is the new physics engine, which means Easel can now support much larger worlds, as only the parts of the world that change need to be snapshotted and rolled back as part of Easel's predictive multiplayer architecture. This is such a big topic that it deserved its own post: A Physics Engine with Incremental Rollback.

Parallax is a common effect found in games where the background moves slower than the foreground, creating a sense of depth. It involves creating a stack of cameras that are locked to the same position but with different zoom levels. Previously, this was difficult to do in Easel reliably because of the way its predictive multiplayer architecture works.

For example, the camera may be moved to the left based on the player's input, but when other player's inputs arrive, the camera may need to be rolled back and moved to the right instead. Instead of the camera snapping to its new position, the camera is smoothed between the predicted position and the new position (controlled by the transitionRate parameter). But because your userspace code lives only in the current timeline and has no awareness of the predicted timelines that came before it, it cannot know where to place the stack of parallax cameras so they match the main camera, which could be transitioning from any direction.

The new Subcamera function locks one camera to another at the engine level. This makes sure the parallax is always right, no matter what happens with the timelines and rollbacks.

In Easel, when a fireball crashes into an enemy, you can use Spark to emit a burst of particles that fly out in all directions, creating a satisfying explosion effect. The new PolygonSpark, ImageSpark, and TextSpark functions make it easy to create sparks in different shapes and styles. For example, you could use a TextSpark to flash damage numbers when slicing an enemy with a sword, or ImageSpark to create a burst of coins when breaking open a treasure chest.

While you could previously create the same effects using sprites, sparks are a lot more efficient. Why is this?

When you animate a sprite, you are changing its underlying data every frame. Everything that changes in Easel needs to be snapshotted so it can potentially be rolled back as part of the predictive multiplayer architecture. Sparks are cool because their data never changes. You declare a spark once, and then the engine calculates its position and appearance at render time based on the spark's parameters and the current time. Perhaps surprisingly, the data actually never gets snapshotted at all because it never changes. In Easel, sparks are super efficient. Spark your imagination and let it go wildfire!

The new stroke and strokeAlpha parameters have been added to the TextSprite function, allowing you to add a dark outline to your text, helping it stand out against bright backgrounds. Great for damage numbers, speech bubbles, or any text that needs to be easily readable.

A similar stroke parameter has been added to Span and other similar UI elements, so you can turn off the default stroke if you want your text to be blend in with the background more. Great for styling little hints or reminders next to common actions.

In addition to stroke, you can now also use crater, glare and feather on both text and image sprites and sparks.

In doing this change, we discovered that Easel was basically not culling any offscreen text. This was causing massive peformance issues on games like GTW where the labels of every star in the entire galaxy were being redrawn every single frame. Normally the text would only need to be drawn once and then it would remain on the texture atlas without needing to be redrawn, but in this particular game, each label in the star map is actually the size of a star and so when you're zoomed into one star, the labels 2048px high, and no texture atlas is big enough to hold 50 of those.

Now offscreen text gets culled correctly, meaning it does not get drawn at all. This should result in a significant performance boost for games with worlds full of text.

The with block now accepts a parameter, letting you easily assign the value of a property to a variable:

with Health myHealth {
    Content { "My health is: " + myHealth }
}

The new WithEachPlayer lets you add a behavior to every player in the game, past and present, letting you create more decentralized systems:

WithEachPlayer owner {
    Print { "Welcome to your doom, " + PlayerName + "!" }
}

You can delete WithEachPlayer<Id> too:

WithEachPlayer<upgradeSystem> owner {
    PlayerUpgradeSystem
}
await ConcludeGame
delete WithEachPlayer<upgradeSystem>

Thanks to everyone in the Easel community for your continued support. We love seeing what you're making! Speaking of games, if you haven't already, try out the new Dinosaur game made by NotAHat: https://easel.games/@notahat/dinosaur-game

We want Easel to be powerful enough to make the kinds of games you would play for hours. Popular multiplayer games like Among Us let you walk around an entire spaceship, completing tasks and evading impostors. Unfortunately, up to this point, games of that scale were out of reach for Easel, because the off-the-shelf physics engine would have to snapshot and roll back the entire world to support Easel's predictive multiplayer architecture. It's too much to do every frame.

Until this point, you were required to keep your world small. But not anymore!

Easel's new custom-built physics engine only snapshots and rolls back the parts of the world that change. That big spaceship might have thousands of objects forming the walls, the control panels, the vents, and so on. However, each frame, a surprisingly few number of objects actually change - perhaps less than 30 per frame as the players walk around and interact with the world. A smart implementation keeps objects sleeping while they are offscreen.

With only 30 objects out of thousands needing to be snapshotted each frame, a factor of 30-50x fewer than before, multiplayer Easel games with large worlds suddenly becomes feasible. Release the feral hogs!

Easel's new physics engine is custom-built for Easel, which is why it supports everything Easel supports, but better! Here is a tour of some of the features that make it special.

The fastest way to do something is to not do it at all. When a body is asleep, it does not require any snapshotting, rollback, or any physics calculations until it wakes up again. Unlike other engines which wait for a few seconds of inactivity, Easel puts bodies to sleep immediately when their velocity reaches zero (within a small epsilon threshold, of course, we're not slow).

One tricky case here is gravity, which has the potential to keep your entire world awake with its constant nagging force. Easel tracks the forces and reaction forces on every object and can see whether they are balanced or unbalanced. Regardless of whether it is at zero velocity, as long as one body in a stack has unbalanced forces, the stack has not settled into equilibrium and so the whole stack stays awake.

Like many other physics engines, Easel's broad phase uses a Bounding Volume Hierarchy (BVH) to quickly find potential collisions. Easel's BVH algorithms are optimized to minimize unnecessary snapshotting and rollback, only performing incremental rebalancing when the tree is already undergoing change. Do you only do the vacuuming just before your friends come over? Easel's BVH is lazy efficient just like you.

One additional trick is Easel's BVH also tracks the Categories of each collider, which speeds up common game queries dramatically. It is very common, for example, for a bot to target the nearest player, and if the player is on the other side of the map, it would have to traverse through every single collider in the world to find the nearest player. Finding the nearest Category:Needle amongst a sea of Category:Haystack colliders is a lot faster with a metal detector!

Making a character take a step is something so common but surprisingly complex in physics engines. A common method is to add velocity for the step, then subtract it after the physics simulation is complete, but a problem arises when the character collides with an obstacle mid-step.

Even if the physics engine does its job correctly and zeroes out the velocity, later on when the previously-added step velocity gets subtracted, it reintroduces the bounce back that the physics engine just zeroed out. It makes your character feel really bouncy.

• Some games fix this by damping out all velocity, which removes bounce back but also removes knockback too, removing some of the fun and feel of the game. Walk into a wall? No bounce, good. Get hit by a fireball? No knockback. Seems wrong.
• Other games fix this by creating a kinematic character controller based on raycasting. In physics engine terms, kinematic (as opposed to static or dynamic) means that the character is not affected by forces and collisions. In other words, the physics engine has failed to produce the desired results, and so it is now being bypassed entirely. You had one job physics engine. Physics. Do it. Please. Not not like that. Okay fine I'll do it myself.

Non-bouncy stepping has been built directly into the solver of the Easel physics engine. Simply use ForcefulStep with the new restitution=0 parameter, and Easel's new physics engine will make sure the step does not bounce back.

The trick is, Easel treats stepping in a similar way to how it corrects for position overlap.

Have you ever played a game where your character gets stuck in a wall, and the physics engine tries to eject you, sending you flying across the map? It is a common physics engine glitch. Super Mario 64 speedrunners famously love to make him slide backwards up the stairs on his backside using a glitch like this. Ow.

Modern physics engines try to avoid this problem by solving for position correction separately. The force that would eject your character out of the wall is applied immediately to the position without changing your velocity, which means the ejection velocity does not last beyond the current frame.

ForcefulStep in Easel is implemented as part of position correction, which is why it does not cause bounce back, unless you want it to. We're killing two (angry) birds with one stone!

In reality, it is a bit more complicated for numerous reasons. Easel first solves for both ejection+stepping and velocity at the same time, then we store that ejection velocity, then we remove the ejection+stepping constraints and solve again, storing the stabilized velocity. At this point, nothing has moved yet, which is why we are now free to sweep for the next time-of-impact using the correct velocities. When it comes time to take a step, we use the ejection velocity, but at the end of the frame we only commit the stabilized velocity and so the bounce disappears.

In other words, Easel collects all the data it needs up front without making changes, so that when it does make a move, it can make the correct one.

We love it when two fireballs collide with each other in mid-air.

Finding the collision between two fast-moving objects like this requires continous collision detection, because if we just checked for collisions once every frame, we might miss the precise moment when the two fireballs overlap.

Continuous collision detection is Easel is performed by sweeping and then shape casting like other physics engines, but in doing this we noticed a few differences between Easel other physics engines which may be interesting to some nerds game developers:

• The Rapier physics engine can produce an incorrect result when the fireball begins the frame touching a mirror. In Easel, collisions are resolved first, causing the fireball to bounce and change direction, and only then does it search for the time-of-impact of those two fireballs. In Rapier, the time-of-impact is searched for first using the original velocities, meaning that in this case, it starts by sweeping that fireball in the wrong direction. This difference happens because Rapier does the position integration early, committing to a substep length before it knows what the time of impact is going to be. Easel stores enough information up front that it can do the position integration after it knows the time of impact, avoiding this problem.

• Box2D 2.4 does sweep using the correct velocities but takes a different approach of doing the full normal physics simulation, then backtracking, which is why all collisions are already resolved before continuous collision detection. Interestingly, the new Box2D 3.0 does not support dynamic-to-dynamic continuous collision detection at all, meaning those two fireballs would have no choice but to miss each other like ships in the night. Perhaps this is a future direction for Box2D as, besides this, it seems they have achieved the holy grail of avoiding substepping at all by using speculative contacts.

• Photon Quantum, a professional multiplayer rollback netcode engine, does not support continuous collision detection at all, citing that their physics engine is stateless and so it would be too expensive. It seems incremental snapshotting and rollback of our physics state has enabled Easel to support this feature performantly.

One inconvenient edge case with the previous physics engine is that a body with a velocity or turnRate and no colliders would not move at all.

It could be argued that this is correct. If there is no mass to hold momentum, there's no movement, but we are not just making a physics engine, we are making a game engine. Sometimes bodies are just a way to group sprites together, and the physics is not important.

Now if you give a body a velocity or turnRate, it will move itself even if it has no colliders. Attach a TextSprite and you could have a simple billboard floating up the screen, scrolling away to a galaxy far, far away.

Sidenote: Photons don't have mass but they still have velocity, in fact there are 10^17 of them hitting your eyes right now every second, so maybe some physics engines need a reality check.

Easel's physics engine is built upon the collision detection algorithms of Parry, an excellent open source library created by Dimforge that powers the Rapier physics engine.

Making a physics engine has been a huge endeavor. Many little decisions have been made to make implement it in a way that is neat, efficient and works well with Easel's multiplayer architecture. Now everything, not just the physics engine, but all parts of Easel only snapshot and rollback the parts that change, meaning you can make much bigger worlds.

It's time think bigger!

Match blocks, statements as expressions, itch.io export and more! Keep reading to learn what is new with Easel this month.

Easel is a 2D webgame engine backed by an exceptionally productive programming language. Intrigued? Visit our home page to learn more.

Game developers often publish their games to itch.io or other platforms to share their games with a wider audience. With a click, you can now generate a zip file which you can upload to itch.io or any other website. The zip file will embed your hosted game on Easel using an HTML iframe. See Exporting to learn more.

Every control flow statement can now be used as an expression. The last value in the block determines the result:

let x =
    if happy && youKnowIt {
        Clap { hands }
        123
    } else {
        0
    }

Within a loop, the break statement determines the resulting value:

let hit = loop {
    let that = await BeforeCollide
    if that.Category.Overlaps(Category:Projectile) {
        break that
    }
}

See Control Flow to learn more.

Sometimes a calculation involves many steps. You can now include multiple statements inside parentheses (), which means you can split your calculation into multiple lines and use intermediate variables to make it easier to read. The last value in the parentheses becomes the resulting value:

let x = (
    let a = 123
    let b = 456
    a + b
)

Any statement is valid inside the parentheses, so you can use control flow statements, call functions, create behaviors, etc:

let x = (
    let a = 123
    let b = 456
    if happy && youKnowIt {
        Spawn unit { HappyDancer }
    } else {
        on Paint {
            Spark(color=#ff0000)
        }
    }
    a + b
)

See Block Scopes to learn more.

Easel now has match blocks! Match blocks are a concise way to choose a code path using pattern matching:

let x = "Pineapple"
match x {
    123 => Print { "It's 123!" },
    "Banana" => {
        Print { "It's a banana!" }
        Spawn unit { BananaMonster }
    },
    IsString => Print { "It's a string!" },
    [x, y, z] => Print { "It's a array of length 3!" },
    { type = $apple } => Print { "It's a Map of type apple!" },
    _ => Print { "It's something else!" },
}

Match blocks can return values and can be used in expressions:

let scoreChange = match x {
    $apple => 100,
    $banana => 200,
    $pineapple => 100,
}

See Match Blocks to learn more.

Previously, callbacks could only ever return 1 value. Now they can return as many or as few as you want:

let giveMeSomeValues = || {
    return 123, 456
}
let x, y = giveMeSomeValues()

The Easel compiler is a very precise machine. For every line of code, it needs to perform accurate accounting of all the operands and their runtime memory layout. Even the tiniest off-by-one error would crash your game. This is one of the reasons the language was kept simple until now, not allowing for statements and expressions to mix, and limiting callbacks to returning a single value.

Changing Easel into an expression language was a very delicate undertaking, but they say if you did everything right, it should seem like you did nothing at all. Enjoy the new syntax and features, we hope you never need to give a thought to the complexity under the hood that made this possible!

You can now modify accumulators directly using the =, += and -= operators, which is much more intuitive:

owner.NumGamesPlayed(overwrite=123) // old way
owner.NumGamesPlayed = 123 // new way

owner.NumGamesPlayed(overwrite=123, showOnLeaderboard=true) // old way
owner.NumGamesPlayed(showOnLeaderboard=true) = 123 // new way

owner.NumGamesPlayed(delta=1) // old way
owner.NumGamesPlayed += 1 // new way

owner.NumGamesPlayed(delta=1, showOnLeaderboard=true) // old way
owner.NumGamesPlayed(showOnLeaderboard=true) += 1 // new way

The compiler automatically interprets += or -= as a delta modification, which means it will merge the change correctly in the event that other deltas are happening at the same time. This is now the standard way to update accumulators, but the old way with delta and overwrite parameters will still continue to work. See Accumulators to learn more.

The above syntax is only possible because you can now override the += and -= operators. If you want to get fancy and use it in your own code, see Set Functions to learn how to do this.

On a related note, Easel now has a special codepath that makes it faster when using += with Strings or Arrays because it can now reuse the same allocation.

Easel now has a gift code system: easel.games/Redeem

Join the Easel discord, find the Welcome channel, and in there you'll find a gift code for 50 MB of free storage that you can redeem as a thank you for being an early supporter of Easel.

Using this new gift code system, we also are now able to giveaway 12-month subscriptions to Easel+ for promotional purposes. Are you running a game jam and looking for prize sponsors? Are you an influencer with an established audience, looking to either test Easel or do some giveaways? Get in touch with us if you are interested.

Easel continues to improve! Keep reading to learn what is new with Easel this month.

Easel is a beginner-friendly 2D game programming language with automatic multiplayer. Intrigued? Visit our home page to learn more.

Games have entities, and they have user interface panels, and when the hierarchy of the two do not line up, sometimes complex code was required to wire the two together. Galleries are a new powerful feature that streamlines this process.

Let's say you are making an inventory management panel. Instead of needing to ship all the data from each inventory item to the panel, each item can instead just display itself in the gallery. Your logic stays local, staying within the context where the data already is, which makes your code simpler.

Galleries allow you to separate the decision of "what" should be displayed from "where" to display it, decoupling the logic of your game from the structure of your user interface, which can simplify your code.

See Galleries to learn more.

The new existential coalescing ??? and existential assignment ???= operators check for existence, and can make your code more succinct.

For example, let's say in your game, a hero can only have one shield. If they pickup another shield powerup, it should do nothing. However, let's say the shield expires after a while, at which point they are allowed to pick up a new shield. We can implement this succinctly with the existential assignment operator ???=:

HeroShield ???= Subspawn shield {
    // only runs if the hero does not already have an existing shield
}

If the left side (HeroShield in this case) already exists, it will short circuit, meaning the right-hand side will not execute at all (Subspawn shield in this case).

See Operators and Assignments to learn more about these new operators.

You can now initialize a field or prop with an Array or Map literal.

Let's say in our game, a player can receive multiple curses, but each player can only curse another player once.

This can be implemented succinctly using a field initialized with Map, like this:

pub field hero.HeroCurses = {} // a map of { owner => curse }

Now it only takes one line to add a new curse to the hero's HeroCurses Map, if it does not already exist:

HeroCurses[owner] ???= Subspawn curse {
    // only runs if the hero does not already have an existing curse from this player
}

Here is an example of initializing a field with an Array:

pub field hero.SnakeSegments = [] // initialize with an empty array

Also, now various arithmetic operators can also be used in initializers, which means you can now initialize a field with flags like this:

pub field hero.PickupTypes = PickupType:Weapon | PickupType:Powerup

Preivously toolbars would reserve space at the top of the screen, above any content, and this area could not be stylized in any way.

Now a ContentScreen will now fill the entire screen all the way to the top, with the Toolbar overlaid on top. This allows you to make more immersive homepages and let your content stand out even more. See Turret Tumblers for an example of a homepage video that now reaches all the way to the top of the screen.

Also, now if you want to encourage players to scroll below the ContentScreen, you can set ContentScreen(expand=false). This makes the ContentScreen only take as much height as it needs, rather than filling the full height of the screen, making room for any content below it to be visible and enticing players to scroll down. See Beelines for an example of a homepage that encourages players to scroll down.

By default, pages have a max width to keep your paragraphs of text legible, but the new Content(maxWidth=64) parameter lets you change this limit or remove it entirely, if you would like your content to better fill the whole page.

The new PhysicsTimescale property lets you slow down or speed up the physics simulation while the rest of the simulation continues at normal speed. You could use this for a slow motion powerup, or to pause the physics simulation while the player is selecting an upgrade, for example.

In order to keep you in the flow of coding, a number of improvements have been made to the editor.

• Ctrl+F will now search for selected text, helping you more quickly find other instances of the same function.
• Press F3 or Shift+F3 to jump to the next or previous search result, respectively.
• The new Ctrl+P shortcut lets you jump to a file by name, making it faster to navigate between files.
• Ctrl+Tab lets you jump back to a recently opened file. Hold Ctrl and keep tapping Tab or Shift+Tab to cycle through your recently opened files. Depending on your browser and operating system, you may want to try Ctrl+Alt+Tab or Option+Tab if Ctrl+Tab does not work for you.
• Ctrl+Enter enters preview mode, then Ctrl+Shift+Enter exits preview mode.
• For power users, the new Vim mode allows you to use Vim keybindings in the editor.
• One subtle but important improvement is the focus will be retuned to the editor whenever you do various actions like selecting another file, reducing the number of clicks to get back to coding.

See Keyboard Shortcuts for more information.

• The new hoverColor parameter lets you customize the hover color of buttons Button(hoverColor=#0fc) or links Link(hoverColor=#f80). See Button.
• The new shadow parameter lets you customize the strength of panel shadows Panel(shadow=0.5). In particular, Panel(shadow=0) can help you make effects like progress bars or title bars without the shadow interfering. See Panel.
• The new LoginToggle lets you add a login/manage account button to your homepage with a single line of code.

Now you can make even more fun and engaging games with Easel!

Storage has been increased for the Easel free tier! Keep reading to learn about this and other new features in Easel.

Easel is a beginner-friendly programming language for multiplayer games. Intrigued? Visit our home page to learn more.

Free users will now be granted 3 MB free asset storage automatically. Remember, Easel is about making webgames, and every additional megabyte of assets means your game will take longer to load for your players, so 3 MB should be plenty for most games!

Now it is even easier to get started building games with Easel!

See Pricing to learn more about Easel's storage plans.

Our primary audience is teenagers, so we want to make sure Easel is a safe and welcoming place for them. That is why now players who have inappropriate names will no longer be matched with others in multiplayer games. The name filtering system is automated and so not 100% perfect, so please report any issues you find and we will improve it.

See Moderation to learn more.

Easel uses TOML files to store game configuration data. Previously you needed multiple, like graphics.toml or players.toml, but now you can consolidate them all into a single easel.toml file.

One feature we did to make this work smoothly is, now when you remix someone else's project, all their comments in their easel.toml file will be preserved in your remix. Much better for learning from other people's code!

See Configuration to learn more.

Easel has a system for detecting infinite loops and stopping them without needing the player to terminate their browser tab. This is particularly useful when you're making your game because it means you won't lose any work if you accidentally create an infinite loop in your code.

The infinite loop detection now has a higher limit for how many loop iterations are allowed per tick. Previously it was 1 million iterations, but now it is 16 million. But what if you are making a game like chess that requires a lot of computation? You can now increase this limit even further, or disable it altogether!

See Infinite loop detection to learn how to increase this limit.

Previously, Easel would suspend any game that receive no inputs for 1 minute. It is quite common for players to switch tabs while waiting for players, sometimes for 10+ minutes at a time, and this conserves resources for both the server and other clients.

Now, this suspension behavior only applies to multiplayer games. Singleplayer games will continue simulating even if the player is not interacting with it. This could be useful if you are making a simulation game, like a city builder for example. The player can just watch their city grow even while they are not actively interacting with it.

See Suspension to learn more.

The Dropdown UI element now has a key parameter, which lets you distinguish between multiple dropdowns in your code.

Also, the value for DropdownOption parameter has also been upgraded to accept any Sendable value, whereas previously it could only be a Keyable value. In particular, it can now contain any floating-point Number, or even an Array or Map, allowing you to represent even more complex data for each option!

See User Interface to learn more about UI elements in Easel.

Anything you code in the Easel programming language is automatically multiplayer, and that is because we have taken great care to make sure Easel is deterministic. We have recently found and fixed some edge cases that could cause non-deterministic behavior in the physics engine, and added some additional safeguards to prevent this from happening in the future.

Don't understand what any of this means? You never need to! That's the beauty of Easel. Just make your game and the multiplayer is taken care of for you.

See Multiplayer to learn more about multiplayer games in Easel.

We are always working hard to make Easel even better! Sign up to our newsletter at the bottom of this page to stay up to date with the latest news!

Stencils are here! Keep reading to learn about this and other new features in Easel.

Easel is a beginner-friendly programming language for online games. Intrigued? Visit our home page to learn more.

Stencils are a new feature that let you limit the rendering of a camera to a specific shape.

You'll be able to use stencils to create a variety of cool effects in your games, such as:

• Scene transitions: Create cool scene transitions by animating a stencil shape that reveals or hides the scene.
• Fog of war: Limit a player to only seeing what their units can see, by stenciling the camera around each unit. Stencils are additive, so overlapping stencils combine to reveal more area.
• Stylized borders: Give your minimap a fancy shape by giving its camera a stencil.
• Search and reveal: Create a spotlight effect by using a circular stencil that follows the mouse pointer

See the Stencils documentation to learn more.

Displaying text in your games just got a lot more powerful! TextSprite has a few new parameters:

• bold and italic let you style your text even more.
• fontSize lets you set the size of your text in em units. Use this instead of the radius property if you want your text to match other UI elements. You should use fontSize over the old heightPx parameter where possible, as pixel units do not respect the user's choice of text size, while em units do. Users may have a larger text size than you expect, perhaps because they have low vision or are using a small screen, and using em units helps ensure your text is readable for everyone.
• align lets you center, left, right align your text.
• vAlign lets you vertically align your text to the top, center, or bottom of its position. The old anchorTop and anchorBottom parameters have been deprecated in favor of this new parameter.

This required reworking some of the text rendering system, and now it is more efficient! The text is now rendered onto a bounding box that is only just as big as it needs to be, reducing unnecessary computation and improving performance.

Physics is a great way to make your games deeper, because people intuitively understand the complexity of physical interactions without you needing to explain it to them.

The physics engine has been upgraded to a newer version of Rapier, which should improve performance. Rapier reports an improvement of 25% on various benchmarks. This means you can make even bigger games with Easel!

As part of this, now when new colliders are added, they will automatically show up in any spatial queries like QueryNearest, whereas previously you would need to call ResetSpatialQueryIndex or wait for the next physics step to have them included. You still need to call ResetSpatialQueryIndex if you move existing colliders around and want that to be reflected in your query. And even then, you may want to consider just waiting until the next frame when the physics engine automatically updates the spatial query index by itself.

Easel lets you code multiplayer games like everyone is in one shared world, like a singleplayer game. Powering this magic is an approach called rollback netcode that lets players see immediate responses to their inputs, even before those inputs have reached other players. We now have a dedicated page that describes exactly what is special about Easel's rollback netcode implementation. Check it out to learn more about how it works under the hood!

Multiple cameras are here! Keep reading to learn about this and other new features in Easel.

Easel is a remixable online game engine designed to match how humans, not computers, think about games. Intrigued? Visit our home page to learn more.

Easel now supports multiple cameras! You can use this for all kinds of effects - minimaps, parallax backgrounds, heads-up displays, overlay screens, split-screen displays, scene transitions and more.

Sprites (for example ImageSprite) can be rendered into a particular camera using the new camera parameter:

ImageSprite(@spaceship.svg, camera=Camera:Minimap)

Use the new Viewport function define which part of the screen a camera renders to:

Viewport(width=12, height=8, anchor=@(1,1), camera=Camera:Minimap)

Multiple cameras is a powerful new feature that opens up many possibilities for your games. This is the first version and there will be more improvements to come in future releases! See the full documentation on Cameras to learn more.

Editions are Easel's way of introducing breaking changes in a controlled manner.

In order to support multiple cameras, we have created edition=15 to introduce the necessary breaking changes to make this feature possible. Particularly, now you can create multiple cameras by calling the Camera function multiple times, whereas previously it would have just replaced the existing camera.

See the Edition 15 - Multiple Cameras page for upgrade instructions. In most cases, you won't need to do anything because you probably only used one camera anyway!

Easel's most remarkable feature is that it makes your game multiplayer, completely automatically. Visit our Multiplayer documentation to learn more.

When you play a multiplayer game in Easel, every player's inputs are sent to each other through a peer-to-peer relay. Even though there is no server, the latency is similar to what you would get if there is a virtual server placed at the midpoint between all players. The virtual server can be closer to players than a real server could be, sometimes even in the middle of the ocean, giving players a better multiplayer experience than traditional server-based multiplayer games.

Easel optimizes this even further by moving the virtual server to the midpoint between only the active players. For example, if a player's spaceship has just been destroyed and they cannot actively participate in the game anymore, you can mark them as Eliminated to tell Easel to exclude them from the virtual server calculation. That means if there are only 2 players left in a 4-player game, they can really battle it out with the best responsiveness possible!

Now, you can also uneliminate players by setting Eliminated = false. This is useful in games where players can respawn after being eliminated, just like in our game Turret Tumblers!

See Eliminated for more information.

Features:

• Camera: you can now pass in a Vector to radius to represent a camera with a different width and height. This sometimes allows better use of screen space, for example to match a vertical game to a vertical phone screen.
• Added CameraBoundary function: limit the camera to stay within a specific rectangle, for example within the map boundaries.
• You can now have multiple Vignette effects at once, layered on top of each other. Vignettes can also now be luminous. Luminous vignettes look like they are made of light rather than paint and so could be used to make a glowing powerup effect, for example.
• SolidBackground can now be semi-transparent or luminous. You could use this, for example, to make the background of the minimap slightly see-through.
• Added IsButtonDown
• PlayerNameDisplay now takes a color parameter.
• Sing now has a seek parameter to start playing from a specific time offset.
• You can now delete a Strobe
• Added IsPartying: so you can display a different interface depending on whether the player is in a party or not.
• Added PartyToggle function: add this to your toolbar to let players join or leave a party easily in your game.

Bug fixes:

• Fixed an issue where if a Subspawn would exist after its parent was despawned if it was spawned during the BeforeDespawn of its parent.
• Fixed an issue where music would not play on iOS until another sound effect was played first.
• Fixed an issue where no cookie would be set for Easel games in an IFRAME in Safari, meaning it would lose all progress on page reload.
• Fixed an issue where friction could not be updated for a PolygonCollider
• Fixed an issue where GravityScale could not be updated

Easel has been an incredibly ambituous project. Putting multiplayer into the fabric of a programming language itself, making it almost invisible to the programmer, is one of those deceptively simple ideas that is full of hidden complexity. On top of that, this was our chance to reimagine the way a next-generation game programming language should be, which was a huge task in itself. Now, after 3 years of development, Easel is now in beta! 🎉

Easel is a beginner-friendly 2D game programming language designed to match how humans, not computers, think about game logic. Even if you've never coded before, you'll love making games with Easel! Visit the About page to learn more about Easel.

Easel is full of unique features that make game programming easier than ever before. In hindsight, they all seem so simple, like there is no other way they could be. How long do you think it took to invent Implicit IDs, the feature that gives Easel its reactive style? A few weeks? No! It actually took 2 years and 1 month! Easel has been a long journey of placing brick upon brick, taking a path then backtracking and taking another. Now we are finally at a point where it's ready for the world to see.

With Easel, we are trying to make the easiest multiplayer game engine ever made. We hope to see seasoned coders and beginners alike making games with it. Could this be you or someone you know? We would love for you to try it out!

Get started with Easel with our Quickstart Tutorial!

Our next phase of development is to grow the capabilities and power of Easel so that you can make the games you want to make. Easel is not yet as fast as it needs to be, because we have been so busy inventing Easel that we haven't had the chance to optimize it yet! If Easel today does not yet have everything you need, please join our mailing list (at the bottom of this page) so we can let you know as each new feature is added.

Thank you to everyone who has been making Easel games during the alpha testing phase! Try some of the games they have made:

• Pew Pew!
• GTW
• Operation Strafetweak
• Chaos Classified
• Snake
• Astroblast
• Acolyte Fight!

Welcome to Easel, a beginner-friendly 2D game programming language designed to match how humans, not computers, think about game logic. Learn to code the fun way: by making games you can play with your friends!

Easel is an entirely solo project that I have been working on for two years, and I am excited to finally share it with you all.

When I made my previous game, Acolyte Fight, I found that a large proportion of the players were more interested in modding the game than playing it. The easy-to-use tools that I had created for myself turned out to be a hit with people who were new to coding. Unfortunately, the tools were limited to the design the existing game and so there was a limit not just to what could be made, but what could be learned. Ever since then, I wondered, what would happen if someone would make a new game engine with the same declarative style of editing, but with substantially more power and flexibility? Would it lay out a path for someone to take from complete beginner to seasoned coder? That is what Easel is all about.

Learning to code can be a long journey. You've got to find a way to do it that is engaging enough that you can stick with it for the long haul. When I was a child, I learned to code by making the tools I needed to mod StarCraft, one of the most popular games at the time. That kept me interested. I hope Easel can do the same for a new generation of coders.

Easel is a specifically online multiplayer engine because I believe that one of the most engaging ways to learn to code is to do it with other people. I hope that Easel can be a place where people can come together to learn and create. I imagine a community of people of all skill levels coming together, helping each other out, sharing their latest creations, and creating amazing things together.

One thing that I really loved about Acolyte Fight was that it introduced coding to people who had never coded before. I hope that the same happens for Easel. The people I hope to reach are not specifically the ones who already want to make games, but instead its the people who want to play games, but gradually become curious about how their favourite game is made. That is why I hope to see some truly fun and engaging games made with Easel that will reach a wide audience and somewhat accidently inspire people to look behind the curtain.

Coding can be a life-changing skill, it was for me, and I hope that Easel can be a part of that journey for you or someone you love.

If you are interested in learning more about Easel, a good place to start is the Quickstart tutorial.

Join the Easel community on Discord!