5 ms·

While there might be something, modern games take a massive amount of data, and for a website, you'd have to load that before playing it. Plus it is difficult

While there might be something, modern games take a massive amount of data, and for a website, you'd have to load that before playing it. Plus it is difficult to monetize. Demos are fun and easy, full games take a lot of work. There are actually some cool web games already out there, but being in the browser isn't particularly interesting, in the end. Infinitown is just a set of objects repeated in different orientations/combinations. The shader-city is awesome though. Very clever :)

hardwaresofton 9y ago
If you're OK with handling a whole bucket of naivete, I'm going to really heap it on: - the game monetization problem's always around (and always going to be around) -- is there a reason one wouldn't pay for a game in their browser but would pay for one on steam? - Some of the greatest games of all time made do with so much less -- Isn't the resource problem just a matter of effort/ingenuity? Also isn't that problem bound to go away as time goes on? (though of course the "modern game" target will also move) - I must not understand enough of why/how the demos are so different. Isn't shader city doing the exact same thing but insted drawing the visible pixels in space (and from a different viewpoint) rather than rendering the higher level polygons? I thought the key innovation/hard bit was the fact that it was inside a single shader.
- dkersten 9y ago
  > I must not understand enough of why/how the demos are so different The difference is that the shader city is a pure function of the inputs. For every value of 'time', it generates the colours for each pixel in the scene. Infinitown can maintain whatever state it likes in javascript.
  - jheriko 9y ago
    you could associate data with the distance field based renderer - e.g. objects at x,y,z locations... the bigger problem imo is that working with such a fancy renderer is a headache. want to render anything else in there? you'll need to do custom depth writes or sort things... want to insert a custom building? now you have to cut a fancy hole in things .. etc...
    - gilbetron 9y ago
      Oh, definitely the infinicity approach is much more malleable, which is why game engines basically work that way after years of "evolution". But the shader approach is more impressive as a fun demo. If you want to make a real game, you go with the infinicity approach!
      - wyqydsyq 9y ago
        As the shaders are basically only good for post-processing whatever output you get from your renderer, you'd definitely need to use an infinicity-esque approach for everything interactive in a game, but you could still leverage shaders in conjunction with that for non-interactive stuff like weather effects, animals (birds flying around etc), pedestrian and vehicle traffic and so on
        dkersten 9y ago
        I suppose you could use the technique to render a backdrop (either by rendering to a texture or by rendering it first, although you’d end up with a lot of overdraw if not careful) and then use a traditional renderer for the foreground. Not sure if it would win you anything, but certainly possible. Could you also upload dynamic object data as VBO’s or uniform arrays or something and read that in your single-shader-renderer? Still likely not worthwhile, but a fun possibility perhaps. I guess that’s not unlike what jheriko said above.
- gilbetron 9y ago
  Naivete is awesome when trying to not be it ;) What does playing in the browser get you when you need to download 100MB+? You use the browser to get access to the standard features and DOM, if you ditch all that, add in a huge upfront download cost, then you might as well just install. There are plenty of cross-platform ways to do it these days. Additionally, browser games have an air (fair or not) about them of cheapness. Then again, I'd be really happy if someone proved me wrong, and significant webgames became a thing. And it is a great exercise to analyze why webgames are bigger. The infinite city is "just" tying a location to a randomly chosen and oriented set of objects. All the rest is standard scene graph rendering pipeline. The city shader does that for each "pixel" in the scene, and takes much less data to get a far cooler effect. Imagine coming up with an algorithm that picks a random lego object (a car, a police station, a boulder, etc) for each inch on your floor. That's infinicity. Now imagine picking a single lego piece based on your location and direction you are looking, and having that always match up even if you move, and when doing so, the resultant "legoscape" is a cool city. That's the city shader. Sorta.
  - wyqydsyq 9y ago
    Being browser-based, you wouldn't be waiting to download 100MB+ if it's correctly designed You'd download a 1-2mb core script bundle that then dynamically lazy-loads resources as required. For example, if Hearthstone were converted to a browser game, you would initially only load the base client, all the metadata and media (e.g. hero SFX, card data, effects, images) would be loaded on the fly as they are required, or pre-loaded at determined points (e.g. load all the data for both players' decks when beginning a match)

hardwaresofton 9y ago

If you're OK with handling a whole bucket of naivete, I'm going to really heap it on: - the game monetization problem's always around (and always going to be around) -- is there a reason one wouldn't pay for a game in their browser but would pay for one on steam? - Some of the greatest games of all time made do with so much less -- Isn't the resource problem just a matter of effort/ingenuity? Also isn't that problem bound to go away as time goes on? (though of course the "modern game" target will also move) - I must not understand enough of why/how the demos are so different. Isn't shader city doing the exact same thing but insted drawing the visible pixels in space (and from a different viewpoint) rather than rendering the higher level polygons? I thought the key innovation/hard bit was the fact that it was inside a single shader.

dkersten 9y ago
> I must not understand enough of why/how the demos are so different The difference is that the shader city is a pure function of the inputs. For every value of 'time', it generates the colours for each pixel in the scene. Infinitown can maintain whatever state it likes in javascript.
- jheriko 9y ago
  you could associate data with the distance field based renderer - e.g. objects at x,y,z locations... the bigger problem imo is that working with such a fancy renderer is a headache. want to render anything else in there? you'll need to do custom depth writes or sort things... want to insert a custom building? now you have to cut a fancy hole in things .. etc...
  - gilbetron 9y ago
    Oh, definitely the infinicity approach is much more malleable, which is why game engines basically work that way after years of "evolution". But the shader approach is more impressive as a fun demo. If you want to make a real game, you go with the infinicity approach!
    - wyqydsyq 9y ago
      As the shaders are basically only good for post-processing whatever output you get from your renderer, you'd definitely need to use an infinicity-esque approach for everything interactive in a game, but you could still leverage shaders in conjunction with that for non-interactive stuff like weather effects, animals (birds flying around etc), pedestrian and vehicle traffic and so on
      - dkersten 9y ago
        I suppose you could use the technique to render a backdrop (either by rendering to a texture or by rendering it first, although you’d end up with a lot of overdraw if not careful) and then use a traditional renderer for the foreground. Not sure if it would win you anything, but certainly possible. Could you also upload dynamic object data as VBO’s or uniform arrays or something and read that in your single-shader-renderer? Still likely not worthwhile, but a fun possibility perhaps. I guess that’s not unlike what jheriko said above.
gilbetron 9y ago
Naivete is awesome when trying to not be it ;) What does playing in the browser get you when you need to download 100MB+? You use the browser to get access to the standard features and DOM, if you ditch all that, add in a huge upfront download cost, then you might as well just install. There are plenty of cross-platform ways to do it these days. Additionally, browser games have an air (fair or not) about them of cheapness. Then again, I'd be really happy if someone proved me wrong, and significant webgames became a thing. And it is a great exercise to analyze why webgames are bigger. The infinite city is "just" tying a location to a randomly chosen and oriented set of objects. All the rest is standard scene graph rendering pipeline. The city shader does that for each "pixel" in the scene, and takes much less data to get a far cooler effect. Imagine coming up with an algorithm that picks a random lego object (a car, a police station, a boulder, etc) for each inch on your floor. That's infinicity. Now imagine picking a single lego piece based on your location and direction you are looking, and having that always match up even if you move, and when doing so, the resultant "legoscape" is a cool city. That's the city shader. Sorta.
- wyqydsyq 9y ago
  Being browser-based, you wouldn't be waiting to download 100MB+ if it's correctly designed You'd download a 1-2mb core script bundle that then dynamically lazy-loads resources as required. For example, if Hearthstone were converted to a browser game, you would initially only load the base client, all the metadata and media (e.g. hero SFX, card data, effects, images) would be loaded on the fly as they are required, or pre-loaded at determined points (e.g. load all the data for both players' decks when beginning a match)