For Ludum Dare 24, I worked on my project in Game Maker: Studio, and did most of my development work targeting HTMl5. I produced a Windows build as well as an HTML5 build, and have spent a lot of time enhancing the game since the compo deadline.
This has afforded me the opportunity to become much more familiar with GameMaker’s HTML5 shortcomings, so it seems like a good time to follow up on my initial impressions from the January beta. While most of the basic features are solid, there’s still a lot of bugs, unsupported features, and inconsistent implementations in the HTML5 runner. Unfortunately, it adds up to make the HTML5 module a bit lacking for serious game development.
Don’t get me wrong — it’s still very possible to make a decent, playable HTML5 game with GameMaker Studio. Just, if you’re hoping to be able to do absolutely everything in HTML5 as you can in Windows, you’re in for a long wait. While much of the framework runs equivalently, there are a lot of minor differences. And while these are minor details, producing a polished, professional game is all about minor details, and getting them right.
I still think there is a lot of promise for HTML5, but W3C, WHATWG, and the major browser developers have to pull together to solidify the technology standards. YYG can’t do some of the things with the HTML5 runner that they currently do in the Windows runner, without this happening. To their credit, they have been releasing updates rapidly, patching bugs almost weekly.
Unfortunately, this means that HTML5 games built in GameMaker Studio are not going to be as pretty or as polished as Flash can be, at least for the foreseeable future. Of course, Flash has many of its own problems: with the rise of the open HTML5 standards, Flash’s future is in doubt, and it seems to be in decline, so it’s not like it’s a great platform to pick up right now if you’re not already well versed in it. Unfortunately, the usurper isn’t quite ready yet. The W3C recently announced the HTML5 recommendation will be finalized in 2014, but even once that has been accomplished, it’s still up to the browser developers to support the standard consistently and completely — something they were never able to accomplish with HTML4. This points to HTML5 being a less solid platform than game developers might hope for.
Here’s some of the shortcomings I ran into while developing Karyote.
Color blending
The Game Maker HTML5 runner doesn’t support all the color blending modes that the Windows runner does. Color blending effects really make games look great when done well, so this is a huge disappointment graphically. I submitted a bug report for this and YYG closed it saying they can’t do anything to address it until the web standards catch up.
Surfaces
Surfaces kindof work in HTML5, but I have a major problem with my implementation in Karyote. Somehow, the game broke when I added a drawing surface, such that in normal run mode, most of the objects in the game don’t draw/don’t exist. I don’t have any understanding why, either.
It works fine in Windows, but in my HTML5 build it doesn’t work unless running in debug mode. The problem only exists when the game is not running in debug_mode, so debug mode is not helpful for me to trouble shoot with. In fact, the running version that I have up of the enhanced build currently is running in debug_mode, with the debug console hidden with CSS.
Creating sprites – no control over collision masks
This was my first game where I implemented procedurally generated sprites, and they work great in my Windows build, but not in HTML5. For some reason, when I create my sprite in HTML5, they don’t get a correct collision mask, and end up with a mask that is much too large, resulting in poor hit detection. It seems the collision mask is set to match the bounding box of the sprite, rather than the image. In the Windows build, the sprite automatically gets an accurate, precise collision mask.
There’s a gml function sprite_collision_mask() which is supposed to allow me to set the collision mask, but this doesn’t work in HTML5, either. In reading up on the issue, I learned this is a bug, and there’s presently a workaround available by using sprite_duplicate(), but this approach apparently can cause excess memory consumption and/or performance issues.
Drawing round objects are approximated
If I draw_circle() in gml, I don’t get a true circle. I get a polygon which has enough sides to reasonably approximate a circle, as long as the radius is sufficiently small. For even a moderately sized circle, you can see the flat edges and corners. Smooth, scalable vector graphics like you’d expect to see in an SVG or Flash animation don’t seem to be implemented yet.
Update: There’s a gml function, draw_set_circle_precision(), which can be used to set the number of sides in your circle-approximating polygon between 4 and 64. The more sides in your pseudo-circle, the slower they are drawn. This still isn’t a true circle, and will still have smoothness issues when scaled very large, but it’s better than nothing.
Conclusion
I still see much potential for HTML5 games, but until these issues have been fixed, it’s going to be hard for GM:Studio developers to equal the graphical quality of a good Flash developer. HTML5 is the heir apparent to replace Flash, but it’s still emerging and has yet to establish itself as a mature technology, and it will likely be a few years before this will happen.
Meanwhile, Flash is not the best game development platform, either, and it’s not the best web application platform, and while it’s under steady assault due to the mobile market spurning it, it’s still a more mature technology, and there are game development frameworks for it. While I can’t really recommend Flash to a new developer, if you’re a seasoned Flash developer you may want to stick with Flash for web browser games for a while longer yet, unless you really want to reach the mobile device market yet don’t want to do native development for some reason. But really, the answer for mobile devices is to do native development — the difference between a native Android or iOS game and what can be delivered through HTML5 is like night and day.
Or, if you’re really looking to make web browser games, you may want to take a look at some of the competing technologies, such as Construct, or Unity 3D, native HTML5, or something else.
GameMaker has some definite strengths, and is making steady strides, but the battle is far from over and there are other legitimate contenders in the market.
If you use GameMaker for other platforms, the HTML5 module is still worthwhile, but you’re not going to be able to do absolutely everything you want to be able to do with it. Buying it now still gives you a lot of capabilities, and if you haven’t yet, you’ll probably want to get started now in order to get familiar with them so that you’ll be ready to deliver robust, high quality games once the technology catches up. Waiting until the platform is perfect before jumping in is just not a good idea, as you want to have as much of a head start as you can get to sharpen your skills.
You’ll need to HTML5-ify a version of your project to work around some of the limitations of HTML5. Use your source control and fork a branch for your HMTL5 customizations and workarounds.
An HTML5 game has a lot of potential to be a good way to entice players to try your game, and may lead them to download your other builds, by providing a limited demo that runs right in their browser. And there are plenty of games that you can make right now that are “fully featured” as long as you don’t require the things that HTML5 isn’t capable of delivering right now. But if you want something with a lot of eye candy, the equal to what you can currently do on your Windows GameMaker projects, it’s just not there today.