Hi everyone,
as a simple exercise and challenge to myself, I'm attempting to flowchart logic which might be useful for detecting if a player is "loitering". This is aimed at the note in the rules saying a player "cannot simply move back and forth to avoid drawing an event.". So far, this logic hasn't been implemented as it is complex and tricky to avoid generating false positives. So I know the devs here have higher priority things to work on, so I'm taking it upon myself to get some discussion going and perhaps/hopefully get a complete/robust flowchart logic for this check.
(and maybe it could be used in future to develop an actual check for this
)
A bit about myself: I've been working as a software developer and database administrator for over 20 years in the industry. I've always enjoyed puzzles/riddles/challenges, so this particular "problem" is something I couldn't resist tackling. The biggest trick I've learned over these years, is that one person alone will almost never think of all the possible cases, and so peer review is absolutely crucial.
So here we are now, I've been doing a bit of research and surface scraping into this issue/game lately, and am feeling pretty good about my current version. So please, I ask for constructive criticism and helpful feedback for this. Please, if you think you can present a case/situation that "breaks" the logic I have, please please please, post it .. using that, I can refine the logic to account for these.
Note that my goal in this is as follows:
1) we MUST not have any false positives. This is absolute, bad bad bad.
2) we do NOT have to detect 100% of all loitering cases (yet). There may be vague cases which are impossible to programmatically detect, as the move itself may be perfectly legal (ie move, place 1 hack token, move), however, it may be "obvious" to a person that the move was done simply to "Loiter".
Basically, we'd rather catch some or most Loiter moves, as long as we don't trigger any false positives. Even if we detect the more basic/obvious cases, I think is still acceptable. We don't need "perfection" on the detection, but we absolutely cannot have any false positives.
With that in mind ... attached is a pdf of the flowchart I have so far.
as a simple exercise and challenge to myself, I'm attempting to flowchart logic which might be useful for detecting if a player is "loitering". This is aimed at the note in the rules saying a player "cannot simply move back and forth to avoid drawing an event.". So far, this logic hasn't been implemented as it is complex and tricky to avoid generating false positives. So I know the devs here have higher priority things to work on, so I'm taking it upon myself to get some discussion going and perhaps/hopefully get a complete/robust flowchart logic for this check.
(and maybe it could be used in future to develop an actual check for this
)A bit about myself: I've been working as a software developer and database administrator for over 20 years in the industry. I've always enjoyed puzzles/riddles/challenges, so this particular "problem" is something I couldn't resist tackling. The biggest trick I've learned over these years, is that one person alone will almost never think of all the possible cases, and so peer review is absolutely crucial.
So here we are now, I've been doing a bit of research and surface scraping into this issue/game lately, and am feeling pretty good about my current version. So please, I ask for constructive criticism and helpful feedback for this. Please, if you think you can present a case/situation that "breaks" the logic I have, please please please, post it .. using that, I can refine the logic to account for these.
Note that my goal in this is as follows:
1) we MUST not have any false positives. This is absolute, bad bad bad.
2) we do NOT have to detect 100% of all loitering cases (yet). There may be vague cases which are impossible to programmatically detect, as the move itself may be perfectly legal (ie move, place 1 hack token, move), however, it may be "obvious" to a person that the move was done simply to "Loiter".
Basically, we'd rather catch some or most Loiter moves, as long as we don't trigger any false positives. Even if we detect the more basic/obvious cases, I think is still acceptable. We don't need "perfection" on the detection, but we absolutely cannot have any false positives.
With that in mind ... attached is a pdf of the flowchart I have so far.
but that's understandable.