0
\$\begingroup\$

I'm thinking about developing a scalable real-time online multiplayer game. it would be an online 2D battle game. I'm an experienced software developer but this is my first experience in game development. After doing some research on the internet I found the following architecture for my online game:

  1. Game Core: Using Python or C# to build the game logic including the environment, objects, movements, etc. it would be a server-side game. It means that every event would be handled and controlled by the server and users just send their inputs to move around and act (e.g. moving, shooting, ...)

  2. Web Service: There would be a database to store players' information and a web service (using WebSocket) to authenticate users, interact with them, and stream the data. Players send their requests to this web service, then the requests will be sent to the Game Core using a local network socket.

  3. Unity: We will use Unity to render the game on the client side.

The problem is the Game Core, I don't call it a Game Engine because it will not have any graphics on the server side, it's just the game logic. I tried to write a few lines of code for the Game Core, but it doesn't seem right, because I'm creating everything from scratch including player movements, gravity, etc. it's like reinventing the wheel.

How should I approach this server-side development to maximize development speed and minimize duplicated effort?

\$\endgroup\$
3
  • 2
    \$\begingroup\$ Unity allows you to develop in C# and includes "netcode" [libraries to synchronise player and game state across the network]. Posting as a comment as it's not a direct response to your question. Be aware that implementing proper synchronisation across games is a hideously complex topic that impacts everything from how you implement your physics engine to constraints on game design. Have a look at arstechnica.com/gaming/2019/10/… and developer.valvesoftware.com/wiki/Source_Multiplayer_Networking to get an idea \$\endgroup\$
    – Basic
    Commented Sep 14, 2022 at 8:49
  • \$\begingroup\$ I'm sorry, but we generally don't handle technology recommendation questions on this website. The reason is that what technology to use for a particular game is highly specific to the particular requirements of the game and depends a lot on personal preference. \$\endgroup\$
    – Philipp
    Commented Sep 14, 2022 at 9:16
  • 1
    \$\begingroup\$ I've attempted to edit out the off-topic "which technology to use" aspect of this question to focus on a more constructive "how to develop the server side efficiently" angle. Hopefully that's enough to keep the question open while still being useful to you. \$\endgroup\$
    – DMGregory
    Commented Sep 14, 2022 at 11:32

2 Answers 2

2
\$\begingroup\$

If you're building your front end in Unity anyway, I'd strongly consider using Unity on the back end too, if feasible, for a few reasons:

  • Both the client and server will care about many of the same concepts / classes / etc. If you have to implement these ideas and structures in two different languages/environments, you're duplicating effort.

  • This duplication creates new opportunities for bugs to arise, if a change is made in either the client or server code, but missed (or implemented subtly differently) on its counterpart. If both your client and server are built from the same shared codebase, changes in one automatically get incorporated into the other on the next build. (And without needing complex codegen/transpiler infrastructure to translate for you)

  • You're probably going to want some of the server code to run client side too - not to authoritatively decide the next game state, but to predict what the server's response is likely to be and begin animating/transitioning toward that state before the server's reply arrives. This client-side prediction helps the game feel smooth and responsive, rather than feeling like it's frozen or lagging when waiting for the next server update.

So this means you're likely to save a lot of effort if you can keep your development centralized in one language/engine rather than split.

If you're worried about server bloat, from unnecessary client-side concepts like rendering and animations spilling over, you can use the tips in this answer to conditionally compile out your display logic and assets in server builds, to keep them lean.

If running the full Unity engine on your server is not practical for your needs, I'd still recommend building your server app from the same C# codebase that you use in Unity. Then make whatever minimal shims you need to fill-in for the missing UnityEngine namespace code and game loop / messaging infrastructure you need to call into that game code. That can help you get the best of both worlds in terms of reduced duplication and improved server scalability. And you can use the Unity engine's API as a battle-tested guide for how your server-side core API might look.

\$\endgroup\$
0
\$\begingroup\$

If you are a Unity developer and have no idea about backend development then I would suggest to include backend developer(s) to the team as in this kind of multiplayer game development, the major role is of backend developer. All gameplay logic, AI are managed by the backend code. Only gameplay user interaction is handled by the frontend unity code. Game runs completely from the backend. Backend developer also helps in architecting the game in a better way to make it scalable. Server side games also help a lot in other ways also, like real time upgradation, difficulty management etc.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .