🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

linking unity or godot to networking

Started by
5 comments, last by dirty_elf 2 years, 3 months ago

my brothers and i are conceptualizing a game. if we decide to use an engine i’ve narrowed down our choices to godot or unity. it may be our game is simple enough we don’t need an engine, but we’d also like to learn so we may just use one anyways. the game we are envisioning will have one large lobby where players can form individual games that other players can join and play once full. no need for auto matchmaking or any algorithm to automatically match players

in my research and watching brief tutorials i think i have a handle on how to use the engine to create the game client, but the part i can’t seem to find is how to connect a game client to an online lobby or matchmaking server. is this something that is typically done outside of the engine? would i write my own server code in some other language (go, python, c#, etc…) then have the client (via the game engine) communicate with it?

are there any good resources to read? what is a good way to narrow down language choice?

new here, first post in fact. thanks in advance for the conversation!

Mechanical engineer with an unhealthy obsession for code.

Advertisement

I decided to write my own “engine” once, to try to understand how the math behind the camera works, including mouse picking. Are you familiar with OpenGL at all?

If you use C++ as your language of choice, then there are network sockets (for instance Winsock on Windows). Network sockets are only complicated if you do not know basic TCP/IP.

With Unity there is the Photon engine.

Neither Godot nor Unity have built-in networking support.

Unreal Engine does have some built-in networking support, and with the companion Epic Games Services, you also get accounts/lobbies/etc. The built-in networking support can also be re-purposed for Steam, Google Play, or the iOS game kit.

Often, lobbies are actually just another “game level” running, where the rules are different. (In Unreal speak, this is a different GameMode.) Then players that match up and want to play, use server travel to all join the “game” they select.

It is actually possible to build a reasonable game on top of Unreal Engine with entirely just blueprints/wiring, you don't have to write C++, at least for moderately simple games, but if you want to dive in deeper, Unreal requires C++. Also, Unreal requires pretty high-end target (gamer) hardware, and very high-end development hardware, or you may suffer quite slow build times. On the other hand, Unreal solves a bunch of problems that large teams run into, that the other engines can't solve – things like “we have multiple level designers working on the same level at the same time, and they need to interact through central source control” and such.

enum Bool { True, False, FileNotFound };

you say godot doesn’t natively support networking… is it even possible to create an online game with matchmaking in godot or unity? what would that involve? what would it look like from a conceptual level? since my goal is a 2d online game, are there better options for me?

Mechanical engineer with an unhealthy obsession for code.

There are some libraries in the wild that provide what you want at some level. We've used RakNet back in 2012 for a 4E type of game. But I don't think there are production ready solutions for what you want.

Neither game engine out there provide this feature as a built-in one, you always have to use plugins/features from their stores or open source solutions from GitHub for example, write your own code or buy a license of the engine company directly. Then you usually need a server for your online game. Lumberyard has some level of AWS support as both come from Amazon but that's it. So your best bet as a beginner is to get into network technology. TCP/IP and UDP are the 2 common used technologies for games.

Once you have either written your own TCP/UDP backend to use in the game engine of choice or installed a third-party one, you need to write the server software. As how games are different from each other, so are game servers. Making an online game is another level of abstracting the game mechanics. You can think of it as one application which is decentralized split into two parts, one running at your machine and the other somewhere else on the internet. Both need a well defined way to talk to each other, some level of security (SSL/TLS or something custom) and you have to design the game different to an offline one, at least to some degree.

A game server can run in multiple ways. Either you want the game run on the server entirely or you just want some degree of validation or don't care about anything and just route messages from one client to the others. I guess the later kind of server is the easiest and the first one the most complicated as you have to design it in a way that the game runs on a good performance level. It gets even more complicated once you add accounts and save states to the game online. Those are different kinds of servers (database and acount managing) which run dedicated from the game server.

Some good news for development is that you don't have to rent a server but can develop everything on your local machine at first and later move to some kind of dedicated device if you need.

I don't know if Steam offers something like that but then you're bound to their platform at least. Maybe worth working through their documentation

ive been reading the documentation on godot, and there is a whole section for networking - https://docs.godotengine.org/en/stable/tutorials/networking/index.html

it seems as if it may be possible to do what i am looking for all within godot, but it may not be the most efficient

i am reasonably comfortable with networking and programming, but have never implemented anything like this before. i am wondering if it would be better to start down the path of having it all contained within godot, or working on the backend server outside of godot and then somehow linking them together. the latter seems more performant and flexible, while the former seems a bit easier yet potentially slower and less full featured. maybe i start with the easier solution and move away from it where/when i find it is necessary

Mechanical engineer with an unhealthy obsession for code.

This topic is closed to new replies.

Advertisement