this post was submitted on 15 Jan 2024
14 points (93.8% liked)

Godot

6008 readers
85 users here now

Welcome to the programming.dev Godot community!

This is a place where you can discuss about anything relating to the Godot game engine. Feel free to ask questions, post tutorials, show off your godot game, etc.

Make sure to follow the Godot CoC while chatting

We have a matrix room that can be used for chatting with other members of the community here

Links

Other Communities

Rules

We have a four strike system in this community where you get warned the first time you break a rule, then given a week ban, then given a year ban, then a permanent ban. Certain actions may bypass this and go straight to permanent ban if severe enough and done with malicious intent

Wormhole

!roguelikedev@programming.dev

Credits

founded 2 years ago
MODERATORS
 

Hey, I am planning on building a co-op multi-player deck builder as a side project, nothing fancy or grand of sorts.

I'm kinda new to this Godot thing, but I kinda get the gist of it. Was always interested in it.

I have prior experience with Game Maker and Unity, so picking up the basics was rather simple, given that I also do programming as a job. So don't simply dismiss this as too ambitious a project to start with when learning Godot.

I just want to ask it out there, are there any advise on how I should structure the code or any advise in general? Just want to be prepared for issues in the future and plan for it.

Basically, my initial idea of the game is think of multiplayer Slay the Spire. But I want a more elaborate upgrade system to the cards, closer to Wild Frost.

For now, my head space for the design is to have:

  • Card details, ie names + descriptions + image are resources since they are data that are "loaded in".
  • Actual cards that exists throughout the run would be actual nodes, with modifiers as child nodes + Multiplayer spawners to syncrhonise them. Base cards will pull details from the resource and have an empty modifier
    • I previously tried to build it using Multiplayer Synchronizer, but then suddenly realized I can only sync simple properties. It didn't let me create a custom node and synchronize it. Then I had to resort to some ID system for the object which became rather messy.
    • Based on my current testing, Multiplayer Spawner seems to do its job better.
    • Should I use a "modifier node" + children to indicate the list of effects, or an array variable? I'm not too sure when to use the node to organize data vs using an array variable
  • The actual cards are stored as a global node, which would be moved to the "playfield deck node" during the gameplay portion

Lemme know if there is some obvious flaw in my approach or if there's a better way to do things. Or if such a project may be too ambitious with the current multiplayer library for Godot.

Especially the multiplayer aspects, since there is not "a lot" of tutorials on it, I feel like there's a few pitfalls that is waiting for me.

top 4 comments
sorted by: hot top controversial new old
[–] BoastfulDaedra@lemmynsfw.com 2 points 11 months ago (1 children)

I've built multiplayer stuff and can give you a little advice on that, sure.

First up, the limit for the amount of network traffic which can be sent over the web is surprisingly small, especially if you're talking about international distances, so don't ever send anything you don't absolutely have to. In the way of that, it actually is possible to have custom nodes synchronize, by linking them to a common shared piece of data that describes how they're built; but I really don't recommend it as it gets very complicated. (This is technically true with Unity, too, but Unity does things a little differently with GameObjects, and legally they're kind of a pain in the ass these days.)

You can use either an array (slash list) or a modifier node, but I generally personally prefer modifier parent nodes because the tree is very efficient and it seems to allow for more flexibility. It's also easier to inspect visually when you switch to remote instead of local. It's up to you, though; you can do either.

There isn't anything about this project that feels "too ambitious" for Godot's high-level networking, it's pretty much what it's made for. It's also been around for quite a while. In fact, you can technically even swap it out for GodotSteam's Steamworks networking interface now, but I haven't tried that out yet; I imagine something similar is eventually coming for other services.

I don't remember the name of it, but there's a video somewhere on YouTube that walks you through creating a very basic Team Fortress clone with Godot 4's high level networking. You might want to look it up.

[–] 0WN3D@lemmy.cafe 1 points 11 months ago (1 children)

so don’t ever send anything you don’t absolutely have to.

Hmm I was thinking that after I've establish a base and was going to optimize, I think that setting the multiplayer nodes to be manually updated should be ok rather than having them done periodically, since a card game game state progress at fixed events rather than being real time.

but I generally personally prefer modifier parent nodes because the tree is very efficient and it seems to allow for more flexibility.

One downside with nodes that I noticed is that if we store the cards in the deck as nodes under a deck node, it becomes rather annoying to manipulate them, eg shuffle them, as compared to list. Would that be enough a drawback to reconsider using a list instead?

[–] BoastfulDaedra@lemmynsfw.com 1 points 11 months ago

I'm pretty sure you can access the children of a node as a list with get_children(); which exposes all of those features anyway.

[–] Navigator@jlai.lu 1 points 11 months ago

Hi!

You should be able to sync any type of var with multiplayer_sync node. I don't remember how it is done thought.

To organize you can really use whatever method you prefer. I prefer to store datas into jsons/dictionaries and use arrays only to use the data for a specific purpose... Also be carefull because you can't send a node on the network to another peer.