<p>I wanted to know what other fellow redditors with more experience in Go think about making a Game server in Go.</p>
<p>Our game is called Wind and Water (<a href="http://wind-water.net">wind-water.net</a>) and here's a short GIF showing how it looks:</p>
<p><a href="http://wind-water.net/images_v16/screenshots/2x/wind_and_water_vs_mode_opt.gif">http://wind-water.net/images_v16/screenshots/2x/wind_and_water_vs_mode_opt.gif</a></p>
<p>The game client was 100% programmed in C++ and so my first option would be to program the server itself in C++ with Asio or another library, but I don't really like the sockets code in C++ and for my job now, I am working with sockets in Go and the code is much cleaner and easier to read. Concurrency would also be cleaner I suspect?</p>
<p>My biggest fear is how the game server will behave as it gets more extensive or if it will handle a larger number of players well.</p>
<p><strong>NOTE: This is <em>not</em> a "which one is better?" kind of thread. I understand both could potentially do the job. Just want to know if anybody has some experience to share :)</strong></p>
<hr/>**评论：**<br/><br/>bkaradzic: <pre><p>It's definitely worth it. A few years ago (2011), even before Go reached v1 I wrote servers for game in Go language, including game server, which was originally written in C++. Game is Airmech: <a href="https://www.youtube.com/watch?v=jKnAcSAoRiU">https://www.youtube.com/watch?v=jKnAcSAoRiU</a></p></pre>shovelpost: <pre><p>This looks quite impressive! Care to tell us some more details about the game? Is the server written fully in Go? What about the game? What other tech was used? Thank you.</p></pre>PaulCapestany: <pre><p>Definitely impressed as well, would love to hear more about the tech too!</p></pre>PacNinja: <pre><p>I have seen them on <a href="https://github.com/bkaradzic/bgfx#who-is-using-it" rel="nofollow">bgfx's readme</a>. </p></pre>Schweppesale: <pre><p>Dude, this looks awesome.</p></pre>Darxide-: <pre><p>my first and main question there is what did you use for graphics. I've heard that the opengl bindings are a bit meh at this stage still.</p></pre>sh41: <pre><p>It sounds like only the game server was in Go. The game client was probably still C++ and maybe OpenGL (or DirectX). (<strong>Edit:</strong> Quite likely DirectX, because the game client is Windows only at <a href="https://www.carbongames.com/airmech/download.html." rel="nofollow">https://www.carbongames.com/airmech/download.html.</a>)</p>
<p>But speaking of Go and its OpenGL bindings, have you tried to use them? What about them is meh? I help maintain the bindings at <a href="https://github.com/go-gl" rel="nofollow">https://github.com/go-gl</a> and as far as I know they're complete without any major remaining TODOs (for many years now).</p></pre>Darxide-: <pre><p>I have not, it's just what I have heard awhile ago when I looked into it.</p></pre>steve_jobs_jr: <pre><p>I've had a game server emulator side project for a fairly long while now that I'd originally started in C++ before taking the leap and switching to Go. Honestly haven't looked back, Go maps extremely well to the types of problems you'll encounter over the course of implementing server code. For example, it's made tasks like concurrency and low-level network I/O far easier to reason about than it would be in many other languages and it's surprisingly expressive given how small its spec is. I'm stuck interpreting raw packet data a lot and have the flexibility to work at that level when necessary but also been able to build layers on top of that to achieve a higher level of abstraction without feeling like I was misusing the language.</p>
<p>It also has an awesome standard library and I personally find it convenient that your code will compile to a single binary, which can save you a lot of pain around deployment strategies.</p>
<p>Edit: typo</p></pre>YuanHao: <pre><p>Cool, this is exactly what I was looking for, thanks a lot ! :D</p>
<p>BTW, what were you working on? I just realized the client logic was quite functional, and it seems like porting the server to Go will be fast. If you are interested on following or adding your feedback into the project, let me know :)</p>
<p>This is the working prototype from few years ago. It's me playing on my computer in Taiwan, and this guy recording it from the UK on his PC and Pandora (cool handheld)! <a href="https://youtu.be/GjcJF_sK7hY?t=55s" rel="nofollow">https://youtu.be/GjcJF_sK7hY?t=55s</a></p></pre>Thaxll: <pre><p>The biggest problem is code reusability between the client and the server, so basicaly if you don't write your server in c++ you will have to re-implement a lot things already working in your client. ( physics, world, logic, player ect .. )</p>
<p>Looking at your game it doesn't look to complicated so Go could definitly work but I don't think it's best choice here because of #1.</p></pre>shadowmint: <pre><p>fwiw even if you use the same 'game logic' classes on both sides (client and server), go is still an excellent choice to write the network layer in, and expose it as a simple c-api which is invoked from C++. </p>
<p>Getting robust server networking running in C++ is notoriously troublesome.</p></pre>Thaxll: <pre><p>Physic will be your #1 problem if the language is different.</p></pre>YuanHao: <pre><p>Yup, game is not really too complicated. The server, actually, only acts as a "relay" of controller input and pretty easy decisions (what move was executed), it doesn't need to know much about the game logic itself.</p></pre>ultra_brite: <pre><blockquote>
<p>it doesn't need to know much about the game logic itself.</p>
</blockquote>
<p>So nothing prevents players from cheating at your game. At that point you're better of going peer to peer, not sure why you need a server at first place.</p></pre>g0dsCookie: <pre><p>+1</p>
<p>I suggest you to write all your game logic in your server and remove it from the client. So the game client does not know anything about the logic. </p>
<p>If the game should also be playable offline in a single machine, you can deliver your server binary with the client ones, let the client start a local server and connect to it. </p>
<p>This way you do not need to rewrite anything and it's harder to cheat. </p></pre>xiegeo: <pre><p>Peer to peer networking code is much harder than server based. considering clients have dynamic IPs and NAT firewalls, you need a server for coordination and fail back anyway. I would only add P2P if there are large data transfers that you want to move off the server.</p>
<p>Unless your logic is bug free, users will find ways to cheat (exploit bugs) even if they can't change the code. So you will need to do other audits to find cheaters and fix the logic, even with the logic on the server side.</p></pre>shadowmint: <pre><p>Look at gRPC using protobufs; you'll find mapping the networking much nicer than doing it by hand; all of the connectivity, retry, etc. is rolled up for you.</p>
<p><a href="http://www.grpc.io/docs/quickstart/cpp.html">http://www.grpc.io/docs/quickstart/cpp.html</a></p>
<p><a href="http://www.grpc.io/docs/quickstart/go.html">http://www.grpc.io/docs/quickstart/go.html</a></p>
<p>You can also look at using -buildmode=c-shared and using your go code on both sides; but this currently isn't supported on windows.</p></pre>knotdjb: <pre><p>Go is a pretty straight-forward choice for this kind of project. Can't really say much else.</p></pre>kl0nos: <pre><p>There will be no problem at all with your game server written in Go because this game is very simple. Using C++ here is overkill and not needed complexity. You are not solving any problems here that would need C++ like for example physics simulation with state on server, collision detection systems, keeping world state in sync with massive amounts of game objects etc. Just go with Go, you will not regret it.</p></pre>danvys: <pre><p>I wrote this small connect 4 game in go: <a href="http://c4arena.com" rel="nofollow">c4arena.com</a>.
It took me some time to figure out how to do some things in go. This language is different from what I am used to. Go looks like language from another planet to me but I am getting better. I am already working on new game. I am glad I started with small project first. Now I have better understanding of writing go game server, so working on new project is easier. Go is definitely worth a try. Good luck on your projects</p></pre>kunos: <pre><p>I used Go for the game server for our game (Assetto Corsa if you want to check it out), the game itself is C++ like yours. If I could go back in time I would use C++ for the server as well. The main reason is that you'll find yourself rewriting the same pieces of code twice quite often. You will also have to add a Go environment to your ecosystem. Yes, Go will offer some nice things from the start, such as the possibility to add a webserver to your game server with few lines of code and, of course, nice concurrency, "free" Linux version and so on.. but IMHO, as awesome as it is, it is not worth the hassle due to the points above. Hopefully one day we'll be able to write server AND client in Go, a man can dream right?</p></pre>Thaxll: <pre><p>I'm curious what did you do for the physic? Did you re-implement all of that in Go?</p></pre>kunos: <pre><p>No that would be simply impossible. The server is simply a message forwarder and the car performance validation is kept to a bare minimum.</p></pre>
