It's an open source html5, multi-player PvP, 2D shooter up game with sound, built in match making, auth server and architected by a team of ex-game developers at Google using mostly free tools to create maps, package assets, etc..
They are using Node to run the game instances on the server. This is mainly because having identical code paths on both sides is highly beneficial due to how much they need to sync up to protect against cheating and have client side prediction. [Note: this isn't an opinion, I asked this question in their study group and the lead game developer told me that is why they chose Node over Go].
Think about that for a second. They created a presentation at Google I/O for the game, have a course running on Udacity building the game from scratch, have study groups at Google's offices, run the auth server on app engine and they still chose Node to run the game logic on the server instead of Go.
I wish Go could be utilized as game servers because it's clearly going to crunch numbers faster than javascript but it seems like not running JS on the server is a catastrophic mistake for game development where you plan to have the client running it in a browser with JS.
The Grits project page says Grits was designed "using Google's technology stack". Unfortunately, they mean it literally because Grits dies with JS errors in any browser that is not Chrome and the latest version of Safari. Grits requires Google's Web Audio API, which is currently only a working draft spec.
Web Audio API is not supported in this browser
TypeError: this._context is null
https://gritsgame.appspot.com/scripts/core/soundManager.js
I don't know. When a professional 3D game developer (the lead guy who coded grits) tells me it's necessary that both ends use the same language to correctly calculate predictions and simulations in the correct timing then I believe him.
If your game is completely out of sync and the input feels horrible because it's delayed then your game is going to be instantly rejected. Having all of your hard work instantly rejected seems catastrophic to me.
Personally I don't understand why both ends need the same language because the server is definitely going to execute the code at a different pace than a random client, but I'm going to take his word for it because he's a professional in the industry with a really good track record.
They had every reason in the world to use Go but they didn't.
It's not necessary per se (much less catastrophic if you do otherwise), but it's certainly much more convenient. It's only necessary if you rely on simulations being identical, which would happen if you are using deterministic dead reckoning or lockstep networking. Client side prediction and server side cheat detection are normally not so strict.
This course is the entire game client. The server side will be part 2 of the course released at a later time.
There's also an hour presentation from Google I/O explaining the client and another hour presentation from Google I/O explaining the server. Both can be found on Youtube searching for "html5 grits".
It's an open source html5, multi-player PvP, 2D shooter up game with sound, built in match making, auth server and architected by a team of ex-game developers at Google using mostly free tools to create maps, package assets, etc..
Here's the source: http://code.google.com/p/gritsgame/
They are using Node to run the game instances on the server. This is mainly because having identical code paths on both sides is highly beneficial due to how much they need to sync up to protect against cheating and have client side prediction. [Note: this isn't an opinion, I asked this question in their study group and the lead game developer told me that is why they chose Node over Go].
Think about that for a second. They created a presentation at Google I/O for the game, have a course running on Udacity building the game from scratch, have study groups at Google's offices, run the auth server on app engine and they still chose Node to run the game logic on the server instead of Go.
I wish Go could be utilized as game servers because it's clearly going to crunch numbers faster than javascript but it seems like not running JS on the server is a catastrophic mistake for game development where you plan to have the client running it in a browser with JS.