Popular Content

Showing content with the highest reputation on 08/09/20 in all areas

  1. 1 point

    Steam for Core web games?

    I was wondering why we haven't seen something akin to a Steam for high quality web games (not casual). With the evolutions in browser tech, complex and deeper games have been quite feasible for awhile (ie https://www.madworldmmo.com or https://embersword.com) , but most of them tend to either get mixed into generic casual gaming sites (Crazy Games, Kongregate) or become their own .io website, essentially forcing devs to handle everything from marketing, hosting to payments and support. Others would rather envelop their web games using tools like Electron to be able offer them on Steam as if they were native games (ie. Cross Code)... While Itch.io and Gamejolt will accept/host web games, they will also mix in with any other kinds of game format and pretty much do very little curation to separate high quality from the rest... isn't there about time we see a curated experience exclusively for core and hardcore web games?
  2. 1 point

    What would you recomend to replace Signals?

    I just found it amusing that the original post was asking what to use instead of Signals in v3 (the answer is, of course, Events), and then gave an example of something a Signal couldn't ever do anyway. The biggest issue is that web devs lead almost exclusively asynchronous development lives. The overwhelming majority of your code and practices are honed around this, and there are so many libs out there to help with it. Which makes perfect sense, it's how the web itself works after all. Look at Promises, created specifically as a proxy to an as-yet-unknown value. A very common occurrence in web apps. In a game, this is almost never the case though. Very rarely do you ever have to wait for the value, it is nearly always calculated instantly (or should be) or available elsewhere in memory. So introducing an artificial async jump into this value fetch is a really backward step. It's the same with data streams too. Unless you are genuinely fetching remote data all you've actually managed to do is add overhead to a situation that didn't need it. The absolute shortest possible path for your data is the best. Retrieved in the fewest jumps possible, with minimal or no branching, invocations or creation of un-necessary objects (which includes anonymous functions, those wonderful little bundles of gc bait). This goes against everything that is standard for a web app. But you're not building a web app.