5 ms·

That's pretty impressive, but it didn't work in FF (Developer 57.0b1 64-bit) for me, had to change to chrome and then it seemed to be getting 8fps (at least tha

That's pretty impressive, but it didn't work in FF (Developer 57.0b1 64-bit) for me, had to change to chrome and then it seemed to be getting 8fps (at least that's what the readout on that page was). The Infinitown posted here was (pretty much) buttery smooth though, and relatively fast loading time (especially the second time with cache), and I bet the codebase is a lot easier on the eyes, though it's likely nowhere near as efficient as writing it all in the shader obviously. Is the world just waiting for a no-dependency cross browser MMO/shooter/whatever 3D game to take the world by storm? Why worry about Steam when people can just go to a website, if the experience is good enough and the game is simple enough? I must not know enough about the industry/how hard it is to make a good game + how hard it is to make a truly good browser-only game.

gilbetron 9y ago
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.
juliangoldsmith 9y ago
>That's pretty impressive, but it didn't work in FF (Developer 57.0b1 64-bit) for me Could that be an issue with the new rendering engine? I'm on Waterfox 55.2.2, 64-bit, and it worked well for me.
gilrain 9y ago
It works great in Firefox 58.0b6 at a solid 60 FPS.
deleted 9y ago
[deleted]
BatFastard 9y ago
It's hard, much harder than creating a native client game. Many more access restrictions, javascript and flash were only two options in the past, and each had it problems. I have been working on a browser based game for TOO long now, and garbage collection is a constant problem. Plus things just run a LOT slower than a native c++ client.
- hardwaresofton 9y ago
  I'm really interested to know what the large problesm you've been facing are. Also, if you're facing a problem with garbage collection, have you tried the emscripten/wasm approach? Using some garbage collected language and compiling it down to javascript? Or maybe even one that is functional to make garbage collection simpler?
  - BatFastard 9y ago
    Send me an email. Happy to talk to you about it. Just the garbage collection issues is enough to frustrate all but the most dedicated developers. I use pre-allocated object pools for just about everything that helps, but it's easy at 60 frames a second for one allocation to build up to thousands of objects quickly if you are not very careful.
batmansmk 9y ago
I thought about it before. You could distribute your own builds prior to Steam. Here is a sample of the value Steam brings to developers: monetizing, managing DLCs, getting online features, getting visibility on the storefront, running promos/discounts/marketing operations, getting analytics, reviews, achievements, distributing free keys to testers, getting some partner connections to deploy server code, running a community forum, managing beta programs with two different builds, supporting screenshots, banning at the Steam level abusive players... it takes a lot of features to provide a meaningful MMO experience; the rendering engine sounds like 10% of the effort ;).

gilbetron 9y ago

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.

juliangoldsmith 9y ago

>That's pretty impressive, but it didn't work in FF (Developer 57.0b1 64-bit) for me Could that be an issue with the new rendering engine? I'm on Waterfox 55.2.2, 64-bit, and it worked well for me.

gilrain 9y ago

It works great in Firefox 58.0b6 at a solid 60 FPS.

deleted 9y ago

[deleted]

BatFastard 9y ago

It's hard, much harder than creating a native client game. Many more access restrictions, javascript and flash were only two options in the past, and each had it problems. I have been working on a browser based game for TOO long now, and garbage collection is a constant problem. Plus things just run a LOT slower than a native c++ client.

hardwaresofton 9y ago
I'm really interested to know what the large problesm you've been facing are. Also, if you're facing a problem with garbage collection, have you tried the emscripten/wasm approach? Using some garbage collected language and compiling it down to javascript? Or maybe even one that is functional to make garbage collection simpler?
- BatFastard 9y ago
  Send me an email. Happy to talk to you about it. Just the garbage collection issues is enough to frustrate all but the most dedicated developers. I use pre-allocated object pools for just about everything that helps, but it's easy at 60 frames a second for one allocation to build up to thousands of objects quickly if you are not very careful.

batmansmk 9y ago

I thought about it before. You could distribute your own builds prior to Steam. Here is a sample of the value Steam brings to developers: monetizing, managing DLCs, getting online features, getting visibility on the storefront, running promos/discounts/marketing operations, getting analytics, reviews, achievements, distributing free keys to testers, getting some partner connections to deploy server code, running a community forum, managing beta programs with two different builds, supporting screenshots, banning at the Steam level abusive players... it takes a lot of features to provide a meaningful MMO experience; the rendering engine sounds like 10% of the effort ;).