What should the "core components" be?

Question

By "core components" I mean things that are not moddable/scriptable. Things like what cards are where (decks, hands, playfield, graveyard), who's turn it is, what "phase" of the turn it is, how many HP each player has, etc. I think the "core" should do the absolute minimum to keep the game running, and everything else should be through the modder's API. Thoughts?

Comments

Who said how much HP a player has isn't scriptable? :)

---

As quick note: I think the condition of game termination should be scriptable as well. If players can have additional stats than hitpoints, then players should also be able to do once they get 100 "marks" on them.

---

I guess it would still be good to have a core default vanilla setting though :)

---

How much HP they have *should* be scriptable, but the "core" will also need to know how much they have so it can determine win conditions and things, so it can't be something that *only* exists in a script. So the HP would be stored by the core and the API would provide something like player.get_hp() and player.set_hp()

---

@skiwi I agree with that. Imagine a "nuclear strike" card that starts with a counter of 10, the counter decreases every turn, and when it reaches zero, that player wins unless any other "nuclear strike" cards are in play, in which case the game ends in a tie. A scripted effect should be able to put the game directly into the "game over" state.

Answer 1

It's hard for me to think outside of a database scope, just by nature. But I will try :)

I do think a database should be used to store cards, decks, and some card properties possibly (attack/defense, description, special abilities, etc.). If I were to suggest the minimum approach, that would be it.

Doing that it would be easy to manage new cards, update cards, remove cards with cascade, perhaps store a player's warehouse or deck as a view that the application would call to load cards in memory for use in a live game.

As far as RDBMS, I have two suggestions. If you were going to use a central DB, I would suggest PostgreSQL as it is much more solid than MySQL, and it's free, unlike SQL Server. Another option, which would be more portable and could be bundled with the application, is SQLite. While it does have a few limitations, it's small size and standalone usage would make up for it in things like a mobile app.

Comments

The pgsql vs sqlite thing raises an interesting point. For this to work, we're going to need to have a central DB that stores all of the players' cards (so I guess pgsql would be the clear choice there). Something like an ER diagram (or class diagram) outline the core components and their relation to one another would be good to have.

Answer 2

I think we should start with the following core:

• A deck
• A graveyard
• A hand
• The playfield

It all actually depends on the scope of the moddability of the game, I would prefer a standardized game where only people can make their own cards, possibly even via a controlled environment such that we can track the cards correctly for balancing means.

Answer might be expanded upon later.