Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[silby]

I have some questions about the implementation of the Dominion game engine that might be unanswerable or boring and maybe Stef/SCSN are unlikely to respond to this far in advance, but I'm extremely curious, so here goes:

I would imagine that any reasonable implementation of a game like Dominion would be based around an "event loop" that handles the phases of the turn (start, action, buy, cleanup, interturn) and cards that are scripted to trigger various side-effects when they're eligible to be played. All well and good. Many Dominion cards are built out of primitive effects that are not very complicated to script, and interact in predictable ways. (+1 Card/action/buy/coin, look at a card, reveal a card, etc.) Other cards have (seemingly?) unique effects, most notably Possession, which in the rules for humans is heavily annotated and some cards have FAQs that clarify precisely how they interact with Possession.

So my initial questions about this for the developers are these, if they care to reveal their approach at all:

- Am I even imagining a design similar to what you're building for the game engine?
- How many "primitive" game-state operations are there? What about higher-order operations like predicates or alternates?
- How many cards have an operation only used for that card?
- Are there any card interactions that have a true corner-case implementation, where the engine produces the wrong effect when A and B interact, but there's no feasible way to correct the individual components to get the right effect?
- I sure would be delighted for card-creation tools to be made available to players with the full power of the engine. I know there's lots of reasons to not ever do this, which I accept. This isn't a question.

[-Stef-]

I am going to answer you a little bit. One of the cool things about two forum members making the new implementation should be a closer distance between the fans and the development. So far I've been very silent, but that is mostly due to time constraints. Also I don't really know where answering you leads to. One of the bad things that might happen is that it leads to a lot of other questions that people also want answered, and at that point I'm just going to say no, not now, now I'm actually going to continue making the game.

People often assume the difficult part about Dominion is in the cards, but so far it hasn't been. By far the most time consuming was setting up the Context. It isn't a lot of code, but I sort of had to figure out how Dominion actually works. The rules aren't always clear about this, and where they are they usually describe what should happen, not the things causing these consequences.

Anyway, as it turns out the Dominion Context has a Stack. Each element of the stack has a Map that assigns each Player a list of Abilities, and could have a cause (also an Ability). An Ability is basically just 'a piece of code' and apart from being executed it can also be cancelled, when one of its tracked cards get moved, covered up or shuffled due to something else.

The Stack is because if something is happening and it triggers something else, we first resolve something else before returning to the first thing.
The elements in the stack don't have just one list but a list for every player because of the turn-order resolution rule.
The cause is there because if something happens (say when-trash-a-card | when-your-turn-starts) and further down its stack some new trigger is set up (you draw a market square | your summoned hireling hits play) it has to still respond to the trigger-being-resolved.

- Are there any card interactions that have a true corner-case implementation, where the engine produces the wrong effect when A and B interact, but there's no feasible way to correct the individual components to get the right effect?

No. If this is the case, that simply means the engine is wrong. It has been, and maybe it still is, but if I find that out I will try to correct the engine (again), never start coding specific interactions.


I'll just give you the current implementation of two cards. One very simple, one a bit more complicated.

Code: [Select]

public class Margrave extends Card {

    public Margrave(int index, CardZone cardZone) {
        super(index, CardObjectName.MARGRAVE, cardZone);
    }

    public void onPlay(Context context, Player player, PlayCardAbility playCardAbility) throws SuspendExecution {
        player.drawCards(context, getCardObjectAssociation(), 3);
        player.addBuys(1);
        for (Player victim : playCardAbility.getVictims()) {
            victim.drawCards(context, getCardObjectAssociation(), 1);
            victim.discardDownTo(context, getCardObjectAssociation(), 3);
        }
    }

}


Code: [Select]

public class Beggar extends ReactionCard {

    private final List<CardMode> CARD_MODES = Arrays.asList (CardMode.BEGGAR_TOPDECK_FIRST, CardMode.BEGGAR_DISCARD_PILE_FIRST);


    public Beggar(int index, CardZone cardZone) {
        super(index, CardObjectName.BEGGAR, cardZone);
    }

    @Override
    public void onPlay(Context context, Player player, PlayCardAbility playCardAbility) throws SuspendExecution {
        for (int i = 0; i < 3; i++) {
            player.gain(context, getMe(), CardObjectName.COPPER, player.getHand());
        }
    }


    @Override
    protected boolean reactsTo(Event event, Context context) {
        boolean inHand = getZone().getZoneName() == ZoneName.HAND;
        boolean isWhen = event.getEventType() == EventType.WHEN;
        boolean isAttack = event.getAbility() instanceof PlayAttackAbility;
        if (!inHand || !isWhen || !isAttack) return false;
        PlayAttackAbility playAttackAbility = (PlayAttackAbility) event.getAbility();
        return playAttackAbility.getPlayer() != getPlayer();
    }

    @Override
    protected void createReaction(Event event, Context context, AbilityCollector abilityCollector) {
        abilityCollector.add(new BeggarAbility(getPlayer()));
    }


    private class BeggarAbility extends ReactionAbility {

        public BeggarAbility(Player player) {
            super(getMe(), player);
        }

        @Override
        public void resolve(Context context) throws SuspendExecution {
            player.discard(context, getCardObjectAssociation(), player.getHand(), getMe());
            NamedPile silverPile = context.getCommonPiles().getActualPile(CardObjectName.SILVER);
            CardMode cardMode = CardMode.BEGGAR_TOPDECK_FIRST;
            if (silverPile.size() == 1) {
                cardMode = context.ask(new WhatCardMode(CARD_MODES));
            }
            if (cardMode == CardMode.BEGGAR_TOPDECK_FIRST) {
                player.gain(context, getMe(), CardObjectName.SILVER, player.getDrawPile());
                player.gain(context, getMe(), CardObjectName.SILVER);
            } else {
                player.gain(context, getMe(), CardObjectName.SILVER);
                player.gain(context, getMe(), CardObjectName.SILVER, player.getDrawPile());
            }
        }
    }

}


[werothegreat]

I notice Margrave does not have an "Attack" tag anywhere (in contrast to Beggar, which extends ReactionCard) - I'm assuming the fact that it has a "victim" means you resolve Attack triggers when victims are involved?  Are Masquerade and Possession dealt with differently, then?

EDIT: Also, any particular reason why Beggar's onPlay method has an @Override tag, while Margrave's does not?

[-Stef-]

I notice Margrave does not have an "Attack" tag anywhere (in contrast to Beggar, which extends ReactionCard) - I'm assuming the fact that it has a "victim" means you resolve Attack triggers when victims are involved?  Are Masquerade and Possession dealt with differently, then?

We have the card types assigned to the card names. Margrave knows it's called CardObjectName.MARGRAVE, and it can deduce it's an attack that way.
If I would replace the name with CardObjectName.SMITHY, it would still function as a Margrave, except that nobody could defend against it (and the client would show you an image of smithy)

By the time we get to the 'victim' part it would be too late. You decide whether to reveal moat before the attacking player draws cards.
The whole possibly-removing-victims has already happened by the time Margraves onPlay is executed.

[Witherweaver]

I notice Margrave does not have an "Attack" tag anywhere (in contrast to Beggar, which extends ReactionCard) - I'm assuming the fact that it has a "victim" means you resolve Attack triggers when victims are involved?  Are Masquerade and Possession dealt with differently, then?

We have the card types assigned to the card names. Margrave knows it's called CardObjectName.MARGRAVE, and it can deduce it's an attack that way.
If I would replace the name with CardObjectName.SMITHY, it would still function as a Margrave, except that nobody could defend against it (and the client would show you an image of smithy)

By the time we get to the 'victim' part it would be too late. You decide whether to reveal moat before the attacking player draws cards.
The whole possibly-removing-victims has already happened by the time Margraves onPlay is executed.

Interesting; is the idea that Reaction is the only card type that really merits having its own (derived) class, since it has things like reaction trigger and reaction ability?  Or are there other derived classes for other cards; could there be a potential problem with trying to extend more than one class? (It looks like Java?  I guess you can get around it with interfaces; I don't really know Java.)

[PitzerMike]

Cool, i like it!

[silby]

Thank you for the insightful peek behind the curtain! Per your concerns, I'll avoid peppering with follow-up questions, but any other "dev log" notes you might produce in the next few months/next year would be very interesting to me. (Maybe someday you'll tell us what all the parts of the context data structure are.)

[2.71828.....]

Thank you for the insightful peek behind the curtain! Per your concerns, I'll avoid peppering with follow-up questions, but any other "dev log" notes you might produce in the next few months/next year would be very interesting to me. (Maybe someday you'll tell us what all the parts of the context data structure are.)

"The Secret History of Dominion Online"

[-Stef-]

Dear f.ds,


One of the cards I posted here is in conflict with the Dominion rules, even though it would have been fine pre Adventures.
Why o why haven't you complained about that yet?

[michaeljb]

Well, this isn't something broken by Adventures, but

Code: [Select]

if (silverPile.size() == 1) {
    cardMode = context.ask(new WhatCardMode(CARD_MODES));
}

seems to contradict this bit from Beggar's official FAQ:

"If there is only one Silver left, put it on your deck; if there are no Silvers left, you do not gain any."

The code looks to me like it only asks the user to pick an order when there is one Silver left, but the last Silver should just go on the deck.

I think you should always get to choose whether to topdeck the first or second Silver, and it looks like this code doesn't let you choose. But I'm struggling to find the case in Adventures where that matters.
You could have enough Duplicates on your Tavern mat to empty the Silver pile, and really don't want the trashing attack you're reacting to with the Beggar to kill one of your Silvers, so you gain to your discard pile first, Duplicate that Silver a bunch, and none are left to go on top?

[-Stef-]

...

Yup that would exactly be it. I would happily add you to the list of alpha-testers, except you were already on it.
We are currently aiming for a closed alpha at the start of September.
Hopefully it goes well and we can expand the list a bit halfway through September.

[gkrieg13]

...

Yup that would exactly be it. I would happily add you to the list of alpha-testers, except you were already on it.
We are currently aiming for a closed alpha at the start of September.
Hopefully it goes well and we can expand the list a bit halfway through September.

Darn I knew I should've posted the solution!

[Watno]

...

Yup that would exactly be it. I would happily add you to the list of alpha-testers, except you were already on it.
We are currently aiming for a closed alpha at the start of September.
Hopefully it goes well and we can expand the list a bit halfway through September.

so why would it have been fine before adventures?

[Chris is me]

...

Yup that would exactly be it. I would happily add you to the list of alpha-testers, except you were already on it.
We are currently aiming for a closed alpha at the start of September.
Hopefully it goes well and we can expand the list a bit halfway through September.

so why would it have been fine before adventures?

Before Adventures, there was no mechanism to interrupt Beggar's Silver gaining with additional Silver gains. You get to choose where the first Silver goes when you can gain more than one, but not when you can gain only one - but after you gain the first Silver, Duplicate can be used to empty the rest of a low Silver pile before the second one is gained.

Two Silvers in pile -> React with Beggar -> choose to gain the non top decked Silver first -> Duplicate that Silver -> no Silvers on top of deck. The code doesn't seem to allow this option.

[Watno]

The FAQ michael quoted says

If there is only one Silver left, put it on your deck.

The code

Code: [Select]

            CardMode cardMode = CardMode.BEGGAR_TOPDECK_FIRST;
            if (silverPile.size() == 1) {
                cardMode = context.ask(new WhatCardMode(CARD_MODES));
            }
            if (cardMode == CardMode.BEGGAR_TOPDECK_FIRST) {
                player.gain(context, getMe(), CardObjectName.SILVER, player.getDrawPile());
                player.gain(context, getMe(), CardObjectName.SILVER);
            } else {
                player.gain(context, getMe(), CardObjectName.SILVER);
                player.gain(context, getMe(), CardObjectName.SILVER, player.getDrawPile());
            }
asks the player wether he wants the first or the second silver on top of his deck if there is only one Silver left, while the only option should be to have the first silver (the only one gained) on top of the deck.

I think the correct code should be simply

Code: [Select]

                player.gain(context, getMe(), CardObjectName.SILVER, player.getDrawPile());
                player.gain(context, getMe(), CardObjectName.SILVER);

[Watno]

Or to be honest, I'm not sure what should be happening. I would believe that you first gain the 2 silvers, and then put one of them on top of your deck (if you gained any), but that doesn't work due to the fact that Donald stated somewhere that topdecked gains don't visit the discard pile.

I'm not sure wether the following should be allowed:

Code: [Select]

Reveal Trader
   Gain Silver
      Gain something else somehow
           Topdeck that something with Watchtower
   Gain Silver to top of deck I'd be inclined to believe it should be possible, but the code I suggested above doesn't allow it.

The problem is for the FAQ to be correct, you either decide which Silver to topdeck beforehand, but only if you will gain 2 (which isn't possible since you only know if you gain 2 after you have fully resolved all triggers for the first gain), or you always topdeck the first, which leads to the above not being possible, which doesn't feel right to me.

I think we need Donald to clarify.

EDIT: Actually, I noticed Charm (which was the "somehow" above) is on buy, so I don't think there is a way to gain something else in response to the Silver gain, but I guess we still need clarification to be forward-compatible.

[Donald X.]

I think we need Donald to clarify.

You gain a Silver directly to the top of your deck, then you gain a Silver that has no special destination.

[Seprix]

Wow, all of this code. I can kind of sort of understand it a little bit.

[drsteelhammer]

anyone taking bets whether that is implemented correctly on the MF client? odds are 25 to 1

[Davio]

I notice Margrave does not have an "Attack" tag anywhere (in contrast to Beggar, which extends ReactionCard) - I'm assuming the fact that it has a "victim" means you resolve Attack triggers when victims are involved?  Are Masquerade and Possession dealt with differently, then?

We have the card types assigned to the card names. Margrave knows it's called CardObjectName.MARGRAVE, and it can deduce it's an attack that way.
If I would replace the name with CardObjectName.SMITHY, it would still function as a Margrave, except that nobody could defend against it (and the client would show you an image of smithy)

By the time we get to the 'victim' part it would be too late. You decide whether to reveal moat before the attacking player draws cards.
The whole possibly-removing-victims has already happened by the time Margraves onPlay is executed.

I would have gone with something like interfaces to specify card types, but then you get things like Band of Misfits and Inheritance and adding interfaces during runtime isn't going to work.

So a runtime lookup of the actual types (through card name, which might change for BoM?) is probably the more flexible option.

[michaeljb]

Yup that would exactly be it. I would happily add you to the list of alpha-testers, except you were already on it.

I think the correct code should be simply

Code: [Select]

player.gain(context, getMe(), CardObjectName.SILVER, player.getDrawPile());
player.gain(context, getMe(), CardObjectName.SILVER);

I think we need Donald to clarify.

You gain a Silver directly to the top of your deck, then you gain a Silver that has no special destination.

Sounds like my and Stef's interpretation of Beggar's text was a little off then.

Soooo....Watno for alpha testing?

[Watno]

anyone taking bets whether that is implemented correctly on the MF client? odds are 25 to 1

I guess the chances it's correctly implemented is pretty high, since the correct implementation is a lot simpler than the incorrect one.

The checking name to determine type thing is problematic I think, since it is possible that there are multiple cards that have the same name, but different types: in particular, some, but not all estates might be attacks (if someone inherited an attack)

[Watno]

...

Yup that would exactly be it. I would happily add you to the list of alpha-testers, except you were already on it.
We are currently aiming for a closed alpha at the start of September.
Hopefully it goes well and we can expand the list a bit halfway through September.

Any news about this?

[Chris is me]

...

Yup that would exactly be it. I would happily add you to the list of alpha-testers, except you were already on it.
We are currently aiming for a closed alpha at the start of September.
Hopefully it goes well and we can expand the list a bit halfway through September.

Any news about this?

Ha! Joke's on you! They never said which September they were opening up Alpha testing.

[Accatitippi]

...

Yup that would exactly be it. I would happily add you to the list of alpha-testers, except you were already on it.
We are currently aiming for a closed alpha at the start of September.
Hopefully it goes well and we can expand the list a bit halfway through September.

Any news about this?

Ha! Joke's on you! They never said which September they were opening up Alpha testing.

...and in an unexpected twist of events, they found out that SCSN had been Goko all along.