Best Practice for Complex Serverside Gamecode?

Greetings,

I’m starting to get a handle on how to design an app with Nakama. I’m curious how we build complex serverside logic in Nakama.

Would all of this take place in LUA inside the GameLoop function of the MatchHandler file?
Or would I develop a separate program, perhaps in another language, and somehow interface with that inside the Gameloop function?

I’m curious how this is typically handled. I’m also generally curious about how to set up my dev environment to build and test serverside logic.

Right now I have to write my LUA, depend on my code-editor to make sure it all checks out, then save it. Then Restart my Nakama server. Then connect to my server with two or more clients, check my use case. If error, I may or may not get something from the nakama server explaining what went wrong. And then try again.

Testing serverside code feels really cumbersome. So I’m curious:

(a) if there are any thoughts on how best to set up the dev environment
(b) if most serverside code is written directly into the Gameloop function, or if it is common for the gameloop function to pass data to some other app that is responsible for computing my simulation.

Thanks in advance!

@Mehoo462 This is a great question. Unfortunately the answer as with most game development questions is “it depends on the game itself you want to build”. Nevertheless I’ll try to suggest some general recommendations:

Would all of this take place in LUA inside the GameLoop function of the MatchHandler file?

Since we added the TypeScript support to the server I would suggest you actually write logic in either TypeScript or Go. It may seem a little more cumbersome but the compiler tools will allow you to catch errors more easily when you want to refactor parts of your code in the future.

Or would I develop a separate program, perhaps in another language, and somehow interface with that inside the Gameloop function?

We never suggest this approach. I would recommend you avoid it. Either you’ll develop your multiplayer logic within your game engine and use the Nakama relayed multiplayer engine (and deal with client authoritativeness, etc); or you should create your Netcode to be the protocol for messages between the game client and the server loop and handle the server side portion of the gameplay within the match handler authoritatively.

I think I answered your two major questions. I agree that the development cycle is slightly slower as you work on your logic. An alternative approach is to use a mock library and write your game logic as a set of unit tests which can be run with inputs “faked” by passing them into your lifecycle functions rather than start the game server each time.

You will ultimately need to balance this with actual execution flow on the game server as you build up the logic but if the game is turn-based it can be a great development approach. If you provide more information on the type of game you want to build it might be easier to suggest more specific best practices.

Hope this helps.

Thanks for your reply!

I’m just starting to think through how these things I’ve been playing all my life actually work. I’ve completed a few simple things and now I’m trying to imagine how something more advanced might function.

Take for example, an FPS. I looked at this video of Overwatch devs talking about Overwatch netcode. If I understand them correctly, they’re basically running the entire simulation on the server and describing how disagreements between the three instances (client A, client B, and the server) get resolved differently in different gameplay circumstances…

Does this mean I have to rewrite large swaths of my game engine into Lua, Typescript, or Go? If I have to run my whole simulation on the server, wouldn’t I want to maximize the amount of code that is shared between the client and the server? I mean, I see a thousand reasons why that is hard and a terrible idea. But the alternative seems to be to write my game twice. And the second time needs to be in a remote environment that can be tricky to debug.

I’m sure I am both making things too simple and too complex at the same time. I guess I just haven’t wrapped my head around what the server actually is and is not doing in a fast paced real-timish genre like FPS, RTS, actionarcade, etc.

Appreciate any insight!