Convoy From Europa

[xspuipuke]

Yes I understand that; if not the if statement, adding confirmation for Point Luna would do the trick 2. B/c the card draw confirmation would allow a check before soft lock. You won't able to draw if Nuke won't be able to be played. And if you draw before, then you won't able to play the nuke anyway b/c of the MC requirement.

It is mathematically impossible to compute whether or not an arbitrary chain of events will fail. Unless you code every single card combo separately (which is also impossible due to the number of possible effects in the game), you won‘t be able to reliably predict the outcome.

When you add in Point Luna card draw confirmation, does it fail? Can you try it? Make it a hard confirmation.

Point Luna already has a confirmation button for their card draw. Whether or not there is a button for the card draw does nothing towards solving the basic issue.

[FrankJones]

Fun fact: Coding experience is not necessary to write a block of code. All one needs is the ability to follow the logical structure of a set of written instructions (and then a programmer to convert these instructions into a programming language. When I was applying to boot camp, the admission test essentially consisted of similar exercises.

In other words: Anyone in this thread who wants to attempt this task can write a set of instructions (mostly if/then statements; often phrased as "if/else") in plain English. If this set of written instructions functions properly, it would be a relatively trivial matter to convert it into actual code.

That being said, xspuipuke and I, as well as Victoria_La, the lead programmer for TFM here at BGA, do not believe any one set of instructions can cover all cases in a way that would ensure the active player can always choose the order of effects while also ensuring a game never gets deadlocked.

If anyone wants to try, go for it. Keep in mind, once any new information is revealed (such as a dice roll (not applicable to TFM), or a face-down card revealed, undo is no longer possible.

Similar - if anyone wants to try to write a program for a computer-controlled opponent in TFM, no programming knowledge or experience is necessary. The only requirement is being very good at TFM. A written set of instructions in plain English could be translated into computer code. That code will play TFM as well as the player who writes the instructions. The difficulty is: Consider how many different factors we process almost instantaneously when deciding which cards to keep in the opening hand or which actin to take in any given moment.

[RicardoRix]

In other words: Anyone in this thread who wants to attempt this task can write a set of instructions (mostly if/then statements; often phrased as "if/else") in plain English. If this set of written instructions functions properly, it would be a relatively trivial matter to convert it into actual code.

Yabbadabbadoo. No it's not. Massive over simplification.
If that's true, then why aren't you a coder then?

Jump on in - fix it yourself.

[xspuipuke]

I would strongly advise against what Frank suggests. Don't waste your time on writing any if-else statements. They would not be easily implemented into the current code base. This would require a major refactoring of the code and then there's the mathematical impossibility of solving this issue in general so don't waste your time.

[FrankJones]

I would strongly advise against what Frank suggests. Don't waste your time on writing any if-else statements. They would not be easily implemented into the current code base. This would require a major refactoring of the code and then there's the mathematical impossibility of solving this issue in general so don't waste your time.

That was sort of indirectly my point. It wouldn't work, because eventually the instructions would fail.

[FrankJones]

In other words: Anyone in this thread who wants to attempt this task can write a set of instructions (mostly if/then statements; often phrased as "if/else") in plain English. If this set of written instructions functions properly, it would be a relatively trivial matter to convert it into actual code.

Yabbadabbadoo. No it's not. Massive over simplification.
If that's true, then why aren't you a coder then?

Jump on in - fix it yourself.

To answer your questions:
1) My reasons for not becoming a professional coder are personal and have nothing to do with my ability to write and read code. I have written programs far more complex than the code needed to resolve the effects of a card in a board game. If anyone is considering become a professional coder with the intent of programming digital board games (which was my original intent) and would like more details on why I chose not to pursue this path, send me a friend invite and we can chat privately.

2) As to why I haven't fixed it myself- this has been explained already. It is not possible to fix. Any "fix" would result in either 1) a rule of the game not being followed, or 2) the possibility of a deadlocked game, or 3) a necessity and means of dealing with an exposed card in a situation in which the action needs to be cancelled because the effects cannot be fully resolved. If there were a fix that would not result in one of those issues, I would have in fact already written it and submitted it to VIctoria_La for implementation.

[RicardoRix]

Didn't like being backed in to your own corner I see.

The bottom line with this particular issue here is, while strictly speaking it doesn't follow the exact rules of the game, it doesn't really need to either. If you imagine that the rules did say always draw last then it would make extremely little difference to the game. So just accept it as a minor deviation and move on. And from the devs point-of-view the juice really isn't worth the squeeze. Likely as a unwanted side effect, the UI user experience might also be even worse, possibly causing more complaints than just leaving it alone.

Ark Nova has a similar, but worse thing where the game can actually get into a real-life locked position. The game designer can't really help either, the rules don't cover the situation. I think the games then on BGA just have to be abandoned, while in real-life you're going to have to come to some sort of agreement then and there.

So the consideration here is that the dev would need to consider situations outside of the rules set.

[FrankJones]

I wasn't backed into any corner. Why so aggressive? I stand by everything I said. I am not sure what corner you feel I have backed myself into.

I will repeat my last statement since you seem to have missed it:

"My reasons for not becoming a professional coder are personal and have nothing to do with my ability to write and read code. I have written programs far more complex than the code needed to resolve the effects of a card in a board game."

This issue is not a difficulty issue, it's an issue of "is it possible?" And the answer is no. Regardless of what we do, there will be a minor deviation from the rules of the game. So, we choose the "least bad" option, one that attempts to ensure no games will be deadlocked.

As for your second paragraph, yes, I have already made it clear I am in agreement with you on this. My suggestion was for the players who continue to insist we do something and who continue to insist a perfect solution is possible.

[RicardoRix]

I wasn't backed into any corner. Why so aggressive? I stand by everything I said. I am not sure what corner you feel I have backed myself into.

I don't think I was being aggressive, just curt.
xspuipuke reply is more susinctly put.
The coding is simple statements, but when you have to do it yourself a whole load of reasons suddenly pop into view. If you dig into technical rather than personal reasons I'm sure it gets even more distant why just parsing english statements into code is not as simple as it sounds. Just because I can put a plaster on doesn't make me a doctor.

As for your second paragraph, yes, I have already made it clear I am in agreement with you on this. My suggestion was for the players who continue to insist we do something and who continue to insist a perfect solution is possible.

Yes, I wasn't disagreeing with you, just trying to paint the real-life picture for all the folks.

[StrandedKnight]

I still don't see why you can't allow the player to choose the sequence of moves even if card draw is involved.

In the example of Nuclear Zone on the South Pole on Hellas, you would first need to determine whether playing Nuclear Zone is a legal move or not. That is already correctly implemented.

Once you choose to play it, you would get the choice of either drawing the card first or placing the tile first.

If you choose the tile placement first, the game engine then determines all legal locations, which may or may not include the South Pole. The move is still undo-able at this point since you haven't drawn any cards yet.

If you choose to draw a card before placing the tile, the move is no longer undo-able. But you can still use the information from the card you drew to determine where to place the tile. The list of legal locations would still be the same.

This would open up for players to make irreversible mistakes, as is the case with all card-drawing moves. But there is no reason it should result in a deadlock.