5 ms·

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 th

by Jare 14y ago

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.

wodow 14y ago
Do you have any examples of live web-based games that are doing this with Node?
- rartichoke 14y ago
  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/ 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.
  - the_gipsy 14y ago
    Catastrophic mistake, isn't that a bit exaggerated?
    - rartichoke 14y ago
      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.
      - Jare 14y ago
        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.
  - krsunny 14y ago
    I dont see the udacity course where the game is built from scratch, was it removed?
    - rartichoke 14y ago
      It's still there. It's the html5 game development course: https://www.udacity.com/course/cs255 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".
- noffle 14y ago
  My in-dev game thing (http://www.aliengrit.com 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).

by Jare 14y ago

wodow 14y ago

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

rartichoke 14y ago
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/ 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.
- the_gipsy 14y ago
  Catastrophic mistake, isn't that a bit exaggerated?
  - rartichoke 14y ago
    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.
    - Jare 14y ago
      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.
- krsunny 14y ago
  I dont see the udacity course where the game is built from scratch, was it removed?
  - rartichoke 14y ago
    It's still there. It's the html5 game development course: https://www.udacity.com/course/cs255 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".
noffle 14y ago
My in-dev game thing (http://www.aliengrit.com 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).