Building Team Thinking Games At Synthesis

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.

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.

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.

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.

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.

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.

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.