The Castle Doctrine Forums
Discuss the massively-multiplayer home defense game.
You are not logged in.
- Topics: Active | Unanswered
#51 Re: Main Forum » On sockproofing » 2016-10-07 13:10:12
> On the other hand, I always tried to build with the expectation that
> sockpuppets would come and try to solve my house by guessing numerous times
> (the other meaning of brute force) or document it until they are able to
> reproduce the system and get the tool less solution.
This problem is fixed by "Conservation of Value" and "Robbery Ante". They
prevent sock puppets from being used to rob/scout risk-free. Then, with
appropriate balancing, I expect we would find that 32x32 is plenty. If not,
increasing it would indeed be an option - but I think it would be best to
aim to balance things such that increasing it isn't necessary.
#52 Re: Main Forum » On sockproofing » 2016-10-06 11:57:58
Thanks for replying. You raise some interesting points.
> First, if robbery is happening on the server, might as well make self test
> happen on the server too.
That doesn't help, sadly. The player already knows the complete layout of
their own house, so they can work out a solution without talking to the
server, and then communicate it to the server (pretending to play live).
Adding some random element to the game would change this, e.g. making pet
movement nondeterministic. But that would be open to abuse - you could design
a house which can only be solved e.g. 1/1024 of the time, repeatedly build it
and run the self-test until you luckily succeed, and then have a house which
is nearly immune to robbery.
> Where does the "real" money come from in the first place? Like, starting
> from zero, when the first new account joins the server?
>
> I'm guessing that I missed some aspect of your proposal that addresses where
> money comes from in the first place.
Yes sorry, I skipped over that. I had in mind that at the start, all the money
goes to me! Or perhaps the first few players could get some initial cash -
that would benefit any sock pupeteers among them, but only for that initial
round of account creation.
The initial conditions shouldn't really matter - the money will get spread
around the players during the course of play.
The trickiest point would be deciding on the right level for the amount of
money in the economy... probably the right amount would depend on how many
players you expect to be active, which you wouldn't know in advance. But
assuming everyone trusts the server admin (which they have to anyway),
occasional macroeconomic intervention should be ok - temporarily gifting money
to new accounts if there's too little money in the economy, or destroying the
value of abandoned houses if there's too much.
I guess one possible problem would be if it ever ends up with one player (or
cabal) having *all* the money, and knowing it, and being happy to have broken
the game - then they have no reason to try to rob anyone, so no-one else would
get the money to try to rob them. Hopefully this is unlikely!
> Finally, I want to point out that cheating, though it may have been the main
> stone in your shoe, Zed, and other hardcore players, is NOT the reason the
> game died.
>
> Having everything be "real" in the game means that there's a constant,
> vicious cycle of content destruction.
Point taken. I hope my proposals would actually have the side-effect of
helping with this - a house wouldn't be directly affected when its owner
"dies" in a robbery, and would only be diminished rather than destroyed when
it's successfully wholly robbed.
It's still true that a particular incarnation of a house can only be
successfully robbed once (ignoring wives)... but I don't see that this should
necessarily be a problem - most of the content is still enjoyed by all those
who try but fail to rob it. This does make it important to set the balance
such that successful robberies are rare, though.
Getting the balance right with this new scheme would be tricky, and would
probably require lots of tweaking of prices. One thing I'm not sure about is
what the minimum number of active players would have to be to keep the game
going. If it's more than a handful, I guess it's unlikely to happen now.
> One thing that just came to mind would be to allow one person to build as
> many houses as they wanted, that they themselves couldn't rob.
Well, allowing multiple accounts effectively does that. You can rob another of
your own houses, but all that does is transfer money between the accounts.
This does allow sufficiently dedicated players to contribute more content.
#53 Main Forum » On sockproofing » 2016-10-05 13:18:34
- zed
- Replies: 11
3 years later, and this game and its problems still occupy a portion of my
brain. As an attempt at exorcism, I thought I would try to formulate how I
would redesign it to be cheat-immune. I expected that this would require a
radical overhaul of the mechanics in a way which would turn it into an
entirely different game (basically I expected it to have to end up being
Intricacy). But in fact, repeatedly picking at my incomplete "proofs" that no
better solutions could exist, and making liberal use of miscellaneous
suggestions made by various people in the heyday of these forums, I was
surprised to eventually find a solution which, while still involving radical
changes to the game, I believe preserves its core.
For me, and I think for Jason, the core of the game lies in the nerve-wracking
exploration of a player-designed house, knowing that one false move could lead
to failure with painful permanent consequences - while also knowing that the
risk could be reduced if only you had more money, and that the only reason
you're taking the risk is to get the money you need to reduce risks to
yourself and your family, and while also being aware of the irony that success
would mean imposing on another precisely the likely-fatal destitution you hope
it would help avoid for yourself.
I'll briefly recall the problems with cheating in the current design. Firstly,
the default client restricts the player in ways which aren't forced by the
network protocol - by disallowing undo, and by only showing parts of the map
which have been revealed. So one can easily cheat by using a client without
these restrictions. Secondly, and much harder to deal with, a player with
multiple accounts can use their "sock puppet" secondary accounts to boost
their primary account, in a variety of gamebreaking ways. Probably worst is
that they can use their secondary accounts to do all their robbery, so not
risking their primary account at all. More prosaically, since new spawns start
with cash which can easily be transferred to another player, they can use
their sock puppets to directly enrich their primary account.
Before I get to my proposed solutions, let me explain that as a general
principle, I believe that the correct way to handle cheating is not to fight
it head on, but to roll with it: if some behaviour is considered cheating,
and there's no simple sure way to render it impossible, one should rather
redesign the system to render the behaviour unobjectionable. So I will reject
out of hand any solutions involving obfuscated protocols or attempts to police
the playerbase to root out sockpuppetry. I wish cullman luck if ey still
intends to attempt such solutions, but here I'm considering keeping the game
as free software with variant clients to be encouraged, and dealing with
sock-puppetry by allowing players to have arbitrarily many accounts, but
aiming to ensure they can't be used to give any one of the accounts an
advantage over those using only one account.
-----
With all that in mind, here's what I suggest.
For the problem of the protocol not enforcing fair play, I think it's clear
and well-understood that the only real solution is to change the protocol. So:
(i) Safe Self-Test: No permadeath during self-tests.
(ii) Server-Side Processing: All game logic processing during robberies happens on
the server, with the client sending moves and getting back the new visible map
state.
For the problem of sock puppets, I propose the following:
(iii) Conservation of Value: A steady-state economy - no money is created or
destroyed, only moved around and converted between different forms.
(iv) No Permadeath: "dying" during a robbery doesn't mean losing everything.
(v) Robbery Ante: Attempting a robbery requires wagering some money, lost on
"death".
In game terms, this can mean that in order to attempt a robbery you must
take a special tool which isn't used up, say a backpack; this has a
value and is left behind to be sold (at no discount) if you "die" in the
robbery, though you yourself actually escape.
(vi) Reserves: You must keep a certain "reserve" of cash, say a proportion of
your house value, and may not buy tools or build if doing so would eat into
the reserve. If your cash levels are below the reserve level, you must sell
tools and house tiles to get up to it if you can.
(vii) Hidden Values: The current cash of a player isn't shown to potential
robbers.
Now let me try to show that these are basically inevitable.
(i) and (ii) I think are obviously necessary.
For handling sock-puppets, first let me define a "sock-puppet subgame" to be
what happens when you and your sock-puppets all pretend to be playing the game
properly, but interact only with each other. We must ensure that what an
account does within such a subgame can't advantage it against players outside
it.
(iii) then almost follows immediately: if money is created in the course of
the game, by any mechanism, then it will also be created in a sock-puppet
subgame. So there can't be any sources of money. Technically this doesn't rule
out there being sinks - we could have a purely deflationary economy, with
money continuously disappearing and the value of the remaining money
accordingly increasing... but steady-state seems neater.
For (iv), the problem with permadeath is that it penalises those who don't use
sock puppets, who risk a valuable life rather than that of a disposable sock
puppet.
Without (v), a sock puppeteer could scout houses without risking anything,
which runs counter to the core of the game.
(vi) and (vii), or something much like them, are required to handle an obvious
problem arising from (iii) and (v): if players don't get money when they
spawn, and if they have to get money before they can attempt a robbery, where
are they to get their money from? It has to be from other players attempting
to rob their house. But why would anyone try to rob a starter house, if new
spawns have no money? It must be because starter houses often *do* have money,
and because those with money can't be differentiated from those without.
Without enforcing a reserve, we can expect optimal play, at least at first, to
involve immediately spending any money you get, or indeed transferring it to
another account with better protection. With a reserve, even low value houses
will typically be worth robbing.
(vi) also solves another problem, which is how a player can lose if there's no
permadeath. When you're robbed, you have to rip down much of your house to
refill the reserve; if you keep getting robbed, you'll eventually end up with
no money, and probably no family, which we can call having lost.
-----
This scheme doesn't actually wholly satisfy the criteria I outlined (although
I think it's about the closest possible), because it can still make sense to
run multiple houses, pooling any surplus generated from them. However, in
order to generate any surplus, you'll be having to properly play the game with
each house - using the same house design for each is no good, because others
will quickly recognise this and not take risks in its multiple incarnations,
while robbing all of them as soon as they can rob one. So would-be sock
puppeteers will be contributing to the experience of others by providing
interesting houses. This does have the unfortunate corollary that optimal play
will involve devoting your every waking hour to working on one house design or
another... but then that's probably true with only one house, and it isn't
clear that it would actually make sense to divide your attention between
multiple houses.
-----
Some further suggestions on the details of having a "steady-state economy":
New spawns start with no disposable money, but can design a house with a
certain maximum value.
Tools and building components can be sold for as much as they cost (but
you can never sell below the starting house value).
If you use a tool, its value can't be destroyed; instead, it goes to the
owner of the house if your robbery is unsuccessful, or back to the robber
if successful.
When map tiles are destroyed/killed during a successful robbery, their
cost goes back to the house owner (claiming on building insurance, let's
say). But note that this will typically go to filling up the reserve
rather than straight to rebuilding, so this isn't the same as not having
permanent damage.
One remaining problem: if you can sell tiles from your house at full value,
this lets you freely remodel your house whenever you want, meaning we lose
the richness of houses grown organically as more money becomes available.
Although I wouldn't consider this a core necessary part of the game, it
would certainly be nicer to keep it. Part of a solution could be to say
you can *only* sell tiles after a robbery, while at other times replacing
tiles keeps the value of the old tile available for selling later without
actually having it sold immediately. This isn't a complete solution,
because sock puppets could be used to harmlessly trigger such a sell-off.
This could be dealt with by having a successful robbery impose an extra
permanent penalty on the victim, beyond the theft. Perhaps simplest: the
price you pay for house tiles permanently increases each time you're
robbed (representing increased insurance premiums, perhaps).
About the neighbourhood list:
In place of showing the cash held by a house, the list could show the
value of the house itself, i.e. the sum cost of its tiles. If the reserve
is set as a proportion of this, as seems reasonable, this would still be a
pretty good guide to what's worth robbing.
Houses which have been robbed should be removed from the list until the
owner checks them back in. If they leave it too long, this should be done
automatically (repossessing arbitrary chunks of house until it makes up
the shortfall), to stop money falling out of the economy when a player
goes awol.
-----
Probably there are more details to be worked out, but I have the impression
that with these changes, we would have a cheat-proof game which retains the
spirit of the original.
#54 Re: Main Forum » [Off-topic] Intricacy » 2015-07-06 02:21:21
Thanks to the generosity of one Kevin Eaves, there is now a Mac build up (at
http://mbays.freeshell.org/intricacy/ ).
The game has also undergone a lot of polishing since I last posted here, and
has even had a couple of players. I still think TCD players are the natural
audience, so I hope some of you reading will give it a go! Source and builds
for linux and windows also available from the above link.
#55 Re: Main Forum » [Off-topic] Intricacy » 2015-01-23 14:32:15
Yes, sorry about that... one day I'll get hold of a Mac, and make a build for it. With windows I can use wine to make a build, but with OS X it seems you really do need access to a full installation of the OS.
#56 Re: Main Forum » [Off-topic] Intricacy » 2015-01-20 18:16:54
After some helpful suggestions and exhortations from people on the TIGSource
forums, I've done a load more work on this game recently - primarily in trying
to make the UI more friendly and learnable.
So I thought this might be a good time to post here again. TCD players were
the main audience I had in mind when designing the game. Many of you weren't
here when I first released it, and maybe any old hands still reading who
tried it the first time around, but found the UI too confusing, will find it
more to their liking this time.
That url again:
http://mbays.freeshell.org/intricacy/
. Supports Linux and Windows (and possibly could be coaxed into supporting
other platforms, but I'd need help with that).
#57 Re: Main Forum » The Contest » 2014-01-26 20:10:56
jwg:
> Why did your house suddenly increase in value just before I finally robbed
> it?
Hmm, I think I might have robbed the second-to-top while I was waiting for you
to reappear.
> once I fixed my house up (it was broken after my son was killed)
Aha! That explains some of the oddities I observed... I think I understand how
the house is meant to work now. Very nice.
Good luck with maintaining your position!
#58 Re: Main Forum » The Contest » 2014-01-26 18:27:52
$200,000 of that was from me.
Quite an entertaining chain of events - after realising we were in a Prisoners' Dilemma situation where we were both rich enough to be able to afford to rob the other, and though I would have been perfectly happy to live and let live I knew he'd know that I couldn't know whether he knew that I was of this persuasion, I decided I had to rob him before he robbed me. After taking down a few of the lower top houses to fund the venture (sorry about that!), I started scouting. But between scouting trips, after sinking a fair few tens of thousands into the venture, he must have seen what I was up to and disappeared from the list while he tightened his defences.
I left to get on with my neglected life, and checked my tapes an hour or so later - to find myself cleaned out. I died to a simple trap soon thereafter, and am now finally free from this game! I'm not going to try to claw my way back up.
This was not what I intended to do with my weekend. Great fun, though. It's been great to see that, after all those months of reworkings, this game really is working as intended now. The diversity of designs has been pretty impressive.
I am curious who this Mr. Stewart is... I'm guessing jgw.
#59 Re: Main Forum » Electronics Tutorial? » 2014-01-23 22:02:43
jasonrohrer:
> If something is truly NP-hard, it means that for a problem of size K, there
> is no algorithm that can solve the problem in polynomial time...
Don't suppose you have a proof of that? 
#60 Re: Main Forum » On Cheating via Modded Clients » 2014-01-23 09:37:45
Blip: Jason recently made some changes to the build process to help with this problem. I think we can hope that they'll be enough. Try to connect to the main server with a modded version of the latest release to see what I'm talking about, and read the file 'HowToConnectToMainServer.txt'.
#61 Re: Main Forum » Motivation » 2014-01-19 18:14:13
Jason:
> Essentially, you are observing that if you are poor as dirt in a world of the
> wealthy, you are less of a target.
"The only way to win is not to play", eh?
I do worry that this leads to some thematic dissonance. Since players *do*
want to play, the game discourages them from assigning too much value to
family safety. It encourages them to instead primarily aim to maximise their
wealth, since that's the aim that leads to an interesting game.
Since keeping the family alive is helpful as a means to that end, this perhaps
isn't too much of a problem. It still seems odd though.
But I take the point that now isn't a good time to be making changes to the
fundaments of the game.
#62 Main Forum » Motivation » 2014-01-16 18:39:25
- zed
- Replies: 12
As a non-psychotic player, who doesn't get a kick out of butchering families or leaving them destitute, my motivation when playing this game is to protect my family from the psychotic players I know are out there. I always understood this as the intended motivation.
Since salary was removed, there seems to be a simple winning strategy for this: put your vault by the door, and spend all of your initial $2000 on basic family defence. Optionally, although it doesn't seem necessary, take the odd $1000 from neglected starting houses and spend it all on further improving those defences. Make sure that there are no tricky traps which might kill a newbie - you don't want to get any bounty!
Now your only worry is that someone truly psychotic will bring in a load of tools to your $0 house just to kill your family. But it looks like there aren't any of those at the moment (and yes, I know writing this has probably condemned my family to death at the hands of someone perverse enough to want to prove me wrong on that...).
I'm not sure how best to solve this. One way or another, staying at $0 should be disallowed or punished, rather than strongly encouraged as it seems to be now.
#63 Re: Main Forum » Hardcore Anti-Cheat » 2014-01-08 11:35:36
> But if you just compile the source bundle, you'll find that you can't
> connect to the main server. You have to read the instructions, where it
> explains how to modify the header file with the necessary key value, where
> that key value is something like, "Please don't abuse your power to mod the
> game by giving yourself an unfair advantage."
I like it! I hope it would work.
Maybe also include some description of what would be considered cheating, to
deal with people who might otherwise think "oh, allowing myself to undo a turn
after death isn't *really* cheating, it's just protecting myself from
carelessness" or similar.
#64 Re: Main Forum » Hardcore Anti-Cheat » 2014-01-07 19:47:17
> First of all, it wouldn't stop being an open-source game. It would just be a
> closed key game.
> [...]
> What would change is that you couldn't (easily) build from source and play on
> the main server.
I understand. But that would be a major difference. Do you really want to
discourage people making interface improvements and customisations, and
porting the game to new platforms for you?
> Second, what evidence do you have that everyone has been honorable?
der:
: > How do you know that some people aren't peeking at where the vault is with
: > a modded client?
: I know that they are doing it, I've seen by myself.
OK. Then maybe something has to be done.
> Yes, I've been playing with ram dumps on this end. I've already made some
> progress here (so that at least the text maps don't hang around in ram
> anymore).
With the game logic code as it stands, the map is presumably going to be
loaded into ram every time a turn is processed. Not as text, but as an array,
and I'm sure it wouldn't be too hard to find it. You could try to obfuscate
that too in a way which isn't revealed in the public source... but then that's
going to make the game even further from being open source, and be a pain to
maintain.
I'm sure you've thought of all this, but really this
security-through-obscurity does sound like an all-round bad idea to me. Like
they say.
> Here, there's a pretty compelling reason to ensure that the vast majority of
> people are playing with the same game client on the main server. It's not just
> about protecting robbery.... so many other aspects of the game become slightly
> (or very) unfair if people are playing by different rules. What if you never
> have to die in a self test? Wouldn't that be nice? What if you could run your
> self test with no shrouds?
I guess that will always need some trust. A player can always load the map to
test into a separate client not connected to the server, record a successful
run through, then send that to the server. This could be automated.
#65 Re: Main Forum » Hardcore Anti-Cheat » 2014-01-06 00:18:54
The potential for cheating was something that always worried me about this
game, so it's interesting to see it being addressed. My not-very-helpful
thoughts follow.
Regarding "trusted binaries":
It would be disappointing to see what must currently be one of the most
commercially successful open source games ever lose that status. Meanwhile,
although it would make cheating more difficult, I worry that some might see
that as a challenge to be met. Dumping RAM mid-robbery and finding the map
would be an obvious ploy; another would be to disassemble the binary and
compare it to versions without the magic encryption.
Really, it's a delicate question of psychology. What kind of lock makes your
bike least likely to be stolen? Permit me a strained analogy or three.
In the first alpha releases of the game, where the map was dumped to output
and a debug line was output every time a mobile was triggered, there was no
lock at all and the bike looked abandoned, such that a reasonable person with
some urgent need might borrow it. The current situation is a two-digit
combination lock - anyone who really wants to could break the lock, but it's
clear that doing so would be against the owner's wishes. A "trusted binary"
scheme would be a lock which blares out an obnoxious siren if anyone gets
close, with a rubik's-cube-style puzzle to solve to actually unlock it. It's
begging to be stolen precisely because it's trying so hard not to be.
In other words: one way or another, it comes down to trusting the players not
to cheat. Annoying and alienating the from-source crowd, who are likely to be
among the most tochnically competent, and who as far as I know have so far
been entirely honourable, seems an odd way to go about this.
(To clarify: however this may read, it is by no means intended as a threat!)
Regarding trying to wholly prevent cheating:
Overhauling the architecture to keep hidden information on the server indeed
doesn't really sound worth the work and the latency. And even that wouldn't
eliminate sock puppetry - and, though the situation has been improved by all
the tweaks, and charging real-life money for each puppet obviously helps, I
don't think that problem can be fully solved with the game as it stands.
Possibly interesting if unhelpful remark: the design for my game Intricacy
started out much like CD's, but at some point I decided to try to design it to
be wholly impervious to all kinds of cheating - the eventual design of the
overgame, very different from CD's, seemed like a pretty much inevitable
consequence of that constraint.
#66 Re: Main Forum » [Off-topic] Intricacy » 2013-11-23 07:39:01
Yep, that's the solution I had in mind. Glad to have finally forced you to find it, and pleased that you could but not quickly.
I made TST:B by hacking the client! It was an experiment; I'm considering allowing springs rooted in balls in the next version, but I'm not sure that the resulting physics is intuitive enough. It would allow some cool puzzles though, yes, so I might well do it.
#67 Re: Main Forum » [Off-topic] Intricacy » 2013-11-20 12:57:48
OK. I've no idea how OSX is set up, but somehow you need to install SDL (the C library, version 1.4 (*not* the recently released version 2)) in such a way that the headers and library are available. Then "cabal install SDL" should work. Hopefully.
Edit: actually, it might not be that simple - there's a note on http://www.haskell.org/haskellwiki/SDL that it has problems with OSX...
#68 Re: Main Forum » [Off-topic] Intricacy » 2013-11-20 12:21:38
ukuko: excellent. Does that mean you managed to build it on OS X? Was it painful? Any way I could make it easier? Can I have and distribute the resulting binary?
#69 Re: Main Forum » [Off-topic] Intricacy » 2013-11-19 19:37:54
Argh! Yep, bugs abound... remarkably tricky to ensure there's no easy solution.
You can always view solutions to your own locks.
It took me a while to see how to push stuff up from the se side to the nw side in JWG:B... I'm pleased to see that even this "ice-world-sokoban" fragment of the game is kind of non-trivial (though also non-original).
Anyway, I fixed that bug with cached solutions, along with a few others, and added a couple of little convenience features. New version up at http://mbays.freeshell.org/intricacy/.
#70 Re: Main Forum » [Off-topic] Intricacy » 2013-11-19 17:56:40
That's a bug! The cached solution to the old lock isn't getting overwritten, so it's trying to apply that solution to the new lock, with bizarre effects. I'll fix it in the next version, but for now a workaround is to delete your cache - I'm not sure exactly where it goes on windows, but there should somewhere be a directory in your user settings called something like 'intricacy', and below that a directory called 'cache'. If you delete that directory, the correct solution will be downloaded from the server when you try to view it.
And: no, you found yet another bug in that lock! I've replaced it yet again, with what I believe is a bugless version - and I'm sure enough of that that I've put my solution to JWG:B behind it.
#71 Re: Main Forum » [Off-topic] Intricacy » 2013-11-19 11:04:24
JGW:
> I wish I could watch through your attempts! I guess the ability to undo
> makes being able to watch through failed attempts impractical.
Yes, precisely. And moreover, it would be in the interests of players *not* to
send their failed attempts to the server, since that might highlight bugs in
the lock to the owner. I'm trying to avoid a situation where the official
client isn't the best client from the player's point of view.
Jason:
> Also, people have accused me of making obtuse user interfaces.... but...
> ahem!
Actually, would you mind expanding on that a bit? I know the *game* is
confusing at first, and beyond something as dull as a help page I don't see
much that can be done about that, but the SDL UI was designed to be
accessible (while not getting in the way of experienced players). I'm not
really sure what 'obtuse' means here, but I'll happily hear criticism and/or
suggestions!
#72 Re: Main Forum » [Off-topic] Intricacy » 2013-11-18 21:07:42
Dammit, I'm determined to have you solve that lock the way it's meant to be solved! Hopefully this time it's bugless...
(unlike the game, I've found a fair few little bugs already as a result of this testing!)
Also: I can't solve the new JWG:B!
#73 Re: Main Forum » [Off-topic] Intricacy » 2013-11-18 17:48:01
Hi Jason, thanks for giving it a go, and not objecting to me hijacking your board!
I suppose there should be a reset button. I didn't put one in because I worried the UI was already overloaded, and holding down 'undo' has the same effect, but you're probably right that it should be there.
The button with the hexes alternates between colouring modes - in one, it uses the 5-colouring (sic) theorem to ensure that adjacent pieces get different colours - that's the only way it's playable in curses. The other mode has the colour depending on the number of springs in the shortest chain of springs to a stationary piece.
And I don't know, the UI is as pointed and direct as I could make it. Difficult to puzzle out for a new-comer, of course - but I'm assuming that the kind of people who could possibly enjoy a game like this are also the kind of people who will be happy figuring out on the fly how to play it at all!
#74 Re: Main Forum » [Off-topic] Intricacy » 2013-11-18 08:40:03
Damn, you're good! I hoped ZED:B would last longer... the solution you found
wasn't the intended one, but I'm not sure it was much easier than the intended
one!
I'll try to make one which will stump you when I have time.
If it turns out to be too hard to make sufficiently difficult locks in such a
small space, I can always increase the lock size. But I'd like to see how it
pans out with this size first.
You may be right about the arm graphics. I'll experiment.
You're right about the number being score, I'm glad you could figure this out
- but the reason you're maxing out at +2 is that you only have 2 locks.
Players get a point against you for each of your lock slots they can access -
and if there's no lock, they can trivially access it.
For notes: yes, you need to fill all three. This would happen more often with
a larger player base!
I was going to have it that getting one or two notes gives you hints to the
solution, but that got dropped from the final design. I'm considering bringing
it back. But the only non-gameable hint I can think of is to show the final
solved state, which isn't always much use.
#75 Re: Main Forum » What's Your Dumbest Mistake? » 2013-11-17 09:12:52
Yeah, it was one of those traps that I don't want to give away, but I got my revenge (and my bounty!) so the house is no longer functional. I'll just say it was clever use of clocks and wiring. It is funny how quickly in this game you can go from being dead to having $30k to spend
.
Well someone tripped my trap last night and gave me a 21500 bounty... maybe that was you? Cutting wires had unanticipated effects?