Card game, questions on showing and storing information

Hi all, after reading for a while it is time to exit lurk mode :slight_smile:

I have created a physical board game and now I’m making a digital version of it.

This is my first game in gdevelop and it uses a lot of cards.
I have an array for the cards which I copy to another array where I use array tools to shuffle them.

I’m hoping for suggestions on how to do things better because I’m feeling that I’m complicating it too much, probably due to my lack of knowledge.

  1. I have some MarketRow-sprites on screen which gets the information about the card that has been drawn and changes the animation to show the correct card.
    Is this a sensible way to show these cards?

  2. The cards contain a lot of values. I store those values in a global variable Cards (which is structure) and each card is a child array under there with the different values.
    Is this a sensible way to store these values?

  3. When the player buys a card I store it in a global variable Player1.CardsOwned. Also storing the indicator(MarketValueRealEstate) for which line it was bought at and also the income for the player.
    It feels a bit messy, but works okay-ish.

The big issue arises when the player is going to sell the card.
Then I need to take the current line’s Value, and subtract the Debt from the line when it was bought. Now my head really hurts from how to access the correct data points.

  1. I have put all the cards in a Scene group named CardsMarket1 and can create an object matching the name of the card, but I haven’t discovered any way to “grab” that object and use it?

To do the clean up I have made a delete object for every object in the CardsMarket1 scene group to make sure that it has been deleted since I don’t know how to target the one created specifically?

All feedback is appreciated. Thank you :slight_smile:

I found the klondike solitaire example and will see what I can learn and use from that :slight_smile:

Welcome Eric. This is an epic undertaking. Dunno if i’ll be much help, but i’m happy to talk it through with you in hopes i have something to add. I personally think the “right” way is whichever requires the least amount of moving and modifying data, but for complex projects like this the “right” way tends to be the way that my brain thinks about the data.

Ok, so questions to clarify the scope:

Superficially this is vaguely like monopoly, right, where there are a fixed number of cards with fixed values associated with them, but some of the values fluctuate over time? Or are there fixed types of cards, but limitless instances of those cards with differing values?

If i’m thinking about it correctly, you have a global variable Cards where position 1 is a structure of card1’s data and position 7 is card 7’s data… That seems perfectly logical to me. In order to merge that with the sprites on screen, i’d either store the animation number of that card’s sprite in the cards child array… or even better, i’d have the animation number match the card number. So, if you want to place a specific card on the table, all you need to do is set the animation of that card to the number you want, and then populate the fields on it based on that animation number. (like Cards[cardOnTable.Animation::Index()].

i’ll

what do you mean by grab and use? You want to click and drag the card and all its info?

(still looking through your post, but i’ll reply this for now in case i’m way off base)

-a

Thank you Andrew. Correct, a fixed number of cards with fixed values, but those values fluctuate over within 8 different levels on each card.
Good idea with matching the animation number and the card number.

The grab and use issue. At first I had an array with the order of the cards. Then created the object for the top card and showed it on screen. Then when it went away I deleted the object. To delete it I looped through all instances of the cards to make it work for any card drawn.
Now I have realized that it is much better to create all cards and moving them off-screen when not presented to the player. Which gets rid of the “grab and use” problem that I felt that I had and seemingly makes other tasks easier too.