Online Multiplayer/Coop Support

[ac-arcana]

I am certain Cogito is intended to be Single Player primarily, but I am curious if anyone wants to make multiplayer games with it. I personally would like to try to make something coop soon.
Phazorknight, would you be open to some commits that help facilitate multiplayer? I'm not suggesting it be supported in Cogito, but maybe breaking some functions into RPCs for easier implementation for example.

[Phazorknight]

I haven't looked into Godot multiplayer at all, so I can't really say how suitable Cogito is to convert it to it.

In general, I'm fully open to make it support multiplayer! I'd be curious to see how much the current systems/setup would have to be adapted to facilitate it. That would probably influence my decision if it should be its own fork or have it as an additional module inside of Cogito.

I know there was a person on YouTube who was also starting to try to implement multiplayer (user Jaxrud), I encouraged them to join the GitHub threads here.

Personally I'm still gonna focus on finishing up all currently planned features, their showcases, and the documentation for it, but then I might dive into some newer Godot courses I've saved (like this one) to learn more about the engine and use this to improve Cogito further. But that's easily months away for me. 😓

[ac-arcana]

You doing a great job on Cogito and I appreciate all the work you have put in.

I totally get wanting to improve and bug fix what is present. I am all for this, too. New ideas are exciting, but a stable core is really important. I'm not meaning to suggest that you should start working on MP right now.

The short version of this is that when doing MP, oftentimes you use an RPC to duplicate behavior. For example, if a door was opened and you want to sync that then the door opening would be in a separate function and tagged as an RPC. This still functions normally without running actual multiplayer.

I guess what I'm suggesting is that if I make an MP project I'd like to commit those changes to Cogito (just making stuff into RPCs) so that it becomes easier to implement for others.

[Phazorknight]

Yeah no worries, I didn't read this as a "demand".
I'd definitely up to include these kinda updates, if it's simple as that.

I'm more curious/worried about how stuff like inventories or scene / player states would be handled in those cases. If it would even be possible to have players in the same game but in separate game scenes...
That would be the true challenge to make this work or not, I think.

[ac-arcana]

Yes those kinds of implementations can be quite difficult. It's going to depend a lot of what you are going for.

For a coop game, inventories can be completely managed individually. Some games don't even bother to sync loot, others do. That's a design decision really. Whereas, if a game is competitive, you want a server managing inventories to help prevent cheating.

Same with whether players can be in different scenes and how that is handled, its a design decision as well as quite a bit of implementation depending on what you choose.

I would say if you will consider MP in Cogito, it might be best to have the code able to sync objects, doors, items, etc. if desired, but leave the architecture and server management up to the devs using it. There could be a simple MP demo scene, if you really wanted to take it far.

[ac-arcana]

I'm starting to make a public COOP repo with Steam for P2P, but also supporting the basic LAN.

The project is here:
https://github.com/ac-arcana/cogito-arcana/tree/COGITO-Steam-P2P-Coop

Godot Steam is required: https://godotsteam.com/

So far there are only some minor changes to player.gd
The syncing is extremely minimal at this point, position and rotation of the players are the only things synced using a demo level with nothing in it.

I'm going to build on this more. Perhaps this can inform some of the choices for whether MP can be supported in base COGITO.

[Phazorknight]

Oooh, super cool!
Looking forward to any progress on this and what kind of take-aways you'll get along the way.

[ac-arcana]

I can provide a little bit of feedback.
The way I'm trying to implement things has me fighting some of the design decisions in COGITO. This is unfortunate. I am not suggesting COGITO should change though.

Just as an example, the COGITO scenes all have a player, hud, and pause menu built into them and linked together. Right now I'm trying to support opening a game and starting a server when you're already in the map. This means I'll have to remove the current player when spawning in a player for the server. It also means that remote players scripts are going to complain a little, because for example, there is just no need for a remote player to have access to the pause menu.

I'm still working on better ways to solve these problems. For example I've made a variant of the pause menu with a multiplayer button now. I can't inject that into the demo scene and remove the pause menu that was already there, so in code I'm deleting the old one and replacing it.

I'm hoping when you are playing single player and want to host a game I can leverage the save and load feature. Ideally I'll save game, delete the player built into the scene, replace them with a multiplayer version, and then load game.

[ac-arcana]

Just to add to this a little further, I don't have to do it such a complicated way. I could just make completely different demo scenes for MP, but I want to do the complicated thing - be able to plug a scene already made for COGITO straight into this and have it work.

[Phazorknight]

The way I'm trying to implement things has me fighting some of the design decisions in COGITO.

Please keep me posted on your findings, as it's incredibly valuable on possibly improving COGITO in general. There's always multiple approaches to things, and I'm always open to hear feedback.

Just as an example, the COGITO scenes all have a player, hud, and pause menu built into them and linked together. Right now I'm trying to support opening a game and starting a server when you're already in the map. This means I'll have to remove the current player when spawning in a player for the server. It also means that remote players scripts are going to complain a little, because for example, there is just no need for a remote player to have access to the pause menu.

I see this issue and actually totally agree with this. The current need to add these three PackedScenes (Player, PlayerHUD and PauseMenu) is a remnant from when I was just starting out implementing these systems. Having these PackedScenes be part of Level scenes can actually cause some other problems as well.

My current idea on improving this is making that part of the CogitoScene script that's the root node of a level (currently used to set up connector nodes). I'd let the scene script instance player and menu nodes as needed.
This could also be advantageous for multiplayer to let the scene script detect where to spawn each player etc.

[ac-arcana]

My current idea on improving this is making that part of the CogitoScene script that's the root node of a level (currently used to set up connector nodes). I'd let the scene script instance player and menu nodes as needed. This could also be advantageous for multiplayer to let the scene script detect where to spawn each player etc.

If I could override that behavior with another script which allows me to spawn different players etc on my own then that would work really well.

Another option could be to have a scene that just contains the player and related items, and a script that loads levels directly into that scene. as a child.

On a totally unrelated note I just had an epiphany that I might be able to extend the player as a class into a multiplayer version and then I am not destructive with changes on the player.

[ac-arcana]

Ah I didn't think of input for some reason, totally make sense. Thank you. I can just override it and add a close for my menu as well.

Also, @Phazorknight for the ui hints that show on the top left, is there a quick way to make those from any class, or do they always need a reference to the ui?

[Phazorknight]

If you're looking for how to display your own hints, you'll find the function in the PlayerInteractionComponent, since that is the most common reference and usually gets passed to every object when an interaction occurs. Also easy to get when entering zones etc.

send_hint(hint_icon: Texture2D, hint_text: String)

This just emits a signal that then gets picked up by the Player_HUD.

If you're looking for changing the appearance of the hints themselves, there's a PackedScene "prefab" that gets instance when a hint signal is received.

[ac-arcana]

I'm just looking to post a hint when a server is opened, a player has joined, etc. So I'm not really using the interactor. Looks like I'll have to hook into the Player_HUD. Thanks!

[ac-arcana]

I'm almost hooked into the menu system and able to create games and join them through the pause menu (similar to games like Outward).

This fits in pretty much seamlessly. I have been able to just override classes I needed to change, which means the changes are non-destructive. I've added a couple of class names which I will eventually commit into base COGITO. Otherwise it just adds bloat for those who only want Single Player.

My conclusion from the architecture so far is that brining commits to change things into RPCs and such in base COGITO are mostly going to be unnecessary.

Considering the need for a GD Extension or GodotSteam, I think its best to keep this as a separate branch from COGITO.

I am happy to keep this a public branch, up to you Phasorknight if you'd like it to be a branch on your master repo.

I'll commit the changes to my branch once I'm a little bit further on here. The menu integration has been a big task.

[ac-arcana]

I've now got a working hacky menu integration. Its buggy, and needs a lot of work, but its functioning. I'm still only syncing position and rotation. I hope to work on syncing a lot more stuff soon.

[ac-arcana]

Just an update on this project. I've now fixed some of the connectivity bugs.

It works testing on Steam, but you need two computers on separate steam accounts to test it.
LAN works well in tests. You can just run two instances in GodotSteam and then set one to host and one to join. Note that currently it only will try to connect to localhost, so you can't use LAN on two computers until the menu is developed more.

I am now syncing position, rotation, and velocity, and smoothing them. Next step is going to be to start syncing items, switches, doors, etc.

[Phazorknight]

That's amazing progress. How are the player's represented in each other's viewport?

Implementing a basic player model with maybe even rudimentary animations would be cool. I haven't looked very hard but I haven't found a lot of generic manneqins that are set up ready-to-go for Godot, at least none that are MIT/CC0 licensed.

[ac-arcana]

I haven't looked for a good player model, so right now they are 'cool beans'. A capsule with a box near the top that looks similar to sunglasses.

Also, as of last night, I have switches fully syncing.

[ac-arcana]

I've been slowly plugging away at this, just wanted to say there is still progress happening.
All switches, doors (and locks) and carryable objects are now syncing. Next up I want to tackle item pickup and drop.

[Prashanna135]

Any update on how the project is going?

[ac-arcana]

I haven't found time to work on it for a while. Most interactable objects in the demo are synced but there is still a lot of work that needs to be done. I've made several issues on the branch showing what is left to do. I will return to this project once I've got some time for hobby coding, but that might not be for some time still.

…

On Mon, Jul 15, 2024, 07:37 Prashanna135 ***@***.***> wrote: Any update on how the project is going? — Reply to this email directly, view it on GitHub <#98 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJVOI7LFFICW45SPO2CDXTZMPNBVAVCNFSM6AAAAABEOWH7QWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMBVGIYDANQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[niefia]

Gave it a try and amazing to see what's already been done here. I did encounter a few issues though that weren't reported in the issues section, may give it a try contributing and seeing if I can fix those.

Some of them may be specific issues to it being run in 4.3, but I can't actually see any earlier release of Godot Steam P2P available. I'm at least familiar of bugs in regular Cogito's 4.3 so aware of those already.

The structure of this code is great btw, will make it so easy to keep updated

[ac-arcana]

Thank you for the kind words on it! I still have a 4.2 of Godot steam. I wonder if it's archived on other sites?

The online project is also pretty far behind the main branch.

Next week I have off work, so I might find some time to update the branch and do a little work to it.

Please feel free to create new issues that you've found on my repo.

PS I think this is GodotSteam for Godot 4.2.2
https://github.com/GodotSteam/GodotSteam/releases/tag/v4.9-mp

[niefia]

Thanks for finding that, tested the issues I was having and they were all still present in Godot 4.2.2

Managed to get GitHub to let me make branch of it also, so I've submitted a PR to fix one of the issues I've encountered

Trying to figure out the cause of the other issue I posted but that ones super weird

[ac-arcana]

I have updated the Coop branch so that it is only a few commits behind COGITO, and current commits should be easy to bring in.
I also think I tracked down the issue you posted with hint interaction. Have a look and see if its fixed.

[ac-arcana]

P2P Coop branch is now updated to 4.3. Still needs a lot of love, but its slowly getting better.