ChrisVilches/Card-Game-Kernel

Designing the API first

Opened this issue · 0 comments

API Design

Nested containers

Example:

Player 1 has a container named player1 and Player 2 has player2. Both of them have a deck and hand containers, and there are many others, and some are nested as well.

The ID for each one would be:

[:player1, :deck]

[:player1, :hand]

[:player1, :another, :nested]

And accessing them would need the complete array to get to them.

Invoking events

Invoking/triggering events would be on a per container basis. These can be invoked even from cards, such as:

class MyCard < Card
    def some_method
        DATA_STORE.containers.get([:player1, :hand, :nested]).invoke :new_turn_event
    end
end

The event is then triggered on all cards contained in that container. Whether the execution is recursive (it goes down the tree and affects all nested containers) or not will be considered (maybe parametrizable).

Ideally everything works like this, although invoking events on an individual card should also be possible (but discouraged).

Try to remove IDs as much as possible

Using too many IDs for everything looks like a code problem. It can be fixed or improved.

IDs on containers are fine, but cards may work well without IDs.

Allow container manipulation

The append method isn't enough. It must have preppend, shuffle, and manually moving cards around.

Cards declare which container they reside on

Cards should have something like:

card = Card.new
# add to container...
card.container #=> [:player1, :my_container]

(Enhancement) Containers and data stores should be related in some way

If there's a container labeled as [:player1, :hand, :nested], then there should also be a:

data = {
    player1: {
        nested: {
        },
        c: 5
    },
    a: 2,
    b: 3
}

This is only for convenience and create some Rails-esque convention over configuration, but it's not necessary to use it like this. There could be a global data store for all the data, or only one nested Hash for each player, etc. The developer can decide how to store the data the way they need to.

This is too high level. It doesn't match with the purpose of this library.