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.
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.
- 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.
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.
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.
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.
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.)
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"!
"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?
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.
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.
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?
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.
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.
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.
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.
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.
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].
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.
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.
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.
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.
