How Figma's Multiplayer Technology Works | Hacker News Reader

How Figma's Multiplayer Technology Works

figma.com

268 pointsAqua_Geek63 comments

I appreciate the technical achievement of "multiplayer," and it does work impressively well.

However, no one one my design team likes it. I certainly don't. It's akin to having someone breathing over your shoulder as you're trying to work. And with design, especially, I tend to create a bunch of nonsense and "bad" designs before getting anywhere near a level worthy of sharing or even a team critique. Even if I don't care what others think of me or my skills, it's very disruptive to the creative process to know that someone is watching you.

In my experience, at least, there do not seem to be very many use cases for "multiplayer." I mean, even using Google Docs at the same time as someone else is jarring and disruptive in most cases.

Perhaps the only use case where we've actually liked having it is for a critique (especially when a teammate is remote) or a demo.

Personal preference aside, I think Figma is great. I still miss some things from Sketch, but overall Figma is a great tool. My team recently transitioned/is still transitioning from Sketch to Figma, and I can imagine that many other design teams will be making the same move too.

I wonder if your concern would be addressed if Figma allowed creating a private branch that you could merge back later.

As a designer who has been part of small and large teams there is a critical problem is solves which makes it worth it: Versioning.

Versioning is hell, there are git-like solutions like Abstract or Cactus but aside from those solutions being half-baked, the need for versioning at all disappears with multiuser/multiplayer. You have one doc, one source of truth. When I work with other designers, PMs, copywriters, etc. Who all need to make edits for one reason or another, it because a nightmare really quickly.

The fact is 99% of the time, you'll be in the file alone. Just like Google Docs. But when you need it, it saves you a lot of time.

FWIW, I felt the same way transitioning to working within a software development team coming from a world in which my work was done much less tracked while still in progress, however I eventually realized that 1. typically no one is watching because they are aware of the structure of the workflow and that doing so would be inefficient, and that 2. when they do, there's little reason to be shy about it since anyone paying attention understands it's a draft and all that encompasses.

Maybe consider labeling the files that are in progress as such?

I've now gone fully the other direction and will open draft pull requests as soon as I start committing code, knowing that I have nothing to lose from doing so and often end up being saved time and with a better finished product sooner when someone whose intuition probably told them to peek at this particular piece of work for a reason.

TL;DR - You can get used to this and even grow to prefer it. That said, design is not engineering and I may simply have Stockholm Syndrome.

> However, no one my design team likes it.

Figma realized the same thing before starting the project:

> If anything, people hated the idea.

It seems they simply wanted to build this feature regardless of what the users think:

> But ultimately, we had to do it because it just felt wrong not to offer multiplayer as a tool on the web

Funny.

I have the exact opposite feeling towards this feature. It's completely changed the game at my design studio, made me a better designer, and makes us all more productive. We've gotten to the point where we'd probably turn down work if it meant we couldn't use Figma to do it.

That said, we are all producers at my studio and we also respect each other's space. Everyone designs in some capacity and we're all very comfortable in our skin. We don't really "snoop" on each others work if we know it's not time for feedback or we're not co-designing. The only time I'd pop into someones file or artboard I know they are actively working in is if I need to quickly copy/paste something I know they have (little things like this are amazing). Speaking of co-design, this is my favorite part of Figma. A few days per week we dedicate time to co-design with another person, kind of like pair-programming. Generally we both already have a base level of work complete and we talk through it, then riff on each others ideas and work to come up with something new or solve problems in different ways. Working this way at least a few days per week has really paid off for us and it's quite fun. I also feel like I learn new design tricks or skills I wouldn't have if I wasn't working this way.

I feel like between using this feature in a pre-planned way and also having some unspoken rules/constraints around how we review each others work is all you need to do to make this less of an issue. Honestly I look at it the same as literally standing over someones shoulder. I would never do that unless invited, and even then I'd prefer to sit next to them and it be more collaborative. There is also the trick, which some people do at our studio, of simply working in a private file until you're ready to paste everything into the collaborate projects. It's as simple as a copy/paste and you have complete privacy if that's what you want. We purposely do this with most of our clients so they are not tempted to leave feedback before we're ready.

As a counterexample I work with one other designer on my team and we have a really trusting relationship. We treat the product and marketing we design for as something we both steward rather than something either one of us exclusively owns. Being able to say "Hey can you take a look at this and help me figure out why it doesn't feel right?" and then have them copy the artboard and tweak it with me while we're on a video call is fantastic. (We both keep pages full of garbage designs while we're teasing things out too.)

Also since you can see the other person's cursor on your screen, you know when they're "watching" you. But in our case we don't really spend time scoping what each other is doing until one of us asks for help.

To echo what other commentators are saying regarding versioning, as someone who used to do Git, Plant.io, and Abstract to sync Sketch files, Figma removes this huge painful time-wasting part of our workflow.

We use Sketch Cloud for syncing and versioning. Works well.

I’m afraid I have to agree. Cool technology, but it seems like the sort of thing that would keep you second guessing yourself and promote the mediocrities of bikeshedding and design by committee.

> My team recently transitioned/is still transitioning from Sketch to Figma, and I can imagine that many other design teams will be making the same move too.

I'm curious why. I would've thought that the main advantage of Figma is the "online collaboration" aspect, but if you don't like that part, what is it that makes Figma better than Sketch?

I'm curious too. Our team uses Sketch and are super happy with it. This collaborative feature is definitely not a reason to switch.

I can use it from Windows.

In that case, why switch from Sketch to Figma and not to, say, XD? I feel like "multi-platform" was not _the_ reason people like Figma better than Sketch (maybe it's part of it, but not all).

I am all for XD, just stating a valuable reason in mixed enviroment offices.

Sounds weird to use "multiplayer" when there are no players involved, but users. On the other hand, I guess "multiuser" doesn't convey the real-time-ness they want to convey.

FWIW, here's how it's done for actual multiplayer games, especially the ones where latency is critical: https://gabrielgambetta.com/client-server-game-architecture.... Arguably, their software is more similar to a turn-based game, and formal correctness of the results is more desirable than "a smooth experience", as is the case for multiplayer games.

Figma's case is more challenging in some ways, too, though. In multiplayer games, like the one described on your website, you rarely have multiple actors independently manipulating the same object, there's a moderate tolerance for imperfect resolution of conflicts, and the server can reject messages that are more than a few seconds out of sync with the server state.

Figma needs to have very consistent, predictable resolution in order for users to trust it with business-critical documents, and it needs to allow users to operate offline for arbitrarily long periods without throwing their work away when they reconnect. This has to happen across multiple versions of the software, and across documents (e.g. when dependency libraries are republished).

Yep, I agree the use case is somewhat different - I wrote as much after the link. Probably why calling this "multiplayer" sounds weird.

Note: there's no client-server architecture needed with things such as Figma since it can be done P2P. I'm just past the beginning stages of it. You can use a mix of WebRTC/WebTorrent's infrastructure to get a serverless (i.e. use WebTorrent's signaling services) for P2P. A library called Bugout [1] implemented it this way.

If you want to see an example of how it works, check out my side project Doodledocs. I modified the Bugout library a bit for performance improvements, but my project is using its concept on how to spin up a serverless (i.e. not your servers but those of WebTorrent) P2P web app [2].

[1] https://github.com/chr15m/bugout

[2] Doodledocs is a collaborative doodling web app that I created as a sideproject, so it is just a bit related to Figma. I didn't make CRDTs yet, since I want a simple doodle environment for pencil/eraser (+ simple web annotation/image annotation).

Link: https://doodledocs.com (browsers tested: Chrome/laptop, Chrome/iPad, Safari/iPad).

Doodledocs looks like a really fun project, I'll definitely take a look :)

I didn't mention P2P or edit my comment at any point, BTW.

Huh... weird, maybe I read into things. I also read the word "collaborative" somewhere.

Oh! I see, I read "gatherhunterer" his comment as the top comment. I meant to reply to him, I simply clicked "reply" on the top comment.

Yeah, it's jarring. In the linked post from 2016, they clarify:

> The real-time collaborative editing feature that we’ve been working hard on over the past year is finally ready! Our implementation is called “multiplayer” since it was inspired by cooperative multiplayer games.

But real-time/collaborative editing (or "live editing") had already been a thing for years. It's weird that they felt the need to rename it and slap a cool backstory ("videogames!") on it.

It's not that weird. They can call it whatever they want. Multiplayer is a better name than 'live editing' anyway.

> They can call it whatever they want.

I never said otherwise.

> Multiplayer is a better name than 'live editing' anyway.

Right now, three of the top four comments in this thread are people criticizing and/or being confused by the term they used.

You may think that, say, "internationalization" is an awful, unwieldy word. As a guy who used to work in an i18n department, I'd agree. But if you're making internationalization software, and you decide to just call it "multiplacing" instead to save typing, you're going to confuse and put off a lot of your target market. That's not, generally, a good idea.

Multiplayer is already an entrenched term. Multiplayer actions have nothing to do with collaborative live editing, other than there are asynchronous events and state. This is true of all sorts of live analytics platforms.

"Figma didn’t start out with multiplayer editing support." - In the same vein, Uber has multiplayer. It's barely coherent marketing noise.

> Multiplayer is already an entrenched term. Multiplayer actions have nothing to do with collaborative live editing, other than there are asynchronous events and state. This is true of all sorts of live analytics platforms.

What is multiplayer gaming other than multiple players mutating a global, shared state at the same time? Seems close enough to collaborate live editing to me, especially when you consider games like Minecraft or Factorio (MP). The only confusing thing for me was that I had no idea what Figma even is and it took me a few paragraphs in to figure out what the article was actually about.

A source code review of Quake 3's network model:

http://fabiensanglard.net/quake3/network.php

It merges unacknowledged data into packets containing new information.

There's also GGPO which has been open sourced recently:

https://github.com/pond3r/ggpo

Great write up on your website! I remember Valve had some great pages about network game programming too.

I think “real-time collaboration” or “multi-user” would have been better choices than “multiplayer”. I was hesitant to criticize the term at first because it is so ill-fitting that I was unsure I understood what feature they were talking about.

It’s interesting to see this on HN at the same time as the GNU article about “Service as as Software Substitute”. I would have much more piece of mind that my personal or proprietary information is secure if I didn’t have to trust Figma. A peer-to-peer collaboration platform that I can run locally would be innovative and exciting.

I was trying recently to prototype a multiplayer experience, and got pretty stalled when it came around to the networking side. My goal wasn't to make it fast/scalable, but rather just to be able to have 4 people sit at my kitchen table and answer "is this game idea interesting/fun". But the resolution of movements, timing things, client/server stuff was actually a pretty steep cliff for someone who had never done it before. There's also a lot of interesting decisions to make upfront then about rendering, real-timeness, how you'll split up movement collisions, etc.

Regardless of if this is for a "Game" or not, I find reading more about these things quite interesting.

A lot of folks run into exactly those issues when they try to make fast multiplayer/multi-user.

It’s less useful out of the context of the presentation, but maybe this could help with your project:

https://www.slideshare.net/HunterLoftis1/making-sense-of-mul...

I don't know the full context besides what you've typed here, but for 4 people in the same kitchen evaluating a prototype, it seems like it would be a lot easier to pair up 4 controllers to the same computer.

Common advice your hear from gamedevs is to never start a networked game as a local game then "add the networking later". It's too fundamental and will require a rewrite.

Great write-up! Thanks for taking the time to do this.

This is incredibly similar to the way we did multi-user simultaneous editing in https://Clara.io back in 2013/2014. It was also a tree-based OT-like system, but there was a few differences.

I also wonder if you guys studied how we did it...

I worked at Salesforce then and we had this from an acquired company: https://web.archive.org/web/20140625063431/https://goinstant...

A lot of folks were using it to add "Multiplayer" to our apps.

Hey. Clara.io is fantastic.

What's the current state of play with it?

It was challenging to make money from students on the web -- which is the main demographic using Clara.io. It is sort of a selfless thing unfortunately.

So the parent company, Exocortex, pivoted towards 3D ecommerce and introduced the threekit.com brand aimed directly at that market.

It has been working okay: https://venturebeat.com/2019/01/10/threekit-raises-10-millio...

I think the approach of mutating each property independently is an excellent approach and I'm glad to see it working at scale. It's just like regular CRUD except that instead of mutating the whole resource, you just mutate one property at a time - And if two users edit the same atomic property at the exact same time, it doesn't really matter who's edit arrives last because there is no absolute right answer so long as both users can observe the same outcome.

I also did some work in that area several years ago which I refined over time into a sample app and a set of libraries: https://github.com/SocketCluster/ag-crud-sample#ag-crud-samp...

> When we first started building multiplayer functionality in Figma four years ago, we decided to develop our own solution. No other design tool offered this feature,

I could've sworn I've seen people on HN say there were tools that did real-time collaborative design before figma.

Name one?

It's a wireframe tool, but Mockingbird: https://www.gomockingbird.com/

Precursor, a prototyping tool I worked on, had "multiplayer" mode way before figma https://precursorapp.com/

I'm certain they were aware of it. We had a signup from a Figma domain in 2015 and I emailed them about Precursor in 2016 before they had implemented multiplayer.

> As a startup we value the ability to ship features quickly, and OTs were unnecessarily complex for our problem space. So we built a custom multiplayer system that's simpler and easier to implement.

That sounds like a bad reason to implement you own mechanism. There are many valid reasons to design your own system (your requirements being different is the most common one), but “the state of the art is too complex” sounds like a good way to reinvent all the solutions to the technical problems the state of the art faced and end up with an equally complex solution in the end.

This isn't to dismiss the work exposed here, and the really pleasant write-up, though.

Unrelated, but repl.it wants to do the same thing for code. It's an on line IDE, something like Cloud9, that lets you click, write a program in almost any language and run it on their servers. You can collaborate with others, where you all see the same terminal etc. This seems amazing for learning and small remote groups who want to code together. Repl.it is already becoming a place where bright kids learn to code and produce some pretty impressive things.

same as glitch.com (heavy on JS thought)

I do not know how usable Multiplayer is. I sometimes had that if i had one browser window open and opened another that i had two sessions in Figma, which was slightly annoying. But for me the dealbreaker with Figma as a tool is it sometimes has issues with exporting content to png. Meaning I had to import it in GIMP before re-exporting it. The idea is really neat, but it needs some work before I can really recommend it over more traditional tools.

My wife just started learning ui/ux. I think the realtime aspect could help with tutoring.

Is there anything currently being researched around Multiplayer tech with better efficiency than CRDTs or OT? It seems like almost all of such implementations currently just implement CRDTs or OT.

Better efficiency? What sort of efficiency are you seeking? I’ve built the core of a text OT system in C which can handle about 5M concurrent edits on a single machine. (Not counting network overhead.) I don’t think the upper bound on performance is the algorithms themselves.

The article specifically states they didn't implement CRDTs because they can do it more efficiently with a trusted server.

Anyone know what program was used to create the animated diagrams?

figma?

Figma is the one web app that always forces my safari down to its knees... even though I have a strong processor and lots of memory.

Well you're using Safari, don't expect the best performance.

CRDTs are absolutely critical, if you don't know about them, read this article & then research them!

If you're wanting to use CRDT tools, I recommend two:

- https://github.com/automerge/automerge (immutable)

- https://github.com/amark/gun (mutable)

Not sure why you're being downvoted but thanks for the links

I didn’t downvote, but the reason is that while CRDTs are indeed awesome, similar results can be achieved by OT. And in many cases more efficiently. So not absolutely critical, strictly speaking :)

He's getting downvoted for excessive self promotion often without a disclaimer. If you look at his comment history, he's non-stop spamming his own product, gun.js. If you search for gun.js, almost all mentions are made by him: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

There's only a small handful of HNers who upvote OT/CRDT/sync/realtime database submissions. So by now everyone is tired of seeing him promote gun.js again and again without contributing any other relevant technical insights.

Which is a goddamn shame. There aren't that many others who have first hand experience implementing these systems successfully. The other regulars who always appear in these threads get upvoted to high heavens even if they aren't saying much because we value these first hand accounts so much (josephg for share.js, raphlinus for xi editor's crdt, etc). But unfortunately after seeing gun.js hundreds of times I still have no idea how it works and his code is completely unreadable.

I don't think he realizes that if he had just explained why gun.js is amazing in a relevant way, others would help promote gun.js for him.

@MarkNadal Sorry if this was too mean

>So by now everyone is tired of seeing him promote gun.js again and again without contributing any other relevant technical insights.

I don't understand this perspective. Every single time Mark comments, he offers technical insights that are relevant to his experience with gun and distributed tech in general.

I mean look at this comment that you're bitching about. It's not just shameless promotion. It's on-topic and relevant to this discussion...

It should be noted that he's not "selling" gun, either. It's a completely free and open library.

The article starts without introducing what figma is. I read for a while before discovering this is something like Google docs... Multiplayer work-sim maybe?

Figma feels like the height of over-engineered backends with corresponding low-innovation frontends.

Figma is a marvel of software engineering. Have you used the competition? Have you used Figma?

Reply on news.ycombinator.com