13 ms·

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 a

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.

TomGullen 15y ago
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?
- udp 15y ago
  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 easy. I think the web being "open" is a great thing, but obviously it's a genuine concern for people who distribute games. There's already a big problem in the Flash circles of strange Chinese portals stealing a game and sticking their logo on it. It's not just about the code, either - all the assets (images, sound) pretty much have to be readily available in an unobfuscated format.
  - TomGullen 15y ago
    I think you can argue that this is largely offset by the opportunity the web as a platform can offer you and your games. 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.
  - gte910h 15y ago
    >not some kind of bytecode Have you ever tried to reverse engineer/figure out the details of any of google's compiled javascript? It's pretty damn obtuse.
- kevingadd 15y ago
  Compiled code being decompiled and repurposed illegally is already a problem for people authoring software in Java, .NET and Flash. It would be dishonest to say that HTML5 won't suffer from this problem given that it makes it even easier to repurpose someone's hard work for your own ends. 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...
- Wilya 15y ago
  Other games tend to hide their assets into cryptic packages and file format (or they can even try to encrypt them). Not always impossible to bypass, but very annoying. It's a bit harder to do in html5, where you are supposed to use the standard formats for images/sounds, etc. 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 ?
  - udp 15y ago
    > 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. How do you propose to obfuscate images and audio in a way that's going to work across all browsers and can't be easily circumvented (and it obviously can't be security through obscurity if it's to be used by more than one game). > In practice, though, can someone make something out of loads of minified javascript ? Or is it equivalent to reading deassembled C ? Minified Javascript would be very easy (unless the minifier renamed everything, but even that isn't too bad). Javascript compiled with something like Google's Closure Compiler would be a lot harder, but still a lot easier than disassembled C. The assets are much more of a problem than the code - although not being able to compile the code means if you do find a way to obfuscate the assets, your deobfuscation code is going to be out in the open.
AshleysBrain 15y ago
Just want to throw in that our engine mangles the code with Google Closure Compiler 'advanced' mode, so it's probably really hard work to reverse engineer the code.

TomGullen 15y ago

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?

udp 15y ago
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 easy. I think the web being "open" is a great thing, but obviously it's a genuine concern for people who distribute games. There's already a big problem in the Flash circles of strange Chinese portals stealing a game and sticking their logo on it. It's not just about the code, either - all the assets (images, sound) pretty much have to be readily available in an unobfuscated format.
- TomGullen 15y ago
  I think you can argue that this is largely offset by the opportunity the web as a platform can offer you and your games. 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.
- gte910h 15y ago
  >not some kind of bytecode Have you ever tried to reverse engineer/figure out the details of any of google's compiled javascript? It's pretty damn obtuse.
kevingadd 15y ago
Compiled code being decompiled and repurposed illegally is already a problem for people authoring software in Java, .NET and Flash. It would be dishonest to say that HTML5 won't suffer from this problem given that it makes it even easier to repurpose someone's hard work for your own ends. 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...
Wilya 15y ago
Other games tend to hide their assets into cryptic packages and file format (or they can even try to encrypt them). Not always impossible to bypass, but very annoying. It's a bit harder to do in html5, where you are supposed to use the standard formats for images/sounds, etc. 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 ?
- udp 15y ago
  > 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. How do you propose to obfuscate images and audio in a way that's going to work across all browsers and can't be easily circumvented (and it obviously can't be security through obscurity if it's to be used by more than one game). > In practice, though, can someone make something out of loads of minified javascript ? Or is it equivalent to reading deassembled C ? Minified Javascript would be very easy (unless the minifier renamed everything, but even that isn't too bad). Javascript compiled with something like Google's Closure Compiler would be a lot harder, but still a lot easier than disassembled C. The assets are much more of a problem than the code - although not being able to compile the code means if you do find a way to obfuscate the assets, your deobfuscation code is going to be out in the open.

AshleysBrain 15y ago

Just want to throw in that our engine mangles the code with Google Closure Compiler 'advanced' mode, so it's probably really hard work to reverse engineer the code.