Multiplayer in Godot 4.0: Scene Replication (Part 1) | Hacker News Reader

Multiplayer in Godot 4.0: Scene Replication (Part 1)

godotengine.org

258 pointsTomte68 comments

You really can‘t overstate the huge leaps Godot has made in the last few years. Not only is it in many cases a viable alternative to something like Unity, but also more consistent, cohesive and easier to learn at the same time. The great blog post, like this one, only emphasize their qualities at that. And all that while being open source and crowd sourced.

This is an important combo:

  - open source,
  - easy to learn and
  - crowd funded.

By being open source, anyone can have access to it. By being easy to learn, most people who try it can do something cool with little effort. By being crowd funded, developers can work on it for as long as enough people are using.

Remember yesterday PHP 8.1 was released. Much the same story but in entirely different parts of the same spectrum.

> By being easy to learn, most people who try it can do something cool with little effort.

this is quite important - a good, smooth learning curve for a product (whatever it is) is important to adoption.

Being able to get up and running, and get a simple scene/game working is really great, but you also need power for the power users. Luckily for godot, since is pluggable, you can actually make it as advanced as you wish, and also have others contribute.

I hope godot success - it's one of the best open source engines out there.

It slots nicely with Blender and Krita in what might be the perfect indie developer production pipeline.

Thanks for pointing out Krita, I hadn't heard of it until now. For anyone else who hasn't, it's an open source digital painting program.

To expand on that: it can also do animation and is a very good general purpose image editor (far superior to GIMP imho). Basically, it's like an older Photoshop, without many of the more photography-oriented features.

I've worked on games where the entire team was using Krita for 2D assets and I feel like we were actually more productive than when everyone was on Photoshop. Outside of photography, I don't think I've even touched Photoshop in a few years now - Krita can even open PSD files.

It's decisively ahead of Unity for 2d for me at this point, and catching up with 3d. The few times I've had issues I've been able to start a PR and it's generally merged pretty quickly. Way better than depending on Unity to fix it at some indefinite point in the future.

It's pretty impressive. Godot's 3D is more than good enough for any indie game at this point, still behind Unreal and Unity but not sure it matters.

It's Good Enough™ for interesting 3D gameplay that doesn't need photorealism.

Seriously, too many games nowadays focus on just the "visual wow" with millions of vertex + raytracing, they fall flat in terms of gameplay.

I am friend of the founder I can tell the guy is amazing. When we were teens he dreamed something like this.

I also know him from my teens and agree with previous poster. Juan is an amazing coder. (hello biomemo :))

Hi great friend! let's connect! info for dms in my profile.

I've shipped commercial games alone with Unreal Engine 4 and Godot. I highly recommend Godot 3. Godot 4 wasn't quite baked last time I checked, but it will be a ripper with Vulkan support and very much of an overhaul.

If you're half-clever with your 3D knowledge (don't render an entire world in 1 mesh), Godot 3 is perfectly fine. The tooling of UE4 will win any time if you want to do open world though. Even though I've made a pretty convincing prototype, _huge_ blade-runner kind of world in Godot with flying cars; so it's all technically possible.

In other words, if you don't need consoles (and frankly as an indie you don't want to deal with the big boys), Godot is perfect.

Just don't hope you'll live off your game any time soon though, the indie market is utterly algorithm driven and therefor fucked. The learning experience and the joy of using Godot however, is well worth learning game development with.

Godot and Blender are really becoming some of the best in class in their own field.

With the advent of Windows PC "consoles" in the near future, I guess the need for traditional consoles will demiss.

For someone like me who is totally unfamiliar with what you can do with Godot, I found this video clip of top games illustrative https://www.youtube.com/watch?v=iAceTF0yE7I

As a gamedev beginner, I was pleasantly surprised by Godot and GDScript. The API is fairly sane (just enough magic to get out of your way), documentation is good, GDScript is easy to pick up if you know Python and the exporters for HTML5 (wasm) and Android worked without issues out of the box.

There are some weird things here and there, but so far the pros far outweigh the cons and I see myself prototyping ideas quickly in Godot.

Godot is amazing

The discourse on HN is even better. I come here every day for insight and context and encouragement.

Thank you Godot, thank you HN, no waiting required.

Ive been using 4 for a while now and its awesome. Still getting used to all the syntax changes. Got my material maker and unionbytes painter flows setup (both godot based tools) so suddenly my blank spaces are coming to life w textures. I love reading the change log (recompile often) and feel like I might actually be learning about cpp because of it.

This seems like a good a place as any to ask: what's the current state of C# in Godot?

Pretty decent support for mono and C# in Godot 3.x. It’s not perfect, but most things are well supported. There is a proposal to move everything to .NET 6, but it has been delayed until after the big Godot 4.0 release (4.1 next year at the earliest.)

https://github.com/godotengine/godot-proposals/issues/2333

A big challenge is that the current architecture requires a custom build of the engine that builds the whole executable as a .NET app that just happens to execute all the C++ engine code rather than a regular executable that integrates other languages as a plug-in. In theory, this is fine, and maybe ideal for modern .NET, but I don’t think there is much institutional support within the project for making special exceptions for C#. I believe they also no longer have the source of external funding (maybe MS?) that funded the original mono integration.

So, from my perspective, C# development has languished and might not make the leap to Godot 4. It appears to suffer from a chicken/egg problem where a majority of current users simply prefer GDScript. I think it would be a loss to drop C#, however, as I’m sure there are developers out there (myself included) who would prefer a modern .NET integration over mono and are holding out to see what the future holds.

I love Godot, but i tried the fps demo project, and performance was not good.

And I'm still curious if it's possible to make a low latency first person shooter.

I'm not confident it's currently possible to implement network prediction, even with gdnative.

I wish there was an equivalent to ogre3d, this engine was lightweight, flexible and easy to use... Urho3d is nice but the samples are verbose and hairy.

For the author: There's a small typo in player.gd:

    helath = value.decode_u8(4)

helath -> health

As someone who's currently doing a "roll your own" networking scheme with Rust and a bit of Bevy's ECS, it's interesting to see how engines do it. Much more "automatic"!

This feels a lot like what node did for js when it comes to client/server.

Great article - couple of questions:

"when the server adds the scene to the SceneTree, it automatically sends that information remotely. Each connected client will then instantiate the scene automatically,"

What information does it send remotely? Is it all the 3D info for every object? "Put a cube at 10,10,10, with scale 1, rotation 0 etc"?

"The RPC system will also work appropriately for the nodes spawned this way, so you can easily integrate state synchronization with messaging."

What is "messaging"? Why is integrating state synchronization with messaging a useful thing?

What information does it send remotely? Is it all the 3D info for every object?

For most games, no. For big 3D virtual worlds, yes. This is a big difference between games and "metaverse" systems. Most games use a big bulk asset download, rather than dynamically loading assets is needed. What to load next at what level of detail given the current location of the camera has to be well handled to provide a good user experience. It's similar to the problems of displaying a partially loaded web page, only in 3D in real time with far more content.

Did you read the article? The code sections show the player_name and position variables being synced with the position being synced every 16ms/62.5Hz.

The sentence right before your first quote answers your question -

"Note that the client code doesn't "instantiates" the scene explicitly. However, since the scene is marked for replication [... your quote]"

In this case its sending the scene for the clients to instantiate.

They gave an example of messaging as well - RPC.

Hmm, I've read it a bunch of times now but am still unsure: they ARE sending every bit of data - position, scale, rotation etc - about every cube/model/asset for a scene ("Since the scene is marked for replication [...your quote]")... and then after that they are syncing selected properties of that data ("player_name", "positions") every 16ms. Is that right? If you have a Fortnite-style map, every time you joined a game you would get all the map/model pos/rot/scale data sent to you?

And for messaging, I wrote "Why is integrating state synchronization with messaging a useful thing?" but I guess it would have been clearer if I asked "Why is integrating state synchronization with RPC a useful thing?"... what are some examples of what that's used for?

That does sound right. Apologies if my tone was rude earlier I was posting with little sleep.

I believe you want state sync and RPC integrated because you want a meaningful order to events.

Say a bomb exploding is done via an RPC call for legacy reasons and now position is via state sync. Youd want to ensure the explosion was ordered in respect to position updates to ensure it goes off in the right place.

GO godot! Be the best!

A question not related to the content in this article: Does GDScript offer better dev experience over using existing scripting languages like Lua? Does the benefit worth the maintenance cost?

See the FAQ for a list of reasons: https://docs.godotengine.org/en/stable/about/faq.html#what-w...

Yes. GDscript is fully integrated into the IDE, and once you learn “the Godot way” of scene management, development becomes fluid. Conversely, breaking out into another language to interface with Godot (my own personal experience stems from C# + Godot) while technically feasible, does not hold the same developer experience, and feels kludgy in comparison.

In my experience, spawning is generally a mistake. It brings a huge amount of potential pitfalls for join in progress, and often becomes an attack vector for griefing. On top of that, it makes hardware usage unbounded.

What you usually want is pools.

https://gameprogrammingpatterns.com/object-pool.html

Is this the kind of pool you're referring to? Just curious, I don't know a lot of gamedev.

Exactly that. Ideally, nothing gets allocated or freed during a given frame, it's just previously (upfront) allocated entities getting flagged as active or inactive.

Pools? (Vs spawns?) Good reference to learn?

I don’t follow. Spawning objects (which the article talks about as part of the network code) is unrelated to (re-)spawning players as a gameplay feature (which is where griefing could be an issue), neither of them make hardware use “unbounded”, and both are completely orthogonal to using pools as an allocation technique.

If you're in a competitive multiplayer game and you know that dropping an object on the ground or shooting a certain projectile will trigger new object spawns for a player who doesn't have them cached, you can do so rapidly and cause their machines to stutter/desync.

If you are building a competitive multiplayer game, maybe don’t use Godot’s basic/development network implementation?

Why wouldn’t those objects be loaded in a competitive multiplayer game?

Yeah not sure about this one chief. Is this an engine specific thing? I don’t see why spawning can’t happen on an async thread.

Anecdotally, this occurs often in the game Escape from Tarkov. New game objects entering the world can cause client stutters. This was a larger problem during earlier builds of the game because it was more pronounced and the stutters could either be used offensively by degrading performance on enemies computers or it could just be used to gauge game state.

Also to note, Tarkov has several inherent design problems.

This seems to be an engine specific thing though. Unity has always struggled with spawning objects in big maps. Rust had a similar problem for many years.

I think the two can live interchangeably. Pooling and such is more of an optimization technique.

For a tutorial like this limiting the number of concepts to throw at the reader is better than making sure its 100% production ready. I would be worried if reading a post like this was all you need for your entire games netcode in prod.

Is there a sane way to create an 2d array in GDScript yet?

I remember having an epiphany over the ordeal so maybe I found something. I will update this comment when I get home and read the code.

No, but like in every other programming language you can implement something like that yourself either by 1) nesting arrays (columns) within an array (rows) and access items them by map[x][y] or by using a single array and transform x and y into an index like y*width+x.

I always take the second approach and wrap it in a class [1].

[1] https://github.com/ZuBsPaCe/godot-base-code/blob/main/Script...

You can also emulate a 2D array in 1D. For array[w][h] you would allocate array[w * h] and instead of indexing array[row][col] you would index array[w * row + col]. Wrap all of that in a nice API and for all intents and purposes it's the exact same thing.

see https://stackoverflow.com/questions/2151084/map-a-2d-array-o...

Love the name

Wonder how long the wait for 4.0 will be?

If you don't mind compiling from source (it's super easy with Godot) you can try it now.

Edit - got me SMH

Whoosh, as they say, but thank you.

Since it looks you've missed it this was a pun about this [1].

[1]: https://en.wikipedia.org/wiki/Waiting_for_Godot

Anyone ever get so bored of web development that they just want to make a game or some shit?

yes I’m trying to make the leap, want to create something that people use to have fun

Yep.

Everyone loves games, so yes.

Yeah, but game development is hard, and I can never keep the momentum going long enough to actually finish something.

I don’t wanna die making modals and rest apis.

Just a small hint, if you care to take it. You don't have to reinvent the wheel. Start small. Small victories will build to large ones, and everyone can just use a win sometimes.

I had, had the WORST time completing a game project. I had gotten into the headspace where I thought I couldn't finish it (and, as for a large, wholly original project, maybe I can't).

I just decided to make a small match three game with minimal assets and minimal menu. Looks terrible. Unpublishable. But I finished it! I know how to plan it out, I know the warts that are involved, and I know how to get it on the platform I want should I want to publish.

There's something to be said for finishing an MVP of even a minimal project.

This advice is spot on.

Anytime I’m talking with someone at a meet-up who wants to learn gamedev, I advise them to make pong and add a new mechanic to it. If they can’t learn to do that, the odds of them making the game they envision is extremely low.

I’ve been in the industry for twelve years and have done the indie thing very successfully, and I still have low confidence when it comes to making a game that is any good. I keep waiting for it to get easier, but every time it does your ambitions increase to match.

My best (or possibly worst) advice is just finish 1 thing, and from there you can't go back to not finishing something. I used to flip projects every other month, now I go years on one thing and don't even want to change.

I say possibly worst advice because there have been times, and I'm currently in such a time, where I'm working on a fundamentally flawed idea but can't give it up in favour of something else. I need to finish it and finish it well, even if it feels undoable.

Eh it's not that hard, there's just a lot of aspects to work on so you have to work on it consistently. Maybe try a game jam sometime, like Ludum Dare and the sort.

Yup. Currently making one. Biggest challenge is the art. I can’t draw for shit so have to hire freelancers.

How's it been going? Any advice for people who are also terrible artists who will need to hire?

Have a budget. Be patient. Clearly communicate your vision for the game in writing.

Join a game jam! Every time I do one I think “At the end of the weekend I will have made a game”. Feels super good.

I suggest Ludum Dare nd GMTK jam. But there are many jams going on check out itch.io/jams

Kind of, I just decide to focus on rendering graphics/GUIs or compiler dev stuff instead, as game development is hard, pays bad and expects everyone to work like slaves while being thankful of having given the opportunity to work on a game, only to be laid off at the end of a crunch cycle just because.

Having seen how the sausage gets made has made the lose the interest of being part of such industry.

If you want to have fun doing games, try some retro game development, homebrew, or game jams.

Naturally there are studios where the above doesn't apply, sadly they are still mostly the exception, on an industry that carries crunch time as medal of honor.

Reply on news.ycombinator.com