7 ms·

HTML/JS is criminally underrated as a game development platform. You get so much from it, like instant deployment, delivery, multiplayer features, and so much m

• probably_wrong 7y ago
  I would bet that the reason HTML/JS is "underrated" is because it presents a unique problem: that no two browsers behave the same way when it comes to HTML rendering. As a quick test I just opened two browsers in my PC (Windows), ran the Acid3 test, and got different results at different speeds. My phone's browser gave me yet a third result. That's a bad start for a multimedia platform that I'll be in charge of supporting. For all its weaknesses, there was a platform that offered all you mentioned plus good portability and saw the success you speak of: Flash.
  • ermir 7y ago
    Well, the rendering problem can be solved by using an existing game engine. Rendering is done in WebGL, and the engine abstracts away the browser-specific details. Furthermore, because of Google's dominance, not many browser engines are left in the market. Essentially all you have to do is support WebKit, Gecko, Blink, and you'll cover 99.9% of your userbase.
  • kyle-rb 7y ago
    When people refer to HTML5 for games (including this post) they usually mean the HTML5 canvas and its associated APIs (canvas/webGL), not using actual HTML elements to render game graphics. From what I know, canvas rendering is pretty much the same across different browsers. It's a pretty low level API so there's not as much room for interpretation. In any case, the Acid3 test you're running is focused on the specifics of HTML/CSS layout, and don't think it tests the canvas at all. I think that canvas has done a good job of taking over the use cases that Flash had, and is very portable these days (basic canvas has 98-99% support[0]). [0] https://caniuse.com/#feat=canvas https://caniuse.com/#feat=canvas
    • jtolmar 7y ago
      Canvas rendering isn't that consistent, and when it goes weird it's often OS specific instead of merely browser specific. Some things I've run into: - OSX likes to turn random Unicode symbols into emoji (extends past Canvas) - Fractional font sizes on Chrome/Linux get bizarrely stretched out (after a transform that makes the font not a fractional size) - Complex clipping operations freak Chrome out - All the compositing rendering options are broken somewhere or mis-defined to the point that it's weirdly hard to render anything to an alpha channel You also need input APIs to make a game, and the input APIs often have strange inconsistencies in function names, returned objects, or event ordering. Canvas is nice and straightforward if you want a purely sprite-based game with only mouse/keyboard input (but even then you need to jump through hoops if you want pixel art). Anything beyond that is going to need cross-platform debugging.
      • Mirioron 7y ago
        Canvas has also had some really weird performance issues in the past that are browser specific. Chrome once decided that the number of images used was too many in an animation, so it had to decode some of the images in the animation on the fly. This obviously killed all performance. This bug has been fixed, but I'm sure there are many others like it around.
  • vertex-four 7y ago
    The HTML part of javascript game engines is generally just enough to get a <canvas> on screen and dive into WebGL. The thing is, you can target Unity/Unreal/etc at a browser and get most of the benefits listed above, plus the benefit of using more-or-less the same toolkit as everybody else.
    • Mirioron 7y ago
      Has Unreal improved their HTML5 offering? It used to be rather poor, because of the immense filesize of the engine. Have they got it down to reasonable levels yet?
  • mrec 7y ago
    > ran the Acid3 test, and got different results at different speeds It's worth checking the Acid Tests homepage [1] here: > Acid3, in particular, contains some controversial tests and no longer reflects the consensus of the Web standards it purports to test, especially when it comes to issues affecting mobile browsers. [1] https://www.acidtests.org/ https://www.acidtests.org/
  • greggman2 7y ago
    How is that a unique problem? If you have an iOS native app and you want an Android native app the difference are probably 100x the differences needed to deal with Safari's quirks vs Firefox's vs Chrome's. Same for Mac->Win->Linux.
    • boomlinde 7y ago
      The context of the discussion is HTML/JS as a game development platform. Considered as a platform, that is rather unique. iOS and Android are generally not considered as a single platform.
• skymt 7y ago
  You don't need to develop for HTML/JS directly to target the browser as a platform. (Not to say it's not an option worth considering, just that you can get the delivery benefits from other stacks.) Many current engines can build for the browser as well as native applications: Unity, Godot, GameMaker, OpenFL come to mind.
  • ermir 7y ago
    Using things like DOM integration, WebRTC multiplayer, URLs as navigation requires you to develop for the web as a first class platform , which you can only do with JS directly.
    • izacus 7y ago
      And you lose being able to deploy native, responsive and less buggy code to mobile devices, consoles and other desktop OSes. The value proposition just isn't there when Unity and similar engines exist.
      • ermir 7y ago
        Yes, you lose many of those capabilities, but you also gain new ones. I bet agar.io would never have been played had it been a Windows executable or a Steam game. The friction in starting the game and playing the game is so low, that it drawfs all other downsides by far. In fact, this is the exact justification why HTML/JS business apps have thrived, because even though JS has tons of problems, all of them can be overlooked when you gain the capabilities of the web.
• pietrovismara 7y ago
  If only JS had better multithreading shared memory capabilities it would be perfect for me. But just with fixed length array buffers limited to numbers I can't do much. I tried regular IPC instead but there's too much latency. It is a huge shame.
  • disease 7y ago
    I was going to reply "but SharedArrayBuffer!" until I checked the site below and came back to reality. https://caniuse.com/#feat=sharedarraybuffer https://caniuse.com/#feat=sharedarraybuffer
    • pietrovismara 7y ago
      And as I said, SharedArrayBuffer is a fixed length, number only array. While it may work well for some use cases, it really can't for many others. Or am I missing something? By the way, browser compatibility is not a concern if you develop for Electron. Just target Chrome and you're done.
      • meheleventyone 7y ago
        I think they meant it’s not supported. Although saying that memory in lower level languages is basically treated as an array of numbers and you can treat the array buffers similarly. It’s also how Wasm memory is exposed. So you can serialize JS and other data in and out of them.
      • seangrogg 7y ago
        Although it's number-only said numbers can be used to represent anything, really. If you can convert your data to number-friendly formats and back there's really no issue. If you need strings you can use the native TextEncoder/TextDecoder and shuffle things around as UTF-8. If you need JSON-like objects you can look at encoding formats such as Protocol Buffers, Thrift, and the like. This introduces non-zero latency shuffling data between formats but that's largely what normally occurs over IO boundaries anyways.
    • 7y ago
• degenerate 7y ago
  Hacking in HTML5 multiplayer games is a difficult issue. There are cheats/hacks for Agar.io, Slither.io, etc utilizing JS injection scripts and extensions.
  • riadd 7y ago
    Fun fact: there is a hacking forum that still have failed to create trainers for Curious Expedition due to "weirdly changing memory addresses". I think if they would have realized that it was just a browser game it would have been much easier for them.
  • ermir 7y ago
    I have been thinking about this problem a lot and I may have a solution. Essentially, every time the user loads the page he gets a different obfuscated version of the base game. In this way, no script or plugin can be made to hook to your code since it's different every time the game loads. In addition, you can also obfuscate the protocol (for multiplayer) so that network sniffing tools can't capture the relevant data when communicating with the server. Finally, you can tie an obfuscated version of the game to a particular user, so you can find hackers or make it harder for them to run the game.
    • z3t4 7y ago
      Or just run everything on the server (hit detection, positioning, etc) and just use the client for rendering and interpolation.
      • strbean 7y ago
        But that means writing a reasonable server! Jokes aside, there are some Korean MMOs that rely on excessively trusting the client as a core part of their business model. If you offload as much state as possible to the client your server costs go way down. Maplestory is an example of this: if a player is alone on a map, essentially all map state, physics, etc. is handled purely on the client. When another player enters the map, half of the NPCs get 'handed over' to that player, and the server syncs state between the two clients. On the other hand, you have to keep in mind hacks like bots and wallhacks. In the case of bots obfuscation is practically your only defense. In the case of wallhacks you can try to keep clients in the dark as much as possible, but there will always be a period where the client knows more than the player should (unless you want enemy players to 'pop in' once they are fully in view).
• danShumway 7y ago
  My current project, Loop Thesis, is completely HTML5/Javascript. It's going to be a downloadable game, but (at least right now) I can bundle it entirely in a web browser, and often do for demos. It's complicated. I don't regret writing Loop Thesis in Javascript; there are substantial benefits to the web as a platform. If I went back to rewrite Loop Thesis from scratch, I wouldn't do anything different. But benefits aside, there are also complications and headaches, particularly around timers, audio, controller support, and garbage collection. I think there are concerns that have to be balanced. There's definitely room for more games on the web, and there are huge benefits to looking at it as a platform, but I don't want to give the impression that it's all rainbows.
• kaycebasques 7y ago
  > HTML/JS is criminally underrated as a game development platform. Tom Greenaway is making the same argument: https://web.dev/ready-player-web/ https://web.dev/ready-player-web/ > You can just send a link to your friends and they can join your game with a single click. Web Bundles takes it a step further and lets you share the entire game, P2P, as a single file: https://web.dev/web-bundles/ https://web.dev/web-bundles/ Disclosure: I work on web.dev
  • gavinray 7y ago
    Woah, I tend to keep up on the fairly bleeding-edge of web tech and I hadn't heard of Web Bundles before. It seems pretty neat, my question is what the functional difference between this and running something like wget with recursive and convert-to-local flags? Let's say I have some contrived portfolio website and it contains links to several sub-page sections, and some static resources (images, JS, fonts, CSS, etc). I can run this and get an offline copy of the website that I can browse or distribute how I wish: wget --mirror --convert-links --adjust-extension --page-requisites --no-parent http://example.org
• Vekz 7y ago
  My game http://crashgiants.io/ http://crashgiants.io/ is WEbGL + Webrtc multiplayer and has very fun to build because of all the features you mentioned
  • strbean 7y ago
    I need to check that out! I've been watching WebRTC since 2011, excited to have some equivalent of a TCP socket. It took them SOOOOOOO long to add data channels. Are you using it for P2P, or making the 'peer' be a central server?
    • ermir 7y ago
      I did not make the game you are asking about, but WebRTC has an even better feature than TCP, which is unreliable datagrams (essentially UDP). Very few people have done anything with it, since server support for WebRTC data channels is very limited. Still, you can use dirty hacks such as leveraging Puppeteer as a WebRTC endpoint and make true lag-free experiences for the web. Last I checked a few months ago this library was working for WebRTC data channels on node.js. Check it out, but it might not work properly: https://github.com/node-webrtc/node-webrtc https://github.com/node-webrtc/node-webrtc
• gitgud 7y ago
  It's also the fact that JavaScript is an event-driven language which matches the impendence of the architecture of many games.
• ntr-- 7y ago
  Completely agree. Shameless plug: our game https://mnml.gg/ https://mnml.gg/ has been an absolute dream to develop for a 2 person team. One of the benefits we've found that rarely gets mentioned is that there are minimal fees. Our only outgoings are server costs and Stripe fees: no payments for Unity/Unreal, no App/Play store cuts. Another is that depending on your game mechanics lots of existing technologies solve problems that big game engines often handle for you. Thanks to Postgres transactions we have never spent a second thinking about client/server synchronisation. For those who saw the game on HN a few weeks back, we have turbocharged our tutorial and game information and the player base is growing. Jump on and play a round!
• pjmlp 7y ago
  The major problem is that you have zero control over canvas and webgl being hardware accelerated, and this destroys the whole experience.