View Full Version : I swear I came to a board where you had to guess...
kalirion
01-02-2011, 11:43 AM
At least you'd have to guess without being able to think 50 moves ahead to see if anything started conflicting...
So I turned on the "show possible solutions" and saw this:
http://img52.imageshack.us/img52/1373/squarelogic.jpg
Now could someone please explain to me why the 4-square solutions are disqualified?
So anyway, I decided to follow this, and hid all numbers other than 5 and 6 on the two painted 270x squares. But was still stuck.
Eventually I asked for a hint. First it told me to look at the 270x set. That the 2 squares were too small to contain the full solution. Yeah, already knew that.
Then it told to paint the lower square the same color. Well how was I supposed to know (without the hint) that the lower square is part of the set, and not the higher square? How was I supposed to know that the lower square was not part of the 21x or the 13+?
So the question is, did I miss something (if so, what?) or did the game screw up?
lmdemasi
01-02-2011, 01:52 PM
The purple 9 must extend down to the third square, since the 2 light blues can't be next to each other. So the 4 division must go down and there are only 3 spaces for the 270.
kalirion
01-02-2011, 02:08 PM
The purple 9 must extend down to the third square, since the 2 light blues can't be next to each other.
Damn, I didn't even think of that! Was that one of the official rules I missed, or just common sense?
Edit: Guess that explains the light brown sets in bottom right as well. Thanks, +rep!
lmdemasi
01-02-2011, 04:54 PM
Hmmmmm, I didn't do the tutorial and I don't remember seeing it say that anywhere, I think I just assumed it had to be like that.
cwangersky
01-03-2011, 12:21 AM
I don't recall the tutorial saying that, either, but it may have... of course, the tutorial being 4x4 may not have had many chances to potentially get colors brushing up against themselves. The tutorial did say that the marked cell will always be the leftmost cell of the topmost part of the cage, so the 270x dark blue must go down, not up.
kalirion
01-03-2011, 07:22 AM
Hmm, I need to pay better attention then I guess.
KHarward
01-03-2011, 08:08 AM
At least you'd have to guess without being able to think 50 moves ahead to see if anything started conflicting...
So I turned on the "show possible solutions" and saw this:
http://img52.imageshack.us/img52/1373/squarelogic.jpg
Now could someone please explain to me why the 4-square solutions are disqualified?
So anyway, I decided to follow this, and hid all numbers other than 5 and 6 on the two painted 270x squares. But was still stuck.
Eventually I asked for a hint. First it told me to look at the 270x set. That the 2 squares were too small to contain the full solution. Yeah, already knew that.
Then it told to paint the lower square the same color. Well how was I supposed to know (without the hint) that the lower square is part of the set, and not the higher square? How was I supposed to know that the lower square was not part of the 21x or the 13+?
So the question is, did I miss something (if so, what?) or did the game screw up?
Officially, the cage "rule" is in the top-most, left-most square of the cage, in that order (meaning, top takes higher priority over left). So with the 270x, the rule is in the top-most, left-most square of the cage. If the 270x cage went "up", then when it turned up *that* square would have been the top-most square and would have had the rule in it instead. Since the rule isn't there, we know the cage doesn't go up.
In general, cages never grow "up" during hidden cage. They can grow left, but only after growing down first.
I think the game does not do a good job of explaining this. So I think we're to blame.
As for a rule about colors not touching...officially no such rule exists. We did not want seeing the colors to be a requirement for deducing the logic of the puzzle. To that extent, the AI that solves the puzzles *never* considers whether it would be painting two colors next to each other. However, in practice, it is a *fairly* safe bet. I think this is one of the very few flaws of us using colors for our cages. However, the boards look really beautiful to me when complete, and it seems like a fair trade-off. We considered having Hidden Cage mode require you to draw in the lines around cages rather than painting colors, so that this issue wouldn't exist, but the interface for that was really clunky. Painting in the colors just felt better, and we could keep the all the colors. (This was a big issue for us.)
However, across 25,000+ puzzles, I would not bet big money that two cages of the same color never touch. But I would bet big money that cages never grow upwards in this version of the game.
Ken
lmdemasi
01-03-2011, 09:46 AM
Thanks for the reply Ken! Always nice nice to get a response from somebody who knows the answer.
UncleSquirrel
01-03-2011, 02:30 PM
However, across 25,000+ puzzles, I would not bet big money that two cages of the same color never touch.
Ken
I would bet semi-big money that no two cages of the same color ever touch. I wrote the code specifically to disallow that possibility; however, it was very tricky code (since there are lots of finicky cases during puzzle generation, including the merging of certain like-typed cages, etc) so it's always possible that there's a bug. But you should only see two cages of the same color touch each other if there's a bug in the code.
Nevertheless, Ken is right to point out that our AI solver does NOT use that "inference" when it is analyzing boards (and setting Par, etc). So you don't have to, either.
In other words: I personally believe that you CAN get away with using the "no two directly adjacent cages will share the same color" inference in your own puzzle-solving, but that inference is never *required* that you use it since the AI solver didn't use it when verifying solution uniqueness / deductive soundness during generation.
kalirion
01-03-2011, 02:33 PM
Good to know, thanks!
Regarding the puzzle generation - were they generated once and hard coded into the game, or does every game install have unique puzzles based on some random seed?
captain_video
01-03-2011, 06:21 PM
Good to know, thanks!
Regarding the puzzle generation - were they generated once and hard coded into the game, or does every game install have unique puzzles based on some random seed?
The puzzles are all pre-constructed, no random seeds. There are scripts in the data files which know how to generate the puzzles, and the script programming is a Trade Secret. :)
And to Ken, WB guy! I was worried about you!
KHarward
01-04-2011, 09:27 AM
The puzzles are all pre-constructed, no random seeds. There are scripts in the data files which know how to generate the puzzles, and the script programming is a Trade Secret. :)
And to Ken, WB guy! I was worried about you!
Captain Video is correct. The data files contain the recipes for the types of puzzles to create, and enough information to ensure everyone gets the same puzzles. Then the game generates each and every puzzle on the fly as needed.
Technically we could generate hundreds of thousands of puzzles. We were originally hoping to release expansion packs of more puzzles, but we ended up handing out 20,000+ puzzles with this initial game because it wasn't clear whether there would be enough of a community to warrant expansion packs. And since it was our first game as TrueThought, we cared more about making it a wonderful experience than trying to nickle and dime our customers. On the whole, I'm glad we did that.
Thanks for the kind words Captain Video. My house has had some difficulties of late, but things are getting back in order, and, as I like to say, I'm not dead yet :-)
We are eagerly approaching an end to a project we've been working on. When that's done we hope we can finally get back and release our patch for SquareLogic which addresses the Cloud issue(s) and a few other odds and ends. To everyone who has been waiting, thank you for your continued patience. We still care very deeply about SquareLogic and we want it to be a great game experience.
Ken
vBulletin® v3.8.7, Copyright ©2000-2013, vBulletin Solutions, Inc.