Making a deck/shuffling.

[Amy]

Hello playMaker forum ^_^ I am currently working on a cross hybrid rpg/card game. I'm really looking for anyone who even wants to talk hypothetical's or who can shoot ideas. I'v already created a rudimentary hp, mana, system and have created two workable cards. (Fireball and Heal).

With those small hurtles tackled I'm trying to work my brain around the notion of inventory creation (So they can build the cards they want.) As well as a way to shuffle the cards and draw five of them every turn. Then each new turn, a new card is drawn. Anyone out there that could help?

[Maart]

Shuffle the deck:
Put the values that represent your cards in a string
Count your cards. lets say there are 20
Get random number max 20
Draw the card from the deck that represents your random value
Put this value in a new string and remove it from your old string with string replace
Do this in a for loop for all cards

[Amy]

This may be too general for me..or maybe I'm an idiot. I'm going to go ahead and see if I can figure out what you're saying in playMaker. I hate being a noob ><

So, I assume my little flow chart will have to look like this. User Buy's 20 different cards -> User Equips Cards -> Deck of 20 cards is made -> Shuffles five cards into a 'hand' -> Next turn adds one card.

[Maart]

I made a template with a simple example

[Jos Yule]

I'm currently experimenting with the ArrayMaker/ArrayList actions for Deck and Card handling. I've got the list of cards setup as a string (loaded via an external XML file - may eventually be a web-call). Using ArrayMaker, i then create an Array and fill it with contents of the string. I'm using a string like:

Code: [Select]

Aa1, Aa2, Aa3 ... Ac1, Ac2, Ac3 ... Ca1, Ca2
So, i've got the "suit" as the capital letter, the "type" as the lower-case letter and the "strength" as the integer value. This list is split on the comma, and then put into the Array.

I suppose i could stick with just using a String variable to hold all the data - this might make serialization easier. But i'm also worried about messing up the string some how - using an Array seems... cleaner? Less error prone? I guess only time will tell if that is true!

Jos

[jeanfabre]

Hi,

 Just created a shuffle action that goes with ArrayMaker:

http://hutonggames.com/playmakerforum/index.php?topic=835.msg6934#msg6934

What is the "strenghts" of your cards?

 I would strongly recommand you maintain an array per property, this might seem a lot of overhead, but I think it will pay back real quick as the system will grow.

so have perhaps, one gameObject, and in it three array, named "suit" "type " and "strength", and for a given index, you can get the card details by querying one of this array for that index.

so, the direct benefit is the following, if you want to have several hands, you create new arrays ( maybe as a child of your player game object), and in there you only have an array of 5 integers! easy, if you want to know which card they are, simply go through them 5 index, and get the type, or strengst on them array you created earlier. It simply becomes a convenient look up table ( here look up arrays ).

Hopefully that make sense.

So concrete possible process to get 5 cards:

-- have a prefab or (build that at runtime) with an array of int. let's call it "POOL" If you are playing with 56 cards, make an array of ints and 1,2,3,4,...,53,54

-- reset the "hand" array of your player ( so it has nothing in it)

-- generate a random number called "index" within the "POOL" array length
-- get the int at this index, and put that value in "hand"
-- DELETE that index in "POOL", cause you have taken it, that card doesn't exist anymore
 
-- generate again "index" within the "POOL" array lenght ( that is 53 now)
-- get the int at the index, and put the value in "hand"
-- DELETE that index in "POOL"

 etc etc until you get 5 cards.

You might get confused at first, because you are dealing with ints everywhere, ints for the index of the card you pick, ints for the reference to the card in the set of "look up arrays"

I guess I could create convenient actions to do just that, ( take x random unique elements from an array, and other goodies)

 Tell me, if what I explained is too much, if so, I'll do some actions to ease your work.

 Bye,

 Jean

[Jos Yule]

I've been thinking about moving the "actual" cards around, rather then using a simple index into a Architype array. That is probably a better way to do it.

My game is a bit more complex then a typical card game, but not as crazy as Magic The Gathering. I've got 4 suits, each with 4 "kinds". For example, my suits are "food", "person", "prop" and "creature". A "kind" of "person" could be "clown". We then have 5 clown cards, with values from 1 to 5. So our basic deck has 80 cards, 20 for each suit. Then we also have 18 special cards.

I have to not only keep track of the pool of available cards, but also used/discarded cards. This is so when the draw pool is emptied, we only shuffle in the ones that are out of play, excluding the ones currently in players hands.

I've also got "targets", each which can hold 3 cards, and there are always 4 in play. The players try to fill the targets with cards from their hand. So i need to keep track of cards in play on the targets too. And the targets themselves, as each is different (requires specific or generic cards to fill).

So, i've got a a template array, with all the Cards in the game, and a template array for all the Targets. A pool of available cards (pointers (indexes) into the Card template array). A pool of available Targets (pointers (indexes) into the Target template array). Arrays for the players hands (4 of them). An array which contains the current Targets (pointers). An Array for played/discarded cards. An Array for finished Targets. An array for each target currently in play, so four, which contain the cards currently on that Target.

I think that covers all the arrays i'd need

I'm still not sure about all the indirection/pointers. I think it would be easier/faster to just have the data itself available in these arrays, rather then pointing back into the template Arrays...

You've even further broken out the data, by splitting out the suit, type and strengths. That seems really third-normal form (from DB design). I'm not sure that i'd actually gain from that. I think moving the actual card data rep from array to array is more straight forward. The targets i can see keeping split out however.

I'm still designing, prototyping all this architecture, so as i go i get a better idea of what is going to work. Complicating this is that it is a network game, so i also have to send data over the wire about hands, targets, etc.

Appreciate the discussion about this stuff. It is hard to know if what you are doing makes sense without anyone else to bounce this stuff off.

Jos

[jeanfabre]

Hi,

 Maybe go for a totally object oriented approach, you could use arrays of gameObjects instead of dull strings or ints. You could then really manipulate the cards as if they were physical entities. that is the card being shown is also the card you query and host into an array and query for its type, suit,  if it's being used, etc etc.

 Then you benefit from "clever" cards, or better said, "cards" you can query, ask things, flag, etc etc

 As your system becomes more complex than a regular combination, I would actually look into that. because that would also be the enabler for animated cards, as you give hands, and progress through your game ( you know the usual card animations like flipping, moving around the table, create a new deck, etc, you would call a card "MOVE TO HAND" and pass it a player id or something and not worry that much more about how it's actually doing it within your game engine, you leave that to the card to compute.

 Do you have scripting experience? if you do, I would also envisage having to build some convenient actions specially for your game, to get to the point within Fsm. I normally never encourage doing so, but your system I think would call for such thing, simply because it make sense to optimize the Fsm states and actions for the purpose. You would end up with a set of actions to easily work with your game, and you could then plug some very powerful OOP component with your actions to query fast and well right within Fsm.

Bye,

 Jean

[Jos Yule]

Ya, i'm bought between wanting to use PM as my higher-level state keeper, but put all the code into methods/classes. Having actions which would then call into that, or encapsulate that functionality makes sense.

I've been trying to separate the visual from the model as much as possible, so i'm not sure about actually bundling the data and view together in a class/component on a (visual) GameObject.

I'm not new to programming (scripting or otherwise), but i am new to Unity, and its unique architecture. As with any new environment/toolset, knowing the language is the least of the learning needed.

I'll keep posting in this thread as things move forward.

Jos

ps. good to have a place to have a conversation about this stuff!

[jeanfabre]

Hi,

 When mixing classes and PM, make sure you create the right proxy, remember that PM can not work with System.Object reference ( that is bear bone classes), only GameObjects or Components. So either go for component based framework OR a static class that you can then call from everywhere including PM actions, I would tend to work with a singleton in your case.

during runtime, I always ending up mixing everything... I guess because building a true MVC system is just a pain if you start from scratch, never saw the benefit of it if a true MVC framework exists and mastered...  but that might be because I am not a real programmer... I personnaly much prefer thinking in terms of OOP then  MVC, I feel more confortable and I seem to find that it suits the way Unity works better.


Bye,

 Jean

Ps. Yeah, interesting thread!

[Jos Yule]

Have been working on Dragging and Dropping, with lots of feedback stuff. Has been going well. One thing that i didn't really have in my head is that i can use the variables in the FSM, rather then having scripts attached to GameObjects.

Also, i'm more and more bought into having an OOPish design, and not worry so much about MVC (or whatever). Getting this Drag'n'Drop stuff working has been illuminating, in the sense of "just do it and see what happens". I wouldn't want to do that whole project without any planning/design (and really, i've already done tonnes of that), but because of my inexperience with Unity, i did need to just do some work.

The FSMs to support the Drag and Drop, and feedback, are not too complex. A sprinkling of global events and variables, 4 FSMs - 1 on the drop target, 2 on the drag objects and 1 for the Finger Gestures Actions for detecting drag events.

So, forward movement! Now to figure out some more of the dynamic elements - instancing unique drop targets and drag objects.

j

[Jos Yule]

Here is an image of the FSM on the draggable objects, which deals with the Trigger Enter/Exit stuff.

I'm now using Tags and Child Of comparisons to ensure that i'm only able to drop on drop targets, rather then also on other draggables.

[Jos Yule]

This is the FSM which deals with the Dragging - this FSM is on the same GOs that the FSM in the previous post is on. ie. Draggable items have both this FSM and the other one attached.

[Jos Yule]

And here is a link to a demo of the Drag and Drop: link

There are 3 draggable items, and 4 drop targets. The 1st draggable has 2 valid drop targets. the 2nd has none. The 3rd a single valid target.

You can see snap over, snap back, and that when using the 1st draggable, it will snap over either of the two valid targets, when dragging between the two of them. This is what i needed the Array for, to keep a list of valid targets, when leaving other targets.

Some of the colour feedback on the draggables is not working fully correctly. FYI. Again, this is just a demo, mostly for myself, of how this is working for me now.

Jos