Web Native Game Development

0:00The web has quietly become one of the most capable platforms for game development. Advances in WebAssembly, WebGL, and WebGPU have given developers tools that rival native desktop performance, while game engines like Unity and Godot have added robust web export pipelines. However, building games for the browser comes with its own set of constraints, including file size, browser compatibility, and the need to quickly capture and maintain the player's attention. Eric Dabalbor is a principal engineer at Pokey, which is a web games platform serving over 100 million monthly users. He's also a game developer himself, with titles including Silly Skies and Village Builder.

0:44His unusual position building developer tools that power the platform while also shipping games on it gives him a rare perspective on what it actually takes to succeed in web game development. In this episode, Eric joins Joe Nash to discuss the history of web games from the Flash era to today's renaissance, how WebAssembly and WebGPU have transformed what is possible in the browser, the trade-offs between different game engines for web publishing, and more. Joe Nash is a developer, educator, and award-winning community builder who has worked at companies including GitHub, Twilio, Unity, and PayPal.

1:22Joe got his start in software development by creating mods and running servers for Garry's Mod, and game development remains his favorite way to experience and explore new technologies and concepts.

1:45Welcome to Software Engineering Daily. I'm your host for today's episode, Joe Nash, and today I'm joined by Eric Doubleboer, Principal Engineer at Pokey and a developer of web-based games. Eric, welcome to the show. Thank you. Thanks for joining me all the way from the other side of the world. A dreadful time. Really appreciate you being here. So I want to start by asking you, what was your journey into game development? How did you wind up at Pokey? Oh, yeah, that starts a long time ago, actually. When I was 16, something like that, I played a lot of games, of course, on desktop. I actually never played Flash games or stuff like that.

2:19And I was very interested in, okay, how are games being built? So when I was very young, I already started looking into, okay, that's what I want to learn later. And I had a good friend of my parents who was a software developer, not in games. He was working on something completely different, but he knew how to write software. So he could explain me a little bit like, oh, this is how you do it. One of my favorite games back then was Half-Life at first, not the second. And that had an API to write bots for it. So you could fight against, in multiplayer, fight against bots. And that's actually the first, my introduction to programming was writing bots for Half-Life in C++.

3:00Not the easiest thing at all, but it was very fun. I learned a lot about what makes it fun and just how programming works, how all ecosystem works. I was not very good at programming, which kind of helps because my logic was so flawed that the bots would behave in unexpected ways, which actually made them interesting. Emergent behaviors for incompetence. Amazing. Yeah. I remember uploading that, I think it was DLL back then, uploading it to, I don't know, a file sharing website. And it got like a couple thousand downloads of people who wanted to play it. And it was, wow, great. So I started studying software engineering in high school, in university.

3:45And for a long while, I didn't do anything with games anymore. I still remember when I was younger, I still did a little bit with games. I got to a point where I started working on a game engine, still C++ with DirectX on Windows. And then I had my first day of really software engineering university. And I still remember thinking, I'm finally going to meet all these people who are also software developers interested in building games. We're going to make stuff together. I remember being so disappointed that first day because all the people I met, they couldn't do anything. I was building an engine and they didn't even know what a pointer was yet.

4:25So I think that slowed me down. And all those years studying, I didn't do anything with games. I had a couple of my own companies for a while. And then about seven years ago, my own company stopped. And I started looking for a job. And the first company to approach me was actually Pokey. Like, hey, you're, well, I was living in Kuala Lumpur, but I was moving back to Amsterdam. You're coming to Amsterdam. You want to work here. So I went to them for visits to their office, super nice office. And they explained what they do. Well, I didn't know web games that well, but it all sounded very interesting.

5:03So I did a couple of other interviews, but then I was like, yeah, this is what I'm going to do. Oh, I forgot to say, before that, I played a lot of games, especially with a good friend of mine. And we played StarCraft II a lot. And in StarCraft II, you can make mods. And those mods are not really programming, but you're working in an editor and you do a little bit of scripting stuff. And there was a lot of custom games that we really liked. So we started building our own custom game. And that was our first step into building a game. And we couldn't do enough. So we actually thought, okay, let's not build this in StarCraft 2 as a mod.

5:41Let's make it like a full game. So I actually learned how to use Unreal Engine and started building a game in Unreal Engine. It's still on Steam as somewhere in the future to be released. Probably not going to happen, but we made a Steam page and all. We had something working, but it was, I think, in the end, the game was interesting, but it was multiplayer and multiplayer. Like multiplayer only, which is very difficult on Steam. like if you launch a multiplayer game where players play against each other you either have a big audience on launch and you have enough players to do the matchmaking or you don't have enough players to do the matchmaking and you can have like a thousand players a day but if they all try matchmaking at different times during the day you're not going to start any matches and everyone will just like okay there's no player in this game yeah so i don't think that game would have ever worked don't think we're ever going to release it but it was again something like game development so pokey was interesting to me yeah i started as back-end engineer at pokey but then i also launched two games on pokey because i with that friend as well we stopped the steam game we started focusing on web games also to as they say dog food your own products like it's good to look at pokey not just from hey i work at pokey but also hey i have a game i'm a developer yeah that's so cool yeah always very excited to hear about people who come into it via blizzard rts editing i loved the warcraft remap editor it was like such an influential part of like my teens and yeah the starcraft one similarly and yeah we'll get into talking about poké especially your game especially silly skies silly skies absolutely like captured me within like seconds i was like this is a beautiful design i love this game but i guess first let's set the scene because we're here to talk about web-based games that's where poké is that's where all your games at the steam one are and you mentioned flash earlier and i think that's a really good place to start this conversation for me my experience with the web as a platform really did start with flash i was really into new grounds and animating and then post apple and the iphone and the famous steve jobs kills flash and all that it feels like flash games died a death and languished for a while but i get the impression actually part very driven by pokey and being proximate to your office but like just in general that web games are having a bit of a renaissance again and the web platform has finally caught up to where flash was is that something that rings true for you yeah definitely definitely so like i said i didn't use to play those flash games i don't know how i missed that whole thing i was building websites as well back then i guess but somehow i never played flash games i just played like games on cd roms and stuff but i know the whole story of course like i remember one of the first things when i joined pokey is that i actually got a history lesson from one of the founders like hey this is what happened in web games in the past which was super nice so i know flash games were really big i still sometimes talk to developers who are saying like there's nothing exactly like flash was back then they would like to have that era back i don't think that's a thing that is coming back even if you would reintroduce flash now just the audience has different expectations it's different but yeah flash games was super big back then and when iPhone killed Flash, it basically died on the whole web at some point.

9:00A lot of those games got lost. There's a couple of companies that do transpiling Flash games to web games. So there's a whole bunch that have been recovered. But I think there's still a lot of experience that's lost with Flash. And a lot of developers from that era just stopped. They couldn't make those Flash games anymore. They started doing different things so that they also didn't come back. There were the dark ages for web games, I would say. But now there's definitely a renaissance where every big game engine, I guess, except for Unreal, has a web export functionality. Unreal used to have web exports, but they removed it at some point because it was too difficult to keep on par with their normal rendering pipelines.

9:44And I think WebAssembly and And of course, OpenGL, they really brought back, especially WebAssembly brought back the ability to easily run those games on web. Almost all the engines, Unity, Godot, others, they all use MScript to compile their stuff to WebAssembly. And yeah, that is great. Now we have WebGBL for a long time, WebGL 2. Now we have WebGPU making even more possible. So there's still a bright future, I think. Yeah. So you mentioned a lot of APIs there. So I think I've done a bit of phaser dev, mostly actually for an Electron game, but I've dabbled a little bit. But I feel like I'm not on top of WASM and WebGL.

10:26I'm aware of the principles of WebAssembly and what space it's playing in. But I'd love to learn more. Can you tell us about what WebAssembly is and how it helps with this problem? Yeah, sure. So normally on the web, you would run JavaScript. Just plain JavaScript. Your browser has like a JavaScript engine. It converts the JavaScript to bytecode and bytecode to an intermediate layer and that intermediate layer to machine code that actually gets executed. But JavaScript, you can do all kinds of weird stuff. So the runtime basically constantly has to update what that bytecode looks like. And it's not quite optimized, but it's not perfect.

11:04Besides, it's JavaScript. It is text. There's some big text codes. A lot of games are like the game engines. They have a lot of code in them. So you want something that runs a bit faster and is smaller. And that's where WebAssembly comes in. So WebAssembly is basically immediately that intermediate layer. So you don't go from a textual language to an intermediate layer. And that intermediate layer gets compiled to machine instructions. You just immediately have that intermediate layer. So WebAssembly is already almost machine instructions. There's very little translation needed to actual machine code.

11:41And WebAssembly, because of that, it can be very fast. WebAssembly has like a static buffer array, like a heap memory area. It has very limited amount of instructions. So no super complicated stuff. But it runs very fast, faster than if you would write the same thing in JavaScript usually. And then you have these ways to say like, hey, I have this WebAssembly function, expose that to JavaScript. So you can call it from JavaScript and the other way around where you can... FFI kind of situation. Yeah, yeah, exactly. And you have the other way around from WebAssembly, you can call JavaScript functions.

12:20The nice thing about WebAssembly is that you can take like C++, for example, code, and you can compile it to WebAssembly. So where a normal compiler would compile it to machine instructions, you now have WebAssembly as a backend for your compiler where it outputs WebAssembly. And mScripten is the example of that C++ to WebAssembly. And most engines and platforms and things are all using that to generate WebAssembly. Okay, awesome. So this is probably a really silly question, but I'm trying to get all the pieces together in my head. So when you're writing, so like WebAssembly, I guess, is using the same like browser platform APIs, just for a limited instruction set.

13:04So like, I guess WebAssembly has no access to browser APIs. So WebAssembly is really just like you have these functions you define that JavaScript can call and it can call these JavaScript functions. That's it. So if from WebAssembly you need to create a DOM node, it will always go into a JavaScript function. that JavaScript function calls the DOM API and goes back into WebAssembly. Okay. There has been a lot of talks about different specs for WebAssembly to be able to call DOM APIs and browser APIs directly. But that was never implemented so far. I think one of the reasons for this is that WebAssembly, it's called WebAssembly, but it's not just being used on the web.

13:50It's being used in other environments as well, where you want a safe execution environment. You want something where you know for sure, if I execute this wasn't blob, it's not going to do anything weird. Because WebAssembly cannot. The only connection to the outside is what you define for it. So it's very safe to execute that on a machine if you know exactly, if you don't give it like, I don't know, open, delete, those kinds of commands. Interesting. so like if you're developing a web game in c++ or web script and you also need to make like the canvas container for your wasm bit yeah yep okay yeah cool interesting okay great so that all makes sense web gpl where does that come in so i guess my intuition of web gpl is that's web gl web gl sorry gpl because there's also web gpu web gpu yeah cool web gpl so that's the new license Yeah, so that's exposing ability to utilize graphics hardware in the browser, right?

14:47Yeah, exactly. So WebGL is basically, the API looks very similar to OpenGL. Great. If you're familiar with that API. So it's basically a wrapper around OpenGL, I would say. Allows you to draw 3D primitives to a canvas. And there's a lot of wrappers around that to draw whole FBX models or other things, for engines, of course. But it's the same as on desktop when you would have an engine that uses WebGL as backend to draw. And then WebGL. So WebGL is comparable to OpenGL. You have WebGPU now, which is comparable to Vulkan. I'll give you my next question. Okay, great, cool. Yeah, so on desktops, you've got all these new graphics APIs.

15:33On Windows, I guess you have the latest version on DirectX, which is probably different than the previous ones. on Mac you have? Metal. Metal, yeah. They all, I think, use Vulkan in the backend then. So that's a new type of graphics API where in OpenGL, you're basically firing commands. You're saying like, hey, set this texture now, set this array of vertices and now draw this primitive using those vertices. And then it executes those in order and you have to wait for it. With WebGPU Vulkan, it's a bit different. You say like, okay, here is a texture, a vertex buffer, and now queue the rendering command with those.

16:13So it's more asynchronous where WebGL, you're waiting for the result. You're waiting for something to draw. With WebGPU, you can batch a whole bunch of commands and then say, okay, send this to the GPU to render. I don't want to wait for the result. I'm going to do other stuff. So it's a lot faster that way. You're spending a lot less time waiting, but also a much more complex API to use. But of course, on the web, yeah, you have engines taking care of that. Yes, for sure. But for the engines, it's also a bit complicated, I know, because it's such a different way of rendering where you're not waiting for stuff, you're batching all these things.

16:50They usually have to quite change their pipeline to make use of this. Right. Okay, cool. Every AI team eventually hits the same wall. The models are solid, the infra is solid, but the data coming in is hours old, because the pipeline is batch when it should be streaming and nobody's had time to fix it. That's not a modeling problem. That's a pipeline problem. Estuary gives you CDC, batch, and streaming in one platform. 200 plus connectors, live in hours, not weeks. Your AI is only as good as your pipeline. estuary.dev In mobile application security, good enough is a risk. GuardSquare uses advanced, multi-layered code hardening techniques and automated runtime application self-protection and mobile application security testing, combined with real-time threat monitoring to deliver the highest level of mobile app security.

17:47Discover how GuardSquare brings all these together to provide mobile app security for your Android and iOS apps without compromise at www.guardsquare.com. If you're running Postgres in production, you've probably felt the moment analytical queries start fighting your transactional workload. Most teams end up adding a second database and all the pipeline complexity that comes with it. Tiger Data, creators of TimescaleDB, takes a different approach. We extend Postgres with hybrid, row, and columnar storage so one table handles both writes and analytical scans. Native compression cuts storage costs up to 95%.

18:22Continuous aggregates keep dashboards live without bash jobs. And it scales to petabytes without you re-architecting. Companies like Cloudflare, Octave Energy, Schneider, Axpo, and Floco run production workloads on Tiger Data today. No stale data, no second system to operate, just Postgres. Managed for you, ready for the workload you're building toward. Try it free at tigerdata.com. So the picture I now have is there's a lot of these new APIs that have moved just quite far from the old days of like trying to manually draw shapes on the canvas right or sorry that being basically all the capabilities you can have and you mentioned there are game engines which like compile to these platforms so we're starting to get in the tools what is the state of i guess for end game devs who aren't getting down at the low level like what is the state of tooling right now pretty good like unity has that's the most used game engine especially with indie devs of course they use it for like i think almost all mobile games are using unity maybe godot these days as well but unity and godot both they have good web exports been working on that for a long time for web you have a lot of different engines as well you have something like default which is also works very well on web also on desktop also mobile you also have really specific web engines these days.

19:37PlayConvass is, I think, a really good one. PlayConvass is like Unity, but then native for the web. So PlayConvass, you write everything in JavaScript. If you're doing Unity, you write your code in C Sharp and it uses WebAssembly. With PlayConvass, you're still writing it in JavaScript. So it doesn't compile to WebAssembly, it just uses JavaScript, which for web developers is a bit easier to follow, easier to understand. And it's a great engine with like a point and click editor and everything. You have a lot of engines, which is like this Chinese engine. You, of course, have Construct, which is also a web native engine, also great.

20:19You have Pixie AS, which is more like a framework than an engine. That's somewhat in the Phaser ballpark, right? Yeah, so Phaser uses Pixie AS. Phaser is still a little bit layer on top of it. Phaser also a web native engine, so you write in JavaScript. pixie as is more like a framework for developers who don't want like a whole engine they just want simple primitives like hey draw this image there draw that image there things like that so you have a whole spectrum here where on the one end you have a unity which is like point and click and everything in there and you have pixie as which is do it yourself but it helps you a lot cool yeah i guess that's the well i was gonna say in desktop development that's unity at that end is still there and then your other end is like sdl2 right that kind of yeah exactly that's very similar yeah awesome so you mentioned that unreal moved away from having a web export because they had trouble maintaining it and i imagine that struggle must be true the other editors as well so i guess like one question i had is like if i'm developing a game on unity and i want to publish it for desktop for mobile and web can i do that from one code base or like is the web platform like where does it sit equal to those others am i always going to have trade-offs and things i can't include in the web version as far as i know no like you can well there's definitely some things more difficult on web but most of the stuff you can just do on web like it's super easy in unity just they have a button to do a web export and then you can have a look to be honest i don't know exactly which features from the unity editor they don't support i don't use unity that often But I think most of it is there.

22:00Unity also, since a couple of versions ago, they have an experimental WebGPU export as well. So before, Unity export would be WebGL. But now that the WebGPU is more stable in browsers, since only a couple of months, I would say, they also have this WebGPU export. And that supports even more, I know, for example, skeletal mesh animations. on desktop they would be done on the gpu using compute shaders in webgl you don't have compute shaders you just have like rendering shaders but with web gpu you have compute shaders so they ported this to use web gpu like everyone web gpu they ported this to use compute shaders so skeletal mesh if you have a lot of animations it's a lot faster with web gpu there's other effects and things.

22:52I think particle effects with web GPU are also a lot faster. So Unity is actually still actively working on their web export because they also see the web ecosystem is growing. So they see the importance of this. So they're working on this, getting better and better. So, I mean, you just raised a really good point, which I guess is a perpetual fear with using anything new on the web, which is obviously support for browsers and how far you can go. So I guess if you're publishing for the web, part of what you're aiming for is like mass audience, right? That you want to get it out as far as you can.

23:24What is the support status of a lot of voice-backed minds? You mentioned WebGPU is very new, but like if we're using, compiling with mScript and to Wasm and I'm using WebGL, am I more or less covered? Yeah, yeah. WebGL is covered. Like even on very old Android phones, you can use WebGL. WebAssembly as well, that's covered. There's just some new instructions in WebAssembly around SIMs, so effector operations. that might not always be supported, but you can actually test for that. So you can have conditional code base there. And so WebAssembly also, I would say everywhere supported. Then WebGPU has been supported in Chrome for a while.

24:03Also on mobile, I know they're very actively working on this. So the problem with WebGPU is that you need your graphics driver to also support it. And a lot of old phones, they don't support that. So they're actually working on like a minimal version of web GPU that can even run on super old phones by just tapping into older APIs and not supporting the things that need these new drivers. So Chrome is really actively working on this. Safari, Apple has also been working on this, but the Safari version has been okay for the last half a year or something now with one of the latest iOS releases. And before that, it was still in beta.

24:47I'm not sure if on Safari Mobile it's enabled by default already. I can quickly, on Pokey, we do actually have a website. You have a support graph. On Pokey, on the public, on developers.pokey.com, we have something called the Player Device Report where you can see exactly what our audience supports. So there I can see, for example, WebGPU is supported by 68 % of our players. So I think there are still older phones that probably don't support it. I know Firefox is working on it, but it's still behind the flag, so it's not enabled by default. So it's coming. The web is, of course, always a platform in development.

25:27There's always new features being introduced and some browsers are faster with it. Others are a bit slower, but it's understandable. And I expect in, I don't know, maybe the end of this year, web GPU is so big that almost everyone has it. Amazing. Okay. Okay, so we bought a Poki again, which you probably at this point explained to our audience. What is Poki? Poki is the biggest web games platform. So Poki, under a different name, already existed during the Flash era. One of the co-founders of Poki had a couple of different sites, Chez Chez Chez in France and Games Freak. And I don't even know those games before my time.

26:09So different portals. And when Flash was dying, the founders of Poki, instead of what a lot of sites were doing, was switching to mobile. Instead, they didn't switch to mobile. They focused purely on HTML5 games. So games that don't use Flash but are written in JavaScript use Canvas, RedGL. And I think that really paid off where a lot of the other sites, they couldn't sustain. They just basically stopped existing. Poki managed to stay relevant. Of course, it was the dark ages of the web games. So there were not a lot of players looking for web games, even knowing that they still existed. So not a lot of players, but that has been coming back for the last years.

26:54So Poki is actually quite big now. We have 100 million monthly users. So that puts us in like the top, I don't know how many websites, 50 maybe. Very cool. So you mentioned it's a portal to web games. So I'm a game developer and I'm looking for a distribution channel for my game. So that's where Pokey comes in. Is that correct? Yeah, exactly. So at Pokey, we don't make games ourselves. We have game developers who want to publish the games on the web and we do that. We're very curated, by the way. So not everyone can just publish a game on Pokey. We have the players on the other side and we have the advertisers on the third side.

27:34So we're like a platform play where they all come together where we make sure that the players get the right games, the games that are interesting. We take care of all the advertising, make sure we have a good setup, good advertiser and everything, like blocking malicious stuff, but also making sure they pay a lot. And then we do a revenue share with the game developers. Amazing. So I guess what does that process look like for the game developer? Because it's like PokeGames hosted on your site, right? It's not like it relates to the user's site. So I guess there's some kind of integrate, like they give you the binary, etc.

28:09So we have a platform called Poke for Developers, which is our developer-facing platform. When you submit a game and we say like, okay, yeah, we're interested in that you get access to this platform. And you basically upload a zip file with an index.html in it and any other assets it needs or anything. But there needs to be an index.html in there. and we'll put the contents of that zip file on our CDN. And then that's basically how the game gets hosted. And we have this whole platform where you get all kinds of tools that we offer. If your game goes live, you'll get all kinds of insights. You also see your invoices on there.

28:49You can upload new versions. You will look, well, it's this whole environment, management environment, like Steam or the app stores. Amazing. So I guess one question I have about the setup. So do you support multiplayer games? like networked multiplayer games yeah we do we have a whole bunch of multiplayer games as well we don't host the back end for the multiplayer games we leave that up to the game developers which is usually also easier because if they push updates or if something is happening makes it easier for them to do devops on those games cool awesome yeah i guess that brings me to your games so you have some web-based games and some of those are on pokey and silly skies as you mentioned i I was absolutely captured by this game.

29:29Jek, you talk about Silly Skies. Yeah, sure. It's a game I built. I want to say at Poké, it's not always normal that employees make games. We don't want employees to compete with game developers on our platform, of course. That will be unfair competition. I have insights into what happens in Poké. But it is good for some people at Poké to have games on Poké. When I first joined Poké, I didn't have a game on Poké. Only later I built a game. And I've always been working on the developer side of our platform, on Poke for Developers. And launching a game on Poke myself made me look at our platform from a whole different angle.

30:10So immediately, I started seeing things like, oh, when I do this, then that's weird. Okay. And you start seeing these inefficiencies in the UI, things that you want to see but can't see. So it's very good to test your own product this way, which I think has been very beneficial. And on the other side, it's also very good to have this game on Pokey with a bunch of players. Like, of course, my games are not the biggest games. I also didn't want that, but you want to have some players. And when we need to test new features and when I, especially when I'm afraid of breaking a game to test something, I just use my own game.

30:48Like, I don't care if my game breaks. That's fine. Then no developer is going to get mad at us. I don't have to ask any developer for permissions. I can test stuff in my game and not be afraid to break it. So it's very useful to have. I have two games on Pokey, Village Builder and Silly Sky. Silly Sky, you like. It's not an original idea. I got the idea from an app game that I was playing in an airport somewhere. And I was like, oh, that's cool. Does a web game like this exist? No. Then I decided, okay, I can build a better version. I would never want to copy a game exactly and put it on a platform.