The Castle Doctrine Forums

Discuss the massively-multiplayer home defense game.

You are not logged in.

#126 Re: Main Forum » Pet movement suggestion » 2013-06-11 10:19:32

zed

If i step down now, on top of the cat, it has 1 possibility to move (up) to increase its distance from 0 to 1
Which it does, if i step back up, ontop of the cat again it has 2 possibilities to increase its distance from
0 to 1
By order of preference it would choose down and go back into the dead-end, however it seems to choose up

Yeah, there's a special rule I didn't mention: if you step onto a cat, when it's deciding which way to move it uses your *previous* position (i.e. the one you stepped from onto the cat). That's what produces this nice fleeing behaviour.

#127 Re: Main Forum » anti-magic dance and police » 2013-06-10 14:05:28

zed

There's another problem with using randomness with fixed seeds. You could
build a house whose solution depended on knowing the precise movement of some
hidden pets. The designer would keep rolling new seeds, or fiddling with the
setup of the pets if the seed is fixed, until the movement was as wanted. A
robber would have no idea how the pets were going to move, so wouldn't have a
hope of solving the puzzle.

#128 Re: Main Forum » Complexity, puzzle families, and the metagame » 2013-06-10 14:00:08

zed
jasonrohrer wrote:

The problem is still imbalance.  House owners have a fundamental advantage over robbers, because they can design puzzles that are unsolvable in practice.

I still don't see that that's been demonstrated. Maybe it's possible, but I don't currently see how.

#129 Re: Main Forum » The Place to Post Your Break-ins » 2013-06-09 10:13:14

zed

Ugh, so now I'm destitute on both servers!

I didn't think of using a brick... nice trick.

#130 Re: Main Forum » The Place to Post Your Break-ins » 2013-06-08 19:25:58

zed

Hey, well done! You even solved part of the puzzle. Another part was rendered irrelevant by a silly bug in the house - some crucial wooden walls had some wires in them. It's annoying how hard the difference is to see, when you can't see the blueprint...

You have my respect. The person who followed up that robbery by slaughtering my family, however, has only my quite genuine hatred.

#131 Re: Main Forum » Complexity, puzzle families, and the metagame » 2013-06-08 12:13:33

zed

Yes, I see.

If you want this game to be something other than a distributed laboratory for
maximally fiendish level design, then I agree the design needs a radical
overhaul.

In some ways this is a shame. This idea of a puzzle game with competitive
level design is one I've been dreaming of for years. In fact I was a bit
cheesed when I first learnt of this game, since I had finally started work
only a few months before on something remarkably similar - though a game
expressly intended as a puzzle game and nothing more.

Well, I'm still working intermittently on that game, and have used the lessons
I've learnt from studying this one to inform the design. So I don't mind so
much if Castle Doctrine takes a different direction. Whether my game will get
any players at all is another question... The genre "massively multiplayer
puzzle design and solution game" is certainly going to have very niche appeal,
but I think it ought to exist.

#132 Re: Main Forum » Pet movement suggestion » 2013-06-08 10:09:33

zed
jasonrohrer wrote:

It's a bad sign if the game is hinging so much on the nuances of animal movement, I think...  those nuances shouldn't matter as much as they do.

I don't think you can hope for nuances not to matter. A house can always be
designed whose solution will hinge on the precise behaviour in a given
situation.

So I think the best you can do is aim to have the nuances as unsurprising and
easily discovered and learnt as possible.

#133 Main Forum » Complexity, puzzle families, and the metagame » 2013-06-08 10:05:14

zed
Replies: 20
jasonrohrer wrote:

The core problem is that the systems in Castle Doctrine are so general that people can build pretty much
anything with them.  The puzzle space is clearly NP-complete (when generalized on NxN grids instead of
32x32).

I'm sure that's true in the abstract. But 32x32 seems to be small enough to
stop it being feasible to abuse it. I mean, with enough space I could
certainly imagine building a turing machine and requiring the player to press
switches to input an appropriate program, or with less space (but still much
more than 32x32) use similar tricks to make them find a discrete logarithm or
something.

But we certainly haven't seen anything like that, and with current limitations
I doubt that we will (I have my hat ready for eating). If someone actually
managed something like that, I would say they should be congratulated and then
some limit on (say) the number of relays should be added to make sure they
can't do it again.

In fact we've seen nothing that's even slightly complicated, abstractly, in
terms of circuitry. The hardest puzzles have involved pets - and none of it
has actually been theoretically hard, just detailed.

Perhaps it's worth thinking about what makes a puzzle interesting to solve.
Essentially, I would say: solving a puzzle is interesting precisely when it
requires surprising ideas. So the solution must involve some technique that
the solver hasn't seen before, or which it wasn't obvious would apply in this
case. Here we're using human notions of what counts as new and surprising - so
e.g. having to press a column of switches by moving up and down to maneouvre a
column of dogs over them can be interesting only once, even if the initial
conditions or other details of the setup change.

From the point of view of game design, we want to make sure that puzzles which
are hard for the population of solvers to solve are also interesting for them
to solve. So the situation we want to avoid is where there is a family of
puzzles which are identical from the human perspective, but where each one is
nonetheless hard for solvers who have seen the form before, but not solved
that particular incarnation. This is exactly what NP is getting at - although
since the size is bounded it isn't really a matter of complexity classes, just
actual complexity at the largest size you can fit in 32x32.

So we want that for any such family of puzzles, there is a method of solution
which isn't too hard for humans to find, and which doesn't take too much
calculation to apply to any particular instance. e.g. a dog column of the kind
described above is fine - once you've got used to the basic mechanics, it's
easy enough to solve any such puzzle. It's good and healthy that these kinds
of families of puzzles are possible - when they're first discovered, people
using them will have secure houses while the solvers learn to solve them, but
soon enough there'll be a large enough population who can solve them that they
won't be viable security anymore, and the puzzle setters will have to think of
something new.

So I'm not currently convinced that there's any real problem. In particular,
the solution to the "obfuscated magic dance" puzzles people complain about,
where you have to walk around in some bounded area near the entrance to
manipulate distant pets, is just to wait. Players will learn how to solve
those classes of puzzles, so setters will discover that they're not viable,
and will have to move on to something new.

#134 Re: Main Forum » Pet movement suggestion » 2013-06-07 16:10:38

zed
Matrix wrote:

The current implementation uses simple rules already. What you are actually seeing as a problem is a non intuitive result (at least for most players I guess).

Yes. The current system is good - the results are entirely predictable, mostly
intuitive, and fairly easy to calculate.

Matrix wrote:

The update order that you are suggesting ("diamond" outwards clockwise/anticlockwise) is actually more complex than the current implementation, not simpler. If you think about it, puzzles relying heavily on animal movement mechanics wouldn't be any easier to solve with the suggested system, just the movement would look more intuitive to those players who find it unintuitive now. At the same time, those players who actually try to figure out animal movement in order to solve puzzles would have a more complex system to deal with.

I would say it's no more or less complicated, abstractly. It's the same basic
scheme, with some different choices for orderings. I hope it would make the
rules easier to discover without having to read about it in the source or the
forums, and make it easier for humans to predict details of pet movement.

I might be wrong!

#135 Re: Main Forum » Pet movement suggestion » 2013-06-07 06:07:49

zed
dalleck wrote:

I see your suggestion more as a cross-hair than a diamond though, as if a cross is radiating out from the character.

Is this what you mean?

I don't think so. This is what I mean, using increasing numbers then letters
to indicate order of processing:

   g
  h7f
 i826e
j93*15d
 ka4co
  lbn
   m
dalleck wrote:

In addition, dogs should always favour moving forwards first, that is, the direction they are facing.

The problem with using facing is that it's based on your current position
rather than your new position. So it would lead to surprising behaviour like
your moving directly next to a dog which was one square diagonally away from
you, but the dog not moving onto your new position.

#136 Main Forum » Pet movement suggestion » 2013-06-06 23:58:00

zed
Replies: 21

With a game like this, it is important that the full details of the game
mechanics are as easy as possible to discover and reason about.

Currently there are two aspects of the game which are not immediately
transparent: sub-turn power propagation, and pet movement.

This post is about the latter.

The current mechanics in short: pets aim to maximise/minimise their distance
from the player; each turn, pets are processed in order according to current
position, processing row by row from bottom to top, left to right within rows.
When there is a choice, pets rank directions in descending order of
preference as follows: left, right, down, up.

The problem: the asymmetry this leads to, the simplest example being that a
column of dogs will move smoothly downwards but will stutteringly separate out
when ascending, is unintuitive. The result is that predicting pet movement
often becomes a matter of painstaking and error-prone calculation. This means
that puzzles which rely on the details of pet movement can be effective but
unfun.

It's important that the mechanics rely on simple rules, so complicated
solutions involving queuing systems are not a good idea.

I suggest instead the following simply tweak:

Instead of making the order of processing be as described above, reading
across the map from bottom to top, have it be in order of distance from the
(post-move) position of the player.

That's distance in terms of number of moves to get to the square - so
expanding in diamonds out from the player.

Within a diamond, it can still be from bottom to top and left to right,
although perhaps neater would be to have it go round, say, anticlockwise
starting from the square to the right of the player.

(So in other words, I am in short suggesting to enumerate the grid "in polar
co-ordinates" (with the grid metric) rather than the current cartesian ones)

I would suggest that direction preference for tie-breakers also be relative to
the player - e.g. a pet prefers the direction away from player, then the
direction 90 degrees anticlockwise from that, and so on rotating round.

The most obvious results of this: dogs would always flow smoothly towards you,
while cats would always skitter off, separating out. I think this would be
much more intuitive and so more easily learnable.

What do we think?

#137 Re: Main Forum » The Place to Post Your Break-ins » 2013-06-06 11:05:26

zed

Lysergik: sorry, didn't read this thread properly, hadn't seen that you were persisting with a reinforced form of the design. I shouldn't have given even that little hint about how to solve it. To make up for it: I hereby swear on my honour as a thief that I won't solve it myself.

#138 Re: Main Forum » The Place to Post Your Break-ins » 2013-06-06 09:42:05

zed

Ah, nicely done!

That was the best house I've seen so far, by the way. I had figured out how to solve it (without items), but it was going to take hundreds of moves so I thought I'd wait until there was more money in there...

Assuming there isn't some shortcut to solving it itemlessly - I'm amazed you had the patience to go through the self-test, Lysergik!

#139 Main Forum » A use for children » 2013-06-02 13:11:58

zed
Replies: 5

How about this:

If you manage to keep a child alive for (say) a week, they reach adulthood. They are then able to work, bringing in a salary.

That should be fairly easy to implement and enough to make children worth keeping alive (assuming the economy is set up such that extra income is more a benefit than a robber-luring liability, which I think it ought to be).

Optionally, as suggested previously, grown-up children colud also act as extra lives. Or, to keep up the sexism, only sons.

#140 Re: Main Forum » Electronic Devices - Bits and Storage » 2013-06-02 07:58:55

zed
Blip wrote:

That's a pretty useful piece of wiring, zed. I think I just robbed your next house; five-bit binary encoding is nice[...]

That wasn't mine, that was built by the person who robbed my house! Seems they stole my ideas along with my money...

#141 Re: Main Forum » Electronic Devices - Bits and Storage » 2013-06-01 15:35:24

zed

Interesting stuff!

Here's the map I've been waiting all week for someone to crack - today someone
finally did! Congratulations and thanks to whoever that was. (I then tried to
rework it into something more interesting, but died during testing...)

http://castlefortify.com/c/e70285c

It's based around a 3-bit binary counter - that's what's going on along the south wall.

Let me draw out that basic component (a "half adder") in ascii (same notation
as before, with # for a wire bridge):


             +-+-+
pulse in -> -#+v+#-  -> pulse out ("carry")
power in -> +#v+V+
            +v-+

So when a pulse comes in to the left, the state (i.e. whether or not the top
row is powered) flips, and if it was on a pulse comes out on the right.
Chaining them together, you get a counter.

If anyone finds a more compact design, I'd be interested! I had a much neater
design in v5, but it relied on the "bug" that wire bridges triggered switches.

Returning to that map: the stuff in the middle produces a pulse of length
three, and the circuitry in the top left listens for such a pulse and turns
off the trapdoors if it hears it. I'm sure there's plenty of unexplored
potential for that technique.

#142 Re: Main Forum » New players, maps » 2013-05-31 16:12:48

zed

Bringing back unmapped houses could be fun. But I'd be wary of having the criterion for mappedness being under the owner's control. If it's a matter of having a certain amount in the vault, players would be motivated to (i) build the guessing-game-based houses we thought we'd put behind us (ii) log in regularly to sell tools and spend surplus cash. This would be fun for no-one.

I do quite like the suggestion of having maps cost money at first, but becoming common free knowledge once enough people have bought them. You'd need to not have it reset when some small changes are made to the house; maybe if it was free before the edit, a map for an edited house could have an initial cost corresponding to the money spent making the modifications.

#143 Re: Main Forum » Inverted switch bug » 2013-05-31 14:01:31

zed

Oh... good to see a top house fall, but that wasn't mine! Mine's the one with a load of trapdoors just in front of the entrance, and around 140 skulls.

#144 Re: Main Forum » Inverted switch bug » 2013-05-31 13:09:45

zed
jere wrote:

Anyway, someone should solve my house. It shouldn't be hard once you grok the ideas of this thread.

Are you the guy with all the money?

I painstakingly recreated that house (the bottom portion) and then realized memory was involved. Well, damn. That's a little bit more than I was expecting.

Sounds like you're nearly there!

#145 Re: Main Forum » Inverted switch bug » 2013-05-31 09:42:35

zed

Yes, this is in my opinion one of the best features of the game. It allows for some real richness, especially when combined with pets.

It would be nice if the mechanics were more easily discoverable. I recall finding it quite mysterious until I read the source code.

How about animating the switches each turn, so they flash in turn through all states they pass through during propagation, showing the eventual loop twice? That should be enough to give the idea. It would have to be fast enough not to be annoying, and preferably configurable.

Anyway, someone should solve my house. It shouldn't be hard once you grok the ideas of this thread.

#146 Re: Main Forum » Inverted switch bug » 2013-05-31 01:36:13

zed

That's no bug, that's just how electronics works in this game wink

If you think of inverted switches as "not gates", then wiring one into itself is forming a contradiction - the output is on if and only if it is not on. Just as with real electricity and transistors, this leads to strange and cool effects!

Here's how to make sense of it: if you think it through logically, you'll see that the power should be oscillating between two states. In one state the lights are powered, in the other not. The way the game is coded, tiles like lights which need power to activate are only activated if they get continuous, non-oscillating power.

#147 Re: Main Forum » Thought about how to fix "stuck" houses » 2013-05-30 19:05:28

zed

That would certainly make the process of fixing up a house after a robbery
less fiddly and error prone.

It wouldn't on its own be enough to prevent once-robbable houses, though.
It would just be a matter of ensuring that a successful robbery involves a
crucial pet dying to a trap.

You could however reasonably deal with that by making it a requirement of the
self-test that no pets die.

There would still be the possibility of making sure that the *easiest*
solution involves frying a crucial pet - which would likely work because of
the following.

I think any attempt to prevent once-robbability would have to be combined with
a rule that a house can't be robbed twice by the same player. Otherwise, even
with a protected family, anyone who solves your house will be able to take an
arbitrarily large proportion of your savings. That removes the motivation for
keeping any savings at all.

(This rule could be explained explained by the robber not wanting to risk that
he was seen pre-balaclava by some neighbour on his way to the first robbery,
and that they might see him again - and put one and one together and get one.)

Note that this would also do much to address the asymmetry between puzzle
setters and solvers - a puzzle would remain viable after being solved, so each
puzzle setter would serve multiple solvers.

#148 Re: Main Forum » v6 released, and Full world reset happened » 2013-05-29 10:58:10

zed
bey bey wrote:

That setup seems a bit redundant to me the way it's designed since it's always on

Oops! It was buggy. Corrected now, hopefully!

#149 Re: Main Forum » state info text on blueprints » 2013-05-29 10:10:50

zed

...but yes, putting the full info in the tooltips would be fine as a fix, at least for the case of mobiles on traps. Broken walls could do with an extra graphic, I'd say. Not sure about other cases.

#150 Re: Main Forum » state info text on blueprints » 2013-05-29 10:08:27

zed

I think it can be done in an easily repeatable way. Sure, it would involve allowing people to rob you, costing some money, but would then leave you effectively invulnerable.

I suppose I'll have to prove the concept next life!

Board footer

Powered by FluxBB 1.5.10