Web Native Game Development

The 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. Erik Dubbelboer https://x.com/erikdubbelboer is a Principal Engineer at Poki https://poki.com/ 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. His 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, Erik 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 tradeoffs 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. Joe 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. Please click here to see the transcript of this episode. http://softwareengineeringdaily.com/wp-content/uploads/2026/05/SED1934-Erik-Dubbelboer.txt Sponsorship inquiries: [email protected] https://cms.megaphone.fm/organizations/619b680e-d813-11ea-9750-e7ecac406436/podcasts/e60108fe-e328-11ea-b2b6-1348249f900a/episodes/3913370a-bc44-11ed-ace6-8b1f96d82bba/[email protected] The post Web Native Game Development https://softwareengineeringdaily.com/podcasts/web-native-game-development/ appeared first on Software Engineering Daily https://softwareengineeringdaily.com.

• 0:00Speaker 00

  The 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 Doubleboer is a principal engineer at Poki, 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:44Speaker 00

  His 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. Joe got a start in software development by creating mods and running servers for Gary's mod.

• 1:27Speaker 00

  Endgame development remains his favorite way to experience and explore new technologies and concepts.

• 1:45Speaker 01

  Welcome 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 Poki and a developer of web-based games. Eric, welcome to the show.

• 1:56Speaker 02

  Thank you.

• 1:57Speaker 01

  Thanks for joining me all the way from the other side of the world at 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 Poki?

• 2:07Speaker 02

  Oh yeah, that starts a long time ago, actually. When I was sixteen, something like that, I played a lot of games, of course, on desktop. I actually never played flash games or stuff like that. And 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, the first, not the second. And that had an API to write bots for it.

• 2:49Speaker 02

  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++. Not 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 kinda helps. Cause my logic was so flawed that the bots would behave in unexpected ways, which actually made them interesting.

• 3:24Speaker 01

  Emerging behaviors for incompetence. Amazing.

• 3:27Speaker 02

  Yeah, 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 that. And I was, wow, great. So I started studying software engineering in high school, in university. And for a long while, I didn't do anything with games anymore. I still remember the, okay, I did, 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 like really software engineering university. And I still remember thinking like, oh, I'm finally gonna meet all these people who are also

• 4:11Speaker 02

  software developers interested in building games. We're gonna make stuff together. And I remember being so disappointed that first day because all the people I met, they couldn't do anything. Like I was building an engine and they didn't even know what a pointer was yet. So 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 Poki, 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 a visit to their office, super nice office.

• 4:57Speaker 02

  And they explained what they do. Well, I didn't know web games that well, but it all sounded very interesting. So I entered in a couple of other interviews, but then I was like, yeah, this is what I'm gonna 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 2 a lot. And in Starcraft 2, 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. Let's make like a full game.

• 5:43Speaker 02

  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 gonna 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,

• 6:25Speaker 02

  you're not gonna start any matches and everyone will just like, okay, there's no player in this game.

• 6:30Speaker 01

  Yeah.

• 6:30Speaker 02

  So I don't think that game would have ever worked. Don't think we're ever gonna release it. But it was again, something like, oh, game development. So Poki was interesting to me.

• 6:39Speaker 01

  Yeah.

• 6:40Speaker 02

  I started as backend engineer at Poki, but then I also launched two games on Poki, 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 Poki, not just from, hey, I work at Poki, but also, hey, I have a game.

• 7:00Speaker 01

  I'm a developer for Poki, 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 3 map editor. It was like such an influential part of like my teens. And yeah, the StarCraft one is similarly. And yeah, we'll get into talking about Poki, especially your games, 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 Poki 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 Newgrounds and Animating, and then post Apple and the iPhone and the famous Steve Jobs kills Flash and all that.

• 7:45Speaker 01

  It feels like Flash games died a death and languished for a while. But I get the impression, actually part very driven by Poki 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?

• 8:03Speaker 02

  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 Poki 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.

• 8:46Speaker 02

  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. A 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. It were the dark ages for web games, I would say. But now there's definitely a renaissance where every big game engine,

• 9:31Speaker 02

  I guess, except for Unreal, has a web export functionality. Unreal used to have web export, but they removed it at some point because it was too difficult to keep on par with their normal rendering pipelines. And I think WebAssembly 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 WebGL for a long time, WebGL2. Now we have WebGPU, making even more possible. So there's still a bright future, I think.

• 10:15Speaker 01

  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. I'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?

• 10:34Speaker 02

  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, well, it's quite optimized, but it's not perfect. Besides, it's JavaScript, it is text, it's a big text code. And 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.

• 11:17Speaker 02

  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. And 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.

• 12:02Speaker 02

  And then you have these ways to say like, hey, I have this WebAssembly function exposed that to JavaScript, so you can call it from JavaScript and the other way around where you can...

• 12:13Speaker 01

  FFI kind of situation.

• 12:15Speaker 02

  Yeah, yeah, exactly. And you have the other way around from WebAssembly, you can call JavaScript functions. The 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 M-Scripton is the example of that, C++ to WebAssembly. And most engines and platforms and things are all using that to generate WebAssembly.

• 12:52Speaker 01

  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, it's just for a limited instruction set. So like, I guess.

• 13:05Speaker 02

  No, actually, 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.

• 13:30Speaker 01

  Okay.

• 13:31Speaker 02

  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. And 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. It's being used in other environments as well, where you want, let's say, a safe execution environment. You want something where you know for sure, if I execute this wasn't blob, it's not gonna 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.

• 14:15Speaker 01

  Interesting. So like if you're developing a web game in C++ or WebScript and you also need to make like the canvas container for your Wasm bit.

• 14:24Speaker 02

  Yeah.

• 14:25Speaker 01

  Yep. Okay.

• 14:26Speaker 02

  Yeah.

• 14:26Speaker 01

  Cool. Interesting. Okay, great. So that all makes sense. WebGL, where does that come in? So I guess my intuition of WebGL is that's.

• 14:34Speaker 02

  Web GL.

• 14:35Speaker 01

  WebGL, sorry, GPL, because there's also Web GPU.

• 14:38Speaker 02

  Web GPU.

• 14:38Speaker 01

  Yeah, cool. Web GPL, so that's the new license. But yeah, so that's exposing like ability to utilize graphics hardware in the browser, right?

• 14:47Speaker 02

  Yeah, exactly. So WebGL is basically, the API looks very similar to OpenGL.

• 14:52Speaker 01

  Great.

• 14:53Speaker 02

  If you're familiar with that API. So it's basically a wrapper around OpenGL, I would say. Allows you to draw like 3D primitives to a canvas. And there's a lot of wrappers around that to draw whole like FBX models or other things, whole engines, of course. But it's the same as on desktop when you would just have an engine that uses WebGL as backend to draw. And then WebGL, so WebGL is comparable to OpenGL. Yeah, Web GPU now, which is comparable to Vulkan or.

• 15:27Speaker 01

  That was my next question. Okay, great. Cool.

• 15:29Speaker 02

  Yeah. So on desktops, you got all these new graphics APIs. I don't know, Windows, I guess you have like the latest version on DirectX, which is probably different than the previous ones. On Mac, you have.

• 15:41Speaker 01

  Metal.

• 15:42Speaker 02

  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 Web GPU, 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. So it's more asynchronous where WebGL, you're really like, you're waiting for the result. You're waiting for something to draw. With Web GPU, you can batch a whole bunch of commands and then say, okay,

• 16:23Speaker 02

  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 much more complex API to use. But of course, on the web, yeah, you have engines taking care of that.

• 16:39Speaker 01

  Yes, sure.

• 16:40Speaker 02

  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. They usually have to quite change their pipeline to make use of this.

• 16:55Speaker 01

  Right, okay, cool. So the picture I now have is there's a lot of these new APIs that have moved us 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?

• 17:18Speaker 02

  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 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 on mobile. You also have really specific web engines these days. PlayCanvas is, I think, a really good one. PlayCanvas is like Unity, but then native for the web. So PlayCanvas, you write everything in JavaScript.

• 18:00Speaker 02

  Like, if you're doing Unity, you write your code in C# and it uses WebAssembly. With PlayCanvas, 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.

• 18:24Speaker 01

  Yeah.

• 18:24Speaker 02

  Cockos, which is like this Chinese engine. You, of course, have Construct, which is also a web native engine, also great. You have Pixies, which is more like a framework than an engine, so.

• 18:37Speaker 01

  That's somewhat in the Phaser ballpark, right?

• 18:40Speaker 02

  Yeah, so Phaser uses Pixies. Phaser still a little bit layer on top of it. Phaser also web native engine, so you write in JavaScript. Pixies 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 Unity, which is like. Point and click and everything in there and you have Pixie S, which is do it yourself, but it helps you a lot.

• 19:12Speaker 01

  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?

• 19:20Speaker 02

  Yeah, yeah, exactly. That's very similar, yeah.

• 19:22Speaker 01

  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 of the other editors as well. So I guess that 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 codebase? Or like, is the web platform, like, where does it sit equal to those others? Am I always gonna have trade-offs, some things I can't include in the web version?

• 19:48Speaker 02

  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, you 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. Unity also, since a couple of versions ago, they have experimental web GPU export as well. So before Unity export would be WebGL, but now that the web GPU is more stable in browsers,

• 20:28Speaker 02

  since only a couple of months, I would say. And they also have this web GPU 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 on 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. I think particle effects are with web GPU are also a lot faster.

• 21:10Speaker 02

  So Unity is actually still actively working on their web export because they also see the, the web ecosystem is growing. So they see the importance of this, so they're. They're working on this.

• 21:22Speaker 01

  Nice.

• 21:23Speaker 02

  Getting better and better.

• 21:24Speaker 01

  So I mean, you've raised a really good point, which I guess is is a perpetual fear with using anything new on the web, which is obviously support for browsers and how far you can go. 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. What is the support status of a lot of voice podcasts? You mentioned WebGPU is very new, but like the if we're using, combining with MScript into Wasm and I'm using WebGL, am I more or less covered?

• 21:47Speaker 02

  Yeah, yeah, WebGL is covered or 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 a factor 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, also 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 they don't support that.

• 22:28Speaker 02

  So they're actually working on like a minimal version of WebGPU that can even run on super old phones by just tapping into all their APIs.

• 22:37Speaker 01

  Oh, cool.

• 22:38Speaker 02

  And like 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 like 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. I'm not sure if on Safari mobile, it's enabled by default already. Like I can quickly on Poki, we do actually.

• 23:10Speaker 01

  You have the website.

• 23:10Speaker 02

  You have like a support graph and yeah. So on Poki, on the public, on developers.poki.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 like the web is of course always a platform in development. There's always new features being introduced and some browsers are faster with it. Others are a bit slower, but it's understandable.

• 23:48Speaker 02

  And I expect in, I don't know, maybe the end of this year, WebGPU is so big that almost everyone has it.

• 23:56Speaker 01

  Amazing. Okay, so we brought up Poki again. We should probably at this point explain for our poor audience, what is Poki?

• 24:03Speaker 02

  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. Jujujue in France and Games Freak. I don't even know those games before my time. So 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, WebGL.

• 24:44Speaker 02

  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. So 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?

• 25:21Speaker 01

  Very cool. So you mentioned it's a portal to web games. So I'm a game developer and I'm looking for like a distribution channel for my game. So like that's where Poki comes in. Is that correct?

• 25:29Speaker 02

  Yeah, exactly. So at Poki, we don't make games ourselves. We have game developers who want to publish their games on the web and we do that. We're very curated, by the way, so not everyone can just publish a game on Poki. We have the players on the other side and we have the advertisers on the third side. So we are like a platform play where they all come together. Where we make sure that the players get the right games, the games are interesting. We do the ad, 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.

• 26:10Speaker 01

  Amazing. So I guess what does that process look like for the game developer? Because like Poki games are hosted on your site, right? It's not like a redirect through to the user's site. So I guess there's some kind of integrate, like they give you the binary, etc.

• 26:23Speaker 02

  So we have a platform called Poki 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'll also see your invoices on there. You can upload new versions.

• 27:04Speaker 02

  You will, well, it's this whole environment, management environment, like Steam or the App Store.

• 27:10Speaker 01

  Amazing. So I guess one question, how about the setup? So do you support multiplayer games, like networked multiplayer games?

• 27:15Speaker 02

  Yeah, we do. We have a whole bunch of multiplayer games as well. We don't host the backend 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 dev ops on those games.

• 27:31Speaker 01

  Cool. Awesome. Yeah, I guess that brings me to your games. So you have some web-based games and some of those are on Poki. And Silly Skies, as you mentioned, I was absolutely captured by this game. Yeah, can you tell us about Silly Skies?

• 27:44Speaker 02

  Yeah, sure. It's a game I built. I want to say at Poki, 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 would be unfair competition. I have insights into what happens in Poki. But it is good for some people at Poki to have games on Poki. Like, when I first joined Poki, I didn't have a game on Poki, only later I built a game. And I've always been working on the developer side of our platform, on Poki for developers. And launching a game on Poki myself made me look at our platform from a whole different angle. So immediately, I started seeing things like, "Oh, when I do this, then that's weird, okay."

• 28:29Speaker 02

  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 Poki 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, especially when I'm afraid of breaking a game to test something, I just use my own game. Like, I don't care if my game breaks, that's fine. Then no developer is gonna 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.

• 29:13Speaker 02

  And I have two games on Poki, 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. There was a web game like this exists?" No. Then I decided, "Okay, I can build a better version." I would never want to copy a game exactly and put it on our platform, so I had a lot of ideas to make it different. And that's how this game came. I built it together with the same friend. I started that Steam game way back in the past. I'm a developer. I'm not good with graphics and things like that. Like, if I would design the game, it would look awful.

• 29:54Speaker 02

  Maybe I could do something with AI these days, but no, I wouldn't want to do that. So the friend I have is not a game developer. He like works in a completely different field, but he is a good designer.

• 30:09Speaker 01

  Amazing.

• 30:09Speaker 02

  So he actually made all the graphics and together we think a lot about like game mechanics, testing it, what should we build? And then I basically do the programming, he does the graphics. That's how it comes together.

• 30:21Speaker 01

  Very cool. Yeah, I think part of the reason it captured me, I guess this goes to the web platform as a whole, but certainly to Poki. It's like a really good example of a game, I think, that like works regardless of like which platform the person is on. So I guess part of the challenge, or what I would assume is part of the challenge of being a web game, especially on Poki is like, you know, they could be on desktop, they could be on a tablet, they could be on phone, they could be on whatever. I think that's must be a really tough challenge as a game developer. And I guess that's where your reports come in. Like, do you talk to developers that come to the platform about like what audience they should be prioritized? Do you try and get them to address all audiences? Or do you assume like mobile first or this kind of thing?

• 30:55Speaker 02

  I would say these days we're doing mobile first because our mobile player base has been growing a lot, but a game needs to work in any platform. So when you upload a game to Poki, we have a team that does a lot of QA on your games. It's not like Steam or the app stores where they do like a quick check and it's all fine and you can publish it. No, we'll actually have a team QA your game and send you really like also gameplay suggestions, other things. They will test it on desktop, they will test it on mobile. It needs to work on both. And as a game developer also, I know that's a pain. Like as game developers, I can see other developers as well. You're developing on a desktop machine, so you're testing it in a desktop. And on desktop, the Poki player is like a screen, like a rectangle, and you build your UI around that.

• 31:40Speaker 02

  And at some point, okay, now I have to test it on mobile. And that's so different because mobile, it's always best for web games to build your game in portrait modes. Like on mobile app, a lot of games are landscape as well, but on mobile browser, on web, the user switch between games a lot more and

• 32:02Speaker 01

  Right, and then having to rotate.

• 32:03Speaker 02

  They do that in, yeah, so you don't want to constantly rotate their phones.

• 32:07Speaker 01

  Fascinating.

• 32:08Speaker 02

  So we always say your game needs to work on portrait mode. And that's very different because that's all of a sudden like a very different aspect resolution. Very different. Instead of your screen being white, it's it's long all of a sudden. So your UI needs to be completely different for mobile. Then you have all these different phones with like notches on top and whatever. So you're placing UI elements there and then, oh crap, I cannot place UI there because then the iPhone notches in the way. And it's a pain in the ass, but it's rewarding when it works at some point. And this is also where game engines can help a lot. The various game engines offer pretty okay solutions to dynamically scale your UI based on the screen resolution.

• 32:53Speaker 02

  And Poki also has different tools to help you with this. We have like an inspector tool where you can upload a version of your game and it has mobile testing capabilities as well. And it will put some like Poki also renders some elements on top of your game. So it will show you where those are rendered so you shouldn't place any UI there.

• 33:12Speaker 01

  Yeah, I'm really fascinated by that behavioral element about like you see players on web mobile changing a lot. It's also interesting because I feel like I've heard this portrait thing from, I think it was Brian Bucklew of Case of Cud, was developing mobile Case of Cud to be portrait mode. But that's on an app, so it's probably not for the same reasons. But he was also going portrait mode for an app game, which is, yeah, really interesting. Are there any other like weird behaviors? I guess at the platform scale, you see things that most game devs don't see.

• 33:42Speaker 02

  Yeah, one interesting thing I read a couple of days ago. Netflix is even going portrait mode for their videos. Like they see like portrait is winning overall on mobile in mobile land. So of course, like Instagram, YouTube Shorts, everything is portraits. I remember when I was younger, I would take pictures on my phone in landscape mode. And then I met my wife who likes to Instagram a lot and she was like, no, always take pictures in portrait mode. So all of a sudden, everyone always takes pictures in portrait mode these days. Portrait mode is completely winning on the web, on mobile, on the web as well.

• 34:22Speaker 01

  I think I have heard that about Netflix as well. I've heard people talk about how like all shots now are composed. So like people are like the bit that will end up in the portrait of the clip. It's meant to be showed in widescreen. That's wild.

• 34:32Speaker 02

  Yeah, yeah, I know. So games also definitely, they should be portrait.

• 34:38Speaker 02

  But games as apps, of course, is slightly different. There's a slight difference between, not necessarily between the player base of players who play games on mobile app versus mobile web. But there's definitely a difference in how they play. Where on web, like on Poki, if you don't like the game, you exit it and you click on another game immediately. You have no incentive to try the game for a while, to stay there. While if you download a game as an app, you kind of already put in some effort there to pick it out, to download it. So those players, if they have to switch to landscape mode, okay, sure, they're, they're kind of, they have some incentive to try the game for a while at least, because they spent all this time on downloading it.

• 35:23Speaker 02

  That's a big difference.

• 35:24Speaker 01

  Does that affect your game design in terms of, I guess you don't have time to tutorialize and it needs to be straight in?

• 35:29Speaker 02

  Definitely, definitely. So where on Steam, or like any other game platform except for the web, I always see a lot of games have onboarding with text, for example. They, you start the game the first time and it will show you all these pop-ups with text on what is what and whatever. On web, that doesn't work. If players need to read anything, or too much, like a little bit reading is fine, but if they read too much, they don't want to do that, they click on to the next game. On web, you really have to capture that audience within the first couple of seconds, basically. If those first couple of seconds are not interesting enough, then we'll just click on another game. They have no incentive to try out your game. They're similar to like how you browse videos on Instagram and TikTok, you just, if it's

• 36:14Speaker 02

  not interesting immediately, you swipe to the next. And that's very similar for web games, where you just go to the next game, because it's so easy. So the onboarding for web games needs to be really strong, where if it's a tutorial, it shouldn't feel like a tutorial. It should feel like you're just playing the game and it introduces the mechanics one by one on a, in a natural way. You shouldn't have any text to read. It shouldn't start very slow and then pick up speed or something. No, it should immediately show you like... I would say a vampire survivor type of game.

• 36:48Speaker 01

  Right.

• 36:48Speaker 02

  If I would be making that for the web, I would start the player off with like the most crazy abilities for a couple of seconds or something like 10 seconds to really show what is possible. And then take them all away and let them regain it quickly or something like slowly. So you you want to pique that interest immediately.

• 37:07Speaker 01

  Amazing. And I guess that how easy people move on from your game must also be affecting people's like development cycles, right? Like they're not going to be developed. No one's doing like a seven year long development for a web game, right? Like, and I got, I have an intuition that web games are smaller and tend to be, you know, very level based, like a procedurally generated anyway, or just like score based. But the studios you work with, do they, are they doing like really short turnarounds on games?

• 37:31Speaker 02

  Yeah, yeah, definitely. It's also possible to make games with with a longer content and have players come back. Of course, you have save games on the web. So those games definitely exist. A lot of them are made for mobile app first and are then ported to web. But the really like web native development studios, they they try to do shorter periods. They test a lot. It's very easy to update your games on the web. People don't have to like download a new version or something that that's automatic. You test a lot where later you add more content if you see a lot of players are interested, but you you need to get that beginning.

• 38:11Speaker 02

  Those first couple of minutes of gameplay, basically, that's what you need to like really get down. And if you have that down, then you can add more content.

• 38:18Speaker 01

  Yeah. So you mentioned testing. So I know that, you know, obviously, a lot of Poki's developer platform is focused on monetization and discovery. What other areas of like the game dev problem space you think of addressing in your developer platform?

• 38:30Speaker 02

  So one of the more interesting features we have is called the Poki playtesting. I think that's quite unique, where because we have this lot of like crazy amount of players that just click on games and want to play everything, we can match. Okay, when you request playtests in Pokéball Developers, you get 10, 20 players, random players. We just show your game to them. We don't show it to other players, we just show it to a couple of players. When they choose to play your game, the web actually has APIs that allows us to capture a video of them playing your game. The Canvas has like a Capture Stream API, which allows you to capture a video. So we have this Poképlaytesting tool.

• 39:13Speaker 02

  If you upload a new version of your game, you request playtest videos. Within a couple of minutes, you'll have 10 videos of people actually playing your game.

• 39:22Speaker 01

  Amazing.

• 39:23Speaker 02

  So within minutes. So if you have like a day of developing your game, you can upload, I don't know, multiple versions a day. You request those playtest videos, you see those players playing your game. Based on that, you make more changes, upload a new version again, again, request those videos. It allows for a very nice, fast development cycle, where those players getting to play your game are also your actual audience. Like, I know from a game developer, when I was building my games, I also had my wife, I had my friends, everyone test my games. But that's, one, that's not my target audience. Two, they're my friends and my wife, so they're nice to me and they will not say if it sucks.

• 40:05Speaker 02

  Three, the first time you let them play the game, they may not understand everything, they do the onboarding. The second time you let them play the game, they already know what to expect. They have done that onboarding. You cannot test the onboarding a second time on the same person. And that onboarding is the most important part of web games. So testing like with your friends and family, it's fun, but it's not that useful. Well, playtesting, yeah, actual players on Poké get to play your game and you get the videos of them playing it. That's actually useful feedback. And you'll get 10 videos. I can tell you, a bunch of those videos are going to be players who, 10-second videos. They see your game and they're like, nope, and click on something else.

• 40:50Speaker 02

  Which is also very honest feedback. It's less useful. There's also, of course, always a couple where the players actually try to play your game. And then you get a video with like their keyboard inputs, their mouse inputs. It's very useful.

• 41:02Speaker 01

  That's cool.

• 41:02Speaker 02

  I've seen playtests of games where, the most fun example I always think of is a video where, a game where it was like a side scrolling bicycle game. So you were a character on a bicycle, 2D side scrolling, and you had to press the spacebar to flip, to go the other direction. And the game was showing this spacebar button with the word space on it. And you could clearly see some players who had no idea what a spacebar was. Like, maybe a younger audience has no idea what it's, so you see them clicking, you see them pressing all kinds of keys, they see them trying everything except for pressing that spacebar.

• 41:43Speaker 02

  So that's very useful input that you, feedback that you would never get out of other playtests. You would also not get that out of, I don't know, like Steam games, mobile games on App Store. They always have these services where you hire professional playtesters to playtest your game. Yet they know what a spacebar is. They are not your target audience. And here it was very clear, like, okay, you need to actually have like a clear picture of a keyboard with the spacebar highlighted. For the player to understand what a spacebar is.

• 42:14Speaker 01

  That's fascinating. It really reminds me of, I'm pretty sure it was an academic study, but maybe it wasn't, but there was a great study that looked into the use of color in UI. Because like so many games, like you'll have like, you know, RPGs, you'll have your three colored bars, right? Like red for health, blue for mana, green for agility, or like stamina or whatever. And it looked into like how widely understood that color scheme actually was. Cause everyone does, like, it's so widespread and it's never explained. They just assume the players know. And then the minute you're outside of like that audience, actually completely indecipherable. Yeah, that's really cool. Well, one of the things I've always thought about Poki and why I was excited to speak to you is like, I feel like a lot of our audience are game dev curious and want to do more, but haven't found a way to like make the economic jump yet.

• 42:56Speaker 01

  And I think the web and Poki, in my impression, like thinking about my future where I make the escape and I do like game dev, like Poki is something I'm looking at really strongly. Do you think that's true? And do you think that's a path that you've seen others follow?

• 43:07Speaker 02

  So the nice thing about having your games on Poki is that you don't have to do any player acquisition, any marketing of that kind. Poki does that for you. So I know a lot of developers who are building games for Steam. They're building games for the app stores. If you don't do any marketing, you're not going to get any players. That's it. Like those platforms, they don't promote your game. You need to do that yourself on Steam. If you have like almost no wishlist, Steam is also not going to promote your games. The app stores especially, there's, I don't know, like more than 100 games being published each day in the app stores. It's crazy. So on Poki, we have all these players.

• 43:50Speaker 02

  If you look on Poki on a game page, you see a lot of other games there as well. So we're promoting other games next to the game the players play. So we are doing all this user acquisition for you. We don't really have game developers that do their own player acquisition, that spend money on marketing for their games. Poki is doing that for you. So we have a whole bunch of game developers who are just indie game developers by themselves, who focus purely on building their game. So they don't even know how marketing on TikTok works or something. They just focus on building their game. And that's the nice thing as a game developer. That's kind of, I myself, what I want. Like, I don't want to spend any time on how I'm going to get users to play my game.

• 44:34Speaker 02

  I just want to build my game. And I think that also for Poki results in better games. Because if you really want to build an app or Steam game that's successful, at least half of your time is not going to be spent game developing. It's going to be spent getting players, spending money on that even. On Poki, 100% of your time is spent on building the game, improving the game, which is so much nicer.

• 44:57Speaker 01

  Yeah, that is the absolute dream. I feel like, I mean, I have two thoughts and it's like personally, the idea of like, oh, I need to get good at TikTok, has like actually been a barrier to like investing in making a game. And then you see these really tragic stories like every day on the game dev reddits, where it's like, I developed a game for seven years and launched it and no one played it, right? So like getting past that fear, yeah, I think that's a really good benefit of the platform. So you mentioned, obviously in Playtest it shows it to a limited selection of players. You know, if I just go to Poki, there's no sign in or anything. So there's like no ability to target like what kind of audience you're looking for to playtest? I imagine that would be.

• 45:31Speaker 02

  Oh, no, no, there is, because actually these days we do have an account system that was launched earlier, end of last year.

• 45:39Speaker 01

  I'm missing out.

• 45:40Speaker 02

  It's the web, so we can place cookies, we can see what users are interested in. And we of course have like, games are categorized, you have categories. So if you're saying my game is a tower defense game, yeah, then we're gonna show that game with other tower defense games to an audience that's probably interested in tower defense games.

• 46:02Speaker 01

  Cool. I've now found the account creation. It's nice how unobtrusive it is. I like that your menu is like literally the same as like a game icon on the page. It's very, in this world of like, you get pop-ups to sign up and sign in and things. I really appreciate that. That's very cool.

• 46:17Speaker 02

  I think you do get a pop-up after you played for one hour and you are not signed in. Because it is the web where games are using cookies, local storage, indexDB for save games.

• 46:29Speaker 01

  Yeah.

• 46:30Speaker 02

  But if you play a lot, you can lose those cookies. You can lose, like Safari is very famous for just dropping cookies because they have like a smart anti-tracking algorithm thing. And our games are actually running in an iframe on a separate domain on the site. So the games are not in the same iframe, on the same domain as the site itself to protect cookies and things like that. But then Safari sometimes, especially on mobile, is like, okay, I'm gonna delete those cookies.

• 47:00Speaker 01

  Oh, that's so upsetting.

• 47:01Speaker 02

  We've even seen cases where we were inspecting a game on Safari mobile and Safari would delete the local storage entry while we were playing. That's how crazy this gets. So, yeah. So after an hour of playing, we usually prompt players now to like, hey, if you create an account, then you can your save games go into the cloud. So we have this system where games can just store stuff into local storage. And then once in a while, we'll just read local storage and store it on our server.

• 47:33Speaker 01

  Very similar to just cloud saving.

• 47:35Speaker 02

  Yeah, exactly. Except you don't have to implement any specific API. It's just you're using local storage.

• 47:42Speaker 01

  Oh, it's always on the client. You're just grabbing it. Cool.

• 47:45Speaker 02

  Yeah, yeah, exactly.

• 47:46Speaker 01

  So we've spoken about where the web platforms come from, some things we're looking at at Poki. What still sucks? As a game developer, what do you wish you could do on the web that you can't currently? Or at Poki, what kind of problems are you thinking of tackling?

• 47:58Speaker 02

  So one of the things I'm working on right now is to work on a project with a little bit more social sharing. I think the sharing APIs on web are still not great. There's like a navigator share function, I think, but you just give it like, hey, here's the data you should share. And then the user can pick the app and do whatever. And I cannot, for example, from the web, say, push this to the Instagram app to share something. Like I can only open this native share menu. So the sharing API is still very limited on the web. Besides that, I think I don't really have anything where I think, oh, that should be better.

• 48:40Speaker 02

  One of the more important things with web game is the file size, of course. We've seen that for every extra megabytes a person has to download to play your game, you're gonna lose like a couple percent of players. It just takes too long, they click away. So you want the user in game, or at least in the menu, with the least amount of bytes downloaded. Or the really web native engines like PlayCanvas, that's quite easy. They have these easy options to just delay loading whatever is needed later. So if you have a level based game, you're gonna load level one and then have the player in level one. And all those other levels you can load later, you don't need them right now.

• 49:25Speaker 02

  Unity, for example, they compile, so they use WebAssembly. WebAssembly, great, but one of the downsides is, is one big blob. You have to download the whole blob to start executing it. So Unity games always are rather big.

• 49:42Speaker 02

  Unity assets as well, like Unity, most games are built before Unity introduced addressables. Addressables is a Unity system where you can dynamically load assets. And if you use addressables in the app or in Steam, it's not that useful. Like those are, you already have those files on your disk, so loading them is quick. On the web is very useful, because then you can delay the loading of models and levels and whatever. But most developers don't build their game with addressables, and adding that later is very difficult. So most Unity games, they load everything that the game needs into memory, and only then the game is playable.

• 50:25Speaker 02

  So the conversion to play, as we call it, for Unity games is always lower. I would really wish Unity would address that and build a more interesting or an easier system to dynamically load assets. But of course, that's very difficult for them to tack that on now. They have that addressable system, but it's very difficult to start using that when you already started building your game.

• 50:49Speaker 01

  Yeah, and I guess how do you, from the web assembly side, I guess you'd be building like multiple binaries and then doing linking and...

• 50:55Speaker 02

  Yeah, so the web assembly, they would probably still do one big blob, but then all the assets or the levels, those are not in web assembly. Those are just data and that you can load later. The same issue is with Godot, they also built like one big blob that you download to play the game. But there, I know the web lead, Adam Scott, not the actor, other Adam Scott.

• 51:16Speaker 01

  Yep.

• 51:16Speaker 02

  He is actually...

• 51:17Speaker 01

  I know Adam Scott, he's great.

• 51:18Speaker 02

  Yeah, he's working now on a system for Godot where you can easily say like, hey, load this later. That works really well, that's gonna make Godot a lot more interesting. Because of course, these big engines, they offer so many features that you can build crazy games in there. But yeah, the file size of those, those games is always an issue right now. And if you could load those assets more easily dynamically, that would be great.

• 51:43Speaker 01

  That's fast going back to the conversation we started with about engine choice and such right now. That's a really good lens of looking for that. Like going for one that, as you say, is like web first gets you some neat benefits for understanding like, you know, actual behaviour on the web platform. Very useful. Well, that brings us to the end of our time. Eric, thank you so much. This has been lovely. Great to learn about the state of the platform and what you're working on. Thank you for joining us.

• 52:05Speaker 02

  You're welcome. Thank you.