Discuss the massively-multiplayer home defense game.
You are not logged in.
I guess I'd rather not explain these things - if players can't figure them out after playing the game for a while, it's a bug in the ui design. Though it should be easier to figure out with more active players.
ukuko: I'm afraid I can't make an OS X binary myself - it seems you really
need to have a Mac to compile for one. It should be possible to compile it
from source, though.
JWG: Thanks for testing this out! And yes, you have to do a self-test much
like in TCD (but without risking anything). The overgame is a little
complicated - but I'm hoping it's possible to figure it out. It's designed to
be resilient to sock-puppet abuse.
I hope Jason won't mind me abusing his board like this. I'll keep it short.
I have written a game, partially inspired by and significantly informed by The
Castle Doctrine, and I thought this would be a good place to make my first
public announcement and call for testers.
The game is called Intricacy. It is a competitive puzzle-design game:
something like what The Castle Doctrine was for a few weeks with versions 6-8,
before Jason purposefully changed its direction.
I hope some of you will give it a go.
++-+ $: power +V$v+ v: voltage-triggered switch +---V---pulse out---- V: inverted voltage-triggered switch
Ha! So simple once you've found it... makes you wonder how we failed to
stumble on it until now!
So... this brings back the idea of some kind of "looping"
inconsistency sprite for these voltage-triggered switches, to let you know
visually that something is up, and the circuit is oscillating. But it seems
like that would need to apply to doors and other stuff too, which makes the
whole thing messy... I mean, the door is currently settled into "open"... it
is actually open. Like, we've peeked into the box and found where the
particle actually is.
I think it would be neat and informative to have "partially powered" sprites.
That could be slightly-closed doors and trapdoors, dimly glowing grids and
lights, and perhaps some kind of blur effect for the relays. It makes sense
that the traps would act the same when partially powered as when unpowered.
Here is an example clock: http://castledraft.com/editor/YmwWhe
That's brilliant!
For some reason I had convinced myself that a signal generator was impossible.
I'm happy to be proven wrong!
Here's a slightly more compact version of the same design:
++-+ $: power
++V$v+ v: voltage-triggered switch
+V---V---pulse out---- V: inverted voltage-triggered switchRe the game design issues: I'm in multiple minds on this. On one hand, I've
had great fun playing with the electronics, and love how it interacts with the
trap-setting part of the game. On another hand, there are UI issues when an
important part of the game mechanics is not properly represented on-screen. On
a third hand, some source of intricacy (pun will have been intended) wherein
there can be continual innovation is required for the game to avoid
stagnation, and electronics fits that bill nicely. On a fourth hand, it's a
puzzly kind of complexity which is explicitly not what Jason wants.
To combat the UI problem, I'm tempted to suggest that the electronics be
memoryless as in Jason's recent patch, but with a new tile acting as an
explicit exception: a "capacitor" which, if it is powered on one turn, acts as
a power source on the next turn. That way you could still have clocks and
counters and so, but they'll be easier to reason about. (Of course capacitors
don't actually work like this with mains AC electricity, but nevermind!)
If the handgun range were two, wives with shotguns would be genuinely useful - with the right spacing, she could chase even a gun-toter down a corridor. Combined with panic buttons to release well-placed dogs, this could be interesting.
If a family member first sees you as the result of a move which causes the screen to scroll, it seems to get to move immediately. Normally they don't start moving until the next turn.
Presumably this is a bug? I don't know if it's new, but the panic buttons make it particularly nasty - what looks like a safe move might be instakill.
Actually, I wonder whether we won't end up seeing higher-end houses making
clever use of pits to safely demonstrate to a robber that the vault isn't
hidden behind a bitlock. Of course, it's hard to prove that absolutely, given
the constraints of view distance, but you might be able to demonstrate it
enough to convince a robber who thinks he's clever and well-tooled that it's
worth a try.
Should be interesting to see how this develops!
> Essentially, for a long time, I've been trying to trim the building part of
> the game down to thwart "uninteresting" house design, but it turns out that
> uninteresting house design is possible no matter what. So, now I've changed my
> line of attack on that problem through the metagame, and I'm going back and
> reconsidering all the stuff that I trimmed out.
I'd be careful with that. Bounties are a nice idea, but they don't quite
provide the right motivation. There's currently no reason other than cost to
have an accessible vault at the end of your fly trap, rather than having an
uninteresting bitlock-style barrier between the end of the trap and the vault.
If there were some way to prove to the robber that the house is "fair", then
it might work - you'd be motivated to build a "fair" house in order to lure
robbers in to their deaths. But I don't see a neat way to do that. Giving out
partial blueprints, with the owner deciding which bits of the house are shown,
might work - but would be cumbersome.
Jason Rohrer said:
> Yes, I agree that grinding is bad.
>
> It seems like.... almost like.... the money should build up on a house like
> a bounty, but NEVER be available to the owner of that house???
>
> One problem with a bounty that the owner can't get is that you're not really
> stealing from the owner anymore. Taking that bounty doesn't involve taking
> something that the owner wants....
Well, my suggestion about not being able to spend down below a certain amount,
determined by house value, acts a bit like this. It's money which the owner
can't get at but which robbers can, like a bounty - but having it stolen does
hurt the owner.
I'm not sure how to present that mechanic to the player in a non-confusing
way, though.
> Really, the idea of this game is that you get more money to build your house
> by risking your neck robbing others OR trapping others in your house to get
> their dropped tools.
>
> That sounds great and really well-balanced. There is no "grinding" there,
> because the only way to get more money in the game is to play well (either
> as a robber or a house designer).
Right, that would be really interesting if it could be made to work.
But I'm not sure I like being forced to rob or kill to play the game... why
shouldn't I be able to sit tight behind security based on difficult but
safe puzzles, and earn my way with an honest job?
As I understand it, the main motivator in this game is meant to be the desire
to keep your family alive, with larceny and murder of intruders being means to
that end which you may find yourself resorting to. I feel that would change if
they were forced on you so bluntly, by having them be the only source of
income.
I find these days that when I do play, I can't bring myself to rob a player
with a living family - since I know it's only going to bring their deaths
closer. Do you really want to prevent people from playing that way?
Tricky!
> This would be a huge change. Goodness, how many "huge changes" are left
> before this game actually works? This is by far the hardest design that
> I've ever worked on.
I know... It's been fascinating to watch!
> But the idea of "receiving" your salary only when you return to the game...
> that defeats the whole point of salary (which is to make your house worth
> robbing).
Sure, which is why you'd need some other mechanism to keep the house worth
robbing.
Here's what I think is a clinching argument that the current salary system is
problematic:
Currently, it makes sense to log in every hour and spend all your money, even if
you just waste it. That's grinding. So the current system motivates grinding.
I think we agree that that's bad.
> Or taking a house off the list after some short amount of time?
> No, this is a game about getting robbed.
Well it still would be, if the amount of time isn't too short.
> The whole reason salary exists is to give people something to steal.
>
> It is NOT there to give you money to build a better house.
Right, but currently it *does* have that effect - but only for people who log in
to spend it frequently enough.
This game currently has a serious flaw: if you don't log in every few hours
and spend your accumulated cash, you will lose.
I'm sure this wasn't Jason's intention. I think he's stated as much.
The salary mechanic is the obvious culprit. Left alone, the value of the house
rises until it becomes worth someone's while to bruteforce it. So you have to
log in periodically to spend your salary.
The obvious solution would be to pay salary only when you log in. But recall
why the salary mechanic is there - it's precisely to make sure that there's
something to steal. If salary were paid on login, everyone would just make
sure they had $0 in the vault at all times.
So I think we very much need a different way to solve that problem of making
houses worth breaking in to.
I have a suggestion for this, though I'm not sure it's the best one.
I suggest making a distinction between stealable and disposable money. If you
think about it, the immediate effect of being robbed - assuming you're one of
the paranoid maniacs making up the world of CD, who don't believe in banks and
keep all their money in a box behind deathtraps - isn't that you won't be able
to build that trap-ridden extension you were dreaming about, it's that you
won't be able to pay the utility bills or the mortgage. Your next few
paycheques, or a large slice of whatever your wife managed to secrete on her
person, will be going towards dealing with that before you can think about
spending more on building work or tools.
So I suggest having a corresponding mechanic here. I'm not sure how most
clearly to represent it in-game, but in short the rule would be that you can't
buy anything if it would put your cash reserves below a certain value. That
value should depend on the value of the house, i.e. the sum of the costs of
the tiles and mobiles. Scaling linearly sounds fine to me, with the cutoff
being some fixed proportion (1/5?) of the house value.
Salary could then be paid on login. So the effect would be that everyone is
forced to leave some cash in their vault, but that there's no advantage in
logging in every few hours.
But now there's a new problem: it's now in the player's interest to
*avoid* logging in. If you've been robbed to below the cut-off point and then
log in and have your salary paid, you effectively have to leave some of that
salary to robbers.
A second drastic suggestion to deal with that: don't let salary accumulate
while you're away; on logging in, you get at most one paycheque. This isn't
enough on its own, since it would still encourage logging in as soon as the
next paycheque is due. So I suggest it works like this: your next paycheque
becomes due once your house has been robbable for n minutes. At this point,
*your house stops being robbable*, and disappears from the list. When you next
log in (or rather, when you next check out your house), you get the paycheque
and your house becomes robbable for another n minutes.
I suggest n be something like 360, and the paycheques correspondingly be
pretty big.
With these mechanics, there's no incentive to log in any more or less often
than you want to; logging in once a week becomes entirely viable, and
conversely there's no penalty for logging in every few minutes.
Another important effect: it becomes rational to deliberately leave a decent
chunk of money in your house, beyond what you're forced to, assuming your wife
is alive - that way if your vault is robbed once or twice but your wife
survives, you're more likely to have enough left to get back over the
threshold and pay for any repairs.
True... and I like the idea that you could be shot by your own wife even more. But the point remains that it could be a viable but risky component of vault protection. To return to the point of your original post: it should be balanced such that it isn't worth the risk, but preferably such that this isn't immediately obvious (so mechanics really *teach* you to value your family)
Re wives with shotguns: I like that this would give you a risky
vault-protection strategy - put it at the end of a corridor with the wife in
front of it. Sure to work against anyone without a gun (or cutting tools to
get out of her way), but likely to end tragically.
Problem though: she can't really protect the children this way.
Another little, not entirely original, idea that might or might not be worth
considering:
Have an "alarm" tile which, when powered, triggers any family members within,
say, a 5x5 box centred at the alarm to start fleeing. Alternatively, make it
an alarm sign, which causes all family members within line-of-sight to start
fleeing (assuming it wouldn't be too technically awkward to compute LoS
centred at something other than the player).
This wouldn't reduce the need for pitbulls to guard the escape route, but
would at least add a (vulnerable) alternative to thick walls for guarding the sides.
There's a technical problem with using powered doors for this - family members are implemented as just another tile type, so when a family member walks onto a powered door tile, that tile would have to be replaced by the family member. That's mostly why I was suggesting a new tile type for it.
Another idea for diversification of family defence:
Add "locked doors". These can be wrenched open like powered doors, but they
can also be opened by family members. They disappear once opened. There still
have to be clear paths between family members and the exit, but the paths the
family members actually take will allow for taking shortcuts through locked
doors.
Main problem I see with this: it could be used for vault defence, putting the
vault between locked doors so you have to trigger the family to open the
doors. That would be unthematic.
That would be me ![]()
He got careless, fell for a pretty simple "dog released behind you if you go too far in" trap.
(Then someone else broke down all such defences over a series of raids then massacred my family, which made for less entertaining viewing.)
Can I suggest that changes not be saved on reaching an empty vault?
Since family defence has to be based on pitbulls, the current behaviour means that once the vault is accessible, even unsuccessful attempts to reach your family will, if saved, weaken the defences - so it's only a matter of time before they're wholly depleted and your family is butchered.
Nevermind. It's a good change. I say do it, and leave the problem (which I'm fairly sure it will become apparent is a problem) with protecting against careful murderers for later.
Right, I was thinking more about family protection. Once the robber has a corpse to fall back to, if he's careful then the only way to force him to use more guns is to release a pitbull *behind* him, between him and any corpses. The obvious way to do that is to use a pet-based trigger to open a powered door to release a pitbll. This change would make that pretty trivial (and, more importantly, cheap) to foil.
Sounds neat. But I do worry that in combination with other game elements, it
might nerf pet-based traps too far.
Since bricks break windows and kill cats, any cat-based trap can be foiled
just by chucking bricks as soon as the cat is woken up.
The situation isn't much better with dogs - you just have to brick the windows
then let the dog come to you (falling back to a corpse if necessary).
So I'd suggest at least that this be combined with reinforcing the windows to
be impervious to lobbed bricks. I also note that I've never met a cat who
couldn't dodge easily out of the way of a brick...
Even with all that, this change would make protecting families quite a bit
more expensive. But I already suspect that some tweaks should be made (I'm not
sure what) to open up new possibilities for keeping them alive, so maybe that
isn't so much of a problem.
I think this is my favourite so far, from way back in v5:
http://castlefortify.com/c/280fd51
I'll be impressed if anyone can figure out a solution just by staring at it!
No-one even came close in the game... I lost the house to the v6 world reset.
Just got another freeze after hitting '%' to exit. I didn't do anything weird.
I tried to use strace to see what was going on - it looks like it was some sort of lock. 32506 was the main cd process.
$ strace -p 32506
Process 32506 attached - interrupt to quit
futex(0xb5ba3ba8, FUTEX_WAIT, 32513, NULL^C <unfinished ...>
Process 32506 detached
>0<1{10:05:39}~/src/hackings/cd$ strace -p 32513
Process 32513 attached - interrupt to quit
futex(0x8443460, FUTEX_WAIT_PRIVATE, 2, NULL^C <unfinished ...>
Process 32513 detached
I'll try to run the game in gdb from now on, see if I can catch it again.
I've seen occasional hangs on exit, requiring a kill -9.
I'm not sure, but I think in my case it might be triggered by switching to the console immediately after hitting '%'. I can try to track it down further if you like.