Concept

Thinking about implementing a trading card game in java led me to think about what "surrounds" a TCG in general. And these different aspects led me to implement JPortal the was it is now:

  1. First a firm in the gaming industry releases a Set of cards. Sometimes with some kind of theme or some kind of relation to other successfull products (World of Warcraft e.g. led to a TGC spinoff). Such a set of cards (general number about 200) consists of all possible distinct cards a player can get (for that release). Not every player has all those cards, because some are uncommon or even rare and not all playes will have access to them. Thus: all possible cards of one such released set in JPortal are refered to as a CardSet or short just Set. One TGC can have different sets (releases and or themes). In a "programy" way one may think of a CardSet as a template of the real cards, or the class-definition.

  2. A Player can have a number of cards. There are different ways to get cards - as booster packs, as starter packs or as themes etc. All cards a player has got in his drawers, on his table on a shelf or wherever are called in JPortal (for loss of a better wording) CardHeap or short Heap. Naturally cards in a heap can occur more than once - each TCG-player knows - common cards spill out of our ears...

  3. In order to play an actual game, a player can not (usually) play with his complete Heap. Usually a player selects some cards (different sizes..-, 35, 60... or more cards). These selcted cards are called CardDeck(s) short Deck. A Deck ist allways a true subset of the Heap.



Game menus


The 3 middle menu items represent the above concept and were the first to be implemented to the project.

These were card related thoughts.

Game related thoughts were:

  1. the game has to be expandable by "users"

  2. AI Players

  3. the game should have a trading card feeling

  4. the game should provide visual information about the progress and the state

This is what I tried to make out of these thoughts:

The game has to be expandable by "users"

The thought behind the above statement was, that never ever a single person can hope to go anywhere near implementing a large portion of Magic cards into one program. What I'd love to have is a generic game, that can cope with a majority of magic "needs" and that a bunch of hopefully dedicated users are willing if not eager :-) to support a project like JPortal and bring cards into the game. I know - now at the beginning stages of the project that is quite ridicuclous - but once the different mechanisms of the game are built into JPortal that a possibility exists.

To be able to keep up with that goal, I provided a mechanism, that there is NO NEED to have hardcoded information about specific cards in the game itself (though it might be that some methods were only built to support a general functionality right now only used by one card).

To achieve that I implemented two card information sources (none of them hardcoded card in the program)

Each card definition is based on these two entities. Both information sources are collected into a XML file, which keeps all card informations ever needed (for that specific card).

Situations

The game itself is built up on different phases. In these phases certain things can occur. These things to be clearly non specific :-) result in situations. A card can be in different situations, a whole platoon of them like: CARD PLAYED, CARD DECLARED AS ATTACKER etc...

I still might not have "found" all possible situations.

Anyway. Each card can have a "behavour"- script for each situation. (For most cards only 1-2 scripts are ever implemented, since not all cards can be in all situations).

Thus if I play a Fire Dragon internally the game asks the card to execute its CARD PLAYED script. Within that script (which by the way can be edited on the fly in JPortal) all things are handled neccessary for the card to behave like its described in the spoiler text. For the card to be able to influence the game it has to be given much power. Actually YES, each card has within its script absolut power over the game. You could implement cards, which damage the other player for 1000 of points, take away half its library or steal his creatures and put them into your own hand. That is magic. Cards are like that! Each card script is passed a reference to

  1. the current match

  2. the current environment

Speaking in Java-Mode. All public methods of those classes can be called! Which really means you can do much! Look at the class documentation (once it is finished). For scripting I use BeanShell (Look at: http://www.beanshell.org/). You might look at the development section for more info.

AI Players

I was allways intrigued by AI. Once upon a long ago I programmed a computer monopoly with AI players :-). I loved watching 2 AI's battling each other - and do so still with JPortal.

These were the main AI goals:

  1. The AI should be independent of the program

  2. The AI should be expandable by users

  3. The AI should not be "card-specific" at least not very

The AI should be independent of the program

What I mean by this is. The main program should not be aware whether the player is a human or an AI.

Got it!

The AI should be expandable by users

The idea I followed here is quite similar to the one followed by implementing the cards. The game is a flow of situations and some situations require a reaction of an AI. Other Situations require not only an action from the AI but require an initiative input.

Again a whole platoon of situations can occur, like:

unlike a card a new AI must implement ALL those situations, this is what makes a new AI quite a lot of work (if not based on another already implemented one). The SimpleAI first implemented was more a proof of concept than a real AI. It was done to ensure certain situations were at all manageable by a computer player, and quite often if a choice was required I just took a random number and thats it.

The AI should not be "card-specific" at least not very

In order to achieve this I implemented a hint system. Each card can have hints, which are supposed to give the AI a handle for that card. The hints are in general not card specific - but for some specific card the system supports "single" hints. The hint system has still to prove itself, since it was hardly used while implementing the SimpleAI. I have to go further on in implementing the Allorund AI to be certain this works really ok. The system is quite open nonetheless. If someone wants to implement deck or even card specific AI's well he might just do that. There is a) no MUST to use the hint system, and b) you can get all card specific information you can dream of while in AI mode...

The game should have a trading card feeling

Well I wanted to do that. I guess I'm not there yet. To get more of that "feeling" I have to go further on the road of "Quest" mode - or whatever you want to call it. Will do it, if I do it for release 1.0 I don't know yet. First will come a good AI anyways. Without someone to challange the whole game could go to /dev/null.

The game should provide visual information about the progress and the state

I guess I did quite well. At least I can't think of anything missing. Well certainly it could be prettier, what can't. But you get a whole lot of feedback, help bubbles, Attacker / Defender signs, numbers, arrows and so on. Can't really think of more- if you can - please contact me :-)