EPISODE 1934


[INTRODUCTION]


[0:00:01] ANNOUNCER: 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 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. 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 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 his start in software development by creating mods and running servers for Gary's Mod, and game development remains his favorite way to experience and explore new technologies and concepts.

[INTERVIEW]


[0:01:46] JN: Welcome to Software Engineering Daily. I'm your host for today's episode, Joe Nash. Today, I'm joined by Erik Dubbelboer, Principal Engineer at Poki and a developer of web- based games. Erik, welcome to the show.

[0:01:56] ED: Thank you.

[0:01:57] JN: Thanks for joining me all the way from the other side of the world at dreadful time. Really appreciate you being here. I want to start by asking you, what was your journey into game development? How did you wind up at Poki?

[0:02:08] ED: 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. I was very interested in, okay, how are games being built. When I was very young, I already started looking into, okay, that's what I want to learn later. 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. 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. That had an API to write bots for it, so you could fight against, in multiplayer fight against bots. 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 helps, because my logic was so flawed that the bots would behave in unexpected ways, which actually made them interesting.

[0:03:25] JN: Emergent behaviors for incompetence. Amazing.


[0:03:27] ED: Yeah. Yeah. I remember uploading that, I think it was DLL back then, uploading it to, I don't know, a file sharing website. It got a couple thousand downloads of people who wanted to play that. I was, "Wow, great." I started studying software engineering in high school, in university. 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. Then I had my first day of really software engineering university. I still remember thinking like, "Oh, 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. I think that slowed me down. All those years studying, I didn't do anything with games. I had a couple of my own companies for a while. Then about seven years ago, my own company stopped. I started looking for a job. The first company to approach me was actually Poki. Well, I was living in Kuala Lumpur, but I was moving back to Amsterdam. "You're coming to Amsterdam. You want to work here." I went to them for visits to their office. Super nice office. They explained what they do.
Well, I didn't know web games that well, but it all sounded very interesting. 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. We played StarCraft II a lot. In StarCraft II, you can make mods. Those mods are not really programming, which are working in an editor. You do a little bit of scripting stuff. There was a lot of custom games that we really like, so we started building our own custom game. That was our first step into building a game. We couldn't do enough, so we actually thought, okay, let's not build this in StarCraft II as a mod. Let's make it a full game. 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 only, which is very difficult on Steam. 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. You can have 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." I don't think that game would have ever worked. Don't think we're ever going to release it.

It was, again, something like, oh, game development. Poki was interesting to me. I started as backend engineer at Poki, but then I also launched two games on Poki 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 product. It's good to look at Poki. Not just from, hey, I work at Poki, but also, hey, I have a game developing.

[0:07:01] JN: Develop in 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 remap editor. It was such an influential part of my teens. Yeah, the Starcraft one, similarly. Yeah, we'll get into talking about Poki, and especially your games, especially Silly Skies. Silly Skies absolutely captured me within seconds. I was like, "This is a beautiful design. I love this game." 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. You mentioned Flash earlier. 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. I get the impression, actually part very driven by Poki and being proximate to your office. Just in general, that web games are having a bit of a renaissance again and the web platform is finally caught up to where Flash was. Is that something that rings true for you?

[0:08:03] ED: Yeah, definitely, definitely. 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. Somehow, I never played Flash games. I just played games on CD rooms and stuff. I know the whole story, of course. 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.

I know Flash games were really big. I still sometimes talk to developers who are saying, 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. Yeah, Flash games was super big back then. 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. There's a whole bunch that have been recovered. I think there's still a lot of experience that's lost with Flash.

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

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 for Unity, Godot, others, they all use MScript and to compile their stuff to WebAssembly. Yeah, that is great. Now we have WebGL for a long time, WebGL2. Now we have WebGPU making even more possible. There's still a bright future, I think.

[0:10:15] JN: Yeah, so you mentioned a lot of APIs there. I think I've done a bit of phaser dev, mostly actually for an electron game. 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. I'd love to know more. Can you tell us about what WebAssembly is and how it helps with this problem?

[0:10:34] ED: Yeah, sure. Normally on the web, you would run JavaScript. Just playing JavaScript. Your browser has 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. JavaScript, you can do all kinds of weird stuff. The runtime basically constantly has to update what that bytecode looks like. It's not quite optimized, but it's not perfect. Besides, it's JavaScript. This text, this big text code. A lot of games, like the game engines, they have a lot of code in them. You want something that runs a bit faster and is smaller. That's where WebAssembly comes in.

WebAssembly is basically, immediately that intermediate layer. You don't go from a textual language to an intermediate layer. That intermediate layer gets compiled to machine instructions. You just immediately have that intermediate layer. WebAssembly is already almost machine instructions. There's very little translation needed to actual machine code.
WebAssembly, because of that, it can be very fast. WebAssembly has a static buffer array, like a

heap memory, or area. It has very limited amount of instructions. No super complicated stuff. It runs very fast, faster than if you would write the same thing in JavaScript, usually. Then you have these ways to say like, hey, I have this WebAssembly function. Expose that to JavaScript. you can call it from JavaScript and the other way around where you can -

[0:12:13] JN: FFI situation.


[0:12:15] ED: Yeah. Yeah, yeah, exactly. You have the other way around from WebAssembly. You can call JavaScript functions. The nice thing about WebAssembly is that you can take C++, for example, code and you can compile it to WebAssembly. Where a normal compiler would compile it to machine instructions, you now have WebAssembly as a backend for your compiler where it outputs WebAssembly. Emscripten is the example of that C++ to WebAssembly. Most engines and platforms and things are all using that to generate WebAssembly.

[0:12:52] JN: Okay, awesome. This is probably a really silly question, but I'm trying to get all the pieces together in my head. WebAssembly, I guess, is using the same browser platform APIs. It just threw limited instructions there. I guess, and too much exposing canvas.

[0:13:06] ED: Not actually. WebAssembly has no access to browser APIs. 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. If from WebAssembly you need to create a DOM node, it will always go into a JavaScript function. The JavaScript function goes to DOM API and goes back into WebAssembly.

[0:13:31] JN: Okay.


[0:13:32] ED: There has been a lot of talks about different specs for WebAssembly to be able to call DOM APIs and browser APIs directly. That was never implemented so far. I think one of the reasons for this is that WebAssembly is called WebAssembly, but it's not just being used on the web. It'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 blocked, it's not going to do anything weird. Because WebAssembly cannot. The only connection to the

outside is what you define for it. It's very safe to execute that on a machine if you know exactly if you don't give it, I don't know, open, delete those kinds of commands.

[0:14:15] JN: Interesting. If you're developing a web game in C++ or Web Script, and you also need to make the canvas container for your Wasm, or something. Yup. Okay. Cool. Interesting. Okay, great. That'll make sense. WebGPL, where does that come in? I guess, my intuition of WebGPL is that's -

[0:14:34] ED: WebGL.


[0:14:35] JN: WebGL, sorry. GPL. Because there's also WebGPU.


[0:14:38] ED: WebGPU.


[0:14:39] JN: Yup. Cool. WebGPL is a new license. Yeah. That's exposing ability to utilize graphics hardware in the browser, right?

[0:14:47] ED: Yeah, exactly. Okay. WebGL is, basically, the API looks very similar to OpenGL.


[0:14:53] JN: Great.


[0:14:53] ED: If you're familiar with that API. It's basically a wrapper around OpenGL, or I would say, allows you to draw 3D primitives to a canvas. There's a lot of wrappers around that to draw whole FBX models, or other things, full engines, of course. It's the same as on desktop when you would just have an engine that uses WebGL as backend to draw. Then WebGL, so WebGL is comparable to OpenGL. You have WebGPU now, which is comparable to Vulkan, or -

[0:15:27] JN: That's going to be my next question. Okay. Great. Cool.


[0:15:30] ED: Yeah. On desktops, you've got all these new graphics APIs. I don't know, Windows. I guess, you have the latest version on DirectX, which is probably different than the previous ones. On Mac, you have -

[0:15:41] JN: Metal.


[0:15:42] ED: Metal. Yeah. I think you have Vulkan in the back end then. 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." 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 cue the rendering command with those, so 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. It's a lot faster that way. You're spending a lot less time waiting, but also much more complex API to use. Of course, on the web, you have engines taking care of that.

[0:16:40] JN: Yes. Sure.


[0:16:41] ED: 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.

[0:16:55] JN: Right. Okay, cool. 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 trying to manually draw shapes on the canvas, right? Or, sorry, that being basically, all the capabilities you can have. You mentioned there are game engines which 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? What is the state of tooling right now?

[0:17:19] ED: Pretty good. Unity has - that's the most used game engine, especially within the devs, of course. They use it for, I think, almost all mobile games are using Unity, maybe Godot these days as well. 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 works very well on web, also on desktop, also 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. PlayCanvas, you write everything in JavaScript. If you're doing Unity, you write your code in C-sharp, and it uses WebAssembly. With PlayCanvas, you're still writing it in JavaScript, so it doesn't compile to WebAssembly. Just uses JavaScript, which for web developers is a bit easier to follow, easier to understand. It's a great engine with a point-and- click editor and everything.

You have a lot of engines from code cause, which is like this Chinese engine. You, of course, have Construct, which is also a web native engine. Also, great. You have PixiJS, which is more like a framework than an engine.

[0:18:38] JN: That's somewhere in the phasable part, right?


[0:18:41] ED: Yeah. Phasor uses PixiJS. Phasor is still a little bit layer on top of it. Phasor, also a web native engine, so you're writing JavaScript. PixiJS is more like a framework for developers who don't want a whole engine. They just want simple primitives like, hey, draw this image there, draw that image there. Things like that. You have a whole spectrum here where on the one end, you have Unity, which is point-and-click and everything in there. You have PixiJS, which is do it yourself, but it helps you a lot.

[0:19:13] JN: Cool. Yeah, I guess that's the, well, I was going to say, and just not development. That's Unity. At that end, it's still there. Then your other end is SDL2, right? That makes it. Cool.

[0:19:21] ED: Yeah, exactly. That's very similar. Yeah.


[0:19:23] JN: Awesome. You mentioned that Unreal moved away from having a web export, because you had trouble maintaining it. I imagine that struggle must be true at the other end of this as well. 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 code base? Or is the web platform - 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?

[0:19:48] ED: As far as I know, no. Well, there's definitely some things more difficult on web, but most of the stuff you can just do on web. It's super easy. In Unity, just there's a button doing 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. I think most of it is there. Unity also, since a couple versions ago, they have an experimental web GPU export as well. Before Unity export would be WebGL. Now that the Web GPU 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 rendering shaders. With WebGPU, you have Compute Shaders. They ported this to use WebGPU like everyone. WebGPU, they imported this to use compute shaders. Skeletal mesh, if you have a lot of animations, it's a lot faster with WebGPU. There's other effects and things. I think particle effects are with WebGPU, they're also a lot faster.

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

[0:21:25] JN: 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. I guess, if you're publishing for the web, part of what you're aiming for is mass audience, right, that you want to get it out as far as you can. What is the support status of a lot of these APIs? You mentioned WebGPU is very new, but we're using, combining with Emscripten to Wasm, and I'm using WebGL, am I more or less covered?

[0:21:47] ED: Yeah, yeah. WebGL is covered 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 synths, or factor operations that might not always be supported, but you can actually test for that, so you can have a conditional code base there. 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. 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. They're actually working on a minimal version of WebGPU that can even run on super old phones by just stepping into older APIs and not supporting the things that need these new drivers. 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, say, half a year or something now with one of the latest iOS releases. Before that, it was still in beta. I'm not sure if on Safari mobile it's enabled by default already. I can quickly - on Poki, we do actually have the website -

[0:23:11] JN: Have a support graph on, yeah.


[0:23:13] ED: On Poki, on the public, on developers, but Pokie does come - we have something called the Player Device Report, where you can see exactly what our audience supports. There I can see, for example, WebGPU is supported by 68% of our players. 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. The web is, of course, always a platform in development. There's always new features being introduced, and some browsers are faster with it, are a bit slower, but it's understandable. I expect in, I don't know, maybe the end of this year, WebGPU is so big that almost everyone has it.

[0:23:57] JN: Amazing. Okay. We bought up Poki again. We should probably at this point explain for our poor audience, what is Poki?

[0:24:04] ED: Poki is the biggest web games platform. Poki, under a different name, already existed during the Flash era. One of the co-founders of Poki had a couple of different sites, Jeux de Jeux in France and Games Freak - I don't even know. Those games were before my time.
Different portals. 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. 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. Not a lot of players. But that has been coming back for the last years. Poki is actually quite big now. We have 100 million monthly users. That puts us in the top, I don't know how many websites. 50 maybe.

[0:25:22] JN: Very cool. You mentioned it's a portal to web games. I'm a game developer and I'm looking for a distribution channel for my game. That's where Poki comes in, is that correct?

[0:25:30] ED: Yeah, exactly. 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. 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 that and take care of all the advertising, make sure we have a good set up, good advertiser and everything, blocking malicious stuff, but also making sure they pay a lot.
Then we do a revenue share with the game developers.


[0:26:10] JN: Amazing. I guess, what does that process look like for the game developers? Poki games got hosted on your site, right? It's not like it redirects to the user's site. I guess, there's some integrate. They give you the binary, etc.

[0:26:24] ED: 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." That you get access to this platform. You basically upload a zip file with an index.html in it and any other assets it needs, or anything. There needs to be an index.html in there. We'll put the contents of that zip file on our CDN. Then that's basically how the game gets hosted. 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, you will have this whole environment, management environment, like Steam, or the App Storage.

[0:27:10] JN: Amazing. I guess, one question I have about the setup. Do you support multiplayer games, like networked multiplayer games?

[0:27:15] ED: Yeah, yeah, 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 DevOps on those games.

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

[0:27:45] ED: 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 will be an unfair competition. I have insights into what happens in Poki, But it is good for some people at Poki to have games on Poki. When I first joined Poki, I didn't have a game on Poki. Only later, I built a game. I've always been working on the developer side of our platform on Poki for Developers. Launching a game on Poki myself made me look at our platform from a whole different angle. Immediately, I started seeing things like, "Oh, when I do this, then - That's weird, okay." You start seeing these inefficiencies in the UI, things that you want to see that can't see. It's very good to test your own product this way, which I think has been very beneficial.

On the other side, it's also very good to have this game on Poki with a bunch of players. Of course, my games are not the biggest games. I also didn't want that, but you want to have some players. When we need to test new features, and especially when I'm afraid of breaking a game to test something, I just use my own game. 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. It's very useful to have.

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. I was like, "Well, that's cool. A web game like this exists." Now that I decide, 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. That's how this game came. I build it together with the same friend I started that Steam game with way back in the past. I'm a developer. I am not good with graphics

and things like that. It's like, if I would design the game, it would look awful. Maybe I could do something with AI these days, but now I wouldn't want to do that. The friend I have, he is not a game developer. He works in a completely different field, but he is a good designer.

[0:30:09] JN: Amazing.


[0:30:10] ED: He actually made all the graphics. Together, we think a lot about game mechanics, testing it, what should we build. Then I basically do the programming. He does the graphics. That's how it comes together.

[0:30:22] JN: Very cool. Yeah, I think part of the reason it captured me, and I guess this goes to the web platform as a whole, but certainly to Poki, it's a really good example of a game, I think, that works regardless of which platform the person is on. I guess, part of the challenge, well, what I would assume is part of the challenge of being a web game especially on Poki is they could be on desktop. They could be on a tablet. They could be on phones. They could be on whatever. I think that must be a really tough challenge as a game developer, and I guess that's where your reports come in. Do you talk to the developers that come to the platform about what audience they should be prior to? Would you try and get them to address all audiences, or do you assume mobile faster, that kind of thing?

[0:30:55] ED: 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. 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 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, also gameplay suggestions and other things. They will test it on desktop, they will test it on mobile. It needs to work on both. The game developer also, I know that's a pain. 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. On desktop, the Poki player is a screen, a rectangle and you build your UI around that. At some point, you're, "Okay, now I have to test it on mobile."

That's so different. Because mobile, it's always best for web games to build your game in portrait modes. On mobile app, a lot of games are landscape as well. On mobile browser, on web, the user switch between games a lot more and -

[0:32:02] JN: Right. And then have the -


[0:32:04] ED: Yeah. You don't want to constantly rotate their phones.


[0:32:07] JN: Fascinating.


[0:32:09] ED: We always say, your game needs to work on portrait mode. That's very different, because that's all of a sudden, a very different aspect resolution, very different - instead of your screen being white, it's long all of a sudden. Your UI needs to be completely different from mobile. Then you have all these different phones with notches on top and whatever. You're placing UI elements there and then, "Oh, crap. I cannot place UI there, because standard iPhone notches in the way." It's a pain in the ass, but it's rewarding when it works at some point. 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 a screen resolution.

Poki also has different tools to help you with this. We have an inspector tool, where you can upload a version of your game and has mobile testing capabilities as well. 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.

[0:33:13] JN: Yeah, I'm really fascinated by that behavioral element, about you see players on web mobile changing a lot. It's also interesting, because I think I've heard this portrait thing from, I think it was Brian Buckley with Case of Card, was developing mobile Case of Card 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 are any other weird behaviors? I guess, at the platform scale, you see things that most game devs don't see.

[0:33:43] ED: Yeah. One interesting thing I read a couple of days ago, Netflix is even going portrait mode for their videos. They see, portrait is winning overall on mobile, in mobile land. Of

course, Instagram, YouTube Shorts, everything is portrait. I remember when I was younger, I would take pictures on my phone in landscape modes. Then I met my wife who likes to Instagram a lot, and she was like, "No. Always take pictures in portrait mode." All of a sudden, everyone always takes pictures in portrait mode these days. Portrait mode is completely winning on mobile, on the web as well.

[0:34:23] JN: I think I have heard about Netflix as well. I've heard people talk about how all shots now are composed, so people are the bit that will end up in the portrait of the clip, even if it's meant to be showed on widescreen. That's wide.

[0:34:33] ED: Yeah. Yeah, yeah, yeah, no. Games also, definitely, they should be portrait. 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, 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 already put in some effort there to pick it out to download it. Those players, if they have to switch to landscape mode, okay, sure, they have some incentive to try the game for a while, at least, because they spent all this time on downloading it. That's a big difference.

[0:35:25] JN: Does that affect your game design in terms of, I guess, you don't have time to tutorialize. It needs to be straight in?

[0:35:29] ED: Definitely. Definitely. Where on Steam, on any other game platform, except for the web, I always see a lot of games have onboarding with text, for example. They 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 how you browse videos on Instagram and TikTok. If it's not interesting immediately, you swipe to the next. That's very similar for web games, where you just go to the next game, because it's so easy. 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 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. If I would be making that for the web, I would start the player off with 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, slowly. You want to pique that interest immediately.

[0:37:08] JN: Amazing. I guess, that how easy people move on from your game must also be affecting people's development cycles, right? No one's doing a seven-year long development for a web game, right? I have an intuition that web games are smaller and tend to be very level- based that can proceed to be generated anyway, or just score-based. The studios you work with, are they doing really short turnarounds on games?

[0:37:31] ED: Yeah, yeah, yeah. Definitely. It's also possible to make games with a longer content and have players come back. Of course, we have safer games on the web. Those games definitely exist. A lot of them are made for mobile app first and are then ported to web. The really web native development studios, 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 download a new version, or something. That's automatic. You test a lot, where later you add more content if you see a lot of players are interested. But you need to get that beginning, those first couple of minutes of gameplay, basically. That's what you need to really get down. If you have that down, then you can add more content.

[0:38:18] JN: Do what you want. Yeah. You mentioned testing. I know that obviously, a lot of Poki's developer platform is focused on monetization and discovery. What other areas of the game dev problem space you think of addressing in your developer platform?

[0:38:31] ED: One of the more interesting features we have is called the Poki Play Testing. I think that's quite unique. Where because we have this lot of crazy amount of players that just

click on games and want to play everything, we can match - Okay, when you request play test in Poki for 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 a capture stream API, which allows you to capture a video. We have this Poki Play Testing tool. If you upload a new version of your game, you request play test videos. Within a couple of minutes, you'll have 10 videos of people actually playing your game.

[0:39:23] JN: Amazing.


[0:39:24] ED: Within minutes. If you have a day of developing your game, you can upload, I don't know, multiple versions a day. You request those play test 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. I know from a game developer, when I was building my games, I also had my wife, 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. 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 the second time on the same person. That onboarding is the most important part of web games. Testing, with your friends and family, it's fun, but it's not that useful. While play testing, actual players on Poki get to play your game and you get the videos of them playing it. That's actually useful feedback. 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, 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. When you get a video with their keyboard inputs, their mouse inputs, it's very useful.

[0:41:02] JN: That's cool.

[0:41:03] ED: I've seen play tests of games, where the most fun example I always think of is a video where a game where it was like a site scrolling bicycle game. You were a character on a bicycle, 2D, side scrolling, and you had to press the space bar to flip to go the other direction. The game was showing this space bar button with the word space on it. You could clearly see some players who had no idea what a space bar was. Maybe a younger audience has no idea what it is. You see them clicking, you see them pressing all kinds of keys, you see them trying everything, except for pressing that space bar. That's very useful input that you - feedback that you would never get out of other play tests.

You would also not get that out of Steam games, mobile games on App Store. They always have these services, where you hire professional play testers to play test your game. They know what a space bar is. They are not your target audience. Here it was very clear like, okay, you need to actually have a clear picture of a keyboard with the space bar highlighted for the player to understand what a space bar is.

[0:42:14] JN: That's fascinating. It reminds me of them. 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, you'll have RPGs, you'll have your free colored bars, right? Red for health, blue for mana, green for agility, or stamina, or whatever. It looked into how widely understood that color scheme actually was, because everyone does. It's so widespread and it's never explained. They just assume the players know. Then the minute you're outside of that audience, actually, completely indecipherable. 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 I feel a lot of our audience are game dev curious and want to do more, but haven't found a way to make the economic jump yet. I think the web and Poki, in my impression, thinking about my future where I make the escape and I do game dev, Poki is something I'm looking at really strongly. Do you think that's true? Do you think that's a path that you've seen I would follow?

[0:43:08] ED: 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. I know a lot of developers who are building games for Steam, they're building games for app stores. If you don't do any marketing, you're not going to get any players. That's it. Those platforms, they don't promote

your game. You need to do that yourself on Steam. If you have almost no wish list, Steam is also not going to promote your games. The app stores, especially there's, I don't know, more than 100 games being published each day in the app stores, it's crazy.

On Poki, we have all these players. If you look on Poki on a game page, you see a lot of other games there as well. We're promoting other games next to the game the players play. 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. We have a whole bunch of game developers, who are just indie game developers, by themselves, who focus purely on building their game. They don't even know how marketing on TikTok works, or something. They just focus on building their game. That's the nice thing as a game developer. That's kind of, I myself what I want. I don't want to spend any time on how I'm going to get users to play my game. I just want to build my game.

I think that also for Poki, results in better games, because if you really want to build an app, or a 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.

[0:44:58] JN: Yeah, that is the absolute dream. I feel like, I mean, I have two thoughts and it's personally, the idea of like, oh, I need to get good at TikTok has actually been a barrier to investing in making a game. Then you see these really tragic stories, 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." Getting past that fear, yeah, I think that's a really good benefit of the platform.

You mentioned, obviously, in playtest, it shows it to a limited selection of players. If I have to go to Poki, there's no sign in or anything. There's no ability to target what audience you're looking for to play test. I imagine, that would be -

[0:45:32] ED: Oh, no, no. There is.


[0:45:33] JN: Oh, there is. Cool.

[0:45:34] ED: Actually, these days, we do have an account system that was launched earlier over the end of last year.

[0:45:39] JN: I'm missing out.


[0:45:40] ED: It's the web. We can place cookies. We can see what users are interested in. We, of course, have games are categorized. We have categories. If you're saying, "My game is a tower defense game," yeah, then we're going to show that game with other tower defense games to an audience that's probably interested in tower defense games.

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

[0:46:17] ED: 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, index DB for save games. If you play a lot, you can lose those cookies. Safari is very famous for just dropping cookies, because they have a smart anti-tracking algorithm thing and our games are actually running in an iFrame on a separate domain on the site. The games are not 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 going to delete those cookies.

[0:47:01] JN: All that subs then.


[0:47:02] ED: 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. Yeah. After an hour of playing, we usually prompt players now to like, "Hey, if you create an account, then you can save." Your save games go into the cloud. We have this system, where games can just store stuff into local storage. Then once in a while, we'll just read local storage and store it on our server.

[0:47:33] JN: Breaking with Steam's with cloud saving.

[0:47:36] ED: Yeah, exactly. Except, you don't have to implement any specific API. It's just you're using local storage.

[0:47:42] JN: Oh, it's the time on the client. You're just grabbing it.


[0:47:44] ED: Yeah.


[0:47:44] JN: Cool.


[0:47:45] ED: Yeah. Yeah, exactly.


[0:47:46] JN: We've spoken about where the web platforms come from, some ways, some of that things are looking at a Poki. What still sucks? As a game developer, what do you wish you could do on the web that you can't currently at Poki? What kind of problems are you thinking of tackling?

[0:47:59] ED: 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 upgrade. There's 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 that up and do whatever. I cannot, for example, from the web, say, push this to the Instagram app to share something. I can only open this native share menu. 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."

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 going to lose a couple percent of players. Just takes too long. They click away. 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. If you have a level-based game, you're going to load level one and then have to play in level one and all those other levels, you can load later. You don't need them right now.

Unity, for example, well, so they use WebAssembly. WebAssembly, great. But one of the downsides is one big blob. You have to download the whole blob to start executing it. Unity games always are rather big. 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. If you use addressables in the app or in Steam, it's not that useful. You already have those files on your disk, so loading them is quick. On the web, it's very useful, because then you can delay the loading of models and levels and whatever. Most developers don't build their game with addressables, and adding that later is very difficult. Most Unity games, they load everything that the game needs into memory and only done the game is playable. 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 easier system to dynamically load assets. Of course, that's very difficult for them to take that on now. They have that addressable system, but it's very difficult to start using that when you already started building your game.

[0:50:50] JN: Yeah. I guess, how do you, from the WebAssembly side, I guess, you'd be building multiple binaries and then doing linking and -

[0:50:55] ED: Yeah. The WebAssembly, they would probably still do one big blob, but then all the assets, or the levels, those are not in WebAssembly. Those are just data and that, you can load later. The same issue is with Godot, they also built one big blob that you download to play the game. There, I know the web lead, Adam Scott. Not the actor. Other Adam Scott.

[0:51:17] JN: Yeah. I know Adam Scott. He's great.


[0:51:19] ED: 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 going to 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. Yeah, the file size of those games is always an issue right now. If you could load those assets more easily dynamically, that would be great.

[0:51:44] JN: That's fast, going back to the contractuary side with about engine choice and such right now, that's a really good lens of looking for that. Going for one that, as you say, is a web first gets you some neat benefits for understanding actual behavior on the web platform. Very useful. Well, that brings us to the end of our time. Erik, thank you so much. This has been lovely. Great to learn that state of the platform and what you're working on. Thank you for joining us.

[0:52:05] ED: You're welcome. Thank you.


[END]