11–20 of 41 posts
The problem with HTML5 games is that the game's source code is on your machine which means DRM is gone. Not only that but the problem for me is that my assets and my source is freely available to you to use in any way you want. You can take it and rehost it on your website and I lose any way of making a profit off my game.
With WebGL, the performance seems great, and the graphics and effects look sharp too. Audio was definitely an issue, and more work needs to be done there by browser makers. Using WebkitRequestAnimationFrame over setTimeout helps battery life and performance a lot.
If you're interested, you can check it out here – http://chrome.bouncymousegame.com/ – I'm thinking about doing a post about our experiences making this game for mobile and for web, and some of the economics behind game-making as well.
The problem with HTML5 games is that the game's source code is on your machine which means DRM is gone. Not only that but the problem for me is that my assets and my source is freely available to you to use in any way you want. You can take it and rehost it on your website and I lose any way of making a profit off my game.
I don't buy this to be honest, what's stopping you from stealing from any other game? Why have you singled out HTML5 as exclusively suffering from this problem?
On the other hand, since you're using HTML5, it's not too hard to make your product a service. When you do that, you can hide all your important code on the server instead of the client and thus make it much harder to steal. Of course, that makes it much harder to play said games on a mobile...
and goodbye battery life. Even the simplest HTML5 game find a way to use 90% of my CPU.
Google's really put work into making javascript perform as well as possible, and it shows.
Earlier quoted context omitted.
That's because many mobile browsers aren't optimised yet - I think that will be solved with time.
I question whether it's really a matter of optimization. Even on the best modern desktop browser with the most modern JS runtime, JavaScript is going to run 5-10x slower than C. On top of that, consider increases in memory usage. Mobile hardware is likely to keep getting better, but it's not magically going to make HTML5 games run well on mobiles. For that to happen, a few things are needed: Magical improvements in J…
We ported our 2D Android/iOS game, "Bouncy Mouse," to HTML5/WebGL. It's on the Chrome Web Store ( https://chrome.google.com/webstore/detail/cgdllcbmneiklcmbec... ) and doing great. With WebGL, the performance seems great, and the graphics and effects look sharp too. Audio was definitely an issue, and more work needs to be done there by browser makers. Using WebkitRequestAnimationFrame over setTimeout helps battery li…
Google sure is good at guiding the conversation on these APIs. It used to be that everyone complained about Chrome's piss-poor audio implementation, but now people are complaining that Microsoft and Mozilla are 'slow to support' the Web Audio API 'standard' even though it looks like Google documenting their NIH mixer library after the fact instead of an actual market-driven standards effort.
Earlier quoted context omitted.
I question whether it's really a matter of optimization. Even on the best modern desktop browser with the most modern JS runtime, JavaScript is going to run 5-10x slower than C. On top of that, consider increases in memory usage. Mobile hardware is likely to keep getting better, but it's not magically going to make HTML5 games run well on mobiles. For that to happen, a few things are needed: Magical improvements in J…
Yeah, some good points I guess. But the fact we make an engine lots of games use makes it a bit easier: if magical improvements in JS appear which require some tricky changes to take advantage of, we can do the hard work in our engine and all the games benefit from it. But yeah, probably will always be a bit slower. 2D games don't tend to have really complicated logic though.
Your demo asteroids game certainly doesn't, but what about a 2D game that's actually worth playing? Things like physics or flocking algorithms are going to be very expensive in JS.
Earlier quoted context omitted.
I don't buy this to be honest, what's stopping you from stealing from any other game? Why have you singled out HTML5 as exclusively suffering from this problem?
Well, because the web, by nature, is open . Javascript is source, not some kind of bytecode. You can easily look at the source of any web page and do whatever you want with it (granted there are obfuscators available, but run it through a tidier and it's at least easier to work with than assembler would be). It's not that you can't steal games from other platforms, it's just that targeting HTML5 makes it ridiculously…
Theft of assets is definitely an issue. We've actually been targeted ourselves by someone stealing and reselling our product. It's a pretty upsetting and difficult situation so we sympathise with the concerns.
What we learnt from our experience however is the thief was largely incompetent and didn't actually pose as much of a risk as we thought he would to our operations.
I think often the same can apply for theft of assets, it's upsetting that someone steals in in one swoop without any thought and appears to be making money from it, but most of the time they are struggling to make anything at all from your work. If someone more successfully is stealing from you there are a lot of options to take it further if it becomes economically viable. For the majority of developers though I don't think it's as big a concern as many people think it is. Although I'm sure there are some good counter examples and arguments against this.
The problem with HTML5 games is that the game's source code is on your machine which means DRM is gone. Not only that but the problem for me is that my assets and my source is freely available to you to use in any way you want. You can take it and rehost it on your website and I lose any way of making a profit off my game.
I don't buy this to be honest, what's stopping you from stealing from any other game? Why have you singled out HTML5 as exclusively suffering from this problem?
That, alone, is not really an issue. I suppose you could do the same as native games. If a demand is there, an API or libraries to do that will appear.
The source problem seems harder to change, short of rolling your own javascript VM and precompiling everything. And if the source is readable, the "obscure file format" technique breaks down.
In practice, though, can someone make something out of loads of minified javascript ? Or is it equivalent to reading deassembled C ?