Hi , I read the documentation about networking still is not clear how I can use it in a multiplayer game. Can someone make a tutorial step-by-step hot to make a simple multiplayer game. It will be enough to use godot sprite - in 2d wil be suffice - where 2 player collide each other and the collision result will be saved in any kind of db + a simple server chat.
Thank you.
Hi, In case you have not seen them yet,there are two project templates for networking: -Multiplayer Bomber Demo -Multiplayer Pong Demo
These may help you to get started.
Thank you for your answer. :)
But this is what I call "reverse engineering"... Not "tutorial" What I want is to understand the process rather a possible result among all of possible ones.. Why and how are the 2 questions that a tutorial usually answer..
Do you agree?
I'm coming at Godot with no Python or Unity experience, but I have been doing hobby gamedev and game engine development/programming for 20 years. I find it hard to make sense of things like networking in Godot because I've always had to approach everything from the lowest possible level (i.e. sending raw UDP packets exclusively) and build up my own systems from scratch. That's something I've done multiple times over the years, for networking, physics, graphics, scripting, etc. but I am only good at it because I know what the rules are starting with just the raw elements to work with.
Networking in Godot (and GDScript in general) is trickier for me to learn than I thought it would be just because it makes many things much easier than doing them from scratch the way I'm used to, while other things remain just as complex as if they had to be implemented from scratch. There's no clear delineation as to what functionality already exists and what functionality we need to write ourselves, and if there is, it usually only applies to one way of doing something among a set of different ways of going about it, and there's not really much in the way to help us discern the different ways from each other.
But this is what I call "reverse engineering"... Not "tutorial"
I agree, wholeheartedly. I feel like there's enough different ways to do things that there should be some explanation as to the 'why' of the 'how'. At any rate, I'm sure I'll be wielding Godot within the month and perhaps I'll contribute some tutorials once I get the ball rolling on the project I plan to use it for. In spite of there being much documentation about the interface and how stuff works, and tutorials to do all kinds of little things, it seems as though there's still a pretty sizable dearth of information regarding how to go about actually making games with Godot that piece together the various tidbits of know-how.
You know what's the fun thing? There are a admin/some admins who take care about the code before a developer release it to commit in the main branch.... But the same admin/admins ALLOW to have such code without any kind of documentation..
Like the "code" was something separate from "documentation" - that's NOT TRUE ofc - . So who is the fault why we have code without documentation?
I was taught that "code" is INCOMPLETE/IN ERROR without documentation. - I don't talk about fixing bugs here -.
Allow people to commit code incomplete and in error is a bad practice that don't help anyone! As long there are people who are so lazy and not committed to release something complete we are doomed to have such problem until users decide that is not worth to waste time with that "incomplete game engine".
Admins say " I cannot force anyone to write documentation"... BUT they force someone to NOT commit a code if there are errors or miss something? Yes! Ofc. So.. UNTIL admins don't understand the real importance to have a properly documentation we can't do much. We are in their hands and in their brain........
I think Godot's documentation will get there. It's gaining more attention, notoriety, and respect from the gamedev community as a whole, which is going to cause more cries of "we need documentation!" at which point devs will have to go back and write it out. Sure, people would make cool stuff a lot faster if we already had more/better documentation, and thus attract more interest in Godot, but we'll get there. There's a bit of stuff that nobody has any idea about, like WTH is a ProximityGroup node for? Who the hell made it, and what does it do? The API 'documentation' doesn't explain anything at all about it that makes it useful in any way. Whoever is responsible for creating it will come around to making sense out of it for us eventually I figure. The same goes for everything else in Godot that's somewhat of a mystery. Otherwise, there's at least a good number of people who already have made sense of a lot of stuff in Godot, who have been working with it for a lot longer than most, and are dispensing explanations and tutorials. Thank god for them, yessir, otherwise we'd be mostly lost.
If having 30% of documentation is like " we get there" So I can agree with you :))))) Someone can say that we have 90% of documentation but for me it is a lie.
The documentation need at least: Syntax + description + basic example + advanced example + variation in different context + user comments.
