It’s not complete, but it’s close enough that I’m comfortable sharing it.
The goal here is to me a (reasonably) optimized engine for the C# and .NET ecosystem, including and especially a strongly-typed interface to OGS itself.
While I do have an application in this project, it is not the primary goal; it’s more of a simple wrapper around the library I’m building to test out the functionality.
As of today, this doesn’t interface with OGS purely because I cannot seem to get the OGS connector to actually log in, but I’m working on it!
Under the hood, I’m representing the board with 19 64-bit numbers (the first 19 bits represent the black stones in a row, the second 19 bits representing the white stones, and the remaining bits going unused. . .for now [1]) meaning there’s only ever 152 bytes representing the board at any given time.
Doing things this way leans in to the very fast JIT built in to .NET, leading to highly-paralellizable state representation and manipulation.
[1]: I’m probably going to see about packing things into only 19x19x2 bits, leading to each board state being just 91 bytes, stored in 12 64-bit integers and wasting just 46 bits.
Not sure what your overall plans are, but unless you’re needing to store a lot of board states and don’t mind paying the extra expense of the mask/shift instructions to index into your bits, that kind of optimization might be a bit overkill (and could slow you down depending on what you’re doing).
Also, if you’re playing on OGS, don’t forget we go up to 25x25 boards here
Also just food for thought, for a lot of use cases you want to store extra state per intersection, such as markings or position highlighting, stuff like that, so again depending on what you’re looking to do, you might keep those kinds of use cases in mind when pondering your architecture.
Yeah, I hear ya. I was pretty close to scrapping the bit fields before I realized the issue was with the view layer.
Kind of a side objective of this is to see just how many states I can get it to crunch in some arbitrary amount of time; given how C# works, the easiest way to do that is with bit bashing on arrays of ints; pointers and references arent as easy (or even fast) as they are in C/C++.
The good news is that all of the logic would extend just fine to 25x25. That’s just 50 bits total, so a 64-bit int stores it just fine!
Got my barebones analysis mode in place this weekend.
Should be able to get at least basic ogs functionality worked on this week/next weekend now that I have implemented each of the actions that can happen in a game (except for scoring).
This library is consumable by an end user to use! If you want to write a Go bot/AI in .NET, you can! (Link is at the top).
I don’t have it packaged yet, so you’ll need to just grab the source if you’d like to use it. Planning on figuring this out this weekend.
I think the interface is pretty straightforward if you’re familiar with .NET already.
I intend to write some documentation for it anyway, which I’ll share about here.
(If mods would prefer I not necro old threads to share updates about this, please let me know! I’ve seen a few other devs and creators doing this, so I figure it’s probably okay.)
