See also:
There's also a link to the presentation if you want to follow along on your own. Thank you for the invitation. I'm here to talk about Defold, the game engine, talk about web games. I'll do a quick intro of Defold for those of you who don't know what Defold is. I'll talk a bit about games on the web and then the technology behind Defold that makes it run well on the web. And then some questions if you have any at the end. Alright. Defold is a cross-platform game engine. You can build games for web, for mobile, for desktop, and for consoles. Truly a cross platform game engine. And we just recently added PlayStation four support with PS five coming in maybe two months. The only missing piece of the puzzle is Xbox, but we're working on it.
Microsoft is a bit slow to reply, but it's getting there. A bit of history. Defold used to be owned by King, the makers of Candy Crush. From 2014 to 2020, it was owned by King, but at that point in time, Defold was also like a public product since a couple of years. And we made the decision to move Defold into a separate independent software foundation. It's not a company, it's actually a foundation registered in Stockholm, in Sweden. The source code and the trademarks were transferred. And from there on, we've been on our own. I'm the share person. We're a team of six developers working on the game engine. We're funded through end user donations, but primarily through partnerships with companies that are interested in Defold or using Defold in some capacity.
It's also source-available on GitHub. Since 2020 we maintain a large repository of open source products related to Defold. And then we have the Defold engine itself with a variant of the Apache license. That's why I say it's source-available and not open source. We can talk about that some other time, maybe. It's also free, there's no upfront costs, no licensing fees, there's no rev share or anything at all. Anyone can use it for free to create games. We don't, do not even charge anything for console access, besides the fact that you also need to, of course, be approved by Nintendo or Sony to get access. It's a 3D game engine, but since we were owned by King for a long time, the focus was on 2d, but you can definitely do 3D games and there are 3D games out there. We have all of the basic, the bells and whistles you need to create the game, and an editor. You script using Lua, there's a code editor in Debugger. There's everything, everything you need to create a game. We also have what we call a zero setup policy. There is a single download, and that's the Defold editor. It runs on Mac, windows, and Linux, all updates. And when you build for any of the supported platforms, you do not need any additional tools. There is no extra setup, no installs. You don't need Xcode, you don't need Android Studio, no SDK or build tools. We take care of all of it, which means that anyone in your team can download and use Defold and produce like a build for iOS or Android in a matter of minutes, basically with no setup needed.
We're also a very small game engine compared to many other cross-platform game engines. And I know that this might be a... People have always opinions about sharing these kind of comparisons. And someone might say that, Hey, you're testing this wrong, but this was like taking an empty project in each of these game engines. And then just building according to the instructions, building a release build and then comparing the size. Defold is significantly smaller for mobile and definitely also smaller for web, which is a good thing because we have a lot of users building for the web. We also focus a lot of our time on the performance of the engines. We need to maintain, good high, stable fps. Even when you run it on a mobile browser on a phone we focus a lot on the memory usage of the engine.
You can run it on really old devices. And we even have games running on a kaiOS feature phone. We also care a lot about the stability. The engine has been around for a long time. There are many commercial games released with it, it's very battle tested. We do monthly releases and we try to never introduce breaking changes. And this is a challenge of course, because things change in the game managing world. But we really take care to not break stuff in every release. It's very infrequent that we do introduce a breaking change. Just some examples. You probably all have heard of Vampire Survivors. There was a game released recently using Defold called Void Scrappers. It really shows how good of a performance you can get with Defold in these kind of hord survival games where you have a ton of enemies and bullets and things going on on the screen at the same time.
And this game was first released on the web then more advanced version on Steam, and then the developer continued to release on Switch all on his own without any prior knowledge. It's really cross platform game engine. Our most successful game on mobile is a title called Family Island by Melsoft Games owned by Moon Active. It has over 50 million installs on Android. They're one of our partners, they found some development. It's a good game, really good. And an example from the web, we have Monkey Mark, which is a relatively new game released on Poki. It really shows how good the game runs on the web or how good the engine runs on the web, and even if you play it in a mobile browser.
And that leads me to talk about games on the web in general. We recently did a survey among our users, and one of the questions was, what platforms are the most important to you? And the the users could pick three of the supported platforms. And HTML5 came out at the top. A lot of our users care about the web. And Android is the second largest platform because it's relatively easy to publish for mobile on Android at least. But we're really super happy to see that HTML5 games is the most important platform to the users, at least in the survey. And we also see this when we talk to our developers, when they share their showcase games, newly released games and so on. And I think it's come down to that now.
There is really mature and good distribution channels for games on the web. You have Poki, CrazyGames, GameDistribution, and a lot of other platforms where you can release your games. And we also hear success stories from our developers. A lot of our developers have focused in on Poki to some extent, on Yandex, and they're making really good money. This is a platform that is easy to release on, and you can actually make a lot of money, and it's definitely a lot easier to release on the web than it is to be successful on mobile. There is a lot of fierce competition on mobile and releasing on the web is simpler and you can release games faster.
Just as an example, the Poki landing page here I just opened it yesterday took a screen grab and there's actually four games on the front page that are made with Defold. It's really a platform where a small game engine such as Defold can have an impact and where developers can be successful. And we can see similar things on the other platforms as well. But Poki, in the case of our users at least, is the platform that they favor. And actually in, in 2022, there was 220 million plays of games made with Defold on Poki alone. It's a huge increase from last year and I hope to see an even bigger increase in 2023.
And what we also see is that, as I mentioned, developers start off with creating a game on the web and releasing it on one of the distribution platforms on the web. And then once they see that they have a potential hit, they consider porting it to different platforms. We have some developers going from the web to steam and switch, and we have some that then go looking for a publisher to publish their game on iOS as well, or Android for that matter. It's really good to see that this is something that you can do with a cross platform game engine, try out games fast on the good platforms you have on the web, and then transition to other platforms as you have some success and some money to fund the release on more platforms. I'd say that now is a really, really good time to be a web game developer. And I really do hope that we can together persuade more developers to release on the web.
All right, coming to Defold, and again, how do we make it possible to release games on the web for our users, and how do we make the engine small? And what are some of the features we have in the engine that makes it a good platform even for web game development? First of all, the game engine is written in C++, but it's not like modern C++, it's more C than C++. We try to keep it simple. There's no templates, no inheritance, no STL, we use simple data structures nothing fancy. It's easy to loop over an array of data structures representing something in the game engine. And that makes it really, really fast. We've also chosen to use ProtoBuff, and I think that's a really good data format to describe game project data, basically.
ProtoBuff has a text version of their format, that's super merge friendly, it's easy to work with in the editor and with external tools. And then when you build, you get really compact binary format to describe your game and your game components and so on. We've also built Defold to be very modular. There are different kinds of systems running the audio and physics and different graphics and render systems. And as a developer, you can also opt to remove stuff that you don't need. If your game doesn't use any of the built in physics engines, you can just with the checkbox replace it with a nullable empty implementation of that system. And so the size we saw, the 980 something kilobytes, that can be further reduced if you like, remove stuff that you don't need. We have a recording api, for instance, to do screen grabs, and if you don't need it, you can just remove it. Super simple, just tick off a checkbox. And you can also extend the engine with additional native code. I'm gonna go into that a bit more in the next couple of slides, but that's also a way for you to, with the small engine, expand it with integrations with third party SDKs and so on.
I mentioned Lua before, we actually use the Lua scripting language for the Game logic. The game developer writes their game logic, yeah, using Lua it's super easy to do interop between Lua and C. That's something that is very nice. It's easy if you need more performance, then Lua can provide. It's easy to write what we call an extension and inter interface with some C code for additional performance. LU has also really small runtime, it's perfect for integrating into Game engine because it doesn't add a lot of overhead. And then we use Lu Ajit, which is a JIT version on steroids. It's super fast and really optimized for, for each of the target platforms that you have. compared to other game engines, we have relatively small public API surface.
The Lua API that the developers have access to write their games, it's relatively small compared to many other engines. What we favor is that you should have all of the APIs to create a game, but we provide the low level building blocks and, those can then be used to build more high level things that you need in your games. For UI, we have very basic building blocks, and then you can use those to compose something that is like a UI system, for instance. And developers can of course share these things. We have an asset portal where they can share their extensions or scripts or additions to the small public API we have. And it's a basic scene view hierarchy. Game objects are the building blocks, the containers, they are basically a transform. They have a position and a rotation and a scale and a position in the world basically. And what you then do as a developer, you add what we call components. And these give the game its life. It could be a Sprite for some 2D image, it could be a script for some logic, it could be sounds, 3D models and so on. You can have factories that can spawn additional game of and so on.
And then if we look at how we use Defold on the web, so we obviously use Emscripten, and so it's still the same game engine written in C but we transpile the JavaScript using Emscripten or to web assembly. and through that we of course get the openGL to WebGL, openAL to Web Audio and TCP to WebSocket for free. We also have support for the Gamepad api, and we do use Lua also on the web. When you play a Defold game on the web, there's still a Lua VM running Lua scripts. And in the case of the web, we actually use the standard Lua 5.1 version and not Lua JIT, because Lua JIT has no target for the web and for the browser environment, but it's still fast enough. We're also exploring an idea to replace the Lua version we have in the engine with a typed Lua version that Roblox is using. But it's only on an experimentation level at this point. We also actually have a community project where you can use TypeScript that gets transpiled into Lua when you build. That's also an option if you really don't like Lua, but it's a good language, so I can recommend learning it.
What we don't have, we don't have WebGPU support, for instance. It's not planned. We have a high cost of maintenance for all of the graphics backends. We already have OpenGL, we have GL Vulkan, MoltenVK, which is translation layer to Metal on Apple, and we have the proprietary APIs for console. Just adding in another graphics backend will add a lot of additional work. And right now we don't really need it, but probably at some point, or if someone wants to fund that development, we can add it, but it's not on the roadmap. We also do not support WebTransport. We have WebSocket support, as I mentioned, but not WebTransport. I think that's something that is interesting for multiplayer games. It's something that we will explore and create as an extension that you can use. WebXR is also not something that our users are asking for, and it's not something we can spend any time on right now. Some things that we do not use that are popular and talked about in web game engines are not on our roadmap as of now at least.
Alright, so I mentioned that you can extend the game engine using what we call a plugin system. You need to add in your game additional native code. We can't package it all into the game, into the standard version of the game engine. And if you're serious about releasing games, you need to interface with a bunch of SDKs. If not, I mean, if you release on Poki, you need to interface with a Poki SDK. If you release on CrazyGames, you need the CrazyGames SDK, you might need Facebook's. If you release on mobile, there's a ton of different third party services that you need to integrate, like monetization, obviously various ad frameworks, analytics, and so on. There's a lot of things that we do not provide in the standard build of Defold, but we also do provide a huge list of ready-to-use extensions.
We have for all of the popular services that you need to integrate with, but it all starts, if you want to create your own, with some kind of C++ entry point because the engine is in C++. And then you need to set up some Lua bindings so that you can call your C++ code from Lua. And you want to think about the Lua bindings and your game should be cross platform. You shouldn't have to think about: is this game running on the web or, or mobile, or is it the desktop version? You should always be able to use the same Lua code. You have to think about making the Lua bindings as platform agnostic as possible, and you take care of the platform specific stuff under the hood basically.
In your extension or in the engine and this may seem like it goes against what I said about the zero setup policy, because if you have additional native code, it needs to be built somehow. And what we do is that we have build servers that are provided for free. You can also host them yourself if you want to. If you build a project with some additional native code, we identify that there is native code, we send it to the build server, we compile and link it, and then send back a custom engine with the standard set of features plus your extensions, and then that version of the engine is cashed locally and used when you build for your target platforms. It's a really convenient system. It takes care of all of the setup burden for the developer.
And I'll just briefly show an example and then we're done with this presentation. Let's say that we have the Facebook SDK, so that runs on Android, iOS, and the web, but we still need a single Lua API to interact with it. Your game shouldn't care if it's running on a mobile or on the web. The API from the developer's point of view, from Lua, should be basically the same. To achieve this, we need some wrapper code around the JavaScript or Objective C or Java SDK that's provided on the different platforms. It starts with some binding code for the Lua API. Then we have some generic C++ code per API function, then some platform specific C++ code that then calls into the native code. And I'm just gonna show some screenshots here.
You're very briefly explaining it. It starts by a declaration, a macro that declares that this is an extension. It has a bunch of lifecycle functions. You can run some code when your app starts, when it shuts down each frame that you update, or when you get some kind of system event. Minimizing or maximizing, for instance during initialization, we use the Lua State and the Lua API to set up our user facing Lua API. A couple of functions here to initialize and get the version and to log out and get an access token. This is the entry point with the gen generic setup of, of a Lua API. Then if we look at the init function, we have some generic looking C++ code, nothing fancy and you can see that we call to platform underscore and then something.
That's a call out to a platform specific implementation of the Facebook initialization function basically. For Android, this function looks like something like this. We set up some general Java native interface to call out to Java. And if we look at the version for the web instead we have some code that calls out into JavaScript land, basically to an Emscripten library. Here we interface with JavaScript code and the Facebook SDK that is loaded in the browser page that the game is running in. That's basically it, it's a couple of layers of wrapping around it, but it gives you a very nice, easy to use API for the developers. All of the build steps are taken care of by our build servers. As a game developer, it's super easy to integrate these extensions and use them from one API, where you don't have to care about the underlying platform. And this goes for showing ads or handling in-purchases on mobile or any other service integration basically. That's it. That's a wrap. Thank you for listening. Does anyone have any questions? You can also just send me an email or message. I realize that I don't have my email here, but it's Bjorn Defold se if you wanna reach out and via email instead.