← Software Engineering Daily
Software Engineering Daily
Web Native Game Development
00:54:08
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 w...
Loading summary
Transcript105 lines
- [00:00]
Narrator
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 Dabelbor 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, 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 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.
- [01:45]
Joe Nash
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 POKY and a developer of web based games. Eric, welcome to the show. Thank you, thanks for joining me. All the way from the other side of the world, a dreadful time. Really appreciate you being here. So I want to start by asking you, what was your journey into game development? How did you wind up at poki?
- [02:07]
Eric Dabelbor
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 and I was very interested in okay, how are games being built? So when I was very young I already started looking into, haha, 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 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 the whole ecosystem works. I was not very good at programming, which kind of helped because my logic was so flawed that the bots would behave in unexpected ways, which actually made them interesting emerging behaviors through incompetence.
- [03:27]
Joe Nash
Amazing.
- [03:27]
Eric Dabelbor
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. 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 going to meet all these people who are also software developers interested in building games. We're going to 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 visits to their office, super nice office, and they explained what they do. Well, I didn't know web games that well, but it all sounded very interesting. So I did in a couple of other interviews, but then I was like, yeah, this is what I'm going to do. Oh, I forgot to say before that I played a lot of games, especially with a good friend of mine, and we played Starcraft 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. So I actually learned how to use Unreal Engine and started building a game in Unreal Engine. It's still on Steam as somewhere in the future to be released. Probably not going to happen, but we made a Steam page and all we had something working, but it was, I think in the end the game was interesting, but it was multiplayer and multiplayer. Like multiplayer only, which is very difficult on Steam. Like if you launch a multiplayer game where players play against each other, you either have a big audience on launch and you have enough players to do the matchmaking, or you don't have enough players to do the matchmaking. And you can have like a thousand players a day, but if they all try matchmaking at different times during the day, you're not going to start any matches and everyone will just like, okay, there's no players in this game.
- [06:30]
Joe Nash
Yeah.
- [06:31]
Eric Dabelbor
So I don't think that game would have ever worked. Don't think we're ever going to release it. But it was again, something like our game development. So Poke was interesting to me. Yeah, I started as backend engineer at Pokey, but then I also launched two games on Poke because I with that friend as well, we stopped the Steam game. We started focusing on web games also to, as they say, dog foods, your own products. Like it's good to look at poking. Not just from, hey, I work at Poki, but also, hey, I have a game developer, Pokey.
- [07:02]
Joe Nash
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 Frame Map editor. It was like such an influential part of like my teens. And yeah, the StarCraft one similarly. And yeah, we'll get into talking about Pokey and 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 what web based games. That's where Pokey 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, when the iPhone and the famous Steve Jobs kills Flash and all that, it feels like Flash games died a death and languished for a while. But I get the impression actually part very driven by pokey and being proximate to your office, but like just in general that web games are having a bit of a renaissance again and the web platform is finally caught up to where Flash was. Is that something that rings true for you?
- [08:03]
Eric Dabelbor
Yeah, definitely, definitely. So like I said, I didn't used 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. 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 the Flash games anymore. They started doing different things so that they also didn't come back. Were the dark ages for web games, I would say. But now there's definitely a renaissance where every big game engine, I guess, except for Unreal, has 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 emscript and to compile their stuff to WebAssembly. And yeah, that is great. Now we have WebGBL for a long time, WebGL2. Now we have Web GPU making even more possible. So there's still a bright future, I think.
- [10:15]
Joe Nash
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:34]
Eric Dabelbor
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 or 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 the bytecode looks like. And it's not what's quite optimized, but it's not Perfect. Besides, it's JavaScript, this text, this 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, 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 or area. It has very limited amount of instructions, so no super complicated stuff, but it runs very fast, faster than if you would write the same thing in JavaScript usually. And then you have these ways to say, like, hey, I have this webassembly function, expose that to JavaScript, so you can call it from JavaScript. And the other way around, where you
- [12:13]
Joe Nash
can FFI kind of situation.
- [12:15]
Eric Dabelbor
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 Emscripten is the example of that C to WebAssembly, and most engines and platforms and things are all using that to generate webassembly.
- [12:52]
Joe Nash
Okay, awesome. So this is probably a really silly question, but, like, 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 just threw a limited instruction set.
- [13:05]
Eric Dabelbor
So, like, I guess WebAssembly has no access to browser APIs. So WebAssembly is really just like, you have these functions you define that JavaScript can call, and it can call these JavaScript functions. That's it. So if from WebAssembly you need to create a DOM node, it will always go into a JavaScript function. That JavaScript function calls the DOM API and goes back into WebAssembly.
- [13:31]
Joe Nash
Okay.
- [13:31]
Eric Dabelbor
There has been a lot of talks about different specs for WebAssembly to be able to call DOM APIs and browser APIs directly, but that was never implemented so far. I think one of the reasons for this is that WebAssembly, it's called WebAssembly, but it's not just being used on the web, 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 wasm 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:15]
Joe Nash
Interesting. So like, if you're developing a web game in C rev scripten, you also need to make like the canvas container for your wasm bit. Yep.
- [14:25]
Eric Dabelbor
Okay, cool.
- [14:27]
Joe Nash
Interesting. Okay, great. So that all makes sense. WebGPL, where does that come in? So I guess my intuition on WebGPL is that's WebGL. WebGL, sorry, GPL. Because there's also Web GPU.
- [14:38]
Eric Dabelbor
Web GPU, yeah.
- [14:39]
Joe Nash
Cool. WebGPLaster. That's the new license. Yeah. So that's exposing, like, ability to utilize graphics hardware in the browser, right?
- [14:47]
Eric Dabelbor
Yeah, exactly. So WebGL is basically the API looks very similar to OpenGL. Great. If you're familiar with that API. So it's basically a wrapper around OpenGL, I would say, allows you to draw 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 control and then WebGL. So WebGL is comparable to OpenGL, you have WebGPU now, which is comparable to Vulkan or I'll give you my next question.
- [15:29]
Joe Nash
Okay, great, Cool.
- [15:30]
Eric Dabelbor
Yeah. So on desktops you got all These new graphics APIs, I don't know. On Windows I guess you have like the latest version on DirectX, which is probably different than the previous ones. On Mac you have Metal. Metal, yeah, they all. I think you've spoken in the backend then. So that's a new type of graphics API where in OpenGL you're basically firing commands. You're saying like, hey, set this texture now set this array of vertices and now draw this primitive using those vertices and then it executes those in order and you have to wait for it. With WebGPU Vulkan, it's a bit different. You say like, okay, here is a texture, a vertex buffer and now cue the rendering command with those. So it's More asynchronous where WebGL you really like, you're waiting for the result, you're waiting for something to draw. With GPU you can batch a whole bunch of commands and then say, okay, send this to the GPU to render. I don't want to wait for the result. I'm going to do other stuff. So it's a lot faster that way. You're spending a lot less time waiting. But also much more complex API to use. But of course, on the web. Yeah, you have engines taking care of that. Yes, sure. But for the engines it's also a bit complicated. I know, because it's such a different way of rendering where you're not waiting for stuff, you're batching all these things. They usually have to quite change their pipeline to make use of this.
- [16:55]
Joe Nash
Right. Okay, cool.
- [16:58]
Narrator
Every AI team eventually hits the same wall. The models are solid, the infra is solid, but the data coming in is hours old. Because the pipeline is batch when it should be streaming and nobody's had time to fix it. That's not a modeling problem, that's a pipeline problem. Estuary gives you CDC batch and streaming in one platform. 200 connectors live in hours, not weeks. Your AI is only as good as your pipeline. Estuary.dev.in Mobile application security good enough is a risk. Guard Square uses advanced multi layered code hardening techniques and automated runtime application self protection and Mobile application security testing combined with real time threat monitoring to deliver the highest level of mobile app security. Discover how guardsquare brings all these together to provide mobile app security for your Android and iOS apps without compromise at www.guardsquare.com if you're running Postgres in production,
- [18:02]
Eric Dabelbor
you've probably felt the moment analytical queries
- [18:04]
Joe Nash
start fighting your transactional workload. Most teams end up adding a second database and all the pipeline complexity that comes with it. Tiger Data, creators of TimescaleDB takes a different approach.
- [18:13]
Eric Dabelbor
We extend Postgres with hybrid row and
- [18:16]
Joe Nash
columnar storage, so one table handles both writes and analytical scans. Native compression cuts storage costs up to 95%.
- [18:23]
Eric Dabelbor
Continuous aggregates keep dashboards live without bash
- [18:25]
Joe Nash
jobs, and it scales to petabytes without you re architecting. Companies like cloudflare, Octave Energy, Schneider, Axpo and Flowco run production workloads on Tiger Data today. No stale data, no second system to
- [18:37]
Eric Dabelbor
operate, just postgres managed for you. Ready for the workload you're building toward?
- [18:40]
Joe Nash
Try it free@tigerdata.com so the picture I now have is there's a lot of these new APIs that 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 on the low level, like what is the state of tooling right now?
- [19:06]
Eric Dabelbor
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 also works very well on web, also on desktop, also mobile. You also have really specific web engines these days. Play Canvas is, I think a really good one. Play Canvas is like Unity but then native for the web. So Play Canvas you Write everything in JavaScript. Like if you're doing Unity, you write your code in C and it uses WebAssembly. With Play Canvas 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, and it's a great Engine with like a point and click editor and everything. You have a lot of engines. Cocos, 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.
- [20:24]
Joe Nash
So that's somewhat in the phase of ballpark, right?
- [20:27]
Eric Dabelbor
Yeah. So Phaser uses Pixies. Phaser still a little bit layer on top of it. Phase are also web native engine. So you're writing 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 a Unity which is like point and click and everything in there. And you have Pixies, which is do it yourself. But it helps you a lot.
- [20:59]
Joe Nash
Cool. Yeah, I guess that's the. Well, I was going to say in desktop development, that's Unity at that end is still there and then your other end is like SDL2, right? That kind of like.
- [21:07]
Eric Dabelbor
Yeah, exactly. That's very similar. Yeah. Awesome.
- [21:10]
Joe Nash
So you mentioned that Unreal moved away from having a WebEx board because they had trouble maintaining it. And I imagine that struggle must be true the other editors as well. So I guess like one question I had is like, if I'm developing a game on Unity and I want to publish it for desktop, for mobile and web, can I do that from one code base? Or like, is the web platform, like where does it sit equal to those others? Am I always going to have trade offs and things I can't include in the web version?
- [21:35]
Eric Dabelbor
As far as I know, no. Like you can. While there's definitely some things more difficult on web, but most of the stuff you can just do on web, like it's super easy in Unity, just they have a button to do a web export and then you can have a look. To be honest, I don't know exactly which features from the Unity editor they don't support. I don't use Unity that often, but I think most of it is there 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 WebGPU is more stable in browsers since only a couple months, I would say 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 in with web GPU are also a lot faster. So Unity is actually still actively working on their web export because they also see the web ecosystem is growing, so they see the importance of this. So they're, they're working on this.
- [23:09]
Joe Nash
Nice.
- [23:10]
Eric Dabelbor
Getting better and better.
- [23:11]
Joe Nash
So I mean, you just raised a really good point, which I guess is a perpetual fear with using anything new on the web, which is obviously support for browsers and how far you can go. 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 what you mentioned? WebGPU is very new, but like the. If we're using compiling with emscript and to WASM and I'm using WebGL, am I more or less covered?
- [23:34]
Eric Dabelbor
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 effector operations that might not always be supported, but you can actually test for that. So you can have conditional code base there. And so WebAssembly also, I would say everywhere supported then. WebGPU has been supported in Chrome for a while 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 don't support that. So they're actually working on like a minimal version of WebGPU that can even run on super old phones by just tapping into older APIs 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 say 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 pokey. We do actually you have, you have
- [24:58]
Joe Nash
like a support graph on yeah.
- [24:59]
Eric Dabelbor
So on Pokey, Pokey on the public, on developers pokey.com we have something called the Player Device Report where you can see exactly what our audience supports. So there I can see, for example, WebGPU is supported by 68% of our players, so I think there are still older phones that probably don't support it. I know Firefox is working on it, but it's still behind the flag, so it's not enabled by default. So it's coming 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 and I expect in, I don't know, maybe the end of this year, WebGPU is so big that almost everyone has it.
- [25:44]
Joe Nash
Amazing. Okay, so we bought a Pokey again. We should probably at this point explain for our poor audience what is Poki?
- [25:50]
Eric Dabelbor
Poki is the biggest web games platform. So Poke under a different name already existed during the Flash era. One of the co founders of Poki had a couple of different sites in France and Games Freak, and 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 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 Poke is actually quite big now. We have a hundred million monthly users, so that puts us in like the top, I don't know how many websites. Yeah, 50 maybe.
- [27:08]
Joe Nash
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 games. So like that's where Poki comes in, is that correct?
- [27:16]
Eric Dabelbor
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 Pokey. We have the players on the other side and we have the Advertisers on the third side. So we're like a platform play where they all come together, where we make sure that the players get the right games. 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.
- [27:57]
Joe Nash
Amazing. So I guess what does that process look like for the game developer? Because like Pokegames like hosted on your site. Right. It's not like it redirects through to the user site. So I guess there's some kind of integrate, like they give you the binary, etc.
- [28:10]
Eric Dabelbor
So we have a platform called Poke for developers, which is our developer facing platform. When you submit a game and we say like okay, yeah, we're interested in that. You get access to this platform and you basically upload a zip file with an index HTML in it and any other assets it needs or anything. But there needs to be an index HTML in there and we'll put the contents of that zip file on our CDN and then that's basically how the game gets hosted. And we have this whole platform where you get all kinds of tools that we offer. If your game goes live, you'll get all kinds of insights. You'll also see your invoices on there. You can upload new versions. You this whole environment management environment like Steam or the App Store.
- [28:57]
Joe Nash
Amazing. So I guess one question I have about the setup. So do you support multiplayer games, like networked multiplayer games?
- [29:02]
Eric Dabelbor
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.
- [29:19]
Joe Nash
Cool.
- [29:19]
Eric Dabelbor
Awesome.
- [29:20]
Joe Nash
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?
- [29:31]
Eric Dabelbor
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 unfair competition. I have insights into what happens in Poki but it is good for some people at Poke to have games on Pokey. Like when I first joined Poki, I didn't have a game on Poke only later I built a game and I've always been working on the developer side of our platform on Poke for developers. And launching a game on Poke myself made me look at our platform from a whole different angle. So immediately I started seeing things like, oh, when I do this, then that's weird. Okay. And you start seeing these inefficiencies in the ui, things that you want to see but can't see. So it's very good to test your own product this way, which I think has been very beneficial. And on the other side, it's also very good to have this game on Pokey with a bunch of players. Like, of course, my games are not the biggest games. I also didn't want that. But you want to have some players. And when we need to test new features and when I. Especially when I'm afraid of breaking a game to test something, I just use my own game. Like, I don't care if my game breaks. That's fine. Then no developer is going to get mad at us. I don't have to ask any developer for permissions. I can test stuff in my game and not be afraid to break it. So it's very useful to have. I have two games on 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, oh, that's cool. Does a web game like this exists? No. Then I decide, okay, I can build a better version. I would never want to copy a game exactly and put it on a 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 with 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. 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.
- [31:56]
Joe Nash
Amazing.
- [31:56]
Eric Dabelbor
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.
- [32:09]
Joe Nash
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 Pokey. It's like a really good example of a game, I think that Works regardless of which platform the person's on. Because 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 phone, 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 developers that come to the platform about what audience they should be prioritised? Do you try and get them to address all audiences, or do you assume mobile first or this kind of thing?
- [32:42]
Eric Dabelbor
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 pokey player is like a screen, like a rectangle, and you build your UI around that. 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. Right. And then have the rotate do that in. Yeah. So you don't want to constantly rotate their phones.
- [33:54]
Joe Nash
Fascinating.
- [33:55]
Eric Dabelbor
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 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 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. 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 pokey also render some elements on top of your game so it will show you where those are rendered. So you shouldn't place any UI there.
- [34:59]
Joe Nash
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 feel like I've heard this portrait thing from. I think it was Brian Buckley of Caves of Card was developing mobile Caves 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 any other like weird behaviors you. I guess at the platform scale you see things that most game devs don't see.
- [35:29]
Eric Dabelbor
Yeah. One interesting thing I read a couple days ago Netflix is even going portrait mode for their videos. Like they see 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 or mobile. On the web as well.
- [36:09]
Joe Nash
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 in like the bit that will end up in the portrait of the clip, even if it's meant to be shown in widescreen. That's wild.
- [36:19]
Eric Dabelbor
Yeah, yeah, I know. So games also definitely they should be portrait. But games as apps of course is slightly different. There's a slight difference between, not necessarily between the player base 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 Pokey, 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. That's a big difference.
- [37:11]
Joe Nash
Does that affect your game design in terms of. I guess you don't have time to tutorialize. It needs to be straight in.
- [37:16]
Eric Dabelbor
Definitely, definitely. So where on Steam? On like any other game platform except for the web. I always see a lot of games have onboarding with text. For example, 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 onto 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, they will 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 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's introduces the mechanics one by one on an 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. Right. 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 want to pique that interest immediately.
- [38:54]
Joe Nash
Amazing. And I guess that how easy people move on from your game must also be affecting people's 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. And I have an intuition that web games are smaller and tend to be very level based that could proceed to be generated anyway or just like score based. But the studios you Work with. Are they doing like really short turnarounds on games?
- [39:18]
Eric Dabelbor
Yeah, yeah, definitely. It's also possible to make games with longer content and have players come back. Of course you have saved 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 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 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 like really get down. And if you have that down, then you can add more.
- [40:05]
Joe Nash
Yeah, so you mentioned testing, so I know that, you know, obviously a lot of Poke's developer platform is focused on monetization and discovery. What other areas of like the game dev problem space are you thinking of addressing in your developer platform?
- [40:18]
Eric Dabelbor
So one of the more interesting features we have is called the Pokey playtesting. I think that's quite unique where because we have this crazy amount of players that just click on games and want to play everything we can match. Okay. When you request playtests in poker 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 like a capture stream API which allows you to capture a video. So we have this Poke playtesting tool. 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.
- [41:09]
Joe Nash
Amazing.
- [41:10]
Eric Dabelbor
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. 3. 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. 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. While play testing actual players on pokey 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, 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.
- [42:49]
Joe Nash
That's cool.
- [42:49]
Eric Dabelbor
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 space bar to flip to go the other direction. And the game was showing this space bar 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 is. So you see them clicking, you see them pressing all kinds of keys. They see them trying everything except for pressing that spacebar. 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 like Steam games mobile games on App Store they always have these services where you hire professional play testers to play test your game. Yet they know what a spacebar is. Yeah, 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 space bar is.
- [44:01]
Joe Nash
That's fascinating. It 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 free 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 because everyone 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, that's actually completely indecipherable. Yeah, that's really cool. Well, one of the things I've always thought about Pokey and while 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 make the economic jump yet. And I think the web and Poke, 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 and do you think that's a path that you've seen others follow?
- [44:55]
Eric Dabelbor
So the nice thing about having your games on Pokey is that you don't have to do any player acquisition, any marketing of that kind. Poke 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 wish list, Steam is also not going to promote your games. So 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. 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 player is playing. 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. I just want to build my game. And I think that also for poke 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 while pokey 100% of your time is spent on building the game, improving the game, which is so much nicer.
- [46:44]
Joe Nash
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 Reddit where it's like I developed a game for seven years and launched it and no one played it.
- [47:01]
Eric Dabelbor
Right.
- [47:02]
Joe Nash
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 pokey, there's no sign in or anything. So there's like no ability to target like what kind of audience you're looking for the playtest, I imagine that would be.
- [47:19]
Eric Dabelbor
Oh no, no, there is because actually these days we do have an account system that was launched earlier, end of last year.
- [47:26]
Joe Nash
I'm missing out.
- [47:27]
Eric Dabelbor
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, we have categories. So if you're saying my game is a tower defense game then we're going to show that game with other tower defense games to an audience that's probably interested in tower defense games.
- [47:49]
Joe Nash
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 a million things. I really appreciate that. That's very cool.
- [48:04]
Eric Dabelbor
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, IndexedDB for save games. 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 side. 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 going to delete those cookies. All that. So 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 stay 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.
- [49:22]
Joe Nash
Saving.
- [49:22]
Eric Dabelbor
Yeah, exactly. Except you don't have to implement any specific API. It's just you're using local storage.
- [49:29]
Joe Nash
Oh, it's always hiding on the client.
- [49:30]
Eric Dabelbor
You're just grabbing it. Cool. Yeah, yeah, exactly.
- [49:33]
Joe Nash
So we've spoken about where the web platforms come from. Some ways, some things we're looking 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?
- [49:45]
Eric Dabelbor
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. One of the more important things with web game is this, 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 Play Canvas, 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 going to 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. Unity, for example, they compile, 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. So 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. And 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 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. Most Unity games, they load everything that the game needs into memory and only then the game is playable. 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 tag that on. Now they have that addressable system, but it's very difficult to start using that when you already started building your game.
- [52:36]
Joe Nash
Yeah, and I guess how do you.
- [52:38]
Eric Dabelbor
If.
- [52:38]
Joe Nash
From the webassembly side, I guess you'd be building like multiple binaries and then doing linking and.
- [52:42]
Eric Dabelbor
Yeah, so the. 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 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.
- [53:03]
Joe Nash
Yeah, he's actually great.
- [53:05]
Eric Dabelbor
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. 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.
- [53:30]
Joe Nash
That's going back to the, you know, 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 behavior 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.
- [53:52]
Eric Dabelbor
You're welcome. Thank you,
- [54:00]
Narrator
Sam.