The devil's advocate: Status quo of HTML5 gaming

I really don't want to be provocative, but some might get that impression when reading this. Please bear in mind that I'm a kind guy <img src="smileys/smiley1.gif" border="0" align="middle" />

So, I was a fanatic for Construct Classic. When CC was said to be retired, I withdrawed from the CC forums. C2 was lacking too many features I was used to. Instead I concentrated on my music.

Starting with r139 I gave it another try. After a few weeks of playing around, testing this and that, my impression is:

HTML5 has still a long way to go before consistent gaming is feasible.

It's not Scirra's or Ashley's fault, on the contrary, without C2 it would be much more worse.

The main aspect in gaming is to provide the same gaming experience to every gamer. It's this consistency that I miss in HTML5/Javascript gaming.

Just a simple example: You use a short loop sample and play it looped using the audio plugin. The gamer who's using Chrome will hear what you intended. The gamer using Firefox will hear a large gap between consecutive plays of the loop. Why? Because Chrome fully supports Web Audio, while Firefox doesn't.

Another one: For every audio used in your game, you need 3 files. The original, a ogg and a aac version. Why? Because IE and Safari forces AAC and Firefox ogg. Chrome, thank god, doesn't care and just supports all.

But this doubles the amount of data needed for your game.

And a third one: Chrome supports WebGL, Firefox partly (at least not on my system), and IE will never ever support it, as long as DirectX exists.

There are many more issues, and I'm sure most of you already stumbled upon them. That's where encapsulated solutions like flash have an advantage. It's unimportant on which browser or system the game runs, it's always using the same features/technologies.

And to be honest: As long as HTML5 gaming is subject to a stupid trial of strength between just 4 companies (Microsoft, Apple, Google, Mozilla), that hinder the progress of HTML5 gaming for all people around the world, I just can't hop on the train. Too many obstacles that just aren't needed.

If all developers of HTML5 games would act as one big voice, well, that could possibly be power enough to enforce uniform standards, like ogg support, WebGL support, etc.

But I'm afraid it will keep being a 4 companies' struggle.

tulamide

There is absolutely nothing wrong in playing devil's advocate as it can stimulate healthy debate.

I do agree with many points you make, but then, I was an early adopter in support of CC, not C2.

As it is, I honestly (my opinion here) think that the way the industry is going in just targeting the transient mobile market is a mistake, that will ultimately destroy the game industry. There is just not enough profit in it for the number of people targeting it.

There is also a ridiculous amount of generic cloning taking place, meaning innovation is seriously hindered.

Luckily, I was never in this for financial reasons, but as an enthusiastic amateur.

One of my favorite sayings is "You don't go to war with what you want, you go with what you have."

That being said, you just have to know when to pick the fight.

The tools are there, you have to approach things differently.

You plan out every little detail.

Pick a platform, and if you can extend to others so be it.

For example, memory is limited, so you do things small.

Casual games are usually pretty small, but things like rts, and rpg's are huge. One way to deal with that is make the game in parts, episodic if you will. The net is perfect for that, once more that can work fairly well with Node-Webkit.

On the one hand, I like the concept of HTML5 games, but there will always be the browser wars that interfere with one consistent platform. I had wanted to make a game for my friends and family relating a family tale while playing. it was a great idea, and it was running great in Chrome. I didn;t test it in IE or FireFox because who uses those crummy browsers, right? Turns out most of my family did, and the game had horrible performance and lags. True, it's purely my fault for not testing in those browsers, but it's such a PITA juggling multiple browsers.

And this isn't a new thing either. browsers have always had, and probably always will have major incompatibilities. IE, being a Microsoft product tries to set their own standards, which the rest of the industry does their best to either avoid or side-step (understandibly so).

As long as the browser battles/wars continue, I just don't see HTML5 as a stable enough platform to try and develop for/with.

And Safari, lets not forget Safari, damn offline cache!! damn f***** lack of sound!

Another approach: rather than relying on browsers, use wrappers like node-webkit and coccoonjs. This is a different deployment model, but at least its consistent.

So CC output consistently between all the platforms and that is what you miss?

Just a simple example: You use a short loop sample and play it looped using the audio plugin. The gamer who's using Chrome will hear what you intended. The gamer using Firefox will hear a large gap between consecutive plays of the loop. Why? Because Chrome fully supports Web Audio, while Firefox doesn't.

I've not run into this problem myself, and I'd be interested in seeing an example. I bet 50p I can fix it :D

On a side note, when developing on Windows Phone, this issue even occurs with native development.

Another one: For every audio used in your game, you need 3 files. The original, a ogg and a aac version. Why? Because IE and Safari forces AAC and Firefox ogg. Chrome, thank god, doesn't care and just supports all.

But this doubles the amount of data needed for your game.

It doubles the filesize, but only the relevent audio is downloaded by the user. When packaging as native you can just remove the unnecessary audio files.

And a third one: Chrome supports WebGL, Firefox partly (at least not on my system), and IE will never ever support it, as long as DirectX exists.

IE does now support WebGL and I've not had issue with Firefox myself (FirefoxOS on the other hand...).

So yeah, I'd contest your points :)

newt

The download size for an rpg or rts game may be a bit on the larger size, however the memory usage can still be greatly optimized. I'm currently making an rpg and have very low memory usage (I'll be posting a demo soon). There is potential but even so, C2 isn't as strong as your generic programming language but it does provide multiple exports which is why I like to use it. Also one thing to note is that Html5 is advancing and is still considered "new technology" which is why it hasn't yet been used to its full potential.

tulamide

I'm currently not using any webgl effects but am still able to get decent results in terms of what I want to do. As for sound I guess I can see where your getting at but there are methods to work around with it and get similar results on all browsers.

I will contest the points.

1. Apparently HTML5/JS can't create the same gaming experience. I will contest this. Language is not relevant to gaming experience. Developers and what they can manage with the tools they have hand matter. I assure a good team can provide some fantastic gaming experience with HTML5/JS. Keep in mind that Unity was in the same situation in the very early days. No one used Unity for "serious" games until a few major releases came and developers really picked up the steam.

2. HTML5/JS are not browsers. They are languages. The complaint is the run time environments(RTE) of the language. This is valid. however if you abandon the idea of supporting different RTEs and instead focus on a single RTE(NodeWebkit, CocoonJS...) you will make life easier. If you MUST abide by the limitations of supporting many RTEs.

However keep in mind that this is the same problem across ALL video games. PC is not the same language as PS3, 360(close), Linux, Wii, GC, DS..... all of these different hardwares give the developers who seek cross distribution the same headache... actually in fact using the browser RTE is less of pain as it's shared language. Just use common denomination of browser RTE and your good to go.

Keep in mind that there were game programmers working with with only 256kb disc storage, 640kb ram, 16 colours(and i'm being generous). If people can make robust RPG's that founded companies like Sqaure, Enix... so on. Then I'm pretty sure that everybody here can overcome the hurdles of browser RTE with 2gb+ram, 256mb+gpu, 2terabyte hard drives, digital distribution.

so I contest all the points. These trials of 4 mighty groups aren't just in the browsers, they are in hardware, OS and even API's as well. If other developers can overcome this hurdle to provide excellent gaming experiences. I don't see how an already fantastic cross platform technology is the limiting factor. When in face of what other companies need to deal with. Is the only tiny bump for us in comparison.

Though i will agree with another point. There is nothing wrong playing devil's advocate. it's really important. The discussion of examning idea's is super important. Getting people to evaluate there stance is important. It brings more innovation and thought.

But... node-webkit is the export option of choice for C2 Windows deployment. If CC can only produce Windows executables then isn't that what you need to compare it to? Forget about inconsistency between browsers; CC could never do browsers anyway. Unless I'm missing something.

How come that people bring CC into play? I thought the headline made the context clear: "Status quo of HTML5 gaming". The current state of HTML5 gaming. As far as I know CC has nothing to do with HTML5.

Is it the first paragraph of the original post? It is just an optional introduction to tell you a bit more about me, to let you know my relation to the Scirra products. That's all.

I've not run into this problem myself, and I'd be interested in seeing an example. I bet 50p I can fix it :DWell, you'd see it if you'd have the affected system. For example, Firefox doesn't support web audio on WinXP (as well as WebGL) and their workaround seems to be just triggering a play command with all issues (loading the sound to RAM first, etc.). But that's a guess. The gap however isn't. And I don't doubt you'll find a workaround. I might even find one myself. But that's not the point. <img src="smileys/smiley17.gif" border="0" align="middle">

It doubles the filesize, but only the relevent audio is downloaded by the user. When packaging as native you can just remove the unnecessary audio files.And this is one fine example of what I meant when saying that C2 is making the situation a lot better. It takes care of any conversion for you and handles the files while developing. It's the merit of C2, but doesn't change the status of HTML5 gaming. C2 shouldn't be forced to hold 2 compressed audio formats ready, when 1 is more than sufficient.

IE does now support WebGL and I've not had issue with Firefox myself (FirefoxOS on the other hand...).There's only preliminary WebGL support in the IE 11 preview. And IE 11 doesn't support Vista or XP. The same goes for Firefox: It only supports WebGL on recent OS.

1. Apparently HTML5/JS can't create the same gaming experience. I will contest this. Language is not relevant to gaming experience. Developers and what they can manage with the tools they have hand matter. I assure a good team can provide some fantastic gaming experience with HTML5/JS. Keep in mind that Unity was in the same situation in the very early days. No one used Unity for "serious" games until a few major releases came and developers really picked up the steam.I didn't say that a good team wouldn't be able to provide some fantastic gaming experience with HTML5/JS. I stated that this wouldn't be the same for all gamers. Unity, on the other hand, is a fine example for an encapsulated solution. It doesn't matter if the gamer uses XP or Win8, Chrome or Firefox, etc. The developers don't need to waste time finding workarounds for implicitness.

2. HTML5/JS are not browsers. They are languages. The complaint is the run time environments(RTE) of the language. This is valid. however if you abandon the idea of supporting different RTEs and instead focus on a single RTE(NodeWebkit, CocoonJS...) you will make life easier. If you MUST abide by the limitations of supporting many RTEs.'HTML5 gaming' implies you're developing for HTML5, not for some browser. It shouldn't be the responsibility of the developer to handle all the browsers' just partly support of HTML5. It's the responsibility of those companies to keep uniform standards.

If you buy an audio CD you will be able to play it on each and every CD player, no matter the facturer. You won't happen to see some machine saying "Oh, I don't fully support it, so I'll only play in 8kHz/mono."

Keep in mind that there were game programmers working with with only 256kb disc storage, 640kb ram, 16 colours(and i'm being generous). If people can make robust RPG's that founded companies like Sqaure, Enix... so on. Then I'm pretty sure that everybody here can overcome the hurdles of browser RTE with 2gb+ram, 256mb+gpu, 2terabyte hard drives, digital distribution.I very well know those 640kB games. I started programming my first game on a Commodore Pet 2001, even more limitations. And I totally agree that we can overcome hurdles. My point is, that there shouldn't be hurdles. Those are just the results from only 4 companies each trying to dictate the other.

Basically, what I experienced was the hope of a standard that doesn't exist yet. If you develop for flash, your game will run the same wherever flash is supported. If you develop it for Unity, it will run the same wherever Unity is supported. If you develop for Unreal Engine 3 (yes, it is web enabled), it will run the same wherever Unreal Engine is supported. But if you develop for HTML5 ...?

One of the best known claims is "All you need is a browser." Far from that.

How come that people bring CC into play? I thought the headline made the context clear: "Status quo of HTML5 gaming". The current state of HTML5 gaming. As far as I know CC has nothing to do with HTML5.

Is it the first paragraph of the original post? It is just an optional introduction to tell you a bit more about me, to let you know my relation to the Scirra products. That's all.

Ah I did miss something :P But like Captain said, if you use wrappers like node-webkit or cocoonjs you'll get the consistency that browsers lack no? Unless you need web deployment that is.

I remember a students rant on Charcoal sketching VS oil paints and watercolors.

His argument... Charcoal makes makes messy, blurry surreal images in his hands. And he can do much more realistic images with watercolors and Oil paints.

He went on to boldly state "Only surrealists, and the untalented use charcoals."

I then introduced him to Escher http://www.mcescher.com/Gallery/gallery.htm

Seriously... It is not the medium, it is the artist insight and talent that makes a masterpiece.

If a person can not make something great with the tools provided, they either need more practice, or they need to choose a different medium.

I'm sorry but comparing art (charcoal v.s. ink v.s. oils) to a development platform or runtime environment for software is a ludicrous analogy. Does the paper or the canvas limit the number of charcoal strokes you can use versus oil strokes? Does the frame you hang your art in to display it limit it to only being compatible with watercolors and not oils? Is a viewer not able to view your artwork if it's in inks but not in charcoal?No. Not only is this like comparing apples to oranges, but it's comparing apples to buildings. Vast differences.