(Assembly?) language for programming cards

[mbg]

We decided that the cards would be programmable, so we need some language/mechanism for that. One option would be a simple assembly language along the lines of:

DAMAGE $target 10  
APPLY $target frozen 
APPLY $self asleep

For balance, we might give each instruction some cost (with some instructions possibly having negative costs such as applying negative status effects to the player's own cards) or reducing the accuracy of a card the more instructions it has.

The implementation would consist of:

• A data type to represent instructions
• Some way of calculating the cost of a program
• Some kind of interpreter, coordinating with #4
• Maybe a parser for the language using a library such as megaparsec

@ThomasRules2000 suggested maybe having a visual editor for the language similar to the Psi mod's for Minecraft.

[ghost]

With the cost of the program, the different kinds of attributes could have different base costs and the cost of the attribute increases with more of the same kind of attribute?

[mbg]

Potentially. Is there a balancing motivation you see for this?

[ghost]

From what I remember with games like hearthstone, if a card effectively combines the effects of multiple other cards together it is worth more than the parts separated as you save on a limited deck space for other cards and it is more consistent as you only need to draw one card rather than two. The one example I can think of from hearthstone is drawing one card is one about one mana but every additional card drawn on top of it ups the cost by two extra mana each.

[mbg]

Makes sense!

[dixonary]

It might be preferable, instead of having an embedded language, to encode effects as an ADT (with toJSON/fromJSON instances). This would save us writing a parser.

Eg. cards would have a field effects :: [Effect], where data Effect = Destroy Target | ...

[mbg]

That would defeat the main point of the project though.

[dixonary]

Ah OK, I didn't realise that the parser was the core piece of the puzzle :)

[mbg]

Not necessarily the parser as such, but the idea was to have a card game where the cards are programmable. I think simply specifying their effects as some JSON would be rather boring though. @ThomasRules2000 's visual language proposal is nice, but a simple assembly language would be easier to implement at first (not that parsing that would be particularly tricky in any case).

[dixonary]

In that case a parser will need to return the following information:

• Total cost of running the script
• The list of instructions, which can then be interpreted elsewhere
• The number of targets required (for simplicity of UI it might be best to keep this as 0 or 1 ? Hearthstone does this)

[dixonary]

So the type of such a parser should be (roughly):

data ScriptResults
  = Error String
  | Result {
    cost         :: Integer,
    instructions :: [Instruction],
    numTargets   :: Integer
  }

parseText :: String -> ScriptResults

[mbg]

I don't think that's all information the parser needs to return. The parser just needs to return the list of instructions. The remaining information should then be inferable from that.

[ghost]

Another thing for balance, we might need some sort of cap on how much someone can add to their program, especially with the negative effects. Some are more obvious, like only having the 'freeze self' be max of one but with others like 'heal enemy', someone could have add a bunch of those to bring the cost down enough to then add enough 'damage enemy' effects to be able to kill the enemy instantly.

[oscar-h64]

megaparsec looks like a good library to write the interpreter. There's a nice tutorial here. Does anyone else want this one, if not I'll have a start?

I would say its probably best to only allow 1 of each type of instruction, eg. there's no point having multiple HEAL actions for the same card when you can just combine them

[ZiadAmr]

I'd be willing to write it. I'll start today if no one else has already started

[ZiadAmr]

Quick question, have we already decided how the cards will be programmed?

[oscar-h64]

I was just about to start, you got there just in time. It's going to be a simple language like in the original message, with commands in all caps then the arguments, but I don't think we have any specific commands planned other than HEAL and ATTACK so far.

The way the Main module is coded the interpreter should take a [String] where each element is a line and it'll return a Maybe Program, however we can change that if its not convenient

[ZiadAmr]

So I'm working on the interpreter but I cannot get any further without deciding what instructions we use to program the cards. Currently I have ATTACK n HEAL n does anyone have any suggestion for other instructions?

[dixonary]

DRAW n - player draws cards DESTROY - removes a target program from play

[dixonary]

SILENCE - remove all text from a target program

[dixonary]

RESET - return a program to its owners hand. CHOWN - gain control of a target program.

It might be an idea to come up with flavourful names for all the card effects?

[oscar-h64]

Those instructions look good. It might be worth opening a draft pull request for this so everyone can keep track and see changes, especially because things like the constructors in Instr will affect some of the library functions