Beginner Qs: instanced scenes for unique cards? Or separate scene for each?

Selek

I'm a hobbyist dev who is new to Godot, but not entirely new to making games -- I've made a few simple games in Game Maker Studio 2. I decided to give Godot a whirl, and so far I'm enjoying it, but I'm struggling with organization of my code. I've read much of the official documentation and watched a bunch of tutorials. But I learn better if I dive in, make a simple game, and make my own mistakes.

To that end, I'm trying to prototype a simple card game, involving a deck of unique cards. For now, I want to deal out 3, select 1, process the 1 (not at issue right now), return the other 2 to the deck, and repeat. Eventually I hope to have a deck of more than 100 unique cards, and possibly larger deals and selections, but for now I just want to test with a small deck of say 5 or 10 unique cards.

I created a Deck scene with an array of dictionary entries representing 5 unique cards. I made this Deck script autoload, so it has global scope. I then created a single Card scene, and here's where I tried to get fancy: I had that scene's script choose a card at random from the global deck three times, erasing each from the deck as I did so. Then I put three instances of this Card scene in my Deck scene. To my surprise, this worked, sort of: I get three distinct cards displayed on the screen, and I can call an input event to select one with a keypress, and even use remove_child to delete the other two unselected cards. But now I can't figure out how to access the remaining card's data. It all seems to be null. Also, the global deck scene has repopulated back to 5 cards, even though I thought I'd erased 3 of them.

Should I just suck it up and make 10 separate card scenes, and add each as a unique scene instance to the Deck scene? If so, will that eventually mean making 100 separate card scenes? The whole node/scene thing confuses me. In Game Maker, I'd either make a Card class and the use new() to construct a bunch of unique card objects, or I'd make an array of arrays with card data.

Also, more generally, what should the "top node" of my game be? A UI node? A Game node that in turn controls a UI node and a Game node? I have the uncomfortable feeling that my current structure, with a root Deck node and lots of Card children, isn't going to hold up.

Thanks in advance for any advice!

cybereality

So for a card game you want to create all the cards upfront in the deck, which would be basically an array with a simple class that holds the basic card data. You can do it all with code. If you have a class Card class it might look something like this:

extends Node

class_name Card

var number = 0

func _init(number):
	self.number = number
	
func get_number():
	return number

Then in your main class, you can create a card like this:

extends Node2D

func _ready():
	var card = Card.new(7)
	print(card.get_number())

When a card is removed from the deck, you remove it from the array, and then when the card is done, you can append in back into the deck array.

Usually you want a Control type of Node for the top node (at least in a 2D game). This will help with positioning the UI. You could also use a Node2D (or Spatial for the 3D game) and then have the UI below. The Deck and Cards can be all code, so they don't have to be in the tree. When you want the card to appear on the screen, you can create a visual scene and initialize it with the data that is saved in the Card class (I just put number above, but you can add whatever you want). Then you can destroy the visual card but not the card variable, you will put that back in the deck.

Selek

Thanks for that very helpful reply. I realy appreciate your taking so much time to respond.

I like the idea of using a Control Node as a top node. I also like the idea of putting the Deck and Cards all in code. That was my instinct. I've just watched lots of tutorials that say "make everything its own scene." That may make sense for a platformer, but a strategy game has to hold a lot of data.

So a follow-up question: where should I put the script containing the Card class and the array of Cards that constitutes the deck? In a "Main" or "Game" Node/script just below the top Control Node? If so, do I make this Node/script autoload, so that it can be accessed by anything?

Edit: Does it still make sense to make a Card class if my cards have as much as 12 variables? (The "cards" represent works of art, with artist name, work title, genre, etc.) I had initially represented them as an array of dictionary entries. As you say, a class constructor could do the same thing -- I'd just have to pass as many as a dozen parameters to the _init function. That seems perfectly feasible. One way or another, I have to do a lot of typing.

cybereality

So the Card class is just a script (like Card.gd). You don't have to attach it to anything or put in anywhere (just as long as the file is in your project). The keyword "class_name Card" at the top will allow you to reference it in other scripts. So in the main script I just called "Card.new(7)" I didn't have to import anything or link them together, Godot does that for you.

I don't like autoloads, and you should avoid them if possible. Their main purpose is to save state when you change to a different scene. So, for a platforming game, you might get to the next level and the entire scene changes. Except you might need persistent data (like the player's health, XP, or other stats) so you need a global way for this data to carry over between levels. There may also be functions you want accessible everywhere, like being able to save your game, etc. So there autoload works well.

However, for most of the time, you should avoid autoloads. If you find you have a lot of global variables and state, that probably means you have a bad design. Scripts can access variables and functions in other scripts (for example, you can use get_node("Something") to get another node and then just call a function or load a variable). Mostly you want to only call down (so parent objects modify children objects, not the other way) and if you need to call up, then use signals (which are sort of like events). For example, you can have a button to shuffle the deck, when you press it, it will emit a signal to the main script to "shuffle_deck" and then that script does the work. You still need a reference to the main node, but this avoids coupling them too tightly in terms of accessing variables directly.

What I usually do is have my top node be a Node2D (for 2D or Spatial for 3D) rename it to Game and then attach my main Game.gd script to that node. Everything else will be a child under that top node (or children of the children, etc.). In a child script, you can access the main script like this:

var game_node = get_node("/root/Game")
game_node.shuffle_deck()

That is the easiest way to call other scripts, but signals are a cleaner method once you get into more advanced functionality.

Selek

Thanks -- that was just the kind of help I was looking for. I had a feeling someone would tell me not to over-rely on autoloads -- just as people at GameMaker used to tell me not to over-rely on global variables. I will try my best to get my nodes to communicate without autoload. I love what I've seen so far of signals; they seem very elegant.

While you were responding, I implemented the card class, created five card objects of that class, and filled the deck array with those five cards. For the card class, I even managed to create some optional parameters in _init() to eliminate some of the typing -- yay me! I was surprised how easy it all was.

When messing around inside the card-instantiation script, I seem to be able to access variables in a card object simply by typing Cardname.dataname. This seems easier than making a dozen functions to permit retrieval of data from a card, like get_artist and get_otherdata. But I suppose I'll need those retrieval functions to access the object from other nodes?

Thanks again for your help!

cybereality

Well, in Godot and GDScript everything is public (unlike languages like C++). So you can access variables from anywhere and do whatever you want, just be careful.

Selek

Ah, I see, so in some cases (maybe a huge game with lots of code), a data-retrieval function might be safer than directly accessing a variable. That makes sense to me.

Thanks again!