How Figma draws inspiration from the gaming world

I’ve always been drawn to video games. There’s no feeling like immersing myself in a different time period and location, getting to know a wide range of characters and stories, and experiencing incredible graphics in real time. And building them is equally rewarding. Before Figma, I spent most of my career developing game engines for different consoles.

While we’re not exactly developing games at Figma, one of the reasons I joined is that there’s a lot of overlap between video game engines and the technology that powers Figma. On the engineering team, we borrow elements from the gaming world, and that playful, collaborative spirit is a consistent thread throughout Figma. That extends to our technology, too; some of our most interesting technical challenges mirror those in gaming, from infrastructure to the user experience.

Engineers as digital world-builders

To build vast and imaginative spaces, game designers and engineers utilize “game engines,” collections of different systems that all come together to help us visualize a world. If you’ve played Minecraft, you know how collaborative and creative the community is. After all, it’s a multiplayer game where you design your own world, so there’s a strong culture of user-generated content—like maps and games—to customize your experience. It isn’t unlike a certain creative collaboration tool where people come together to bring their designs to life. 😉

Video game engines usually start with the same building blocks:

• A graphics and rendering system to display the objects and effects you see on screen
• A control system that enables you to take action in the game’s world

On top of those foundational building blocks, depending on the game, you might want to add additional systems. For example, Minecraft might require:

• A multiplayer system to allow you to see, collaborate, or compete with the other players in real time
• A physics and collisions engine driving gravity and how you physically traverse the world
• An animation system to give life to your character’s movements
• An artificial intelligence system to drive all the NPCs (non-player characters) in the world
• A combat system so you can fight with monsters or aliens

In Figma, we’re effectively building a state-of-the-art 2D graphics and rendering system on the web, the same foundational building block used in video games. For every text, shape, and line that a user creates, it’s the engineering team’s job to bring it to life in the browser. Users can pan and zoom to their hearts’ desire, and we ensure that the objects show up correctly on the screen at the positions that the users expect.

Just like games, graphics and rendering are just one part of the equation; much like Minecraft, we need to build on top of that foundation. Allowing users to collaborate is core to making Figma work the way we intended. In fact, we were so inspired by cooperative games that, when it came time to name Figma’s collaboration engine, we called it “multiplayer.”

For example, in a video game, Player A might lay down a building block on the street, while Player B moves a flower into the same spot. In this case, game developers would have to resolve the players’ actions in real-time to avoid collisions. This is something that we also do in Figma, for all of our design elements, so that users can add, move, and edit things at the same time. And while you can’t fight monsters or aliens, you can lay out blocks and pixels to perfection, which isn’t too dissimilar from a game of multiplayer Tetris anyway!

Figma’s multiplayer engine is just one of the building blocks in our digital world. We call our building blocks “systems,” and, in addition to multiplayer, we also have an animation system to make interactions more delightful on screen, and a collision engine that figures out what your cursor is hovering over and how to connect items together. Collaboration in Figma is such a key part of our user experience and—like a multiplayer game—we need to integrate systems like chat and audio

to let users communicate in real time. Additionally, we have systems that are more tailored to our users’ specific needs: an auto layout system to help users visually organize; component and variant systems to help users build a library of assets; a widget

Bringing the power of our open platform to FigJam

We are opening up our platform and inviting all builders to create the first plugins and widgets for FigJam.

and plugin

Plugins are coming to Figma

We're introducing the beta for Figma plugins, and we’re calling all builders to apply to be among the first creators.

system to empower users to build their own systems and share them with the community, and many, many more.

Systems can come in all shapes and sizes. For every core structural system, we can also build a delightful, smaller system on top of it. All of these add up. We have to run many systems in Figma and FigJam—of differing, and sometimes increasing, scope and complexity. On top of that, the code has to run inside of a browser window or in a mobile app, both of which present more memory and performance constraints. To satisfy these constraints, we have opted to use a tech stack that looks more similar to a game engine’s stack than a web stack. We build the canvas in C++ (then compile it into WebAssembly

), which is widely used in game engines for its efficiency and flexibility in memory management; that’s exactly what makes it well-suited for high performance, real-time applications. However, C++ does not come with great libraries for delightful and responsive user interface engineering, so we opted to write our UI layer in React and TypeScript instead. We also use a few different technologies on the server side, including using Rust in our multiplayer server

Rust in production at Figma

How Mozilla’s new language dramatically improved our server-side performance

, which provides better developer ergonomics than C++.

Creativity requires systems-level collaboration

In a video games studio, engineers don’t work in silos. Rather, they work directly with artists to perfect the glow on a character’s face, or with game designers to fine-tune the timing in a boss’s attacks. That kind of creative collaboration really allows the team to push the system to its limits, through the engineers’ understanding of the system, and the artists and designers’ desire to improve user experience. At Figma, not only do we collaborate often to ensure that different systems work well with each other, but we also work closely with product managers, designers, data scientists, and researchers.

When you are building a series of interdependent systems, any changes in one system will affect another. Take the popular Breath of the Wild game as an example: You can build a fire in the game, which provides light, warmth, and a hot meal. Still, the same fire can burn and hurt you, until you realize you can also use it to your advantage to defeat monsters! The game is so satisfying to play because the number of interdependent systems allow it to react to an infinite combination of scenarios.

The same is true of Figma, and that’s why I find my work here so fascinating. For example, we recently discovered a file that we thought had autosave failures. While it looked like an autosave system failure on the surface, engineers Katie Jiang and Jonas Sicking discovered that connectors in a FigJam file (those arrows that smartly connect things together) would oscillate because every user in the file was modifying it and sending slightly differing data back and forth indefinitely. This caused a huge number of multiplayer messages, which overloaded the multiplayer and autosave systems.

What could be causing the connectors to misbehave? After an audit of the code revealed nothing, another engineer, Isaac Goldberg, rigged up some debugging messages which eventually led us to a six-month-old PR change in an area of the code that has nothing to do with connectors! Turns out, because connectors have to smartly connect different pieces of objects, their state can be influenced by the code driving those other objects. For example, if a user changes the position or size of a sticky note with a connector, we have to recompute where the connector connects to, to preserve the illusion that the sticky and the connector are stuck together. It was the perfect encapsulation of an interdependent complex system, where one part of the code causes a bug in an entirely different part of the codebase. In this case, a bug in the layout system for objects led to a failure in the autosave system.

How we put multiplayer into practice

There is a classic scenario in gaming: Everyone is hyper-focused on the graphics, so developers spend most of their time improving the rendering system. But without also investing in the animation system or texture art, the game might look jagged and wonky, and won’t achieve the quality that players are looking for. To build an immersive world that suspends disbelief, we can’t just dive deep into one system—we need to take a step back and look at the big picture, ensuring that every system complements the others.

This thinking drives our development in Figma and FigJam. For example, we recently launched tables in FigJam

. As the product team focused on polishing the single-player use case—things like copy and paste, undo and redo, dragging to resize, and so on—the engineering team collaborated with our platform team to ensure that tables would work well in our multiplayer system. We learned that it’s surprisingly hard to make tables truly collaborative. If a user types in a cell while another user actively deletes it, what should happen? What if one person adds a row and another changes the color of a column that intersects with the row? We ran through so many of these scenarios, making sure that the end result is something that feels natural and consistent with the rest of the app. We could have opted to reduce complexity by locking a table when one person is actively editing it, but that wouldn’t be aligned with the collaborative nature of FigJam.

Even once we solved the hard problem of making tables multiplayer, we realized that observing multiplayer changes was a jarring experience. Imagine: You’re editing a cell and someone starts rearranging the rows so that your cell ends up two rows below where it was—technically correct, but confusing in practice. Designer Jakub Świadek came up with an interaction that would improve that experience, and engineer Tim Babb went to work on a framework that could bring it to life. To properly recreate Jakub's prototype in code, we needed to build a new system to animate elements on the canvas.

First, we started with “live feedback” so that users editing a table could see their actions in real time, even without a lot of explicit animation. As we built the system, we pushed every revision live to our internal testing environment, and the team really loved how snappy it is; it allows the user to see where they are moving a row and column, with just the right amount of FigJam delight. However, since it is tied to only one specific user’s mouse movement (the person initiating the change), we realized that it was jarring for everyone else. So, we decided to layer on more animation, allowing users observing the change to more clearly follow table edits as they happen.

For extra credit, we even looked at how dragging a row feels, and added a rubber band effect to help users understand the limits of where they can drag rows and columns. This is similar to games where designers add invisible walls and barriers to guide users onto the right path, without using explicit signage.

Finally, we partnered with our accessibility team

to ensure that users can navigate tables via keyboard shortcuts. While many FigJam users use a mouse or trackpad to navigate, it is more accessible and equitable to provide a keyboard navigation option for our features. This is actually a very common use case in games as well! Some games allow players to play with their keyboard and mouse, with a standard gamepad, or with specialized gamepads. Going back to those building blocks, a system dedicated to accommodating different control schemes can enable more people to enjoy the game! In the last game I shipped (Wattam), we supported the XBox adaptive controller, and the community reached out thanking me for that decision. I’m glad that Figma continues to invest

A conversation with Figma's accessibility team

Figma's accessibility team shares what they’ve learned from the community and their vision for what’s ahead.

in making our control system more accessible, too.

It takes a lot of deep problem-solving and collaboration to make Figma and FigJam responsive and delightful. I’m humbled by the talented engineers I get to work with, and appreciate that I can “nerd out” on complex systems whenever I want. More than anything, I love seeing users create complex worlds—especially when they build their own games.

If you have a background in making video games, or if you are intrigued by virtual-world-building technologies, consider joining our team—we’re hiring!