Conversion to Play: The Art of Loading

Hi, everyone. It's good to be here. This is, I think, one of the first conferences dedicated specifically to web games. So I felt I really needed to be here, because that's something that I've been spending most of my professional life on.

So today I want to talk to you about the art of loading and the impacts of that on what we think is one of the most important things to consider when you want to create a web game. And being aware of this and taking it into account from the start of your games development will greatly improve your chances of success.

So I'll be covering a broad range of topics. Instead of diving into one thing very deeply, my goal is mostly to build awareness and make you care. So yeah, let's start.

First of all, let me introduce myself. So my name's Kasper. I live in the Netherlands, in Amsterdam, and I'm a tech lead at Pokey, where I've been working for quite some years now. In total, I have about eight plus years of experience in the web game industry. And next to that, I'm also an indie web game developer.

So the two games you can see here on the left, Supernova, on the right, Joyrider are two of my personal projects. I'm very proud of them. Give them a play if you ever have a chance.

Also, a little bit about Pokey, in case you don't know us yet. So Pokey is a web game platform. You can see our homepage here. We have about 30 million monthly active users. And we're trying to build the ultimate online playgrounds and setting new standards for web games. I think we're most proud of, though, our direct relationships with about 300 game developers, ranging from big established studios to one man teams who have built their business from the ground up on our platform. Things we do range from bringing mobile hits like Subway Surfers and Stickman Hoops to web, to reviving Flash classics into HTML5 such as Bubble Trouble, the Nitrome Collection and Impossible Quiz, as well as making new original web game productions possible such as Plumgy Rockets or Narrow One. Give us a visit when you have some time on desktop or mobile on poki.com.

So, as I mentioned, this talk is about the conversion to play so you should probably know what it is and also why you should care about it. So let's just start by saying that of course web is on demand. Games on web are a bit different from games on other platforms because they're not pre-installed. They're downloaded at the moment of play. That means users see something they like, they click and then at that moment they have to download the game before they start playing. So this is an initial hurdle for players to enjoy or even try again and that makes it very important. The loading experience really is key. If this is done wrong or if it's ignored it's going to have some pretty substantial consequences. So we've seen games where only 20% of interested people would end up playing, which is a very small amount and it means you're losing lots of players before they even get to the thing that you're probably very proud of, which is your game.

So, Converse to Play. It's basically the name for the metric we've defined to keep track of this specifically. You can see here on the flow kind of how it works. So on the left, a player sees the thumbnail of your game. They click on it.

They're interested. Then they open your game page. They start loading your game. Then they have to go through your game menus and then finally they start playing your game. So what we define as Converse to Play is this moment from game page view until play. The percentage of users who visit your game that actually end up playing. To work on this, there's a couple of things you can do.

So what I want to do is I want to walk through the most important ones. And here's the first quick overview. By the way, the game on the right, Plungy Ball, is a very recent release from a friend of ours, BlumG, a really awesome one. So things you should be thinking about are, first of all, picking the right engine. Also, you should be optimizing your assets. You should make loading interesting. You should load things only as they are needed. And you should keep the path to play clear.

Let's start with picking the right engine. It's a big topic by itself. And there's actually more people talking about this during the conference. So I would recommend listening to more people. But I'm mostly going to be talking from the perspective of conversion to play. First of all, it always matters, pick something that fits your team and ambitions. If you have a larger team, you probably want a different engine than somebody that's working by themselves. If you have a tech-heavy team, you probably want a different engine than an artist-heavy team. So this will always be different. Luckily, there's a lot of good choices by now in the HTML5 space. But I would recommend, though, is to try to stay as close to JavaScript as you possibly can. If your code has to be converted, compiled, all these kind of things, this obviously will add overhead to your game, which can be a problem. Some things I would recommend trying is check how large the engine is without any game code. So download the engine, build a project without your game in it, and see what's there. See how long it takes to load.

See how large it is. The larger it is, the more of a problem you might have later on. Also, check how much control you have over the loading experience. Some engines allow you to change everything. Other engines will force their own loading bars. Some engines will have multiple loading bars. This all makes a difference, so take a good look.

And finally, you should also be aware of the size of any third-party libraries you use. It's not necessarily engine specific, but if you're using a giant third-party physics engine or other stuff like that, you should really be aware of how much weight that is adding to your game, because every kilobyte matters.

Then, optimizing your assets. Probably the least fun one, but it is important. So overall, just make sure you research your file extensions and use the correct ones. PNG and JPEG are a good example. Know which one to use for which images, because it makes a difference. Also compress all your assets, so you don't need your JPEGs that's 120% quality probably, and for audio, I would also recommend putting it to mono. Then, if you have a lot of images, you should consider putting them into sprite sheets. Now, browsers are a bit better at handling a lot of parallel requests, so it's not the most important thing anymore, and depending on the engine, even rendering images separately might be optimized, but once you get to a large amount of images, you should really be bundling them. Also, if you're using custom fonts, consider using bitmap fonts, and if you can't, then at least you should be removing characters you don't need from the file.

Then, making loading interesting. So, no matter how hard you try, you will always have some form of loading screen. But while people are waiting, you might as well use that time. So, one thing that people usually underestimate is how long it will actually take an average user to load through a game. For example, Poki is, like I said, a global brand. So, we have people from all over the world, people with slower internet connections than yours or slower machines than yours. So, be sure to test on slower machines and be sure to throttle your connection. You'll be surprised how long people are staring at these screens that you've been ignoring because they only take a few seconds for you. So, while you have this time, make sure to use it properly. Set the expectations for what the game will be like. Excite players while they're waiting. Show them key arts, show them screenshots, show them controls for the game, show them how big the game is that they're downloading.

Make sure to use this space efficiently. Another important one is loading things as they are needed. So, this super depends on the game, how much you can do. But the main thing is you should only load things when you need them. That means if your game has like 20 different maps or environments, and they all have their own assets, they all have their own music, you don't need to download all of them before the player even plays the first level.

On the right, you see a gif from Finch, and you can see that you can get into the main menu super quickly, even though in the background, they're still loading the models, still loading the textures, all this kind of stuff. And then as soon as you start playing, it will load the map that you need, etc, etc. Any assets you need later, you can download them during gameplay, you can download them during the menus, and especially music. I usually recommend people to only start downloading, to stream the music, so don't block your loading. But just let it stream in and if somebody has a fast connection, they will have the music as soon as they start playing. For somebody with a slower connection, they can already enjoy your game, but the music will just start a bit later.

And then finally, keep the path to play clear. So, as I showed in the overview at the start, the converse to play is not only affected by your game loading, it's also affected by your game menus. So be aware of how many screens you put in between the start up of your game and the start of your game. You don't need 3 loading screens. If you put splash screens or you have a story in front of your game, that can be nice, but make sure people can skip to them easily. Of course, make the play button easy to find, don't hide it. And one of my favorites, as illustrated in the GIF on the right from Syncith, consider dropping first-time users immediately into gameplay. If they're just starting out, they don't even know yet what they're going to be playing. So why would you force them to sit through menus they're not interested in? Just drop them into the tutorial, let them play. And then if they enjoy it, they can explore the other features later. Also, just as a side note, surfing your game does make a difference. So we are on the web. That means you have to surf your game through web surfers. There are some things that are important here, for example, compressing too broadly and having good CDN coverage. For an individual developer making a game or two, it's not very easy to do because it's also a different skill set. But luckily, if you work with a platform, they probably handle that for you. So we do as well. You don't have to worry about this. So that was a lot of information.

It's probably good to stand still again a bit on why all of this is actually important. And to do that, I want to show two specific examples that worked on this problem and that managed to get some good results from it.

First, Apple Knights. So Apple Knights is the game by Limitless LLC. It's a 2D action platformer where you play a knight, you eat apples and punch enemies. It's a game that's made in Unity, and it's a Unity WebGL export. Which from the first to play perspective, it's not a great starting point. With the right work, you can still get quite some reasonable results.

So the studio actually worked super hard and they did a few key things. Going over the checklist again, they worked on loading things as they are needed, optimising their assets and keeping the path to play clear. So first of all, they started using asset bundles extensively. Asset bundles are a feature of Unity that will allow you to download your assets later on as part of the initial loads. They kind of have all their assets already optimised because Unity is pretty good at that, but they were using a bunch of big third-party libraries that in the end they didn't really need, so they removed most of them. Then finally, they also removed a bunch of what you could call unnecessary menu screens, making the path to play much clearer. That brought them from a game that was around, I think, 8 megabytes at the start to a game that's closer to 30 megabytes, and with that they managed to improve their interface play from 74 percent to 64 percent, which basically comes down to every thousand potential users, 170 more people are playing their game. So that's awesome.

Now, what you might be thinking is, okay, but 64 percent, that's still silence on the low side, and you're partly right. For a Unity game, once again, it's pretty good. And they put a lot of effort in that. But like I said before, staying close to JavaScript is a good idea, so I want to show the next example for that, which is Stickner. So Stickman Hook is a game by Mathbox. It was a big hit on the App Stores already, and they decided to also put their game on web. And after being on web in Unity for a while, we talked and we realized that the game would really benefit from doing a rebuild. So that's what they did. They rebuilt the game from scratch in nativational 5, using Pixy.js, just as a graphics library. And the results are really good. So as you can see, before the Unity builds, it was doing 35% conference play. And after they switched to native builds with pixy, that ended up at 81%. So on a thousand potential users, that's 460 more people playing the game. Which is insane.

And on top of that, the fact that they changed to native builds also allowed them to have way better support on mobile web. And on top of that, because our recommendation algorithms like games that get played, there's a stacking effect here. So the actual impact of the amount of users playing their game was much bigger than just that this number here, it says.

So just as a quick recap, here's the checklist again. Make sure you pick the right engine. Make sure you optimize your assets. Make loading interesting. Load things as they are needed and keep the path to play clear. I hope this will help you get a good start on your web game. And if you already have one, maybe this will help you improve. Thanks for listening.

Yeah, come and play at pokey.com or if you have a game, send it to us. And also we're hiring. Thanks. Yeah, so you have asked, have you developed web games before? And 53% have responded with yes. What do you think about that? That's great. I was kind of unsure whether we would have mostly web like a JavaScript developers or also web game developers in here. So it's good to see actually lots of game devs. That's nice. Yeah, actually it's really nice. I didn't think these many people have developed games for web before. There's not that many of us in general. So yeah. Like actually before the summit, I thought I was alone in the world. So nice to see these many people like 8000 people tune in.

We have some questions for you. First one is, what do you think is a good file size target for my game? That's a good question. Of course my favorite answer would be as small as possible. Every megabyte counts. So really as small as you can get it.

But obviously it's going to differ for every game and for every engine. So I would say if you can manage to get under five, you're doing an amazing job. And if you get under 10, you're doing a good job. So those are probably the targets I would say. But every little bit you can slice, this is good.

Yeah, I know. I know what you're saying. Another question is, which game engine do you use for your own projects? I made two games so far, I'm working on a third one. For the first one, I just use Tree.js. So more like a library than really a game engine. I made that game with the approach of just put a bunch of code together until it works. So not too much thinking about proper architecture, this kind of things. But that helped me get something out because my goal was just to actually finish a game, which is harder than it might seem if you've not done it before.

But then for the second game, the 2D racing game, I switched to Pixi for the graphics with Box2D. So also not really one of the engines that I put on the slides. Also a bit more close to the codes. And I built, I wrote my own kind of more framework, you could say, on top of RxJS, which might be familiar to some of the more web-deaf people around here. So a streaming, a streams library basically. And I'm using that now. So for me, mostly the reason is because I like being very close to the codes. I like knowing, having all the control without having to dive into engine specific stuff, which is a lot slower, but if you enjoy it, that's good. But if you don't enjoy it, I wouldn't recommend. I would pick any of the other engines I put on the slides.

Yeah, exactly. Actually, it's kind of better if you're starting to get into game development because you can learn really the basic stuff how games actually work, the physics and stuff like that. So I like that too. For myself, when I was starting to learn, I was reading a lot of mathematics and stuff like that to find out the collision, the formulas and stuff, and things like that to get to know game development itself, how it would work.

Yeah, I think that's also what surprised me the most about game dev coming also more from a web dev background. It's a lot of math, it's a lot of math.

Yeah, it's a lot of math. Yeah, I should go to my father for that. So I wouldn't know much. So I would go back to my father and ask him some mathematics stuff, and he would explain them to me, and I would code it. And it was really awesome. That's smart. I had a few times where I remember I wrote like three or four pages in a notebook to figure out some equation. Then I asked somebody because I got totally stuck, and then they were like, no, there's this super simple formula. Everybody knows it, just use this. And I was like, ah.

I had a similar experience actually. And we have another question from Panther, and they're asking, what do you think about WebXR games and the potential in that? Good question. First of all, personally, I think it's super awesome. I like web because it's so open and everybody can use it. It's super easily accessible. And I think for new technologies to actually come to web so quickly is super cool to see. But at Pokey, we don't really work with it, just because it's not a super big audience fit. So I don't spend too much time looking at it, also. But I'm very excited for it, more from outside of our specific use case of our gaming platform, just because of the potential of not having to install anything and go straight into VR. Only problem is, you still need VR headsets, of course. So I don't know. I like it. I think everything should come to web. So in that sense, I'm excited. Yeah, exactly.

It's very exciting. And we have another question that they're asking. What is the stance of Pokey on blockchain and crypto games? That's also a good question. I'm not sure if I'm the best person to answer that question. It's not something we're actively pursuing. I think it is something we are actively researching, mostly because we're just about bringing free games to as many people as possible. That's the core. We want to give awesome experiences to as many people as possible for free. So if it can help us with that, then that's very interesting. I think we did do some collaborations with the NaNoFoundation, but again, I don't want to go too deep into it because I haven't been super involved. I don't want to say the wrong things. But yeah, we don't have any crypto games at the moment, at least.

Yeah, actually, I don't know if you saw that, we had a talk with Paul from OpiGames, and he talked about metrigaming and what could happen. What's the future of that with games, with cryptocurrency and NFTs? And it was an interesting talk. Actually, I have another question, is that what were your biggest challenges in reducing the size of your games? I think for the first game it wasn't a super big challenge actually, because I started from the beginning with the file size in mind.

So I think if you designed a game from the start thinking about the file size, it can be relatively easy. The biggest challenge is not using an engine. So because it was all procedural art, except for like the main characters, the whole environment was being just generated with math. Yes, more math. That keeps the file size very small. So that was pretty straightforward.

And then for the 2D games, it gets a bit more difficult because you need the graphics. But there I kind of took the same approach. So I procedurally generated the levels from Vertex data. I have a blog post on that. I can maybe share it. And then there are some challenges with getting it to look nice. Mobile devices don't like huge texture. So you have to do some chunking and these kinds of things. But I think the biggest hurdle for most games in getting the file size down really depends on what engine you're starting with and how many third party things you tend to use. Because if you choose a very lean engine and you don't use many third party libraries, then you have a lot of control over slicing off things. So I think starting off right makes the biggest difference.

Exactly. And I'm just learning something called Spine 2D. I don't know if you've heard about that. So I was using spreadsheets for my animations, 2D animations in my game. And it could get really big in size because of the frames. And Spine has this thing that it has the parts for characters. It has limbs and stuff like that, separate parts. And it exports JSON that handles the animation. So it could really bring down the size of your game. I don't know if you are aware of that. Do you have any thoughts about that? Yeah. I think there are lots of tricks like this. You should be aware of it while you're making the game to take these things into account with all the stuff you're doing, which is why I'm trying to preach this.

Because the later you start, the harder it gets. Yeah, exactly. I also have another question. It's not related to your talk. But I saw that you're in the game dubbing your free time, and you work with Poki. So it's probably a day job for you. And I wanted to ask, how do you manage the time to put into your indie games? Well, to start, I'm Dutch. And Dutch people don't like to work too much. So I only work four days. So that's the first part of it. I have my Fridays off to work on personal projects. And the second part is just not easy. It just takes a lot of time. So the second game, I think I took two years to make. And that's just spread over very long periods. So, sometimes I'll have a week where I'm very productive. And then I'll have three months where I don't touch it. So it's more, what do you call it? It's more a marathon than a sprint. Keep focused on the end goal, and maybe sometimes plan a week off to work on it. I'm working on the new game on my ski trip also. So, find the time you have and keep going until you get there, I think. Yeah, I feel you. Also, what is the new game you're working on? It's going to be a roller coaster game. So I'm simulating some roller coasters, which is forcing me into graphics programming, which is, again, more math. And I'm not good at that. So it's going to take some time. It will get there, eventually. You can contact my father if you have any questions. That would be nice. It's actually really exciting to hear about that. I'd love to play that. Cool. So I think we're actually kind of out of time for questions. Yeah, it was really nice talking to you. Thank you for answering my questions. And you can also keep continuing asking me questions on Discord. And Casper is nice enough to answer in his speaker room on Discord. Thank you, Casper. Thanks for having me.