Live data from Hacker News

Browser Games Aren't an Easy Target

jakob.space

21–30 of 52 posts

Re: Browser Games Aren't an Easy Target

#21

Earlier quoted context omitted.

What makes you think it isn't a requirement coming from their superiors? There are many reasons your link may not work. Why do you assume incompetence?

Never attribute to malice what can be adequately explained by stupidity

... or corruption. ;)

Re: Browser Games Aren't an Easy Target

#22

Earlier quoted context omitted.

We have, with Construct 3 ( https://www.construct.net ) Recent addition of our timeline editor means we think it ticks all the boxes as a replacement.

Can you create graphical assets within engine in Construct (vector or raster) or do you need to import them?

Yes, within Construct 3 you are able to create your graphical assets. Here's a demonstration of someone adding a sprite to their game which shows the interface for drawing the raster sprite: http://www.youtube.com/watch?v=gVGOYvZxlqk&t=3m8s

Re: Browser Games Aren't an Easy Target

#23
post #20
post #17

Earlier quoted context omitted.

Javascript can be obfuscated too. What is the difference?

Well, someone went to the trouble of writing a Rust binary just to hide the game code, when they could have used standard JS obfuscation instead. This suggests to me that WASM has some properties that make reverse-engeneering harder than obfuscated JS could do alone. This would give some validity to the fears of WASM becoming the "new Flash" that were voiced when it was still in development.

> new Flash

... but Flash was easy to reverse too, just download the .swf file and use one of many tools to reverse engineer it. It's probably why there are so many "hacked" flash games available if you search for them.

Re: Browser Games Aren't an Easy Target

#24
It's slightly annoying that when I create a new game (for the browser) or think of ideas for games I inspect things through the lens of cheat-enabling. It happens to the point that I dismiss ideas based on the fact that there is no viable way for me to stop cheating when it leverages it. The funny thing is that I did most of what I could (source-like networking) and basically no one plays my games so the risk of cheaters spoiling it for everyone is super slim. I wonder if it ever makes sense to think in those categories or am I just paranoid.

Re: Browser Games Aren't an Easy Target

#25

Earlier quoted context omitted.

What makes you think it isn't a requirement coming from their superiors? There are many reasons your link may not work. Why do you assume incompetence?

Because the link opens a different news, you click on article A but it opens article B,also the pages work without JS(except the videos or fancy image galleries) only the navigation seems to be broken . A competent developer will show you a blank page and explain that you need to enable Java Script(it could be also not testing the webpage with JS off combined with using JS to layout stuff). The problem is not JS the…

>A competent developer will show you a blank page and explain that you need to enable Java Script

I completely disagree with this, if I'm understanding you correctly. As someone who disables Javascript, I don't want you to purposely break a page that previously worked (in the sense of being able to read the content of the article) simply because a portion of it which I might not even use doesn't work.

The fully competent solution would be to use progressive enhancement[1] (i.e., use functioning anchor elements initially, and use Javascript to add the Javascript-only functionality on top of the HTML solution).

If you don't have time for that, the somewhat-competent solution for alerting non-technical users that Javascript is disabled would be to add a banner at the top of the page (like Stack Exchange does) stating that some features will be broken without Javascript.

[1] https://en.wikipedia.org/wiki/Progressive_enhancement

Re: Browser Games Aren't an Easy Target

#26
post #20

Earlier quoted context omitted.

Well, someone went to the trouble of writing a Rust binary just to hide the game code, when they could have used standard JS obfuscation instead. This suggests to me that WASM has some properties that make reverse-engeneering harder than obfuscated JS could do alone. This would give some validity to the fears of WASM becoming the "new Flash" that were voiced when it was still in development.

> new Flash ... but Flash was easy to reverse too, just download the .swf file and use one of many tools to reverse engineer it. It's probably why there are so many "hacked" flash games available if you search for them.

I never really found any of those tools. Granted I could have looked harder. Perhaps I was looking in the open source world too much and they usually came as binaries?

Re: Browser Games Aren't an Easy Target

#27

Earlier quoted context omitted.

Because the link opens a different news, you click on article A but it opens article B,also the pages work without JS(except the videos or fancy image galleries) only the navigation seems to be broken . A competent developer will show you a blank page and explain that you need to enable Java Script(it could be also not testing the webpage with JS off combined with using JS to layout stuff). The problem is not JS the…

>A competent developer will show you a blank page and explain that you need to enable Java Script I completely disagree with this, if I'm understanding you correctly. As someone who disables Javascript, I don't want you to purposely break a page that previously worked (in the sense of being able to read the content of the article) simply because a portion of it which I might not even use doesn't work. The fully compe…

I agree, the blank page with JS is required should be the least thing they can do instead of some pages where you just get a loading animation. In this case the page appears to work but the links are broken so you can read the titles but frustratingly you are directed to a different article.

Re: Browser Games Aren't an Easy Target

#28

Earlier quoted context omitted.

We have, with Construct 3 ( https://www.construct.net ) Recent addition of our timeline editor means we think it ticks all the boxes as a replacement.

I wouldn't have thought to look there. I'm sure there's many ex-flash devs who would be happy to check it out if they knew.

Any ideas on how best to reach them?

Re: Browser Games Aren't an Easy Target

#29

Earlier quoted context omitted.

We have, with Construct 3 ( https://www.construct.net ) Recent addition of our timeline editor means we think it ticks all the boxes as a replacement.

Can you create graphical assets within engine in Construct (vector or raster) or do you need to import them?

Yes you can create them within the editor, and we've recently added support for importing SVG's.

Re: Browser Games Aren't an Easy Target

#30

Earlier quoted context omitted.

> new Flash ... but Flash was easy to reverse too, just download the .swf file and use one of many tools to reverse engineer it. It's probably why there are so many "hacked" flash games available if you search for them.

I never really found any of those tools. Granted I could have looked harder. Perhaps I was looking in the open source world too much and they usually came as binaries?

https://github.com/AndreyMiloserdov/jpexs-flash-decompiler
Post reply on HN