Advice on handling tokens over cards (Incan Gold)

[Morgalad]

I'm working / learning how to use the BGA studio and for this my little proyect is Incan Gold.

In this game as you draw the card you count the number of gems named on it and then divide it into the "active" players.

I.e: you draw a 5 , there are 3 active players, each player gets 1 gem and 2 are left on the card on the table.

I´m wondering how to keep this simple using the location_arg for keeping the values persisted or maybe there is a better approach.

So some advice is needed.

Thanks in advance.

[fafa-fr]

Hi,
I don't understand what you exactly mean when you say "to keep this simple using the location_arg for keeping the values persisted". I think you need to be more precise, e.g. which values do you want to "keep persisted". I tried to start an incan gold game on studio, to see how you setup your interface, but it didn't start because of an error. If I have time I'll try later, but I really don't know if I'll have time soon.

[Morgalad]

Thanks the code uploaded on the studio is a mess and it is not runnable yet. (sorry)

I mean I would need to keep the remaining tokens over the cards for a later stage of the game.

and when triggering getallgamedatas I would need to redraw them.

[DrKarotte]

As far as I understand you and the Studio this should be possible as location arg has to be an integer, and this seems to be the case. You can store any integer there. Usually it stores the ID of the player who played the card to the location.

But: I am not sure if this is the best way regarding the possibility to get the information later. And you won't be able to use location arg as it is intended.

Surely it would be more complex to use the card value to create a stock with the tokens or something like that.

[Andy_K]

Does it matter where the gems came from after they've been assigned to players? Can you just store the remainder in the location_arg instead?

[Morgalad]

Does it matter where the gems came from after they've been assigned to players? Can you just store the remainder in the location_arg instead?

Hi,
Maybe if I explain (briefly) the game rules would be clearer.

Players run 5 times a expedition into a temple (you reshuffle and draw a row of cards)

A card is drawn, could be gems or a hazard:
-gems are picked from the box, then split among the live players and the rest are left on the card (floor of the tunnel)
-then players vote secretly with a faced down card to explore or to return to the camp.
-the leavers may pick and split the gems left on the floor while returning to the camp, then their gems are safely stored in their tent (these gems cannot be lost now).
-There are 5 types of hazard cards and 3 copies of each: mummy, snakes, spiders... when the 2nd of a kind is drawn the remaining players on the temple drop the pouches with the gems they have collected in this run and flee to the camp.
-The remaining players repeat this process until they decide to retreat or they are kicked off the temple by a hazard

[Andy_K]

Ah yes, I know this game now.

It doesn't matter which card a player got his gems from once he's got them, so once divided out I'd store the assigned gems against the player with a new field player_gems or something. For the card deck, you'll probably need the location_arg to store the index/order of the card in play on the table, but this has a maximum value of less than 30 and you'll never have more than n-1 leftover gems (where n is number of players) so you could quite easily conflate the number of leftover gems into the same integer, by having [location_arg = index*10 + gems] or gems*100 + index, or something like that. It doesn't really matter as long as you don't exceed the maximum value for the field and your information compression is fully deterministic both ways.

There are other ways to store info in an integer too, for example you can store an array of flags by summing powers of 2 for the 'on' positions (1, 2, 4, 8) etc. Make sure your code is documented so you remember how you got the numbers

The gamestatevalues are integers so this sort of thing can be handy there too.

It's not always possible to fit all the information you need this way though, so for more complicated use cases you could add new tables, or new columns to existing tables.

[Morgalad]

I finally decided to use the location_arg to store them (the order of the cards could be messed if pressed F5 but is not relevant for the game).

Now I have something working on the studio, still some work to do.

PS: I published the code in github:

https://github.com/AntonioSoler/bga-incangold/