As a Dev I want to have more documentation and thorough examples for Networking

[ghost]

I would like to see a bit more extensive documentation on the networking part of O3DE. Currently the only thing stated under the HttpRequestor is limited.

https://www.o3de.org/docs/user-guide/gems/reference/network/http-requestor

It would be nice to see what are options are to

1. Use our own library from other open source projects (e.g. boost asio)
2. Other than HTTP requests, could we have examples on TCP/IP requests?

[lmbr-pip]

@NiklasHenricson Would be good to bring your request for more details to sig-network either in Discord, via an issue etc so we can separate what should be covered in docs, and what are new features.

• To use Boost ASIO you can make a new gem that brings that in as a dependency. We should have docs on how to make new gems and add dependencies to them. Do not believe anything today packages Boost ASIO for O3DE.
• For TCP/IP we do have low level socket classes in AZNetworking: https://www.o3de.org/docs/api/frameworks/aznetworking/class_az_networking_1_1_tcp_socket.html

But agree the Networking docs need more work to make them useful.

[ghost]

@NiklasHenricson Would be good to bring your request for more details to sig-network either in Discord, via an issue etc so we can separate what should be covered in docs, and what are new features.

• To use Boost ASIO you can make a new gem that brings that in as a dependency. We should have docs on how to make new gems and add dependencies to them. Do not believe anything today packages Boost ASIO for O3DE.
• For TCP/IP we do have low level socket classes in AZNetworking: https://www.o3de.org/docs/api/frameworks/aznetworking/class_az_networking_1_1_tcp_socket.html

But agree the Networking docs need more work to make them useful.

Hi @lmbr-pip ,

We already have a gem in our project that refers to 3rd party libraries, including Boost, thank you. We've met since the last time we spoke about it.

I think a network workflow diagram would be useful when it comes to the architectural aspect of how things correlate to each other in O3DE.

Something that explains why choose prefabs, over let's say instantiate entities on runtime. This is something my group currently is trying to wrap their heads around today.

Also a more descriptive workflow over the AutoComponents, their XML attributes and more examples on what can be passed in, in which format and where in the C++ code to capture those incoming values/inputs would be very useful.

Another "mystery" is the bus handling for network components. Which buses are supposed to be used, why and when.

I think once all these questions can be answered in the documentation it would be much more straight forward for developers to adapt to the O3DE structure.

Thank you

[lmbr-pip]

@NiklasHenricson Really appreciate the clarification, that type of feedback is incredibly helpful.

Am going to still add this issue to next SIG-Network meeting so we can discuss how we want to approach this and what overlaps with already planned work. Aim to break into smaller tasks so work can be split across contributors.

[lmbr-pip]

One question from SIG-Network was to cover some of the whys of your questions? What kinds of things are you hoping to achieve or solve? This may give help to some of the documentation requests we will break out of this.

I will send your "Something that explains why choose prefabs, over let's say instantiate entities on runtime. This is something my group currently is trying to wrap their heads around today." question to SIG-content.

[ghost]

One question from SIG-Network was to cover some of the whys of your questions? What kinds of things are you hoping to achieve or solve? This may give help to some of the documentation requests we will break out of this.

I will send your "Something that explains why choose prefabs, over let's say instantiate entities on runtime. This is something my group currently is trying to wrap their heads around today." question to SIG-content.

Hi @lmbr-pip ,

A while back ago we discussed our persistent-world-environment setting. Whether or not players and client connections are connected to the game it wouldn't matter. The "world" (server portion of the game) would continue running indefinitely and obey its business rules (time of the day, spawn/despawn/respawn mechanisms, rare NPCs showing up, etc).

I mentioned prefabs, since we look at a level/zone/map as an entity consisting of certain static elements. Trees, Buildings, Bridges, etc. Hence we don't need those to be produced dynamically by the code, contrary to what Dynamic Weather, Quests, NPCs, etc. would outside the level-constraints.

However, there's a grey zone for let's say interactable entities. They can be looked at as both dynamic and static content. E.g. Doors. Should be clickable/interactable and the door opening action should be replicated for all present clients/server instance.

Non-interactable entities (such as the motion of sun, moons/planets, night sky with its stars, etc), would also be part of the level entity, but their motion and changes should be pushed to all clients.

There fore from our perspective we deal with 3 types of entities

1. Static entities (do not change and are non-interactable. E.g. Buildings, Bridges, Roads, etc.)
2. Dynamic entities that are non-interactable (weather elements, changes in trees based on seasons)
3. Interactable entities (Doors, NPCs, etc.)

Those are our questions basically on how to deal with each one of these types of entities, how to organize them from an editor- and network- coding perspective

Thank you in advance,

Sincerely, Niklas