The Playtypus Experiment #7

Why the slow communication ?

Are you guys alive ? Well ? Are you giving up ?

Short answer : Yes , Yes , No

Long answer : No

So … Following the post of Inno i’ll give you a bigger overview of what’s happening behind the scenes :

When I started this game I might have overestimated the tech ready-ness of the networking stack of unity. I’ve been blinded by all the stars of netcode for entities.

At the time I was like :

Yeah, no worries, it’s gonna be super easy with that, the scale is massive, etc … etc …

Oh boy I was wrong … I was so wrong …

The game plan

While the first gameplay and tech side has been mostly done at first by me, now we are two on the same boat …

And we are both crazy … So instead of giving up . We started experimenting.

The issue with netcode was : don’t laught , the scale. It’s simply not gonna work as explained previously in TPE#5 & TPE#6.

So as Inno explained we are doing our own multiplayer stack for the Proof Of Concept of the game.

We ( Me trying to keep everything on a healthy track & Inno being Inno ) went on a journey to develop that in multiple layers, each layer being built on top of each other that roughly look like this :

So Basically we are having our “Netcode” Layer that take care of connecting the clients , creating the server etc … Setup the Entities Worlds etc … That’s the easy thing, It’s green cause , well that part is done and we barely touch it anymore.

Next, PlaytypusNotwerk is the core of our tech.

It’s doing a lot ( maybe too much ) of stuff and currently is 2 layers of features :

• NotwerkTransport -> Welp transporting bits , CF : TPE#6
  • Ensure the reception of the data packages
  • Optimise the data to be as efficient as possible
• NotwerkCommands -> Our implementation of RPC commands ( messaging system between games over the network ) , it’s using the features from NotwerkTransport to do stuff
  • Support for sending a TON of commands at once
  • Better support of Entities IComponentData over the network

Transport , well … transport Commands are way more usefull in our implementation than they are in netcode for entities.

We do have some RoslynCode generator on the side to help with the boilerplate code needed to keep it easy to work with.

So PlaytypusNotwerk is in yellow in the graph, meaning that it’s working as intended, we are confident that it’s working with the features we want and we can actually build on top of it. Now we ensure that the API is staying relatively stable while refactoring the code in the background.

Inno is polishing that bad boy.

What about you Touhma ?

I’m glad you asked !

I’m working currently on the PlaytypusLockstep layer , it’s in red cause is very much ongoing work and we are still figuring out how to build it. How it should work ? Stuff like that.

The main Idea here is that it’s built on top of PlaytypusNotwerk ,that’s the third layer.

Now that PlaytypusNotwerk is functionnal I can act as a “client” for Inno and we figure out the quirk on the way.

PlaytypusLockstep is going to be ( for now ) for a few layers working independently of each others :

• A clock system ( Tick , Tack , Tick ) -> In other word a Tick system over the network.

  You Know what a tick is The idea is to execute actions in the game at a stable pacing to ease the issues of synchronisations

• A Verification Layer -> Framework for the gameplay to be able for the gameplay to verify if an action is possible or not.

  Roughly : Can you build something here ?

• A Planification Layer -> Planning depending on the state of the network when commands need to be executed.

  The build has been validated by the server, now when Am I going to see the action executed on my side ?

• An Execution Layer -> Framework for the gameplay to be able to specify gamecode to execute on both side

  What to do in the game code for the building to be functioning ? Components, Colliders, Animations, etc …

• A cleaning Layer -> Cleaning of the data now useless

  Once a command is consumed be sure that it can’t be executed a second time to avoid issues

• A Synchronisation Layer -> checking that everyone is in sync

  Ensuring everyone have the same results with the same orders of actions , if not , Kick the player and notify the players

The main Idea behind the Lockstep package is that we want to ensure actions are sync on the network and the gameplay is made so we are always in the same state than our friends while playing :)

Currently, it’s still in a rough state but we are prototyping that. Adding features when needed to PlaytypusNotwerk Clarifying the dependencies on the System Execution orders etc …

So pretty much not ready yet.

Next time you see a game with network that don’t work as intended right away. Welp , please be patient with the devs, it’s hard as hell.

Don’t yell at the devs, yell at the management that don’t give dev enough time & resources to figure it out in a good way.

What now ?

Still pretty much work is ongoing.

Once the Lockstep layer is done, we should be able to get back to the gameplay and test it in real condition with our Factory Framework to network it.

Until that please share this blog & the discord it would help us a LOT in the future when we start the real production work of the game.

If you have any question feel free to send it our way ! :D

Until then, you can join Our Brand new Discord to learn more about the project, chat, share ideas & meet the dev team !

Take Care everyone !

Touhma