Discuss the massively-multiplayer home defense game.
You are not logged in.
Okay, I put a temporary fix in place server-side to prevent people from dying from this.
An updated client with a real fix for this problem is coming soon.
Looks like there is some kind of bug in the game client that somehow lets you "leave" the house multiple times at the end of your move list.
I'm not sure what's causing it, but it has happened 36 times in the history of the game, and it last happened to someone 5 days ago.
It's pretty rare, and this is the first time that someone reported it. I'm really sorry that this happened to you!
--Fixed the electrobreaker issue and wireless transmission by not jumping back to start state when a circuit overruns the substep limit (thanks Iceman).
--Huge optimization to power propagation and transitions by skipping cells (like empty floor and walls) that are never affected by power.
--Got rid of terminal print out when a mobile steps on a button.
--Fixed so that Un-ignore All button does not jump back to the top of the house list (thanks MMaster).
Okay! It's live.
You want to go from
"worrying about your house obsessively while you're at the grocery store"
to
"checking your house obsessively while you're at the grocery store"
!
Sorry, sorry! Swamped with way too many threads to read.
The paintings are being made as we speak, in fact. It took me a while to narrow in on a printing company who gave me confidence that they would do a really good job.
They should be done on Monday or so, and then they will send one to me so that I can look at the quality and approve it. After that, they will be shipped out to the winners directly from the printer.
Most of the other prizes are waiting in the wings to go out when the paintings go out. Though I'm still waiting for the gift certificates to arrive from the Custom Cartridge Company. I sent them a check about a week ago.
Yeah, I thought about this!
But decided against it because:
1. It makes paintings harder to see (they are tiny). These paintings are actually 32x32 pixels, but the wall faces are only 14x7 pixels. You're drawing them using sub-pixels, which breaks the chunky "a pixel is a pixel" nature of the game screen. On the sidebar, paintings can be drawn so that their pixels match the game pixel size.
2. It becomes possible to "bury" paintings in a house so that people won't even know that you have them (thus subverting the gameplay point of paintings, which is to track your loot after it has been stolen and maybe steal it back).
3. It makes robbery success messier, adding another degree of "partial" success. Got one painting, didn't reach the vault. I decided early on to have a very discrete success condition (reach the vault, or not) to keep the game focused.
Sorry for the weirdness here. I'm building the game on 10.5, both for backwards compatibility, and also because my only mac doesn't have enough ram to run anything beyond 10.5.
I hadn't even heard of clang until this thread. What happened to gcc?
Oh... and yeah, on the mac, you MUST "bundle" the game as a manual step AFTER runToBuild finishes. Go into the "build" folder and run makeDistributionMacOSX
That will make a proper "CastleDoctrine.app" app bundle and copy all necessary game resources into a nice folder for you. At that point, you should find your "final built folder" in "build/mac".
The "runToBuild" script is pretty much expecting that you are doing the building on Linux (because the game shipped as source for Linux, with no binary at all, back in the day).
Though it may work fine on Windows as well, because no app bundle is needed...
If you poke around in the recordedGame file for that run where you got the bad response from the reflector, you should be able to find the response that the reflector sent. Search the recording text for:
wb 0 2
That's the response for web request 0.
If the reflector is working correctly, it should just be a URL to the server.php file.
If it's not working, you may see some PHP warnings or errors that it is sending instead.
Of course, you can also test your reflector directly by going to it's url with your web browser.
Blueprints demonstrated this simple fact:
Even if you can see the WHOLE map, NP-Hard puzzles are still possible (as in: can likely not be solved in a non-exponential amount of work by a computer or a human).
But we didn't need blueprints to demonstrate it, because it was already theoretically provable: the systems in the game are suitably powerful that they can represent boolean logic statement [(A or B or C) and (D or not B or F) and (not A or not F or E)]. As soon as you can do that, you can encode boolean satisfiability problems in the game maps themselves, where reaching the vault without tools requires finding a set of true/false assignments for A, B, C, D, etc, that make the whole statement true. There is no known algorithm for finding a valid truth assignment for these kinds of problems in a non-exponential number of steps. Effectively, solving methods boil down to trying all possible assignments. For N variables, there are 2^N possible assignments.
This means that even with the map in hand, you'd be staring at 16 buttons and couldn't figure out which ones to press without running through close to 65,000 possibilities on paper.
And even if we eliminate all electronics, I suspect that there are "dog and maze and pit" constructions for where having the full map doesn't help much either. There can be an exponential number of paths through a branching dog/pit maze, and no clear algorithm for picking the right path without going through all possible paths on paper.
This is a hard computer science fact that we will never get around. Any sufficiently powerful system can be used to build puzzles for which there is no known way to solve them in a non-exponential number of steps.
The only solution is to give people tools to bypass these things when necessary. By making these tools precious, tactical, opportunistic tool use is still possible, and the game becomes one of looking for weaknesses to exploit with the fewest and cheapest tools. That's still kind of puzzle-like, but not in the hard Rubik's sense of the word. More like Dishonored: tactical puzzles.
Yes, you could explain it that way. I mean, if it's looping before we hit 32 substeps, it would indeed be still looping through those same states during substeps 33-64 if we did happen to simulate it that far. Same if it self-settles before we hit 32 substeps (it would still be settled in substeps 33-64).
Of course, we catch shorter loops and settled circuits earlier than that for efficiency (no need to run the full 64 substeps, if we have full knowledge about the circuit's possibilities after 4 substeps).
But, essentially, it's like treating all circuits equally in the way that they are settled. We run 'em all for 64 substeps and settle them to their lowest-seen states in the last 32 substeps of those 64 substeps.
The wireless transmission thing was exploiting the fact that some circuits are settled differently than others in v32.
Coding it up now... eta tomorrow.
So.. looking at the code, I had a realization here, but I need more heads to check it.
The way the current system works, if electronics loop globally (return to some state that we've already seen) before 32 substeps, then we march through that loop again, look for the lowest-seen-state of each component during the loop (from this state until we return back to this state), and then set each component to its lowest-seen-state. In this case, we never return directly-powered things to an unpowered state, because thought they were unpowered at the start (before power reached them), by the time the loop is underway, they are powered, and only the in-loop states are considered when settling components. In other words, yes this light was off at some point, but it was on 100% of the time through the global loop, so we leave it on.
If electronics go 33 steps without settling themselves OR ever repeating a global state, then we stop the simulation. At that point, we roll back to the starting state, run 32 more steps from there, and look for the lowest-seen-state for each component. Since we don't have a real loop to work with (because we hit the limit before we saw a loop), we consider all 32 steps along the way as "the loop," and look for lowest-seen-states from that entire span of steps.
Of course, this leads to weird electro-breaker behavior, along with wireless communication. The problem is that we treat looping circuits differently than overrun circuits when we go to settle them. For the looping circuits, we effectively only consider "recent" step history (from the loop itself, and nothing before that). For overrun circuits, we consider the entire step history.
Removing "step 0" from consideration for overrun circuits prevents electrobreaker behavior, but it doesn't really address the fundamental problem of differential treatment of these two cases. What we really want to do is treat the overruns exactly like we treat loops.
But, for the overruns, we have no "full loop" of states to look at. So, we need to pick an arbitrary one. The current arbitrary pick is "the 32 global states that occur from the start state forward". But any other arbitrary pick is just as good.
What about "the next 32 states from where we cut off, forward"?
In other words, don't roll back to the start state. Just roll forward from where we stopped. This is what we actually do for loops (because we know we'll return to this point again if we roll forward from here, because a loop guarantees that). For overruns, we have no guarantee, but we might as well just run for another 32 steps and see what happens.
This certainly fixes the electrobreaker bug.
But I think it also deals with the wireless issue.
That issue depends on receiver circuits that effectively "settle" into an ON state before the 32 steps are up. By definition, these are ON ON ON ON for steps 33 to 64, which means that their lowest-seen-state will be ON if the global state suddenly switches to overrun mode.
Imagine a huge, hairy receiver that takes 31 steps to settle to ON. Now switch on a global overrun circuit. The receiver stays ON, because only steps 33 - 64 are considered when settling it.
Imagine a receiver that takes 34 steps to settle to ON. Then it overruns by itself, and has one OFF state during steps 33 - 64, so it settles to OFF. Another global overrun circuit switching on won't change that.
I'm pretty sure this would work.
One strange side-effect of this is that overrun circuits would settle differently than they currently do. They would ignore their starting state and first 32 substeps when settling, which might mean they would settle into a kind of "half way on" state. Like if this is an 8-bit counter that takes 256 steps to loop, steps 33-64 might involve some bits being stuck on the whole time, which means that they would settle to ON, which would look weirder than them settling to their start state.
I doubt its the keyboard in the case of the British English one.
On Linux, open GL defaults to some kind of vsync for frame updates, which prevents frames from being drawn any faster than your refresh rate. This may be true on some other platforms as well.
So, on Linux, the fix for this is invoking the game this way on the command line:
vblank_mode=0 ./CastleDoctrineApp
This lets the frame rate fly free of the vlbank interval. I regularly see 150 FPS during recordedGame playback if I do this. It also helps to drag the window mostly off the screen (so only a corner is showing) because then the whole screen isn't drawn (not sure how this works exactly, but it works).
Finally, I've had SOME luck running a search-and replace for long columns of all "0" in the recording file and simply removing them. But you need to be careful doing this, because sometimes several "0" lines are actually part of a web response from the server. Also, it may screw up timing somehow (though the recordedGame files actually record time() values, so it shouldn't).
In general, the recordedGames are still a bit fragile.... For very long recordings (like days) they usually end up breaking and falling out of synch for mysterious reasons by the end when you try to play them back.
Thanks! Will look at fixing this.
Yes! Great stuff here.
I split the thread as requested.
Thinking about one electronics propagation per robber step last night, I couldn't come up with a way to make it visually consistent. Assuming that "electricity flows instantly" but it's just the "springs" in the voltage-triggered switches that take time to move, it just becomes weird to make the whole thing turn-based. You're either staring at a switch that looks like it should pass power, but is not actually passing power (because it's "about" to spring open when you take a step) OR you're staring at a switch that looks like it should be blocking power, but things beyond it are still powered OR you're staring at a switch that looks like it should be sprung (because its spring is clearly powered) but it isn't sprung.
The last option is the best one, but it's somewhat incompatible with the way an electronics step is currently resolved (propagate power from power sources, then trigger any power or no-power based transitions---this could result in a light turning on AND the switch feeding that light springing open).
This issue exists for any fixed number of sub-steps where we freeze the state at the end of those steps.
And, any fixed number of substeps will provide us with easy flip-flops (on-off clocks) because you just need to make a circuit with a loop count that isn't a divisor of the fixed number of substeps. It will flip on and off each step. We can thwart that with a fixed number of substeps that is the multiple of a bunch of divisors (like 6*7*8*9), but that number gets huge quickly.
As an example, if you're doing 8 substeps and then freezing the state, a circuit that loops every 3 substeps will turn on and off as the robber moves.
This is VERY different from real clocks, because real clocks don't depend on some arbitrary number (like 8 or 32) to work. They work the same way regardless of the cut-off.
Obviously, some number of purge steps is necessary to at least prevent the power-flow blocking bug that Jere is using there. That will be a first step to "buy time" while we continue to ponder the bigger picture here.
This will only affect houses that currently reach the 32-substep limit, so a full world reset won't be necessary. Yes, a few houses' self tests will be made invalid by the change, but that's no big deal. Some v32 robbery tapes will be weird when watched in v33, but again, only if your house currently is hitting the 32-substep limit.
You're so scared as you leave the house that you drop your backpack in the street, where it is scavenged by vagrants.
Yeah... it's possible to build a circuit (like a 16-bit counter or something) that takes tens of thousands of steps to finally loop. Yes, it's a problem for performance. Josh designed a house back in the day that took 96 minutes to compute a single step:
http://castledraft.com/editor/GtDVc0
As a robber, if you step on that switch, you're in for a 96 minute nap.
Clearly, a step limit was needed to prevent this. Even if we ignore the issue of clogging people's PCs, the server-side simulator needs to chug through all that as well.
But, if there was one electronics step per robber step, that house would be perfectly viable. However, you'd then be in a position where you might force a robber to walk back and forth for 65K steps before finally being able to walk through. Though something like that is already possible with the existing counters. I think this would make it easier though.
Okay... time to retire for the day and keep thinking about this. I look forward to some great thoughts here when I come back tomorrow!
Sorry... a bunch of people posted the exact same thought as I wrote that.
(Also... feeling somewhat sad saying goodbye to the deep esoteric mysteries of electronics in this game...)
Yeah, that is a solution!
"The electronics overheated and you died in the fire."
So... a home owner wouldn't do this on purpose, because they would lose everything if it was ever triggered (even if they skipped tripping it themselves, a robber could trip it and burn their house down). Any chance of someone doing it by accident, though?
Also, I think the whole "sub step" thing is at the heart of what makes electronics so hard to understand. Iceman's mod turns the system down to 1 sub step for a reason.
And Minecraft redstone is easier to understand because you can "see it happening" as various plungers move to and fro, step by step.
So... maybe a paradox circuit SHOULD blink on and off as a robber walks around.
Maybe each robber step should only have one power propagation step.
This seems like a huge change to the game. Then again, it would only affect people who are doing complex electronics. And some things would make a bit more sense (like entering a combination on some buttons but having to wait a step for the internal voltage-triggered switches to transition and finally open the door a step later).
Also... I really wish this came up before the game was released and reviewed...
So... if there were a fixed number of "electronics sub-steps" per step (like 8 or whatever) and NO loop detection at all... just propagate power and trigger transitions for 8 sub-steps and then "freeze" everything where it is at that point, paradox or not...
That would allow more complex electronics stuff to happen ACROSS robber steps. Like, right off the bat, there would be things that flip and flop between steps.
In fact, pushing this idea to 11 would mean just doing 1 electronics step per robber step. Then even the simplest paradox circuit would flip back and forth as the robber walked around.
And even with a fixed number of sub-steps like 8 or whatever, any paradox that loops for a number of steps that is not a divisor of 8 would flip-flop across robber steps, but anything that loops for a number of steps that is a divisor of 8 would appear to be stable. This would be weird.
I dunno... that would be a heck of a lot of blinking going on!
The option of holding sub-state-1 as the "fall back" state if anything loops or exceeds the step count would fix the electrobreaker thing BUT also totally break clocks and other more complicated electronics that depend on later looping.
Anyway, this thread is AMAZING and I sense that we're making progress here toward a solution.
Yeah, I thought about adding a "diode" to the game, but decided not to because you can already build one with the existing components.
Oh, yeah, if you run the game in a proper terminal, when a dog steps on a switch, the game currently prints "Mobile-triggered transition hit".
It might help somewhat in a magic dance house, but not that much, because you can't tell what the dog stepped on exactly, just that something changed because of a dog. You can count how many dogs are stepping on switches this way, though.
I should remove that print out... it's left over from some debugging session that I don't even remember anymore.
The purge would happen at the beginning of each robber step.
It would "run" the electronics for several propagation steps and transitions to get them to "shake out" a bit.
So, anything directly connected to power would become powered on.
Then, it would treat this "post-shake-out" state as the starting state, and run standard loop detection (or step limit detection) from there.
Remember, at the end of this process, if the electronics are "looping", then they are settled into the lowest state number that they each achieved during the loop. If a light was on for the whole loop, it will settle into its "on" state.
The "electrobreaker" stuff depends on the fact that after a switch is hit to turn a light on, the "start" state for that light is actually off, so it's lowest seen state is "off". (The light had no power last robber step, so at the start of this robber step, with the switch on now, the light starts off until the power flowing through the switch turns it on.)
During normal looping, the loop happens after the starting state. But during loops that exceed the step count, no true loop has been found (instead, we have electronics that are changing states without ever repeating a global state). In that case, the current code considers all states, including the starting state, when trying to "settle" the looping components.
Thus, if the starting state had a light off, it will settle to off in that case.
But if we let electronics "shake out" first before even picking the state we consider the "start," we won't have this problem.
Currently, if electronics surpass 32 steps, we consider steps 0, 1, 2, ..., 31, 32 when looking for the lowest seen state for a component.
With this proposed change, we'd run something like 8 + 32 steps, and then consider steps 8, 9, 10, 11, ..., 39, 40 when looking for lowest-seen states (ignoring whatever states were seen in steps [0..7]) when settling components.
The electrobreaker examples have components that are on by step 1 and stay on after that.
This would change nothing for components that are actually looping in fewer than 32 steps (clocks and stuff).
This would change the behavior of global circuits that take more than 32 steps without settling or looping.
STILL.... hmmm....
There's something very unsatisfying about any of this stuff. The step limit really is the point where the game "breaks" and everything stops making any kind of sense.
The behavior of paradox circuits, on the other hand, have a kind of logic to them. But the step limit is like a magic number.
It would be ideal to forbid houses that hit the step limit, but there's no way to actually do this (even if we check for it in self test, the owner could just avoid turning that part of the circuit on during the test, but design a house where the robber would likely stumble their way into the broken behavior).
Even isolating "separate" circuits, which would prevent wireless transmission, would not fix other esoteric uses of the step limit in connected circuits.
It seems like the settling behavior should be almost identical for "true loops" and "step limit" circuits. Picking the lowest seen state seems rather brittle, because a single visit to one low state out of 32 high states can "override" all the high states.
What about majority vote? Each component settles to whatever state it was in MOST during the loop. So if a light was on for two steps and off for one step in a 3-step loop, it would settle to being on.
Argg... but I think this would still allow wireless transmission... a receiver could stay off for 17 steps and then settle into "on" after that. The transmitter could take more than 32 steps to resolve after being turned on, in which case the receiver would be off 17 steps and on 15 steps, making it suddenly settle to "off"
Maybe "recentness" of the states needs to be accounted for? Here we have a receiver in the "on" state for the last 15 steps, but we're ignoring that when we settle it.
Redxaxder:
How does 32 sound?
:-)
Also, I'm glad that we're now using the phrase "the purge" in this conversation. I just saw that movie last night.
Here's a proposed fix:
Instead of starting the loop detection up right from the beginning, run several "purging" power transitions beforehand to get us away from the starting state and into the "middle" of any simpler loops.
Then, at that point, remember THIS as the start state, and run the normal loop detection (or step limit detection) as normal.
This prevents us from EVER returning to the true start state after loop detection (fixing the electrobreaker issue).
It also makes wireless transmission harder, because the receiver can no longer be a simple looper. It will need to "weather" the purging power transitions before it starts "on" looping (it would need to have at least one "off" step AFTER the purging power transitions are over).
Explained another way, whatever states are reached during the purging transitions would NOT be considered as possible "lowest seen states" when settling a looping or over-limit circuit.