Building Team Thinking Games At Synthesis

Rate this content
Bookmark

Synthesis' mission is to create a generation of supercollaborators through games. Learn how we harness the power of open source game dev libraries like Pixi.js and Colyseus to build high quality multiplayer games that kids enjoy.

16 min
28 Sep, 2023

Video Summary and Transcription

Today's Talk is about building team thinking games at Synthesis, an enrichment program aiming to build a generation of super collaborators. The key insight is that design is the main constraint, not graphics or AI. Synthesis uses open-source software and develops its own tools for game design and networking. The architecture of Synthesis games involves a server-native approach and a client-authoritative model for movement. The modular approach allows for quick iteration and flexibility in game development, and investing in content pipeline tools enables the creation of fresh content every week.

Available in Español

1. Introduction to Team Thinking Games at Synthesis

Short description:

Today I'm going to talk about building team thinking games at Synthesis. Synthesis is a concept that will be explained in a quick video. The game involves strategic decision-making and teamwork.

Hey, everyone. My name is Vivek Vidyasagaran. And today I'm going to be talking about building team thinking games at Synthesis.

So, first of all, what is Synthesis? And so, here's a quick video to explain the concept.

Two. One. Where are we going guys? I need everyone over here. Wait guys, I think I know what's happening. It's not about the length of the line, but it's the fastest route to get back to the planet. What's your idea, Tag? Yeah, I'd describe purple. It has the most strategic benefit for us. Oh yes, yes, yes. Haruun had an amazing idea. Oh my gosh. This is the best place for Tag. We're going really fast. We wanted to do extreme risk or we wanted to play it safe. Phoenix blocks the arrow. Let's go Phoenix. Go. The chain is working. The chain. Go for it. Go for it. Oh, this is going good. Yes, yes. Yes. Tristan, Tristan. What are you doing? Oh my gosh, that's lucky. We're first.

2. Introduction to Synthesis Games

Short description:

We're doing really good at this. Synthesis is an enrichment program for kids, aiming to build a generation of super collaborators. We have a wide variety of games in production, including sports and city-builder games. To build the best games, we have set design constraints that ensure every player is impactful, collaboration multiplies impact, and players can make complex decisions. The key insight is that design is the main constraint, not graphics or AI.

We're doing really good at this. Hello, Rahat. Hello, hello. There's other invaders. Other invaders. What? No! No, we should go all the way back. Oh yeah, when we get here. Yes. This is going to be insane. Oh yeah, this is so good. We got this brat, guys. We got this guys. We're going to win this. And this is not school, it's better than school. Cool.

So, that is Synthesis. It's essentially an enrichment program for kids. And as you saw there, they're all playing together and learning about teamwork, collaboration and stuff. So in a nutshell, what we're trying to do is build a generation of super collaborators. So these are people who can, who are able to work together in a team and achieve really good outcomes.

So these are some of the games that we have in production right now. So you can see it's like a wide variety of genres and play styles. We have sports games, we have city-builder games. And so, we need a framework that can build all of this quickly. So when we built the Synthesis game studio and talked about what we want to be prioritizing on, we realized that our product is unique and that we need a certain set of like design constraints to be able to build the best games.

So we came up with these tenets. So they are ensuring that every player is impactful, collaboration multiplies that impact, allow players to make complex, consequential decisions, provide opportunities to reflect and iterate, and thoughtfully balance each player's mind, mouth, and hands. So you can see these are all mostly design constraints. And that was a key insight that we had, is that the thing that really constrains us here is design. We're not trying to make the most graphically complex games or add in a very powerful AI or anything like that.

3. Game Design Iterations and Optimization

Short description:

We want to make games that hit our learning goals and are fun. An example is our early game that we launched the company with. We redid it with new mechanics and a lot of iteration on the game design. Our goal is to optimize for game design iterations.

We just want to make games that are able to hit our learning goals and are just fun to So as an example, this is one of our early games that we launched the company with. And you can see it's quite simple. And then once we came up with these tenets and sort of redid this game with those in mind, we ended up with Proxima v2. So you can see, visually, obviously, it looks much better. But really, the thing that was really different between these two games is all of the mechanics and stuff that went on behind it. And there were like periods of months where every two weeks, we were kind of like making new systems, trying them out, checking they work and pulling other systems out. So basically, there was a lot of iteration on the game design. And that is kind of the focus of the studio. Our whole goal is to optimize for game design iterations.

4. Developer Tooling and Software Architecture

Short description:

We rely on open source software like Kubernetes, Corsius, and Pixie for game design and networking. We also develop our own tools, such as Play for matchmaking and Synthesis A V for audio-video communication. Our engineering teams provide flexibility in team selection and mid-game changes. In terms of software architecture, we use a server native architecture for multiplayer games. Clients send user input to the server, where logic is applied to update the game state. The updated state is then sent back to all clients for synchronization.

And we do this to sort of three main areas, those are developer tooling, software architecture and content authoring. So let's look at each of them in a little more depth.

So developer tooling. First of all, I would be remiss to not mention some of the awesome open source software that we rely on. There's obviously the regular stuff that every software company uses nowadays, like Kubernetes and stuff. But in terms of like the game design and the game side of it, these two tools, Corsius and Pixie, have been very helpful for us. So Corsius is multiplayer networking and Pixie is a graphics library that we use for rendering our games. So we do rely a lot on these third-party tools, but we also have been strategically making our own tools where we feel like we need the most flexibility. So for example, Play is a tool for matchmaking, lobbies, and you can see we do friends services as well. So this gives us a lot of flexibility in being able to match the right kids together so that everyone has a good time and no one feels left out and things like that. And we also built our own version of Zoom, essentially, the audio-video system, which we call Synthesis A V, and that is actually just this bar on the right here. So you can see as they're playing the game, they're also able to interact with their friends and their teammates and strategize about what they should do next and things like that. And building these things ourselves sort of gives the games a lot of flexibility in being able to decide what teams should go together and changing teams up midway through the game, things like that. So it's been really helpful that we have engineering teams to be able to build all this out and the games can... And they can support the games.

So that's the developer tooling part and now let's look at the software architecture. So essentially, in terms of at least the multiplayer architecture, we kind of go with a server native architecture, which is pretty common for games. And for those of you who don't know, I have a quick primer here, but basically you have all these clients that are connected to some server. And then when you get some input from the user through the keyboard or the mouse, the client... Basically the idea here is that the client is a very thin client so it's not doing too much logic. It's just sort of taking your input and sending it straight to the server. And then on the server you run these systems, which I will explain in a second. But basically it's like all the logic to actually update something. So for example, say you want to move the spaceship forward, then you would press like the up arrow key on your keyboard, and the client would just pass that onto the server. And then the server would actually move the spaceship and then also decide if it collided with something. So if the spaceship was right next to a planet or something, then it would do that collision, decide what happens to the planet and the spaceship and then sort of resolve that. And then that new state is then passed on to all of the clients so that everyone is back in sync and we can keep going. So this loop just keeps repeating over and over. And that's the whole idea with server authoritative networking. But there are a few cases where we don't want that, like for example, spaceship movement actually.

5. Client and Server Architecture

Short description:

When you press a key, it needs to go all the way to the server and come back, which is too slow for movement. In those cases, we use a client authoritative model to update the local state and show immediate movement. The new state is then sent to the server and passed along to all clients for synchronization. We try to keep it server authoritative to simplify the architecture. The game state is captured in one class called state, which holds everything and is synced across the server and clients. Spaceships have their own classes with data like position and velocity. Systems handle the update code on the server, resolving changes from the previous frame. On the client side, we have input handling using a switch case statement for keyboard inputs.

The issue here is that when you press a key, it needs to go all the way to the server and do something and then come back, and then only then you just kind of see that change in your screen. So that's way too slow, especially for something like movement. So in those cases, we actually do more client authoritative model, where when you have the input, we're updating the local state that the client has, and we're also like showing that. So it feels like it moves immediately. And then we send that new state to the server. And the server is kind of like, not as heavy here, because all it needs to do is then take that state and pass it along to all of the other clients so that everyone's back in sync. So we kind of use both modes. We only use the client authoritative mode when we need something to respond quickly. So as much as possible, we try to keep it server authoritative. And that actually helps us simplify the complexity of the architecture. And I'll show you how that works. So yeah, this is the only section with a little bit of code. So bear with me. The code is all just quite simple. I'm just there to explain that diagram that I showed you. So I'm just trying to show the game state here. So the cool thing about this architecture is that you have this one state that sort of captures everything about your game. So in this case, all the teams, all the players, planets, spaceships, every single thing that the game cares about is just in this one big class called state. And it's holding everything. And this just needs to be synced across the server and the clients. So inside this, if you look at the spaceships, for example, it's just more classes with more data. So in this case, it's all the things you would expect a spaceship to have. So we have position, velocity, the team it belongs to, et cetera. And the systems are kind of like the update code. So here we have a whole bunch of systems. And every frame, we basically run these systems to sort of resolve any changes that happen during the previous frame. So this is where all the logic in the server actually lives. And on the client side, we just have two things. Like I mentioned, we have input handling and I just put this code here to show how straightforward it is. This is literally like a switch case statement across all of your keyboard inputs.

6. Game Logic, Rendering, and Content Offering

Short description:

In this case, the client sends instructions to the server based on key inputs. The server handles game logic, such as building structures and resource management. On the client side, rendering and updating text are done through listeners. Adding new elements to the game, like meteors, only requires changes in three areas: adding the class to the game state, implementing the system, and rendering the element. This modular approach allows for quick iteration and flexibility. Synthesis games function as a platform with customizable content.

In this case, the numbers are the number of keys 1, 2, 3. And in each case, we just send some instruction to the server. So if they press 1, it builds an extractor. If they press 2, a base. And if they press 3, a mine. So this is all that the client needs to do. The rest of all of their code is like, can they build a base? They have enough resources to build a base. All of those things happen on the server. And then the other side of the client is the rendering. Basically, when you initialize the client, we run this render function for every object. And so we're setting up all the sprites, which are basically just images through the PNG here. And then we also set up these listeners, which is the pattern that Coliseus follows. So basically, when we set up the spaceship, we're listening to any changes in the action points. And then if there is any change, it would immediately trigger this function. And we would just change the text to reflect that new change. So it's very simple, at least logically, when you try to think about it.

So as an example, let's imagine we want to add meteors or something to this game, because you can't have a space game without meteors, right? So how would we do that? So we really need to only change code in three spots. The first one, we want to add the meteor class to the game state. And then we want to implement the meteor system. So this is where you would actually put in the code of, how does the meteor move, and what happens when it hits a planet, things like that. And then we want to add the renderMeteor function in the client code to actually render this meteor. So the images and the animation and stuff that goes with that. So you can see, it's very simple. And this is really what lets us be able to take elements of the game out and then put things in and stuff really quickly, because it's all just so modular. So that's software architecture. Now let's go to content offering. So the way the games are made at Synthesis, it's almost like a platform. And then you have all this content that can go on top. And that's what gives us a lot of flexibility. So we're able to make new maps, make new content, each week.

7. Content Pipeline Tools and Game Configuration

Short description:

Investing in content pipeline tools allows us to create fresh content every week. We use Google Sheets for map creation, providing flexibility to change various aspects of the map. Designers can work in Google Sheets and export the data into JSON for testing. The config schema sets up game settings and can be quickly instantiated with new data. This optimization allows us to create a wide variety of gameplay experiences and build the world's best team thinking games.

And so the kids have a fresh experience every week. And the way we're able to do that much content is by really investing in the content pipeline tools.

So here, for example, this is actually just Google Sheets. And this is what we use for making maps for Proxima. So you can see it's just a one big table. And we have all these sort of code snippets, I guess, that we use for specifying what should be on the map. And you see, there's a lot of flexibility here. We're able to change a lot of the things about the map.

And so the great part here is the person designing these maps doesn't need to know any of the code. They just sort of work in Google Sheets and then export it into a JSON, which is then put into the game. And then you're able to test the new map there. So we're able to churn out a lot of maps in the course of even a single day.

And then the other side of that is the config schema. So this is kind of all of the settings along with the map that sort of set up one game. So here, for example, this is for Proxima. You can see that we have this custom map field. And basically, whatever you made in that Google Sheet, you would just copy all of that JSON over here. And it would just instantiate your game with this new data. So it's very quick to test. It's very quick to instantiate a game, even in actual production as well. And on this side, I have the config schema for another game called Constellation. And here, we provide a lot more flexibility of things you can change. So for example, the time that you have to place HQs or the steel depth or the number of steels. So this really changes the game significantly by changing these numbers. So we're able to get a lot more gameplay out of a single game.

Yeah, so bottom line of all this is we're doing all this to optimize for game design iterations. And the reason we wanna do that is because we wanna build the world's best team thinking games. And the reason we wanna do that is because we wanna build a generation of super collaborators. So that's what we do here at Synthesis. Thank you so much. You can learn more by going to Synthesis.com. My name is Vivek Vidyasagran and you can find me here on Twitter, RX. Yeah, thank you.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
JS GameDev Summit 2022JS GameDev Summit 2022
33 min
Building Fun Experiments with WebXR & Babylon.js
Top Content
During this session, we’ll see a couple of demos of what you can do using WebXR, with Babylon.js. From VR audio experiments, to casual gaming in VR on an arcade machine up to more serious usage to create new ways of collaboration using either AR or VR, you should have a pretty good understanding of what you can do today.
Check the article as well to see the full content including code samples: article. 

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
JSNation 2023JSNation 2023
116 min
Make a Game With PlayCanvas in 2 Hours
Featured WorkshopFree
In this workshop, we’ll build a game using the PlayCanvas WebGL engine from start to finish. From development to publishing, we’ll cover the most crucial features such as scripting, UI creation and much more.
Table of the content:- Introduction- Intro to PlayCanvas- What we will be building- Adding a character model and animation- Making the character move with scripts- 'Fake' running- Adding obstacles- Detecting collisions- Adding a score counter- Game over and restarting- Wrap up!- Questions
Workshop levelFamiliarity with game engines and game development aspects is recommended, but not required.
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
JS GameDev Summit 2022JS GameDev Summit 2022
121 min
PlayCanvas End-to-End : the quick version
Top Content
WorkshopFree
In this workshop, we’ll build a complete game using the PlayCanvas engine while learning the best practices for project management. From development to publishing, we’ll cover the most crucial features such as asset management, scripting, audio, debugging, and much more.
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)