I'm really looking forward to seeing more gaming in the browser and hope it catches on. Imagine writing a game and it works on all platforms, PC, Mac, Tablet Android, iOS, etc. Also, TV manufacturers keep putting more powerful chips in their TV's for HD decoding. Couple with this a good browser, could we eventually see an end to console gaming because everyone's TV can play 3D games? Not to mention a lot of the TV's already have network capability. There's plenty of progress to make no doubt but it seems like a serious possibility to me.
I think the big barrier for building a multiplayer RTS in the browser would be the lack of UDP sockets.
You could certainly do something with websockets but it may involve making substantial compromises.
With TVs you have the added issue that people probably don't want to replace their whole TV every couple of years just to upgrade the graphics or whatever.
> I think the big barrier for building a multiplayer RTS in the browser would be the lack of UDP sockets.
This is brought up often but it appears some basic multiplayer is possible over websockets (I've written a very simple game using them). If UDP is that necessary, people will push for it and we'll eventually see it (or something equivalent) in the browser.
> With TVs you have the added issue that people probably don't want to replace their whole TV every couple of years just to upgrade the graphics or whatever.
This is turning out to be less of the case though as older PC hardware can still run newer games. The need for graphics is no longer growing faster than the resources to power them. This is especially noticable in the indie game market where rather simple graphics games have become very popular. Even high-end games don't "need" new power as much as they once did, the PS3 is what, 7 years old now?
AOE2 uses a "tick-based" system for synchronising input/commands, so it is possible to use websockets for multiplayer RTS simply by increasing the length of each tick. I believe AOE2 and SC2 used ticks of 200 ms or 250 ms; more modern RTS games use tick length of 100 ms.
Generally, in each tick player (or AI) input is received and then transmitted to the server or all other players. In the next tick, that input is then processed by each player's individual simulation of the game world.
A tick-based system does a decent job of handling latency by distracting the player the delay between input and processing through audio confirmation of the order or through a response/transition animation. It would not work for games requiring low-latency, i.e., FPS shooters.
I've built a few prototype multiplayer games that use web sockets (Socket.io actually) and the performance has been encouraging. One game I posted on HN had over 30 concurrent users without noticeable lag. It was also terribly inefficient. Each client had 5 msgs/sec outgoing and 150 msgs/sec incoming. The incoming messages could definitely have been optimized.
This is exactly the reason we started PlayCanvas [http://playcanvas.com]. I don't think it will be long before there is a modern browser in every TV, phone and tablet, in addition to every desktop machine.
I've seen you guys before, I'm gonna have to play around with this sometime. I like how you've decided to also be the publisher/CDN for the games. Right now it seems like everyone who launches some demo has to build and manage their own web presence. Something a native game developer doesn't necessarily have to do. This could help take that extra load off their back. I imagine you'll eventually offer internal APIs of sorts like Steam does, achievements, cloud storage for saved games, etc.
We love how easy it is to get a sample/demo/game published using PlayCanvas, we use it _all_ the time. We offer the option to download your game export and host it yourself but it's one button to publish to PlayCanvas so we're sure most people will want to do that.
(BLK author here)
Whoops - the public server I had running must have died. I'll get it running again tonight.
If anyone wants their server listed just let me know! I have some directions on the site for how to get it in the listing on the page.
To my knowledge Firefox has had support for IndexedDB for a long time without a vendor-prefix. Why does the page claim that it doesn't? Is there a bug in the implementation? A missing feature?
I'm always curious how much optimisation is required for these big voxel engines.
I assume since all voxels are the same size you can just batch draw them but even so there is going to be a lot within viewing distance that may be invisible.
Are they all just assigned to an octtree and then culled against the view frustum or do you really need some clever occlusion culling?
Nobody draws voxels, graphics cards aren't good at them. I don't know about these engines in particular, but in minecraft everything is converted to polygon meshes.
Nobody these days, but one of my all-time favorite games is Outcast[1], which used voxels for the terrain and polygons for smaller details. All it needed was a good CPU.
Every "voxel engine" I've ever seen just draws polygons. One of my co-conspirators on a side project[1] used surface nets over voxels with density bits to create slope-friendly meshes that are also used for physics calculations. Each mesh is pretty large and there are some economies of scale for drawing larger meshes like these.
Minecraft for a long time just batched each visible side, I think even ignoring occlusion, and drew it; I don't know if they precompute larger meshes now.
45 comments
[ 3.4 ms ] story [ 74.8 ms ] threadYou could certainly do something with websockets but it may involve making substantial compromises.
With TVs you have the added issue that people probably don't want to replace their whole TV every couple of years just to upgrade the graphics or whatever.
This is brought up often but it appears some basic multiplayer is possible over websockets (I've written a very simple game using them). If UDP is that necessary, people will push for it and we'll eventually see it (or something equivalent) in the browser.
> With TVs you have the added issue that people probably don't want to replace their whole TV every couple of years just to upgrade the graphics or whatever.
This is turning out to be less of the case though as older PC hardware can still run newer games. The need for graphics is no longer growing faster than the resources to power them. This is especially noticable in the indie game market where rather simple graphics games have become very popular. Even high-end games don't "need" new power as much as they once did, the PS3 is what, 7 years old now?
Generally, in each tick player (or AI) input is received and then transmitted to the server or all other players. In the next tick, that input is then processed by each player's individual simulation of the game world.
A tick-based system does a decent job of handling latency by distracting the player the delay between input and processing through audio confirmation of the order or through a response/transition animation. It would not work for games requiring low-latency, i.e., FPS shooters.
We love how easy it is to get a sample/demo/game published using PlayCanvas, we use it _all_ the time. We offer the option to download your game export and host it yourself but it's one button to publish to PlayCanvas so we're sure most people will want to do that.
Example: http://www.drakensang.com
I assume since all voxels are the same size you can just batch draw them but even so there is going to be a lot within viewing distance that may be invisible.
Are they all just assigned to an octtree and then culled against the view frustum or do you really need some clever occlusion culling?
[1] https://en.wikipedia.org/wiki/Outcast_%28video_game%29
Also there was https://en.wikipedia.org/wiki/Comanche_series even before Outcast. I don't think it used polygons. It was launched years before 3D graphics cards, too..
Minecraft for a long time just batched each visible side, I think even ignoring occlusion, and drew it; I don't know if they precompute larger meshes now.
[1] - http://static.largerussiangames.com/voxels/videos/rigidbodie... (Each 'companion cube' is really attached to a spherical physics body, the physics aren't mapped to the mesh.)
http://manicdigger.sourceforge.net/ - click "development news"
I make it with Script# (C# to JS converter), WebGL, and WebSockets. Both desktop OpenTK version and WebGL version can be compiled from common source.
But it's missing 2 weeks of work to finish the port.