Why can I not draw card(s) first?

[xspuipuke]

I was just playing devil's advocate here. I've spoken to VictoriaLa, one of the devs, about this very issue many times. She was the one to mention Boolean Satisfiability, which I have never heard of before. I now get where she is coming from.

I've said the same thing you just did and like FrankJones I was advocating for hacking stuff in. After some talking I now better understand her position and while such high standards might not be appropriate for BGA, as you say, I can certainly relate to wanting to honor them nevertheless.

Yes, Agricola has many weird interactions and it's great you guys are willing to hack in the necessary code to make stuff work. But, in Agricola, you cannot run into the same problems as in Terraforming Mars, as there are almost no effects that must be carried out: if one fails, you simply ignore it. There's only the restriction that you can't just block a space without carrying out any of its actions—not sure if that may cause problems like the one we're talking about here (you probably know way better than me).

I too wish I could sometimes draw cards before I make another decision but I've come to live with it. A digital implementation can never be an exact representation of the real thing and so I've come to accept the limitations. I was just trying to shed some light on the reasoning behind those decisions as I understand them from talking to one of the devs.

[Acerbic]

Thanks for clarifying, I will of course defer to the TM developers as I have no insight into their framework and they are best qualified to make the call.

Yes, Agricola has many weird interactions and it's great you guys are willing to hack in the necessary code to make stuff work. But, in Agricola, you cannot run into the same problems as in Terraforming Mars, as there are almost no effects that must be carried out: if one fails, you simply ignore it. There's only the restriction that you can't just block a space without carrying out any of its actions—not sure if that may cause problems like the one we're talking about here (you probably know way better than me).

Not to drag this too off-topic, but this isn't entirely accurate. There are a number of cards that force sequences that could fail and the real difficulty is that other people's triggered card effects can intervene, switch the active player and completely ruin the reversibility of the initial action. Based on the testimonials regarding the Steam implementation and the fact that this discussion only brought up one example of a sequence that fails, I actually think this is a significantly bigger problem in Agricola and it's not solvable by setting the kind of restrictions that have been put into place here.

[xspuipuke]

OK, good to know. For sure, Agricola is way more complex, if only judging by the amount of rules questions we get with the weirdest of interactions that we just haven't thought about.

[FrankJones]

We seem to be talking past each other.

So one final attempt at explaining this: Even if there is just a single exception NOW, it is a bad design choice to hack it into the code. Why?

a) You might be missing other interactions not yet encountered or thought of.
b) Future cards may add exceptions that you then need to hack in too, potentially missing other interactions, thus creating a huge mess that no one will ever be able to see through.
c) Your code becomes hard to maintain, e.g., if another dev takes over for some reason etc.

Especially a: You claimed there is no interaction that could cause a problem and yet I've shown you one. And who knows how many more there are that nobody thinks of right now?

We are talking past each other because in two different but related topics, people are
1) taking a very bizarre interpretation of the rules that allows for effect B to be done before effect A even when effect A is literally the only thing that is CAUSING effect B, thus making it impossible to actually do effect B first;
2) Saying that it's okay to break the rules in numerous situations that occur one or more times per game because of a single rare and not-yet-possible situation (because the card is no included yet in the game), even though I have pointed out multiple solutions to this problem, none of which are difficult, other than the fact that one or two people personally believe the solutions to be difficult or unwise.

The example you gave only causes a problem if we allow someone to place an ocean and pay the 6 MC afterward. (I still do not agree that this is a problem, but even if it were, the solution is, require people pay the 6 MC as a cost of placing the oceans. Oceans in TFM cost money. The rulebook for Hellas says "this map includes a special hex where placing you a tile allows you to pay 6 MC and place an ocean." That could easily be interpreted as, "Pay 6 MC and place an ocean, in that order", which would certainly be consistent with the general theme of the game, which is that doing things that get you points and TR increases costs money. And even if it were the designer's intent to allow tiles to be paid for retroactively after placing them and after getting the placement bonus - in the case of the ocean on the south pole - oh well. We would be breaking a rule that happens once in a blue moon to ensure that the rule doesn't get broken once per game.

You keep harping on the example you have given as though it is some sort of "checkmate". We can look at the case card by card and unequivocally illustrate that "Large Convoy" and "Convoy From Europa" cannot possibly ever run into this problem, but you are unwilling to acknowledge the logic in inserting a line or two of code instructing the game to allow the card draw as the first effect of those cards.

That is why we are talking past each other. You are ignoring what I am saying, dismissively insisting you are right and I am wrong, and not attempting to see the merit in what I am saying. The fact that you need such a rare and convoluted and not-yet-possible example to make your point actually makes my point.

(Which, in the case of something like Nuclear zone or Lava Flows, I very much doubt)

[FrankJones]

2) Do not allow the tile to be placed if the player cannot pay 6 MC to place an ocean. Am I to understand that a player can pay to place an ocean by using the money gained from ocean adjacency bonus AFTER placing the ocean? That is preposterous.

Regardless of how you feel about this, it's in accordance with the rules. The Hellas Southpole adds two effects to your queue:
a) Place an Ocean tile.
b) Lose 6 MC.

As per the standard rule, you—the active player—decide the order of effects. So, of course, you may place the ocean first and then pay 6 MC after collecting enough cash. Those are two independent effects.

Whether they are independent is debatable. I would think the logical interpretation is that placing the ocean is the result of paying 6 MC.
Just as causing a volcanic eruption is what causes the temperature to rise, and detonating a nuclear explosion on Mars is what causes the temperature to rise, and placing a greenery is what causes oxygen to increase.

Regardless, as I write in my other post, we can apply the concept of "least harm". What does the least harm to the rules? Requiring someone to pay the 6 MC first and then place the ocean, or, disallowing a player to choose the order of effects in situations that occur 1000 times more frequently?

[FrankJones]

By comparison, what's being asked here is very mild and certainly doable, both theoretically and pragmatically.

To be clear, this is not a slight on the developers of TM in any way - I enjoy the implementation greatly and that's unaffected by whether or not they choose to lift this restriction or the timeline in which they make that decision. I only want to say that I think you've taken your argument too far.

Exactly. What I have been requesting is, as noted above, certainly doable. I am not sure which programming language TFM is written in here on BGA, but I could write out plain language code for these situations that would function without issue and be more (or fully) in accordance with the rules.

For most situations, the solution would be a single line of code at the beginning of the code block for resolving the card, a line of code that translates to, "for this card, always allow card draw as the first effect if desired by the active player".

If and when a situation is discovered that causes a problem, THEN apply whichever currently existing (and rule-breaking) line of code translates to, "do not allow the card draw effect until other effects have been resolved."

In the grand scheme of the thousands of instructions and lines of code required for a game such as TFM, I am baffled as to how you think my solution is so implausible or infeasible or burdensome. I had to handle more difficult programming tasks in my first few weeks learning code.

And since Ocean placement and adjacency bonus seems to be the main issue with the South Pole on Hellas issue, again, a few simple lines of code would deal with that. The player picks an ocean spot with a card draw, and the game evaluates whether that placement would generate enough adjacency bonuses to enable the player to pay 6 MC as required. If "no", then "placement spot is invalid".

This really is not difficult to program. Not in the least.

[xspuipuke]

It's really not that easy as you make it sound. This can become a pit without end pretty quickly.

a) We still don't know if the example I've given is the only one. In a sense, it isn't, as you have this problem with any city-placing card on the planet where an energy decrease is involved. I used Lava Tube Settlement as that's, for some reason, the one card the devs cannot program correctly.
(it let's you play the card even now when you don't have energy, but all other cities not—why?!).

b) When you start hacking stuff in and new problematic effects are discovered, you must hack onto the previous hack, quickly becoming a mess. There are obviously developers like Acerbic who are willing to do that, but you cannot fault someone for sticking to generality. Not unless you want to step in and do the work (if that is even possible—I suppose not). Plus, new effects may mess up stuff pretty quicky.

It's easy for an outstander to claim stuff were easy. You don't know that, I don't know that—only the devs know. And, for some reason (I tried to illustrate those reasons as I understand them), the devs don't think it's easy. This does not invalidate your points and it's certainly good to be vocal about it—I just don't think anything will come from it.

[FrankJones]

It's really not that easy as you make it sound. This can become a pit without end pretty quickly.

a) We still don't know if the example I've given is the only one. In a sense, it isn't, as you have this problem with any city-placing card on the planet where an energy decrease is involved. I used Lava Tube Settlement as that's, for some reason, the one card the devs cannot program correctly.
(it let's you play the card even now when you don't have energy, but all other cities not—why?!).

b) When you start hacking stuff in and new problematic effects are discovered, you must hack onto the previous hack, quickly becoming a mess. There are obviously developers like Acerbic who are willing to do that, but you cannot fault someone for sticking to generality. Not unless you want to step in and do the work (if that is even possible—I suppose not). Plus, new effects may mess up stuff pretty quicky.

It's easy for an outstander to claim stuff were easy. You don't know that, I don't know that—only the devs know. And, for some reason (I tried to illustrate those reasons as I understand them), the devs don't think it's easy. This does not invalidate your points and it's certainly good to be vocal about it—I just don't think anything will come from it.

I hear you. I do.

But most of the time, when developers say they "can't" do something, I suspect it really means, "Time is better spent elsewhere".

I remain very confident that I could write the necessary lines of code to fix this situation, and that the moment a card or combo caused a problem, I could simply add a line of code to fix that. Isn't that how these games are coded in the first place? A beta is released; people play, they find bugs. They report them. The developers fix them.

I strongly believe that we could very easily allow card draw first, and then the moment a problem arose, we could immediately fix it. Would that really be so bad? If one very rare problem occurred in exchange for allowing the rules to be followed as written hundreds or thousands of other times? And then we fix that one very rare problem?

I think it's very feasible. Again, I am speaking as someone who can write (and has written) programs far more complex and difficult than what I am suggesting here. I'm not just hypothesizing out of thin air.

I can accept "We do not think it's worth the time and effort" (Though I would disagree), but I cannot accept "It's too difficult to program the code." Because, that's just not true.

[xspuipuke]

I too think it‘s feasible. How many times I thought exactly that and “why not try write an engine myself“ I cannot count

[dialectic42]

If I understand correctly, most devs here are freelancers. I've seen the devs answer stuff on these forums so you might be lucky enough for them to elaborate. My example above, however, illustrates how it is NOT feasible, in general, to decide whether a chain of events will succeed or not and that's why undoable stuff like card draw can only happen once it is 100% clear that it can't fail, i.e., if it is the last or second-to-last thing happening.

Fantastic points made here.

I wonder if the implementation could do a better job at determining which types of effects could cause a chain to fail and which cannot.

For example, the Olympus Conference and Mars University effects cannot cause an effect chain to fail. These effects could be commonly stacked along with a science card that draws cards.

On the other hand, effects that require the player to pay resources or decrease production could cause a chain to fail.

If we can sort the effects into "failable" and "non-failable" buckets, then the game can allow the player to draw cards when there is only one "failable" condition remaining, and that condition is satisfied.