@jas490 Is it for your chromebook?
What I love about the HTML5 target is how you simply have to press "run" on your desktop and open up the debug url on your chromebook to enjoy your last version of things.
I'm using the HTML5 target quite extensively for rapid prototyping and networking development... The easy of deployment is lovely.
Performance wise, the purists will say performances are not good... I don't understand it. With
webgl, you get almost the same end-results and performances than you'd get with your desktop version. (I say almost... 60fps is a target. Not always easy to reach depending on your game).
--
I first purchased the HTML5 target for my daughter so she could create a game and play with it on our chromebook.
Turns out.. I use that license more than the Desktop version now for my personal projects.
--
It all boiles down to your intent.
I find it rather hard to monetize an html games... You have to go a looooong way to make some money out of it. So if your intent is to make money... that's probably not a good way to go.
I find it easier to get visibility on an html games. Publishing on facebook, on itch.io, on newground or even on a cheap Lamp server. If your intent is to build a portfolio or show off to your friends. That's probably a good way to go.
I find it a littlebit harder to come up with a Smooth experience on HTML5. You will have a few more friction points and a few more bugs. If you are just fooling around throwing ideas for yourself. I'd stick with the Desktop version for a little while. Learn the platform, enjoy it. Desktop has less friction points and is all you should need for a while.
--
Few pitfall to remember when porting an existing game... the browser is a more restrictive sandbox...
--
- File access is completly different.
- - For load/save game state... nothing major. Try to stay bellow the 1M localstorage limit when saving your buffer.
- - If you use files in any other way (saving sprites, saving surfaces, listing files, creating files, downloading content, etc) you will have to revisit it. It won't be possible in HTML5.
- Different Security measure
- - sound: You can't play a sound before the user have interacted with the browser (click) so your splashscreen might need some fixing.
- -
couple of other little tweak to do in iframe.
-
Framerate
- - Unlike the Desktop version, which use clock speed. The Browsers are tied to the monitor refresh rate and GMS rely on it for timing and dispatching.
- -
fps_real will mostlikely always be
60 when using a 60hz monitor. If you are using webgl and your gamespeed is at 60fps don't worry about it.
- Extensions
- - If you use extensions from the marketplace, make sure they support html5 (most of them dont...)
- - If you make your own extensions... that double the work.
- Debugging/Profiling
- - You can no longer put breakpoint in GMS, you need to use the Browser's debugger and profiler. It forces you to learn another tool stack.
Couple of other more advanced area.. buffers, networking (udp vs websockets), 32 bit arithmetics, couple of internal bugs...
The devil is in the detail... if you want to support 2 platforms with the same codebase, expect to throw in a few decision split.
GML:
if (os_browser == browser_not_a_browser)
{
//Desktop version
}
else
{
//Browser version
}
I second that...
This is the single most frustrating thing about the HTML5 target.
Your texture group get mixed up. Whenever you add some sprites to your projects cash are not well invalidated.
Your animation will start blinking like crazy after a build. Don't panic if that happens.. just clean and rebuild.
It's actually quite annoying at the beginning of a project when you start adding your images.
