Godot newbie seeking sprite advice

Chris99

Hi,

I'm an experienced programmer but not when making games, and this is my first use of Godot.

I'm making a 2D card game for Android in which there is a pack of cards, and each card can be valid or invalid. An invalid card will have a red background. In terms of resource and memory use am I better off: 1. Having a node with a sprite for each card. This sprite has the full card valid or invalid image. So for X cards there will be 2X nodes and sprites. 2. Having a node with two sprites for each card. One sprite will be the valid one, and one sprite will be the invalid one, and I can flip the sprite visibilities to show the status of the card. So for X cards there will be X nodes and 2X sprites. 3. Having a node with maybe four sprites for each card. The sprites will be background, invalid background, card edge and card foreground (using the sprites like layers in an image). Each would have an ascending z-index and I would only need to flip the visibility of the invalid background image. So for X cards there would be X nodes and 4X sprites.

I am not sure of the best approach, or if I am overthinking this. One advantage of the third option is that I can very easily create alternate packs of cards for the user to select by altering just a single background image, without having to remake all the cards.

I'm keen to get advise from others that have made card games or other layered assets, as it is an area I can't find covered in YouTube tutorials.

Cheers,

Chris

TwistedTwigleg

I have not done much 2D development in Godot, and even less in Android, but I think any of the methods above would probably work.

Personally, if it was me, I would either go with method 2 or method 3.

From my experience, one of the biggest performance slow downs with Godot is having tons of nodes, so that might be something you want to take into consideration. Though depending on how many cards you have visible at one time, it probably will not be an issue. If it became an issue, you could maybe try to have the cards flipped upside down when not in use or something to save performance, as the upside down card could be a single sprite (where all of the other sprites, the front facing ones, are are invisible)

That said, I have not made card games myself and I mostly do 3D Godot development, so others might have better advice. I found this article on Medium that talks about making a card game with Godot, which may be helpful.

Personally, I would suggest just going with whatever feels most natural to you. (Side note: Welcome to the forums)

Chris99

@TwistedTwigleg - Thanks for the reply (and the welcome) and the link to Medium.

Cards are either visible of invisible, so I don't have to worry about a flipped sprite. I take it some sort of card node pooling is preferable to frequently creating and destroying card nodes when they are required?

TwistedTwigleg

You can probably get away with not implementing a pooling system if you are not creating/freeing several hundred nodes at a time. Godot has a pretty minimal cost for instancing and freeing nodes, so pooling isn't as necessary when compared to other game engines and frameworks.

That said, pooling may help and be easier to implement depending on the needs of your project and how it is structured. I've implemented pooling before and found it can be helpful in Godot when you need to have hundreds or thousands of objects.

The best way to know for sure would be to test. Personally I would start development without pooling initially, just because that way you can get the game up and going sooner, and then later implement pooling if the need arises.