This page is dedicated to high level concepts.
DeckStacker primarily takes care of 3 things:
Let's breakdown what all that means.
I'm defining "card behavior" fairly broadly, here. Let's list out all the different things that DeckStacker cards do:
That's a big list! Generally speaking, these are all behaviors that you may want to utilize for a card game.
Some of these behaviors are very obvious (like card movement and flipping), but some of them are less obvious (like tinting cards and fading them). I've been using this system for a few years, now, and gradually building up its capabilities. I've found that all of these different behaviors come in handy in just about any kind of game using cards.
Another staple of card games is how you are going to group and display cards to players.
In a typical card game, you can have cards arranged in a lot of different ways.
To name a few:
To account for the most common ways cards can be grouped and displayed, DeckStacker organizes cards into stacks.
These stacks have the following settings to change the way cards are arranged:
These stack categories will cover nearly any card arrangement you need for most games. Theoretically, you can arrange cards in an infinite number of ways, but the defaults provided in this system should cover most of what you want to do.
If there is one concept that should be kept in mind when using DeckStacker, it's that all cards need to be a part of a stack at all times. The system uses this assumption fairly frequently. If you don't want a card (or cards) to be strictly organized, there is an option called the "Undefined" stack type, which doesn't explicitly arrange cards in any particular way, allowing you as the developer to enforce your own card placement.
Additionally, if you feel up to it, you can extend the restack code to accomodate more stack types.
As previously stated in the Intro page, DeckStacker was built with the idea that card games generally have 1 thing that happen at a time.
To help facilitate this, a DSAction List is kept in DSActionQueue that allows the developer to add actions to it, and these actions will be executed in the order they appear in the List. This allows the developer to queue up several events ahead of time and let them play out.
Within this setup, you can add timing DSActions, such as DSDelayAction or DSWaitForCardsToStopAction, to allow for the game state to catch up to a particular point before the DSActionQueue continues with its work. (Optionally, you can make your own Custom Actions if you want the queue to pause for some other game state be present, before continuing)
An example of how this can be utilized:
With the exception of #1, the order of operations here are all supported by default DeckStacker DSActions. DeckStacker can only take you so far, though, so a framework is setup for you to make your own Custom Actions fairly easily.
More detailed info about how this works can be found in the DSActionQueue page and DSAction Guidelines and Use.