Searching for advices about a CCG coding idea

[thefiremind]

I really hope this section is still alive, because I have an idea in mind, but before starting to develop it (or at least try) I'd like to hear some advices from the programmers out there.

First, a brief introduction of my background knowledge: I know C++ and Java at "university level" (meaning I'm comfortable with them but never made anything bigger than modest projects for exams), and I modded DotP (Duels of the Planeswalkers) 2012 and 2013, this taught me the basics of Lua and also gave me an example of a possible way to keep the cards separated from the engine.

About the CCG I have in mind: it's not an original idea. I don't know how many of you ever tried Eredan: it's an online CCG with nice graphics, nice mechanics, nice ideas overall... the only 2 bad points are:

• Playable only online. I'm still "oldschool" about this, and I think that any game should allow players to play offline against an AI, be it the dumbest in the world.
• Requires real money to be competitive. You can play for free forever, but you'll always be a hundred steps behind those who buy boosters with real money.

So this is my idea: I'd like to make an offline version of this game that allows to play against an AI with any card I'll be able to code. Maybe in the future I could add a "campaign mode" where the player starts with a weak deck and improves it by beating opponents, but I'd be more than happy even with just "select deck for me, select deck for the AI, play, rinse and repeat".

Let's start with my questions:

1. Separation between cards and engine. I'd like to hard-code as few things as possible. DotP games use XML files that define the cards and contain Lua scripts to implement the abilities. I like this system, but there are 2 limitations. First: when implementing a card that can't be coded with the current support functions, one or more new functions need to be added to the engine. I'm OK with that, but I'd like it to happen as seldom as possible. Second: I never tried to code something that uses Lua scripts side by side with another language (my modding experience only involved writing new Lua scripts while the rest was already set), so I should learn how to do that from scratch.
   I had an idea when I discovered that there are Java functions to compile other Java classes on runtime: why not making each card definition as a Java class that will be compiled and loaded at the start of the game? This would open a world of possibilities because anything that the engine can do, the card itself can do as well. Do you see any drawbacks on this? Do you know other ways to do it?
2. Processing of card effects. Cards make different things happen, with different durations: I could have a statistic modified until the end of the game, but then another card modifies it again until the end of the turn, and when the turn ends I want to go back to the situation given by the first modification. This is a classic for any CCG.
   My idea consists in implementing a list of active effects, and each time I need to update them, I revert the game to its original state and then reprocess the entire list from the start, in chronological order. When an effect ends I can just remove it from the list. Is this a good way to handle the effects? Are there better ones?
3. Structures. I know that going so much into the details could look like I'm asking you to write code, but I'm not asking that: it's something related to the previous question.
   This game will need to keep a lot of information about anything happening on the board: there are effects like "gain life equal to half the damage you sustained since the start of the game", but also "gain life equal to half the damage you sustained this turn"; there are damage reductions, damage increases, multiple "schools" of damage each needing their own counting; there are even effects like "double the attack bonuses you have", meaning I have to keep track of increases and decreases separately. Given that I'll have to revert a lot of times to the original state if I follow the idea explained in the previous question (or a similar idea), are there any advices about organizing all that data?
4. Separation between interface and engine. This is something I'm not too familiar about. I can keep the interface separated from the engine, until I have to ask a player to choose something. I guess that the engine should wait for the player to click on a card on the interface, then get the choice result from the interface and process it. How would you do that? A client/server architecture even if the game will be 100% offline? Multiple threads (concurrency scares me)?
5. AI. I'm not really too focused on the AI, at least until I have something working and playable. Especially in this CCG, an AI that plays cards at random can still give a decent fun to the player. Anyway, I'm sure that I'll want some more from the AI when the time will come, so I'm writing this question now, hoping to get the benefits later. I have read other topics in this section and I saw a lot of people talking about "min-max". I don't know the details about it, but I read an article about the strategy used for the DotP AI. It basically builds lots of possible "futures", each one given by a different choice, and it computes a score of each possible income. While it seems really appealing, I think it's also really challenging to make: each of those "futures" is like a separate match, with the difference that the player won't take decisions in it. Do I really need to implement the match so that it can be copied and played "virtually" by the AI alone? This strategy would also need to save the decisions so that the AI knows what to do in order to replicate the best income, and this is another thing that puzzles me: what's a good way to represent a list of "decisions"? Decisions are heterogeneous: "play card #2 from your hand" and "choose card #10 on the table when you are asked to" can't be represented by just an array that contains [2 10], if you understand what I mean.
   Luckily this game doesn't have "activated abilities", so there will be nothing like "now I choose to activate this card that's already on the table". The only things a player decides are: which characters will battle, which cards to play, eventual choices given by the played cards, and which cards to discard at end of turn.

Any comment/advice is welcome, as well as collaborations, in the remote case that someone finds this idea so interesting to become willing to waste some time on it.

Thanks for the attention, and sorry if the topic became so long: I'm always like this when writing.

[melvin]

I really hope this section is still alive, because I have an idea in mind, but before starting to develop it (or at least try) I'd like to hear some advices from the programmers out there.

I highly recommend basing your game on an existing engine, that would be easiest way to get started.

Separation between cards and engine.

I had an idea when I discovered that there are Java functions to compile other Java classes on runtime: why not making each card definition as a Java class that will be compiled and loaded at the start of the game?

We use this in Magarena. One difference is that instead of compiling Java, which can be hard for beginners, we compile Groovy, which is similar to Java but more suited to card scripting. While this opens up more possibilities for card scripters, there will always be some engine limtiations. For example, Magarena is designed to support only one target per card, this cannot be overcome by card scripts.

Processing of card effects.

My idea consists in implementing a list of active effects, and each time I need to update them, I revert the game to its original state and then reprocess the entire list from the start, in chronological order. When an effect ends I can just remove it from the list.

Magarena's continuous effect system is implemented in this manner. This can be done efficiently if the properties are only updated when necessary.

Structures.

This game will need to keep a lot of information about anything happening on the board

This issue has been on my mind as well, currently in Magarena we just track an additional variable in the Game object for each item we want to track. This creates burden on the engine to update all these variables correctly.

A nice aspect of Magarena is that we use an action driven system. Each modification to the game is an action, action can be playing a card, losing life etc. Each action also has an undo, this is very useful for the AI as it searches the tree of possible moves. I've been thinking that since the history of a game is traceable through these actions, information such as amount of damage a player got this turn can be inferred from the actions.

Separation between interface and engine.

I guess that the engine should wait for the player to click on a card on the interface, then get the choice result from the interface and process it. How would you do that?

Typically the UI will be running on one thread and the game logic will be on a different thread. You can pass messages between threads with queues. The logic wil trigger the UI to setup the interface and then read from the queue. The UI will react to the click and put the selected object into the queue to be picked up by the logic.

AI.

Do I really need to implement the match so that it can be copied and played "virtually" by the AI alone?

We create a separate game for the AI in Magarena. Another method may be use the same game but have a way to undo all the AI actions, this is harder as it may be difficult to return to exactly the same state. A benefit of separate games is that you can create one game per thread to have the AI benefit from multithreading.

Decisions are heterogeneous.. can't be represented by just an array that contains [2 10]

Decisions are like messages, they might have methods like getTarget, getX (for choose X), etc. A list of decisions would be a list of decision objects.

[thefiremind]

Thanks for the advices, they opened my mind a little bit more which is always useful.

[silly freak]

On the Java-Compilation at runtime part: Compiling proper java might prove not to be what you want.
You need to give complete, correct Java classes for this, meaning the code is 1) long and verbose for a card script and 2) not appealing for non-programmers who want to add cards.
If you choose that only some part of the class (e.g. a method body) should be scripted, and the rest is simply added to the source code before compiling, you take a lot of flexibility from your "scripting language".
In either case, you will run into the problem that the compilation itself might be platform dependent. If you use the Java 6 compiler API, availability depends on whether your user has a JDK or JRE installed; so the safe bet is to add a compiler to your distribution - in that case, why not add a scripting engine in the first place?

If you really see it necessary (and there likely is reason for this), you can also create your own dedicated scripting language using a lexer and parser like ANTLR (if you stay with Java). You can then use ASM or similar to create the bytecode for you card script directly, or just create an object that is a representation of that command - possibly directly an action that can be executed by the game. Of course, that comes with more work for you, esp if you want to generate bytecode