Im planning on making a player hosted server game like Minecraft. How does Godot compare to Unreal or Unity as far as Networking goes?Game development center ( ) has a great tutorial on multiplayer. Is their solution complete?
I'd love to use Godot, but I'm scared that I'm going to start building then realize that the networking just doesn't work well, and the only way to fix it is to make lower level changes in the library and that will be really hard because there are not many tutorials or docs. And if I just went with Unreal networking would work perfectly out of the box. Could Godot networking APIs build something that works as well or better than Minecraft or terraria with just high level APIs?
So I've only done some initial investigating into Godot's networking and I can tell you it does 'work' but you're absolutely right to question how useful it will be since for me it's a relatively unknown engine compared to unity or unreal. One thing I have noticed already though is it is much easier to find information on it and get the initial setup done, I haven't though tested out properly whether or not how the networking handles things like hosting which I would like to try but maybe more experienced people who have experimented with Godot could comment on that.
If you do go with Godot, you're probably going to have to learn all about server hosting and so on yourself because of how Godot does not have any kind of third party services for multiplayer the way unity and unreal does so that's something you need to take into account. On the flip side though from what I've seen so far if you don't mind giving out external I.P addresses for people to connect to your game you can pretty much get everything set up yourself and working.
See this thread I made on the topic asking about this very thing, the people responding gave some pretty helpful information on it. By all means someone correct me if I'm wrong but in theory I think with the way Godot is setup by default you could probably host a game on your own server, give out the external I.P address of that machine and people will be able to connect if they have the same client and the game is running. It seems to run very much in the old school way like with Minecraft for example where you just directly connect to an I.P address rather than going through a server browser.
Bearing in mind I'm brand new to this too and still doing my own research and experimenting, I plan on getting an ultra simple 'game' set up where you can just move people about and shoot in 2D and see if I can get people to connect to an I.P address based on that. I think that's potentially where someone serious about using Godot for multiplayer should get started, just seeing if people can connect to your game from other devices.
Another example would be the way the old school Freelancer space sim game is setup now, to get around the issue of there being no multiplayer anymore players simply setup their own 'global server list' and so on which you could connect to using the I.P address provided, that would then let people make games on that server and then the list of games would pop up like the game had never died.
@Lethn said:If you do go with Godot, you're probably going to have to learn all about server hosting and so on yourself because of how Godot does not have any kind of third party services for multiplayer the way unity and unreal does so that's something you need to take into account. On the flip side though from what I've seen so far if you don't mind giving out external I.P addresses for people to connect to your game you can pretty much get everything set up yourself and working.
@Sir_Connery I'll deff try to test out multiplayer first, but should I use Godot if I'm planning on 2.5D? In other words, I want a 3D engine with 2D assets and only limited camera rotation.In other, other words, why don't I want to use Godot for 3D? Thanks
Godot works fine for both 2D and 3D. It's 3D renderer is simply a generation or two behind tech wise, but that is likely not a real issue for most indie developers. Your 2.5D example included.
@itgiawa said:In other, other words, why don't I want to use Godot for 3D? Like Megalomaniak said the rendering of lights etc. in 3D, Godot is at least a few generations behind Unity, and even more so other engines like Cryengine or Unreal. I don't recommend Cryengine or Unreal for solo projects though.
If you're aiming for a commercial level project then why would you use Godot for 3D? Just go with Unity if you're a solo developer. Lighting in 3D games makes a big a difference and the other engines are better at that. To top that you have much more tutorials for Unity. Especially in 3D.
@Sir_Connery When I say 2D over 3D I mean something like this _perfect_pixel_perfect_25d_pixelart_demo/So no need for fancy 3D lighting. I'll be using 2D lighting techniques. The reason I want 3D instead of 2D is I want to be able to shoot up and down at things and I feel like using a 3D engine is prob easier than 2D. Do you still feel like Unity would be a better fit?
I've been working on a game for my friends and I to play during quarantine but I can't figure out or find any information on networking using mirror. Everything I see gives vague answers to even vaguer questions that assume you have prior knowledge of networking. Could anyone give me any sort of direction on how to port forward using mirror or if there's a better solution?
Port forwarding is a way to connect several lan networks together.To port forward, start by opening command prompts and entering ipconfig. Then, copy your default gateway ip into whatever browser you use. From there, you can find the default password for your router at . From there, it differs depending on what brand of router you own but you need to look for something that says port forwarding. The default port for mirror is 7777 so enter that where it asks for the port and pick your computer where it asks for a device. Now, wherever you type an ip to connect using unity just have your friends enter your public ip. You can find it by typing "What is my IP address" in your browser.
Featured Blog This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
LinkedIn and 3rd parties use essential and non-essential cookies to provide, secure, analyze and improve our Services, and to show you relevant ads (including professional and job ads) on and off LinkedIn. Learn more in our Cookie Policy.
Writing a networked two-player game on PC has been on my to do list for a while. Early in my career I wrote code for arcade racing games that were "linked" (as we called it back then), but that networking was machine-to-machine using custom hardware that was fast enough to send a lot of data every frame at 60fps. The goal of this project was to learn more about peer-to-peer networking on PC over the internet, and when working from home started a year ago, it seemed like a good time to start a side project. I like the approach of "built not bought", so I set out to do the code, art, audio and music and get a simple two-player game working.
Tank games have always been a favorite of mine, from Combat on the Atari 2600, to Namco's Cybersled in the arcades to World of Tanks in recent times. Straightforward mechanics and a lot of explosions! And also a good testbed for learning networking.
Back in the day, my friend Mike and I talked about making an arcade tank game, similar to Namco's Tokyo Wars that came out in 1996. Turns out, he still has copies of some notebook sketches of our level ideas:
The scene uses Unity's realtime lighting and shadow systems with a single light source for the sun, along with a blue-to-tan gradient for the background. Mountains, palm trees, rockets, barracks, and burned out trees definitely aren't taken from any real location, but it looks like something I would set up in a sand box as a kid. The ground plane is one big texture and I painted in some fake ambient occlusion around the buildings and scenery to seat them in the scene better.
The cool thing about Unity in my view is that it's easy to get something basic up and working quickly (and sometimes without needing to do any real coding), but there is no limit to how advanced a project can get, all the way to shipping a complete professional game for console, PC, mobile and VR. (Here's a post about a VR project I did in Unity using the HTC Vive and Steam VR.) The Asset Store also has many, many demos and systems of various sizes and complexities that can be downloaded and tinkered with or used as examples. Lastly, there are dozens if not hundreds of online tutorials and books available covering all kinds of projects and games in Unity, including tank games.
Reading this post, someone might say, "Dude, there are a gazillion Unity tank game demos out there, what is the point of doing another one?" My answer comes back to the "built, not bought" approach and having some personal goals for my game projects: Standalone executable (not just running in the editor), an actual game loop that can be played repeatedly without exiting and restarting, and something that has gameplay to it and not just a demo of a basic mechanic or system. And most importantly, even something simple, when done well, offers a lot of opportunity for craft and learning.
Many of the tank game demos and tutorials out there are out of date or a bit simplistic, but there are a couple exceptions. While the one below isn't free ($30), it is a very solid tutorial/example not just on networking but on a lot of aspects of game design:
It's important to check what networking system a demo is built on. Most of the tutorials and demos out there were built using UNET, which essentially has been retired. Also check to make sure that you're using demos or references written in the last couple of years, as things go out of date fairly quickly. Here is a good summary of the situation with "native" Unity networking and a write-up on the available other solutions:
3a8082e126