Improve documentation

[spamguy]

This is a great project! I am writing a NodeJS judge and I use this as inspiration and a primary reference, along with the diplom.org article linked in the README.

The code does lack significant documentation so the GoDoc reference isn't much help. Comments are scarce too. Admittedly I don't speak Go so I'm often guessing what Thing A is doing to Thing B. :)

[zond]

I'm happy that you both like the project and have improvement suggestions!

My time for working on this is severely limited, so how about this?

You fork the project and start writing docs for the parts you understand
now, but you think would actually need some more docs.

Then you ask me about the parts that you don't understand but want to, and
I'll happily answer all your questions in exchange for you including the
answers in your doc fork.

Then I merge your fork and we have a documented project with one more
contributor? :)
On Jan 21, 2015 5:59 PM, "spamguy" notifications@github.com wrote:

This is a great project! I am writing a NodeJS judge and I use this as
inspiration and a primary reference, along with the diplom.org article
linked in the README.

The code does lack significant documentation so the GoDoc reference isn't
much help. Comments are scarce too. Admittedly I don't speak Go so I'm
often guessing what Thing A is doing to Thing B. :)

—
Reply to this email directly or view it on GitHub
#1.

[spamguy]

Heh, I can work with that.

The biggest black box is Adj(): the article doesn't dare touch it, so I'm guessing you just figured out what works for yourself. Do you have any brief high-level commentary on your approach?

[zond]

Adjudicate is the thing that checks on a per order basis if the order
succeeds, right?

It's actually not that hard, just follow the rules in the most naive way:

• A support succeeds if the unit can move to the target, there is a unit at
  the target, and there is no attack against the supporting unit that could
  have moved off unopposed.
• A move succeeds if there is a part, no other move to the same destination
  has more power, and any unit at the destination has less power.

Etc.

The only thing you have to keep in mind is that the adjudicate functions
must never call an adjudicate function directly, but instead call resolve
for the order in question since resolve is what fixes infinite loops and
paradoxes...
On Jan 22, 2015 3:49 PM, "spamguy" notifications@github.com wrote:

Heh, I can work with that.

The biggest black box is Adj(): the article doesn't dare touch it, so I'm
guessing you just figured out what works for yourself. Do you have any
brief high-level commentary on your approach?

—
Reply to this email directly or view it on GitHub
#1 (comment).

[spamguy]

Hello again! I'm still at it, with some modest success. I set up a go environment to see godip do its thing. This is more of a general go question, but I notice there's no way to 'execute' godip, per se, since there's no main package or function. In the past, how has godip been applied towards unprocessed phases of active games?

Cheers (and thanks).

[zond]

Hey again!

Right now, godip is used in https://github.com/zond/diplicity, but that's an entire web app (albeit far from finished) so it might be hard to use as an example.

The classical mode tests (https://github.com/zond/godip/blob/master/classical/classical_test.go) might help some.

But basically you just

judge, err := classical.Start()
...
judge.SetOrder("bre", orders.Move("bre", "mid"))
...
err := judge.Next()
...
fmt.Println(judge.Resolutions()["bre"]
fmt.Println(judge.Unit("mid"))