Choosing a Game Engine or Framework for HTML Game Development

Hello ladies and gentlemen, this is Mike Fleischer and welcome to my Web Game Dev Summit. Now I run the channel GameFromScratch and GameFromScratch.com for the last decade, and over that decade I have covered literally hundreds of game engines and frameworks. And we've never been more spoiled for choice. If you want to develop a game these days, there are so many options out there commercial and free, open source and closed source. You're absolutely spoiled for choice.

Now the problem with being spoiled for choice is too many choices, and that makes any decision harder, especially when you're just starting out. So if you're trying to figure out what technology or game engine to use for your next web-based game, hopefully this talk will help. There are two major approaches to how you can develop a game in the browser. One is you can take the native approach, basically develop it like you would any other web-based application. There are a number of engines and frameworks out there that work, you're typing directly in JavaScript. This makes a lot of sense if your primary publishing platform is for the web. If your lead target is the web, and the most important platform is the web, this is a great way to go. It gives you nice tight integration back to the browser itself. It makes your debugging experience a little bit easier. The other option is basically compiled. This is treating your web browser more or less like it was a virtual machine. Using technology such as WebAssembly or ASMJS as a backfill, and technology such as Emscripten, the tool chains for your game engine or framework of choice, compiles down to almost a byte code that runs inside of your browser. This doesn't generally have tight integration with the browser, at least not when jumping But the nice approach to the compiled approach is you're treating the web basically just as another platform. So instead of compiling for Windows and Mac and mobile and so on, you can add web as an additional target. This is the approach that a lot of traditional game engines take.

Complimentary to the decision of working natively in the browser or compiling it using a technology such as WebAssembly and Emscripten, you also have pretty much three different major decisions on terms of what kind of game technology you wish to use to develop your game. At the top, you've got the idea of just using a standard off-the-shelf game engine, the likes of Unity, Unreal, Godot. You know them. Basically, they treat the web as just another platform. Sometimes it's just a matter of even just a build for web and your game is created. Now, on top of that, you also have some of the HTML5 specific 3D and 2D game engines out there. We're going to cover some of those in this video as well. And then, finally, you have the option of building upon a framework or a collection of libraries that are out there and more or less rolling your own. Now, traditionally, I wouldn't recommend rolling your own game engine because there is a ton more work than you realize, but when it comes to web development, there are so many libraries and frameworks such as Three.js or Box Physics, etc., that you can build upon, that the idea of making your own game engine isn't actually as daunting as it would be in a lot of other scenarios. And one of the things about web development in general and JavaScript technologies is they tend to be very modular in approach.

And it's more a matter of fitting together Lego pieces and building your own engine out of out-of-the-box components as opposed to starting everything from scratch. So we're going to look at some of those building blocks you could also work with as well.

But first, let's talk about traditional game engines. Start things off by talking about some of the traditional game engines that all have some form of web export. I think now in an age where browser plugins are no longer a thing, you're basically looking at an Emscripten backend compiling to WebAssembly in some form for all of these things we were about to mention. And these are great choices, especially if you are already developing a game and you just want to add web as another platform.

And we're going to start with the most obvious example. Now I'm not going to cover all the game engines options out there that compile to web because there are just so many of them. We're going to talk about some of the biggest players in this space. And the biggest player straight out is Unity. Now Unity has the most developers. It has the biggest community. It probably has the broadest platform support out there. It is a fully functioning 3D and 2D game engine. Your primary scripting language is going to be the C sharp programming language. But there are a number of visual scripting options including two that are officially supported by Unity themselves. It has the largest volume of learning materials out there. And quite frankly, if you are not doing web first and you don't know any better which one to pick, Unity is probably as easy of a choice as you could make, just because the community is as good as it gets. The Unity community is massive. That means there are a number of training materials, there are a number of tutorials, there are a number of people that you can talk to if you need help and so on. So Unity is an excellent option, especially if the web isn't your lead platform. If you just want to add another platform to the list, if you're developing for desktop and mobile and web, well Unity could be a good choice.

Another option that used to exist was Unreal Engine. Now Unreal Engine has actually deprecated their web target support. There are third-party plugins that bring this functionality there but I don't think I would recommend Unreal Engine for anyone unless you were already working on an Unreal Engine project because Unreal just hasn't really expanded that much in the web space. There are ways to do it and there are third-parties working on picking up where Epic Games dumped their support. But just know Unreal Engine and Unity are probably the closest direct competitors that you can find when it comes to developing web-based titles. Not really. Unreal Engine is way behind in that regard. On the engine side if you're looking more towards free and specifically open source another option for you is the Godot Engine.

Now both Unreal and Unity have licensing fees or per seat fees attached to them. Unity is not open source at all while Unreal Engine is source available. Godot is fully open source MIT licensed 2D 3D game engine. Now it does not have the scope of either Unreal or Unity. Probably doesn't have the graphic fidelity on high end 3D of either of those. It does not have the gigantic resources behind those engines. But what it does have is a massive community behind it and a heck of a lot of potential. So Godot in the 2D space has been very strong. Getting better with each release. Godot on the 3D side of things is definitely improving. And upcoming hopefully in this calendar year, perhaps early next year we should see the Godot 4 engine with much better 3D visuals as well. The Godot approach is to use the WebAssembly compilation as well. In fact you can actually compile Godot, the editor and tools to run in the browser. So Godot web support is actually very well tested, battle tested and a great opportunity there.

Today we're going to talk about two 2D game engine options in this space, traditional game engines. The first one is the Default game engine. Now this one was from King, the makers of pretty much every mobile game you've probably ever played in the past. They ultimately mostly open sourced the code. It is now completely free to use and the code is entirely available, although it is not under an OSI standard license, so I can't call it open source per se. Default is an excellent game engine. I've been a big fan of it for a very long time. They have their own unique approach to things. The Lua programming language is your primary way of communicating and it uses a messaging based system to keep things decoupled. I would highly recommend checking Default out. It's a different approach to it. It may not appeal to everybody, but I quite like the way it works. Now this ultimately compiles out to WebAssembly as well, so it does not create human readable browser code as a result, but you can also create desktop mobile versions as well, and the performance is quite good.

Now the other option is GameMaker Studio. Now GameMaker Studio has been around for 20 plus years now. Traditionally, a 2D based game engine. It was recently acquired by Opera, the browser maker, and so I'm going to imagine they're going to put more and more emphasis on the HTML side of the equation, but GameMaker has targets for a number of different platforms as well.

Again, Default and GameMaker are primarily focusing on the 2D space. GameMaker uses its own GameMaker script as well as a 2D drag and drop setup for the programming logic. It's got its own approach to things as well. It's a very self-contained environment. It's got all the tooling you need in one place. It is, however, a commercial project, but they did make an evaluation version of it that's fully functioning and freely available. So long overdue. I'm glad to see that there is finally that more accessible version of GameMaker out there. So if you want to go ahead and check out GameMaker, it is an option for web-based game development as well and with the fact that they are now owned by Opera, I expect to see more and more of a focus on the web going forward.

Now on to game engines where the web is actually the primary development platform. If you're looking for the equivalent of Unity but in the web space, that is definitely PlayCanvas. PlayCanvas is entirely browser-based. You do your editing directly inside of PlayCanvas, but it gives you a full functioning 3D World Editor, full 3D model importing support, animation support, everything else you would expect. So if you're looking to create a 3D game with the web as your primary platform on the web, it's hard to go wrong with PlayCanvas. Now PlayCanvas is commercial. Portions of it such as the UI Library PC UI have been made open source, but otherwise it is a subscription-based software. If you're looking for something that is more fully open source but has a little bit less of the tooling, that would be Babylon.js. Babylon.js was heavily supported by Microsoft. It is an open source 3D game engine and framework. You don't really have the Unity-like editing environments, but it is on the other hand completely and utterly open source. So if you're looking to do 3D as primary web as your platform engines, definitely PlayCanvas and Babylon.js are the two to look at. Another option in terms of 3D Unity-like game engines with the web as the primary platform you could consider is Cocos Creator. Cocos Creator itself isn't open source, but it is free to use and it is built on top of an open source framework. It provides a kind of a Unity light functionality, it's not as many features as you'd expect in Unity, but most of what you'd need to create 3D or 2D games is there. 3D model importing, animation support, UI layer, etc. It's very popular in China, but it does have English documentation and an English community, it's just the Asian community is much larger around Cocos Creator.

Do not mix Cocos Creator up with Cocos 2D. We will get back to that one in just a second when we start talking about 2D.

On the topic of 2D, we have a few options there. On the game engine side, a lot of the actual HTML5 based development tools are actually visual in nature where you use a visual programming language and it generates JavaScript code for you. The two most foremost I can think of are Construct 3, which is subscription based software where you use a visual layout kind of set up to create your games, but you can also extend them using the JavaScript language as well as the open source G develop, which again, uses sort of a spreadsheet style of programming, and you can extend using the JavaScript language. Both of those output a web based project in the end. They both provide a lot of the 2D tooling you would need to create a game. They're both primarily 2D only engines, although they both have nascent 3D support as well, but it definitely don't really want to consider either of those for 3D development right now. But for 2D, especially if you are looking for a slightly more visual approach, both are good options. Another one there in that area is Stencil. Now this is a visual programming language. It actually uses hacks, but it can compile for the web based platforms as well. So if you want to work visually, in a 2D environment, Stencil is another one to consider checking out. It is in a weird sort of free, not free hybrid licensing that you're going to want to look at there.

So that is it for most of the major game engines I want to touch on. But then we kind of get into the world of frameworks. Now this is basically kind of like game engines, but more modular, more code based, a little bit less of the overarching things to hold them together. So maybe you're missing a level editor or something to that effect. But here you've got a number of different options. And you can use these to either build up to your own game engine, or you can build your game entirely using one of these frameworks. Now some of the more top level frameworks are PhaserJS, MelonJS and Cocos2DJS. Now Cocos2D started life as, I believe it was Python way back in the day, but there's been ported to just about every platform you can imagine, including a web based platform. This is what ultimately Cocos Creator is built on top of and it provides all of the functionality that you can really imagine for creating a game. It's not the tooling on top. PhaserJS is probably my favorite, personally, HTML5 code based 2D framework. It provides, you know, all the things you would need for sprite sheets, atlases, playing sound, loading levels, etc. And then you've got MelonJS, which is kind of similar but a little bit smaller overall than PhaserJS. So if you want to build a 2D game, any one of those frameworks is a great solid choice. Now in the 3D side of things, you've got one very predominant framework, and that's a tool called 3JS. Now 3JS provides a ton of functionality.

A WebGL abstraction layer, 3D model loading support, scene graph management, object loading, etc. Basically all of the stuff you need to create your own engine, except for perhaps the tooling, is available in 3JS.

In fact, there's other tools such as A-Frame, which is a VR framework which uses an HTML type mark up for creating 3D worlds. It is actually built on top of 3JS. You're gonna find a number of game engines are either built on top of or built using 3JS. It's definitely a powerful building block for building your own 3D titles.

You can build your game directly in 3JS if you wish or you could build your toolchain on top of it. But there are another other JavaScript-based libraries of interest to game developers. On the physics side of things, you've got a port of Box2D, Box2D is probably the most popular 2D physics engine out there. But there's also MatterJS and PlankJS. I don't actually have experience with either of those but they're both 2D game frameworks that run directly in the browser.

On top of that, on the 3D side of things, we've got the AmmoJS which is a bullet 3D physics port for doing 3D simulations, physical simulations. And then we've got OIMO, no idea how to actually pronounce that. And I'm not actually overwhelmingly competent with that library either so I'm not gonna expand upon it other than to let you know. For physics, those are your options out there.

On top of that, we've also got a great rendering library you should probably be aware of. That a lot of these including for example, Phaser and I believe Melon and possibly Cocos2D all build a pawn and that is PixyJS. Now PixyJS basically just abstracts away the rendering layer. So if you need to just do as fast as possible 2D drawing, this makes it so you don't need to know about WebGL or if you're doing fallback rendering, using some other method, PixyJS just takes care of all that for you and a whole lot more. In a lot of ways, it is to 2D what 3JS is to 3D.

So if you want to go ahead and roll your own engine, the nice thing is you've got all these various libraries out there that you can bring together kind of like virtual LEGO blocks, put them together and create an engine of your own, or you can, your game doesn't necessarily need an engine if you're not going to be reusing the code, and it's simple enough in nature. You can just build it right on top of one of these frameworks and go from there so you don't need an engine at all in the end.

If you're going to go the roll it your own kind of approach, or you're using a library or framework that doesn't necessarily provide all of the tooling that you might get from a more full fat game engine, you're going to probably still need some kind of a 2D level design tool. And in this space, I have two major recommendations. Now, the oldest one that's been around for a long time is the Tiled open source project. Tiled is capable of creating not only 2D maps, but also isometric and hexagraphic projection style maps. And then another one in this space that's much younger is the LDTK, or the Level Design Toolkit. Now both of those are excellent tools for composing, visually composing your world as well as populating it, setting up barriers and gameplay objects, etc. So if you are going to go with the homebrew kind of approach, you don't need to create these tools from scratch either. You could bring in tools such as LDTK and Tiled and basically create your own custom game engine using such resources.

Another area you may have to consider is audio support, especially if you are rolling your own. If you use something like Phaser, it has support for audio built in, and it's probably built across some of the libraries we are actually going to be talking about now, but if you need to add audio to your own framework or game engine, there are a couple of options out there. And they're mostly built on top of web audio with fallbacks to the browser audio support. And they kind of take care of those complexities for you. Two of the ones that you probably want to be aware of are Sound.js and Howler.js. Both are great for kind of hiding away the complexities of dealing with audio and kind of getting away from some of the browsers eccentricities that you might face otherwise. They are both open source projects but they are not it by any means and none of this is a comprehensive list. There are a ton of other libraries out there. I just want you to be aware that if you want to make your own engine or framework, there are all of these pieces out there, most of them open source, that you can pull from to create your own engine with a fraction of the work that you would traditionally see in these spaces if you didn't, you know, build on the work of others.

From this point, you've got a pretty good basis of the options that are out there from traditional game engines that can target the web to more web focused engines to visual programming languages and more that you could use to create your game and then the number of frameworks you could use to roll your own.

Choosing the right engine is just really a matter of fitting your needs as best as possible. Also know that this list was by no means comprehensive. There are a ton more options out there. Just so you know, as it gets a little bit more obscure, the idea of finding support for that engine also gets harder. If you want to hire somebody or try and find an answer to a problem that has you stumped, the bigger the engine, the bigger the community, the bigger the likelihood of finding that problem or person out there comes up.

On top of choosing the right engine, you can probably go through a series of questions to probably sort down which one will work best for you. Now the easiest one we can start with is my game 2D or 3D? Just by answering that one alone, if you're creating a 3D game, we just knocked about half the game engines off the list for example. Now the next really easy question is, do I have any money? If you do not have any money available, suddenly the licensing fees, the per seat licensing fees of something like Unity may not appeal to you that much. Keep in mind, Unity costs X amount per seat if you make more than $100,000 a year USD. So if you're trying to keep it as cheap as possible, you may want to stay away from the money or the more commercial engines in this space. Now if you don't care about money, well that makes it a wide open category.

Now the same thing about open source, does access to the source code matter to you? Do you need it to be fully open source, something like the Godot game engine, mostly open source like the default engine, or source available like the Unreal Engine. If these are all important to you, if access to the source code is really important to you, well then you can again knock about half of the engines off the list. So making decisions really always comes down to, you know, bucketing things down and process of elimination.

Now do also keep in mind, one of the big decisions is going to be, what is my primary platform? If you are developing for web first, well web first technology makes a lot of sense. Now do keep in mind though, when you deploy web technologies, you do need to put it in some kind of a wrapper layer such as Electron. Now if you do this, you're not going to have the same performance that you would have probably got if you'd gone native. So for example, if you develop a game in Unreal or Unity for the desktop, it will probably outperform a web based 3D application running in something like Electron. It's just the nature of the beast. So if you need to get that maximum performance, web first probably isn't for you unless your platform is specifically the web. None of the above is also an option. And this is where you start getting into the idea of rolling your own. Now in the desktop world, I would basically never recommend someone write their own game engine unless it was some kind of a learning experience. You'll generally spend more time writing the engine, writing the tools than you will running your game. Often by an order of magnitude. In the web world though, it is a little bit different. Here you've got a number of projects, shoulders of giants that you could build on top of. If you're working in the 3D space, 3JS provides 80 plus percent of the functionality you will need. If you need audio libraries, they are out there.

If you need physical libraries, they are out there. It's mostly a matter of pulling these things together. And then on the 2D side of things, there are a number of renderers and physics engines that we already saw, as well as frameworks that do 90 percent of what your 2D game will require. Things like Phaser or Cocos. You can build on top of those and just build your game logic or your own derived game engine on top. Rolling your own is always an option.

I've given you a number of suggestions in a broad number of categories. Now I'm going to give you probably what would be my suggestion in each one. What I would personally choose. You could take this with a giant grain of salt, and it's under a variety of different scenarios. The number one priority for me was platforms. I wanted to make my game run on as many platforms as possible. So if you are interested in getting a mobile target, maybe VR, web, you name it, it's hard to beat Unity. So if you want to have as broad a support as possible, the Unity game engine is sort of like the IBM. Nobody ever got fired for picking IBM. Nobody ever got fired for picking Unity, especially for these kind of games.

However, if you're more budget constrained or if you're more aligned with an open source ethos, well, you've got the Godot game engine. The Godot game engine doesn't have the research and development money behind it, the huge amount of employees behind it you would see with something like Unity or Unreal Engine. It is, on the other hand, fully open source and has a very active and engaged community, and it is expanding at a heck of a rate. And they're putting a fair bit of emphasis on web support. So if my alignment was more I don't want to spend any money or I prefer open source or both of the above, the Godot engine is probably what I would go with.

Now if I was writing a 2D game, same thing, I would probably actually pick the Default engine. Now Default is not going to be for everyone, especially if you can't stand the Lua language, but I highly recommend if you're looking at creating a 2D game, do check out Default. Again, it's not going to be for everyone. They have their very, they're the most unique game engine on the list today. They take a very unconventional approach to things and it speaks to me. I like the way that code is organized, I like the level tools that you get with it. It's just a very different approach. So if you're interested in something a bit different, 2D and mostly open source, do check out Default. Now if you're into more of a visual programming, you don't want to get into coding at all, that's where options like GDevelop, Construct 3 and Stencil are good options.

GDevelop being the cheapest of those options there, while Construct 3 is probably the most mature of those options. Those are all primarily 2D. I know again, Construct, for example, is some beginnings of 3D support at this point in time, but I wouldn't even consider any of those for 3D game development.

And of course if I was doing web as my primary target, so if I was creating a 3D web only game, I would use either Babylon or PlayCanvas. I don't know which one. If I was more important about the level construction and the tool kind of things, I would probably go with PlayCanvas. If I was trying to save money or if I was working a little bit more at the code level, I would probably go with BabylonJS. I believe there's a really big update coming for BabylonJS any day now. It would be interesting to see what happens there.

And of course, if I was looking at creating a 2D game, a little bit more code centric, or if I wanted to integrate external tools, there are frameworks such as Phaser. And of course, if you're going to build your own, I highly recommend checking out the 3JS JavaScript framework for 3D game development.

Ladies and gentlemen, it is the end of the talk. Hopefully I helped you a little bit, if you're looking and trying to figure out what engine out there I should pick for creating my next game. If you're also interested in learning more about game engines and tools, et cetera, go check out Game From Scratch. Hopefully you will find something there interesting as well. So, I hope you enjoyed this talk, and I will talk to you all later.