|
|
Pegs
I'm trying to decide how best to discuss this. I've come up with a reasonably elegant way to handle the connections between pegs, that allows you to easily see the next peg AND the peg beyond that, to test for possible jumps. I've also got a nice recursive algorithm to move the pegs around and search for solutions.
Recursion is great. A few for-loops and a recursive call, and something that before was difficult, now is simple. I'll post the results when I see it work as well as I think it should.
Meanwhile, I will talk about one odd little self-discussion I was having. It revolved around the typical OO quandry: what should be an object?
It came down to this: should I have a Board object that contains Holes? Or should the Board just have a few arrays to hold Hole information.
I had a Hole object for a while that had a boolean for peg/no-peg, and then an array of "neighbors", which pointed to other holes. I was really attracted to the cuteness of being able to say something like Hole h = otherHole.neighbor(1).neighbor(1); That kind of chaining is kinda neat to write, but it had two things I didn't like.
First, in setting up the board/holes, I really didn't want a networked chain of holes. That was unattractive to me, as the overhead to keep a dual-linked network of holes was a pain.
Second, and possibly more importantly, it didn't make sense that the Holes should know anything about their neighbors. Really, a Hole should just know if it has a peg or not. That's it. By putting the knowledge of the neighbors at Hole-level, that's where the structure of the board was kept. I had no structure in the Board, which is really not right. The Board needs to know what it looks like.
This became very obvious when I wanted to be able to create different kinds of solitaire boards. Some, like the familiar triangle, have six neighbors for each peg (like a hexagon), while others, like the cross, have only four.
I found though, that when I put the list of neighbors at the Hole level, that means I'd have to pass the number of neighbors to each Hole. Which again, seemed weird. The Hole shouldn't care, and should probably get that from the Board... but how would the Board convey it? It just didn't make sense.
So, instead, I put the list of connections/neighbors at the board level, in the form of an array [Holes,Neighbors]. This left the Hole just being a boolean that represented peg/no-peg, so I scrapped the whole Hole object and went with another array [Holes] of booleans, one for each hole.
Looking at it now, with the solution in hand, it seems so obvious. But it took me a bit of playing around to actually get there.
So, we'll see how the rest shapes up, hopefully by the end of the week. Once it's working in Java, I think I might try and get it working in .NET, either C# or VB, or both. Then, maybe Python. It'd be interesting to see it running in each language, I think.
|
|
|
|
Post a Comment
<< Home