Hacker News Reader

Comment by Jare | Hacker News Reader

I agree that Go is a fantastic language for writing servers that need both CPU performance and responsively handle many connections.

That said, if you write the server in Node then you can share some of the logic between client and server without having to rewrite in another language. Examples where this comes handy in games:

- If the server runs the logic authoritatively, the client can run part of that logic locally to hide lag.

- If the logic runs on the client, the server can run part of that logic to catch impossible actions and detect cheating attempts.

View on HN

Do you have any examples of live web-based games that are doing this with Node?

You might want to look at 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.

Catastrophic mistake, isn't that a bit exaggerated?

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.

I dont see the udacity course where the game is built from scratch, was it removed?

It's still there. It's the html5 game development course: https://www.udacity.com/course/cs255

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".

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

My in-dev game thing (http://www.aliengrit.com) shares game logic code across the client and its Node server. If you've cleanly separated rendering logic from game logic for all game entities, it works really well. (i.e. the server just runs the same code without the graphics bit attached).

Reply on news.ycombinator.com