feat(multiplayer) networked player movement tut

[jonbonazza]

No description provided.

[NathanLovato]

Thanks for your contribution.

I'll let someone else chime in, but to me, this doesn't fit what we're working towards with the docs. Although this is still up for discussion. See #3390 and #4064 for more information. For now, I'd recommend you to put this tutorial on a personal blog or personal repository.

We're generally removing tutorials from the docs and moving towards a more reference-like style. Also, we're looking for a good place to have community-contributed tutorials, possibly a community-maintained wiki.

Note if you're looking to contribute new content to the docs, you'll want to check out our writing guidelines ( https://docs.godotengine.org/en/latest/community/contributing/docs_writing_guidelines.html ), gdscript style guide ( https://docs.godotengine.org/en/latest/tutorials/scripting/gdscript/gdscript_styleguide.html ), and there are things like you can't have comments inside the code because they're not translatable for now (#4188).

[jonbonazza]

I understand the writing style mismatches, but can you elaborate on how it doesnt fit the gdscript guidelines? Im following pep8 pretty closely i believe and i dont see anything out of place from whats mentioned in the gdscript guidlines.

No comments is also unfortunate. There are some things that make better sense when you see the explanation next to the exact code it references.

[NathanLovato]

Our guidelines aren't pep8. Also, we care about naming and other aspects that aren't necessarily covered by pep8. Four examples of things you did that don't fit the style guide:

• You have only one line between functions instead of two for long code snippets
• You use abbreviated variable names, like curr for current, etc.
• You put pseudo-private properties before public ones
• You put the class_name definition after extends

[jonbonazza]

@NathanLovato understood. This is something that is commonly asked for assistance with in the Godot community channels, such as Discord, so I think having official documentation around this area is still important. I'm open to feedback around how exactly it should be documented, but having it documented in some way is something we should definitely do I think.

I've seen the idea thrown around that godot-docs is moving away from "tutorials" (from my understanding, "tutorials" here means "step-by-step" guides?) and we should favor "reference" style docs, but so far, I am unable to understand what exactly is meant by "reference-style" documentation. Having been a software engineer for many years, to me "reference" docs means "class reference documentation" which I don't think is what you mean here. Does there exist a clear and concise description of what is meant by "reference-style documentation" in the context of Godot docs? I think this would be helpful to better elaborate on what is desired.

[NathanLovato]

Sure. A good example is the vuejs docs: https://v3.vuejs.org/guide/instance.html#lifecycle-diagram

It's not exactly their code reference (describing each entry in their API), it's full of guides, yet the guides describe a vue application instead of teaching you how to code specific types of apps or javascript and html in general.

In the case of Godot's web docs, I'd start by:

1. Giving an overview of the available apis
2. Giving an overview of each api's broad features and capabilities

At the moment, we need docs that describe how Godot's features work in general over pages that teach how to solve a problem that's not necessarily about Godot.

[mhilbrunner]

Content-wise, this is good, but I agree with Nathan that this strays outside of the scope of what the Godot docs should (and can) cover. Sorry. :/

We can't teach people networking. It's a huge topic. There are other, better resources for that. The high-level multiplayer tutorial points this out and links to, for example, the GafferOnGames article series.

Likewise, we can document what pathfinding facilities or rendering capabilities are available in Godot, and maybe give examples to use them, but we can't go into different pathfinding algorithms you could implement and show how to do that in Godot, or show how to write your own renderer and switch it out. Although both would be cool :)

We just don't have the resources to do this in a good way and to maintain it.

Networking is always going to be a "here are the basics, now build on top of that" thing. Too game dependent, too specific, and too large an effort to cover everything possible.

So closed, but please consider posting this somewhere for visibility and longevity, because it is good content. We really should see about getting something more user-oriented like a Wiki going.

[mhilbrunner]

Addendum:

I've seen the idea thrown around that godot-docs is moving away from "tutorials" (from my understanding, "tutorials" here means "step-by-step" guides?) and we should favor "reference" style docs, but so far, I am unable to understand what exactly is meant by "reference-style" documentation.

Reference-style isn't "this is how you do in Godot", but "Godot has these functions, this is how they work".
Godot doesn't currently have any built-in ways to do network prediction, reconciliation and such. The users need to build this themselves.

Still, having such "how to do X in Godot" is very valuable and useful, I agree. Thus, a official platform for such would be cool, like a Wiki. It's not that we don't want such content, we just can't maintain it ourselves.

[Vennnot]

This would make great course or youtube content Nathan!