3+ Uses of React at a Game Studio

♪♪ ♪♪ Wonderful. Thank you very much, Kathleen. Welcome to everyone. Thanks for joining here. It's going to be an interesting day, definitely, so I'll start with a quick introduction, again.

I am Hendrik. I do live here in this city, so very pleasure to give a talk here. I make mostly mobile games, and I do that in C++ or C Sharp using Unity, but as I said, I've always been very, very curious about the web ever since the very first times I started working. And I did work for some very cool companies down there on exciting projects with really smart people. So, some good times, but nowadays I work at Playpack Games, which is a new studio here in Berlin. Well, we're based here, but we actually work from anywhere, and there you see my wonderful team from all over the world. Our mission statement is to make cross-platform games with a strong, meaningful social element in there.

Right. So, a quick disclaimer, maybe. I'm quite new to React. If you're looking for a deep dive or technical things, there are much better talks for that at this conference, I'm sure of it. I'm going to present three case studies, and all of these are real, but I did change some of the names and the graphics, because that is from freelance times, and also to make it more illustrative.

Right, can I start with a quick show of hands? Who of you has ever made any form of game? Wonderful. Who has ever used Unity to do that? That's still quite a lot. Awesome. Very, very cool. I mean, this is the game's track, so I shouldn't be that surprised, but it's great to see. So, let's make a game. Let's make it single player. Why? Multiplayer is really, really, really hard. So, single player is much easier. Let's ship it on mobile and let's make it casual free to play, because that's what my studio does.

Game development, as it turned out, hasn't changed that much since the 90s, if we're honest. So, you sit at a computer, you have some source code, you have some assets, you have tools and editors to work with those. You pour them into a big box, and then out comes a package, which is like an executable, and that runs on some other person's computer.

Still pretty much the same thing. If you built nowadays to an Android device or an iOS device, in the end, you're still building a package, right? And as you see, at no point does the cloud or any form of servers come into play here.

Game developers are really specialized, right? They're front-end people who are really good at making things look great, feel great, performance, making games fun. But a lot of them are actually not very knowledgeable about the wider web world out there.

All right, let's set off, make a game, it takes a while, and then after three to six months, you have a game. Wonderful, maybe you made it in Unity, you ship it to mobile platforms, it is there, it's on device, right, it's single player, everything looks great. But it is not 1999 anymore, and people do have expectations. So, for example, when a player switches their phone, as people do, like every year, some of them, they expect to keep their saved games and not put them on a floppy disk. So we have to store them somewhere in the cloud. Right?

Another thing, people expect customer support, right? Customer support should be able to, within the game, directly give feedback or give rewards back to players. Right. Well, how do we start with that? Let's start with putting the player progress inside a database, right? How hard can that be? The progress is a single JSON document, it lives on the device. So instead of just having it on the device, we put it in a key value store, something like Firebase works really well. Big companies have their own solutions, right? There's an SDK for it. So we don't actually have to do any backend stuff.

Right. When the game loads, we load it, right? Whenever we do any changes, we write it back to the database. Works quite well. Cool. You notice something here. We can remotely change player progress now, right? Because we can mess around with the game state on the database. So let's do that and solve the customer service problem, right? OK, the case here is the player contacts us, the game misbehaved in some way, you know, something went wrong, and we want to reward them some currency or some items or something like that, right? And we want to write a small message in there. Now the customer service people should not like do manual entries in the database. So we should have a tool for this. What tools should we build? In what language? It should be usable by non-developers. Hmm, time to learn some React, right?

Case one, a customer service tool. You build a small React app, it talks to the database, right? Again, like Firebase, there is an SDK, you don't have to learn anything really hard, right? As a good pattern here, probably for stuff like this, don't write directly to the database and change the state, have the player confirm it, because it feels much, much nicer, right, as part of the customer service conversation. You can see here, the tool on the left schedules a command in the database. The device reads the command, applies it, and writes it back when it's consumed. Right, and then that is what this tool looks like, right? This should all feel very familiar to you guys, some material UI with some text boxes and maybe some custom editors, because you want to have these items in there and have some pickers and stuff.

And at the bottom, there's a big button which writes it all to the database, and that's cool. So you host that somewhere, you protect it with OAuth or something, you know, protect it, and then hand it over to customer service and you're done. No developers needed ever again.

Well, right, how does the React tool actually know which items are in the game or which resources? Moreover, can we visualize the progress of a player in the tool somehow to the customer service people using it? And who takes care of updating this data when the game gets new content?

So let's take a step back. Let's go back to game development, right? In production, we are making our game and games are simulations, you know, more or less, right? And that usually means a more or less complex system, right? And complex systems are hard to reason about. And getting the difficulty right is really, really crucial. I mean, that's the game designers job to make sure that the game is fun because it has the right amount of difficulty.

So what is the main tool that game designers use? Yes, it's Microsoft Excel, because you know, that is a great tool, actually for visualizing big amounts of data content numbers. You have formulas in there, but when it comes to running simulations, it's actually very limited, right? What if you want to introduce randomness, or things over time, or you have feedback loops in there?

So again, why not write a small React app, right? You isolate this complex core logic. You basically make it a mini game. You have some sliders and all of that, right? And you build that together with your designer. It's very fast to iterate because you do it stand alone, completely independent from the rest of the game. When you're happy with it, you transfer all of that back to the game.

But you have the same problem here. Where is all that content managed, right? Where does that live? Hmm. So why not go all in, right, and build a content management system? I mean, after all, if I look at the sponsors, this is something that React seems to be quite popular with, right? So let's take all of these spreadsheets, all of this content, and move it into some form of content management system. Right. What should we use? Well, question number one, what database should we use? I personally really like a Git-like workflow. This is something we're used very much to in Game Studios, to have some form of version control there. So like branches, tag versions. It should be easy to set up locally, maybe usable offline. I don't know. I like to work on the train. Git for data is a really interesting problem. If you know more about this, like databases that have a Git-like workflow, talk to me, because I'm really curious about it. But in the end, what we went with is just having every database entry as a single JSON file. Right? So this is very easy to read by external tools, your engine or your react tools. It's very easy to diff in Git. People are very used to that. And it supports references quite well, right? If you think about it a bit.

And then, moreover, if you have like a database schema, you can generate like custom editors based on that schema. Right? So you know that certain entry inside of the schema is a string with certain validations. Then you render a text field and apply these validations to that. Right. This is very much inspired by Rails. I know it's been a while, but that was one of the first things I got exposed with the web and I found very fascinating. Right.

Moreover, if you want to go really deep, you can really write custom editors. It's fun in React, I find. Right? And you have stuff like drop down fields out of the box. You can tell the writer that writes these dialogues that their text is running a little bit long. And maybe you have inline spell checking and all of that. And that leads me to a very important point, because you guys take a lot of things for granted. That we don't really have in the game dev world. Right?

Think about what your users take for granted. And users, in my case, is the rest of my team who have to work with this CMS, right? Link based navigation. You don't have that in Unity. You don't have that in Excel. Right? Validations, hard to really, you know, you have to put in some work, undo and redo, spell checking, that's just a browser plugin away. And moreover, browser tabs are amazing. Right? You can have multiple views on the same data. And doing that in Unity, for example, becomes really complicated.

Moreover, the things you take for granted as engineers, and I assume there are some engineers here, right? Monorepos are a game changer. In game dev, usually you have to deal with, I mean, at best sub modules, maybe distributed repos, maybe someone home-brewed a Package Manager. Right? It's all a lot more complicated. We're not used to having source code access for everything. Unity's closed source. A lot of things are opaque source. So you can kind of guess or maybe find an old version. And moreover, if you have it in some monorepo, you can just click navigate to any part in the source code.

That's amazing. We're not used to that. Iteration times. If you ever worked with Unity, you know it takes a few seconds. In C++, you might talk about minutes until you get your build on device. Whereas with stuff like ES build and browser reloads, you can get down below a second. That's just amazing.

Hot module reload is an absolute game changer. Being able to do changes to the code base while the game is running and see the changes immediately reflected, even on device is absolutely amazing. We don't have that in the games world usually.

Moreover, I know browsers get a lot of flak for being not standards compliant. But in general, they are surprisingly reliable as cross-platform deployment tools. You have web sockets. They're a really, really powerful tool to talk from client to server and just set up things any way you want. And in general, I would say that the tooling is very, very mature. You can really tell that a lot of big tech companies invested a lot of time and money to make sure that debuggers and profilers are really good.

Well, why do I talk about all of this in this past way? Well, actually, remember this game I mentioned at the beginning, right? So here it is, running inside of the content management system in the browser. And the cases one and two are like this admin link here and the customers playground tool there on the right. Again, these happened in other companies, but it is such a common use case that this happened again in this project.

So yes, we built a whole game in TypeScript and React, right? The runtime is in TypeScript. The editor is built with React on top of the content management system. There's a little 3D world. There's hours of gameplay. There's multiplayer hopefully coming quite soon, right, powered by Node.js and WebSockets, and all of this is deployed to iOS and Android devices, right? Because there is more React, right? You can just use React Native and ship out things to iOS and Android, right? Open source is amazing. You get CI pipelines as a solved problem, right? You don't have to set up your own Jenkins to make builds and deal with signing and all of that. A lot of people have solved these problems. And third-party SDK support is quite good, right?

Moreover, and I find that really fascinating, we do use React Pixie to render the in-game UI. It's, I think, the most experimental part of this tech stack, but also one that had amazing benefits when it came to being able to iterate and make changes to UI in a running game, move things around and work with the rest of the team there. Again, hot module reload is amazing.

Right. This would be a bad talk if I said that everything is amazing, right? And this is what you should do. Some caveats here. If you want to build a AAA first person shooter, I'm not sure this is the way you should be going, right? Native engines have very, very good performance, have graphic stacks that you will not be able to match easily on your own. Moreover, a lot of the things you saw there, require custom tooling. This is not something you can easily pick off the shelf.

I want to point out the learning curve here. Again, I'm quite new to React, right? So, coming from game dev, this is actually quite a change. Like React with hooks, you really have to wrap your mind around that to make sure you, you know, get into that way of working. Maybe it's all very normal to you right now. I'm just saying that onboarding and also hiring are quite interesting problems when you're, like, a little bit out there. And that is this question here, right? How big is that overlap between the web world and the games world? Not just in the technical sense, but also in the people sense. And, I mean, this track does give me a lot of hope, but it's a little bit of an open question.

To summarize, you can absolutely ship a game made with web tech to devices. But even if you just build tools, you can already learn a lot and it can help make your games a lot better. Open source is absolutely amazing, right? The things that are out there that you can just piece together. I mean, Pixie.js deserves a huge shout out. It's an amazing engine. It's very fast. Community is great. Codebase is very, very readable. Right. I do think game development can learn a lot from the web. Right. Ultimately, the hope is that this leads to making games faster, and I do think faster game development in the end leads to better games, and that is what, you know, our industry is, in the end, all about.

And that's it. Thank you guys very much. Thank you. Thank you.

Thank you. Thank you very much, Hendrik. What a nice presentation. I would like to invite you here on the chair because we have some questions from the audience.

Wonderful. Yeah. So let's go with the first one. I was also wondering why not using Git instead of Adibi for game entities and their properties, and data amount is surely not overwhelming. Right. So it is actually Git, right? All of these files are in source control exactly for that reason. But, you know, that still means stuff is file-level. It's not a transaction-based database, for example, right? But, yes, in the end, the question is absolutely justified. And yes, it is Git for the database, yeah.

Great. There is another question coming from an anonymous user. Did you look at Go. to check out the great... Of course, I did look at Go. It is a very cool engine, and they did make a lot of changes in there. We did look at it in the end for what we were trying to achieve. It made sense to go with our own tech stack there. And I was wondering about the learning curve there, because it's a different language, right? As far as I... Go. is definitely a learning curve. One thing I did not mention is that, coming from a C-sharp background, switching to TypeScript I found actually quite easy. It's the same team at Microsoft that built these two engines, and you can see that they transferred a lot of ideas. So I found it very smooth to transition over into TypeScript. Just give me one second, because there are so many... While I'm going through the questions, I also have a question on my own. And I was wondering more about the, you're mentioning form validation.

And I was wondering, what have you used for that? Well, we wrote that ourselves. I was looking at JSON schema, and there's a bunch of things around in that way. In the end, nothing really fit the use case, so we wrote that ourselves. So strings with regexes and references then have to look up whether certain files, like database entries exist.

Okay. There's another question. What would SCAD be a simulation of? I'm not sure what SCAD is. I don't know that. If someone from the audience? Well, all right. I mean, that was... All right, so fair enough. Not all games are hardcore simulations, but a lot of computer games are simulations, in particular single-player games. I should have made that more clear.

Okay. There's another interesting, like server state management learnings. If you have any, like event streaming cores, small F or open CRUD. So yeah, large apps. Do you have any learnings from this perspective, like server to state management solution? Can you specify that? I'm not a web expert, so I don't know all of the terms. Like using, for example, event sourcing, CQRC and nest.js. Maybe if someone is in the audience here, you can go talk with Patrick afterwards. Yeah, talk to me afterwards. That's the thing. The web ecosystem is so big, it's impossible to keep an overview of all the cool things out there. So in the end, we went with the stuff that worked when we pieced it together.

There's another question, have you tried bridging any native code you already had to the browser using WebAssembly? WebAssembly, I have used mostly as a user. It is surprisingly good for our deployment. It's actually not necessary, and I don't mind writing my game code in TypeScript. So I have everything in one code base. It's very easy to interoperate. Thank you.

And there is another one, do you have tools to create in the in-game UI in React, or like built-in tools? So that is actually a really big open topic. I talk a lot with our UI and UX designer about this, and that is something we want to address because these tools don't exist. So we're looking at maybe taking an existing UI tool and writing an exporter that will export to ReactPixie or maybe doing some tooling ourselves there. But it's a really interesting open question.

Yes, just a follow-up question, because I was also wondering because you were mentioning about creating your own tools internally. Have you ever thought about open sourcing them, or is there anything open sourced at all or what's the future? I mean, I do wish and hope that we can open source a lot of these things. Game development, as you notice, is not very affine to open sourcing. I think it's mostly historical, but also it's the pace of game development that you often don't have the time and resources to be able to maintain an open source project on the side.

There is another question, how do you handle the backend for heavy load online shooter or MOBA game? That's a really hard question. Again, maybe this might not be the right tech stack for that. If you want a heavy shooter, if you run that over web sockets, you might run into problems, you may want something that can actually run native on your device and then make use of UDP. There are solutions for that, but maybe that's not the right tech for that. Is there any possibility to just estimate some parts on the client side? What do you mean, estimate? Like, to see the future on the client side before getting... Oh yeah, yeah, no, no, you absolutely have to do that, right? With web sockets, you're talking about latencies in the dozens to hundreds of milliseconds, so, you need to work a little bit to hide the latency. Ok, so that's why you were saying coming soon, the multiplayer part, right? I mean, also making multiplayer games is really hard. Ok... There is another question. Can you use assets purchases from Unity Asset Store in your web-based games? Yes, you can, yes. I mean, you have to work a little bit, but there are stuff that can, like, take OBJ files maybe, or FBX files and turn them into mesh data that you can upload as vertex buffers. I mean, that sounds a little bit out there, but for game developers, that's actually very, very common. That's something we do every day, so that's fine. I do have another question on my own, and you're mentioning also React Native. I'm a huge fan of React Native, and you're saying about React Pixie, or what was the process for moving from React to React Native, or what you had to do to make this happen? Right. You mean, in the end, shipping the whole thing? Yes. Right. So, the current deployment process is to have the game running as a web game, and then wrapping that inside of a web view, inside of a React Native application. I gotcha. And then bridging through into the Native calls. Okay, so like a hybrid. It's a hybrid app.

Okay. There is another question as a follow-up to React Native. Are you using other tools apart from React Native for state management or API connections? So, I know you guys know much more about this, but I'm okay to do like Axios HTTP calls, and that's pretty much my limit. So I did want to look into this whole, like GraphQL and the way you can like do modern APIs, but that's a little bit out of my depth. So for the moment, no, it's actually just React and you know, doing calls.

Yeah, it really depends because nowadays people are not betting on GraphQL anyway. So it's, yeah, I think you, you choose the right stack though. Maybe you can also give up React query, try it with Axios and also maybe Prisma. They're also sponsoring us. And we do have time for one more question, I believe.

And this is does PIXI work in React Native? That was actually my question as well. Right. And if yes, how performant it is? Right. So old school PIXI did, I think version four or so was supported to run into React Native. The guys at Expo. Yeah, they did that and like Evan Bacon had a talk about deploying tons of games. And it looked amazing. I gave that a try. And then with PIXI 5 or 6, it just didn't work properly anymore. So I wanted to take a look at that. But then in the end, you have the browser WebView as a compatibility layer in there. And to me that seems much more trustworthy than shimming some OpenGL calls into some native stack that I don't control as well. Okay. Yeah. Yeah, I think as far as I know, he also built some games using Expo 3js. Yeah, and he ported quite a lot of web packages to React Native, which is really... It's really amazing. But for our case, this did not really work. Also, we do want to be able to do like completely platform-agnostic deployment. Right.

So if we want to make a web game, it should also just work as a web game. All right. And I think it is the last question. Just to summarize everything, what do you think are the learnings from a web developer perspective if they are coming or if they would like to go to game development, what do you think are their... Right. Or what there is to learn, basically. Right. I mean, there's for sure, there's a lot to learn. I think like the pace and the mindset in games are quite different. But it's still, I mean, it's very fun. They are both, I think, very fun communities to hang around in. I mean, you see a conference like this and then you see games conferences. And there's a very similar vibe of just people wanting to build cool stuff. So I would say if you're looking for that, take the plunge, right, go in, make games.

Yeah, thank you very much. With that I think, yeah, people can find you on the Q&A, Discussion Rooms for the remote audience, yeah, thank you very much, Hendrik. And it was a pleasure to have you here on the stage. Wonderful very much. Thank you very much, guys. I just give you a huge round of applause, Hendrik.