Beta graph for sponno moves

[landmeister]

Following my last thread dedicated to sponno directions, I've created a graph including all possible options. I'm not a programmer, so please don't be too harsh with it  .

http://www.megaupload.com/?d=4MPL75SU

All opinions are welcome.

Thank you in advance

[LawrenceG]

Box

?will it end closer to the previously closest visible enemy?

has two "yes" coming out of it. The bottom one should be "no".

[vexillia]

All opinions are welcome.

I suggest you reverse this question "...will it end closer to its side?s rear battlefield edge?" to say "...will it end further from its side?s rear battlefield edge?" as this is more in tune with the spirit of the rules in which the move straight ahead is the default option.

You could also streamline the design to make this more obvious: putting the default path down the left, or across the top, is the usual way to do it.

[vexillia]

Couldn't resist:



I think this is the basic logic with all the decision points identified.  If correct it's easy enough to add the bullet text for you.

[LawrenceG]

All opinions are welcome.

I suggest you reverse this question "...will it end closer to its side?s rear battlefield edge?" to say "...will it end further from its side?s rear battlefield edge?" as this is more in tune with the spirit of the rules in which the move straight ahead is the default option.

IF you do that you change the outcome when the move will end the same distance from its side's rear battlefield edge.

Hence your version of the flowchart gives the wrong answer when the sponno troops are facing exactly across the table (the usual situation if they have come on as a flank march). The layout of your chart looks better though.

[vexillia]

IF you do that you change the outcome when the move will end the same distance from its side's rear battlefield edge.

Que?  If the straight ahead a move is across the table it ends up the same distance from both table rear edges by definition.  Reversing the question changes nothing.

[landmeister]

I think this is the basic logic with all the decision points identified.  If correct it's easy enough to add the bullet text for you.

THIS IS a true graph.  Impressive. Thank you very much. 

[landmeister]

I noticed a wrong result (my fault, not Martin's). If I select:

End closer to visible enemy ---> Select either option ---> Consider bullet points ----> No-----> Remain in place

...the other option is not considered, so a player could choose not to move because no bullet is eligible while it could go straight ahead. 

I think "Select either option" should be modified by "Select one eligible option". If both options are "no" then the element remain inplace, as is intended in the rules. Would it be enough? 

[vexillia]

I noticed a wrong result (my fault, not Martin's). If I select:

End closer to visible enemy ---> Select either option ---> Consider bullet points ----> No-----> Remain in place

...the other option is not considered, so a player could choose not to move because no bullet is eligible while it could go straight ahead. 

I think this fixes this but creates another problem:

[LawrenceG]

IF you do that you change the outcome when the move will end the same distance from its side's rear battlefield edge.

Que?  If the straight ahead a move is across the table it ends up the same distance from both table rear edges by definition.  Reversing the question changes nothing.

If the move will end the same distance from the enemy edge then:

"End closer to opponent's rear edge?" = NO, takes you to "consider bullet points".

"End closer to own rear edge" = NO, takes you to "contact enemy directly in front?" which is where it should take you.

The underlying reason why it changes something is because this is not the logically reverse question. That would be "End no closer to own rear edge?", or equivalently "End closer to, or same distance from, enemy rear edge?".

IMO the truth table approach I used on the other thread is probably more user-friendly. The aim is to make more ergonomic the practice of getting the result, not to expose the underlying complexity of the process.

If straight ahead:

would contact enemy in front or     end closer to closest enemy	would go closer to     own table edge	straight ahead is	bullets are
yes	yes	permitted only if matching a bullet,       otherwise forbidden	permitted
yes	no	compusory	forbidden
no	yes	forbidden	compuslory
no	no	permitted	permitted

A move must be made if any is possible.
If all compusory or permitted options are impossible, remain in place and count as having moved.

[vexillia]

That would be "End no closer to own rear edge?", or equivalently "End closer to, or same distance from, enemy rear edge?".

Will change to former but the double negative is very poor style so will have to think about this.

[LawrenceG]

That would be "End no closer to own rear edge?", or equivalently "End closer to, or same distance from, enemy rear edge?".

Will change to former but the double negative is very poor style so will have to think about this.

Why not just put the positive question

"End closer to own table edge?"

and swap the "yes" and "no" round?

[vexillia]

Latest version:

[foxgom]

Hi

am a physicist and appreciate and can work with flow charts.

The use if them in DBMM makes me think the rules must be complicated.

To me they create a bad impression on any newcomer.

I find the rules quite intuitive.

The text does sometimes have to be read twice (or even three times  ), but try writing an exact set of instructions about how to make a cup of coffee !

[vexillia]

The use if them in DBMM makes me think the rules must be complicated.

Possibly you're confusing the rules text with the implicit, or underlying, logic?