Discuss the massively-multiplayer home defense game.
You are not logged in.
Using visual CAPTCHAs is a bad idea actually, it seems they're not that hard
to break these days. Maybe better than a lottery would be a competition: each
time period, a house is generated, and is freely entered by all. The aim is to
get to the vault, spending as little on tools as possible and, as a
tie-breaker, using as few moves as possible. An unlimited supply of tools is
provided for the occasion. Maybe blueprints are too. There's no immediate
reward for getting to the vault, but whoever has the "high score" at the end
of the time period wins the current prize pool.
EDIT: because there's no other way to do it which doesn't benefit
sockpupeteers, in the event of a tie (on both tool cost and moves), *no-one*
wins and the prize rolls over to the next competition.
Since it's ok for tools to be required, the house generation can be pretty
random. One way would be to use an old player house design as a base, then add
some random noise. If done right, the optimisation problem should be too hard
to brute-force.
It's not really thematic to have a competition like this, which suggests an
organised group of robbers... but maybe that shouldn't be so much of a
concern.
Well, they get some loot which might be enough to buy a lockpick.
Another thing: this system actually fits really nicely with reserves: the
reserve can precisely be the petty cash you have to leave on your
table/mantelpiece.
So the remaining problem is the problem of victory, i.e. the case that one
player has all the money. That's how the server starts off, and it might
return to that state occasionally. I wrote earlier in this thread about
"retiring" as a solution to this, and I still don't see anything better.
But that doesn't handle the case of a winner-troll, who actively wants to keep
the system broken - they can do that by refusing to declare that they've won,
using sock puppets to keep the petty cash cleared out from their rich
accounts, and maintaining an illusion of activity to prevent any system which
might try to automatically detect deadlock.
I don't know... do you think this would be a serious problem in practice? It
would need someone to be good at TCD, and yet to be an arse. Far from
impossible, I suppose...
Maybe this does still need one little new mechanism. Any thoughts? I feel
we're close to a complete solution...
Only thing I can think of is to raffle off a small chunk of seed cash each
time period, enough for some basic tools, with tickets bought by filling in a
CAPTCHA (or thematic equivalent, if possible). When the game's functioning
healthily, this would hopefully get little interest (and the prize can roll
over), but it could act as a safety-valve for when it isn't.
EDIT: I think this has to be the best solution. It could entirely replace the
idea of "retiring", and of "abandoned houses". I can imagine it being made
acceptably thematic: you manage to scrounge up enough change to buy a ticket
for the lottery, but you only have a chance of winning if you use your lucky
numbers. These are presented in CAPTCHA form, perhaps visually as images of
visual-recognition-defeatingly crumpled notes, or perhaps using something
along the lines of textcaptcha.com. To disuade people wasting time on it,
you can be told how many tickets have already gone. Now even if someone ends
up with all the money, sooner or later there'll be lottery winners to compete
with.
Here's an idea. Allow robbers to enter houses without any tools. But only
allow them to explore a small part of the house, and to rob only a small
portion of the house's loot.
It could work like this. Have a new fairly cheap tile, a "locked door". Add
lockpicks as a new tool type, which transform a locked door into an ordinary
unlocked door, without using up the lockpicks item. This can replace the
backpack, although you still aren't allowed to take any other tools if you
don't take a lockpick. So you either go in as a "house guest" without any
tools at all, or you go in as a tooled-up robber with at least a lockpick.
Now we introduce a mini-vault, to be optionally placed in addition to the main
vault. I'll call it the 'mantelpiece' for now, but feel free to suggest
something better. The idea is that it's somewhere you'd store some minor
valuables to be shown off to visitors. Or maybe it could just be a 'table',
being somewhere you tend to leave some petty cash. Anyway, this has two
functions. During a robbery, it acts like a vault, and stores a proportion of
the house's loot - say 10%, with the vault and wife then getting 45% a piece.
During self-test, it's how you unlock any locked doors in the house: let's say
it's where you leave the key, so if you walk onto it during a self-test you
pick up a 'key' tool which acts just like a lockpick.
So you don't have to place this mini-vault at all, but then you're allowing
anyone to try to spam-rob their way to your main vault. You can prevent this
by placing locked doors, which can only be passed by those putting up an ante
by bringing a lockpick. But then you have to place a mini-vault, which will be
accessible by "house guests", and as part of the self-test you'll have to
prove that it is indeed toollessly accessible. You're motivated to make this
difficult. So now poor players can try to get a bit of cash by robbing the
rich while posing as friendly neighbours, with this being a player-generated
challenge.
One final necessary adjustment: so far, this scheme seems to be open to the
same kind of abuse we've been worrying about - players can just use their
sock-puppet accounts to clear out the mini-vault as soon as they check their
house in, so no-one else will get a chance. But if we make it that a
proportion of the mini-vault cash is just destroyed when it's robbed, then
players are better off trying to protect it from being stolen at all.
Sadly, this still doesn't quite work for N=2. If you're the only one with
money, you don't care about some of it being destroyed. Reserves mean that a
little petty cash will have to be available from one of your houses, but not
enough for the poor player to get going. But it seems to works for N >= 3, and
really I think that's good enough.
The ante isn't just a technical means to an end, by the way - it's there to replace permadeath, to make sure there's still a game mechanic to punish failure. I see it that as an essential part of the game. I expected you to too!
Oh dear. Good point. The only way I see to deal with that is to allow
simultaneous robbery checkouts, with only the first successful robbery
counting. That's not quite enough, because you could automatedly shuffle your
money between two accounts every few minutes. But that could be dealt with by
having some proportion of the loot from a successful robbery be destroyed
(autoselling tools if necessary). That should work, right?
Got any more nasty attacks like that?
System-wide chills sound nice, but there's a problem: it's to your benefit to
have your house chilled, so you're going to send your sock puppet to die in
your house to trigger the chill. I don't see a way to deal with that.
You're right that I settled for a system which I couldn't see wouldn't work,
rather than a system which I could see would work. I continue to expect it
would work - but it's a complicated dynamical system involving human
psychology, so I think hoping for a watertight proof that it would work is
over-optimistic. As for your argument that it couldn't work - I agree it's a
valid argument under the common game-theoretic assumption of recursive
rationality (or whatever it's called), i.e. that every player is rational and
that every player assumes every player is rational and so on. The problem is
that this assumption isn't actually true!
But I agree that it would be better to have a system which works even with
that assumption, because it's almost true and it's hard to quantify how false
it is. And it would certainly be nice to have a system which doesn't grind to
a halt when there are too few players, if only because it makes it a bit
closer to plausible that it might actually accrue some players!
So here are some thoughts on incorporating your 'seed' idea.
The aim is to ensure that players who might otherwise be locked out from the
main multiplayer game have a way to get into it. It must not be open to
sock-puppet abuse. Theoretically, an opportunity for non-automatable grinding
would work - at the most depressing end of the scale, that could just be
completing CAPTCHAs. We can aim to make it less grindy.
We can imagine developing a map-generation algorithm which would produce
genuinely interesting and challenging houses, which players won't be able to
develop an algorithm to automatically solve. But at least some of the
generated houses must be solvable toollessly, else bankrupt players will be
stuck. So we have to develop an algorithm which will generate a solvable
house, with the generated houses being such that finding a solution given the
house is computationally difficult. Moreover, we want the results to be fun
for a human to solve, so just embedding a large instance of 3-SAT or similar
is out. Meanwhile, we don't want them to be too difficult for humans to solve,
since this is the first part of the game a newbie will engage with. This
sounds like a really hard problem!
An obvious alternative is to make use of old player-designed houses. I think
Frosty's server did this, with a stock of designs (collected from
castledraft?) used by computer-controlled players. But then we have the
problem that players (and their bots) could eventally become familiar with the
designs.
An alternative which doesn't work is to have automated *robbers*, who are
programmed to irrationally try to rob houses they expect to be empty. That
would have the advantage of making players do something useful for their seed
cash - namely designing houses complicated enough that the computer robber
ends up dying in them. But the problem is that any one sufficiently
complicated design could be replicated over a number of puppet accounts, and
then the system ends up being little better than giving out salaries.
I suppose another possibility would be to sell seed cash for real-world
money... but that would be pay-to-win, and horrible.
Here's an amusing idea: players could have to start off as jobbing painters,
making pixel art for moneyed players to buy. If these replace (most of) the
existing paintings, and new ones expire after some time, and rich players are
forced to buy paintings by a house price cap tied to the number of paintings
they own, I can almost imagine this working... but only almost. Could be a fun
supplement to any other solution, though.
Now I'm out of ideas. The only feasible reliable non-abusable system I can see
is to use CAPTCHAs, which would be awful. Help?
> Once it "gets going," with many players, that problem will persist. When
> the N+1 player joins, people willhave no rational reason to rob them, so
> that player will be frozen out of the economy.
Yes, it's entirely crucial that when players see a $2000ish house in the list
they haven't seen before, they have reason to think it might contain enough
money to be worth robbing. I tried to explain how reserves are meant to
achieve this. You seem to be saying it won't work, but I don't see why.
Certainly it won't work with only two players. When a third one joins,
theoretically it could work and they'll get into the game, but it's unlikely.
With sufficiently large numbers I believe it would work; I don't know how
large is sufficiently large, though.
To clarify things, here's the theoretical way it could work when a third
player Bob joins Zed and JR who are in the middle of a pitched robbing war,
with both (due to well-protected wives) having money in the bank. I see the
new name on the list, and think 'pfft, clearly nothing there'. So I go on a
robbing run against you, or work on my house, or even desert the game in
favour of real life for a bit. Then I come back, see the same name on the
list, and think as follows: "Pfft, clearly nothing there. Unless JR went in
there and died, but why would JR do that when there was clearly nothing there?
Unless JR thought that I'd been in, but why would I do that when there was
clearly nothing there? Unless I went in because I thought JR might, but why
would JR think that I thought that JR thought that it might be worth going in
when there was clearly nothing there? Unless... hold on, this logic is getting
a bit complicated. Do I really trust JR to think through this logic
accurately? Hmm hold on, without that trust, it isn't logical at all... does
*JR* really trust *me* to think that logically? When it's only logical under
assumptions which are seeming rapidly untenable? OK, I'm only risking $500,
I'll go in and have a look. Pfft, that commit trap doesn't work, look I can
just... oh right, yeah. Oops."
Well the problem you're identifying there is that having one player with all
the money is a fixed point of the dynamical system - that state will persist
until it's given a kick by an external force. That can be done hackily through
gifting, or in a more principled way as with the 'abandoned houses' scheme.
But the interesting question is what happens once you've done that, and you
have (one way or another) got into a situation where the cash is distributed
among many players. When I'm considering whether the system works or not, it's
what happens then that I have in mind. Part of it "working" is that the system
rarely gets trapped again in a dead fixed point state - probably more could be
done to discourage that, but still it will happen sometimes - hence the need
for some automated system to kick it back out.
There should be no "gifting". That wasn't an intended part of the system, that
was just a hack to get it up and running. There is the problem that this could
be required more than once, due to fluctuations in activity or to "winning".
The abandoned/retired houses scheme described above is meant to replace the
need for admin involvement in such cases - if the server goes through a
dormant phase and then some people start playing again, they'll be able to get
cash by toollessly robbing the abandoned houses left from the last period of
activity. So actually that's a bit like your "seed" houses, but
player-generated.
Being able to explore a house without wagering anything is just as bad as
being able to rob it - you send in your sock puppet(s) to find the route to
the vault, then go in with your real account to clear it out.
I don't see your inductive argument - could you explain the step from n to n+1?
Computer generated seed houses are an interesting idea, and I don't see why
they couldn't work in principle. You're right that it's a hole in the argument
I gave for having no sources in the economy. Designing a house generator could
be fun. Still, I feel it's a crucial element of the game that the houses are
designed by humans, so I think it's worth fully exploring those parts of the
design space which keep that feature before abandoning it.
I continue to think that the solution I've implemented should work, perhaps
after some rebalancing and some tweaks of the kind discussed earlier in this
thread.
The idea is certainly *not* that Zed's house has some special role as the root
of all things. That's just an initial bootstrapping phase. The intention is to
have the system be self-sufficient, once it gets going.
Here's the thinking behind the backpacks and the reserves.
Players must not be allowed to rob the house of an active player without
risking anything. I'm basically taking that as an axiom, part of what the game
is meant to be. Permadeath may not be a necessary part of it, but I think
permafailure is. So that's where the backpacks come in - a minimal wager /
buy-in.
However, there can be no player-controlled sources of money, so in particular
new players must start with nothing. So how do players get hold of a backpack
so they can start robbing? By others attempting to rob their starter house,
but "dying" and leaving behind the backpack (and maybe tools) they came with.
But why would anyone try to rob a starter house? They need some reason to
think there might be a prize that's worth risking the price of a backpack to
reach. A self-referential answer would be: because they think others might
have tried to rob it, and left behind their tools, which the owner is yet to
have sold and sunk into the house. That almost could be enough in itself, if
players (rationally?) don't trust the rationality of their fellow players...
but I think there needs to be a simple rational reason to get it going.
Reserves, along with not displaying the loot value of a house, are meant to
provide that: when you rob a $2000ish house, as long as you're not unlucky
enough to be robbing a genuinely new house, or one which has already been
successfully robbed, there's sure to be a prize pool there which could be
worth a punt. Currently the numbers are a $200 reserve on a fresh $2000 house,
and $500 purchase value for a backpack (sale value of $400). Does it make
sense to risk $500 for a possibility of $200? Given that you can control how
much actual risk you put yourself in through careful play, I think many
players would consider it worth the risk. Then when I consider that many of
those players wouldn't be as good as they think they are, and would have
accidentally died, even someone as risk averse as me might consider all the
tools those others might have left in the vault and think it worth the risk
too.
That's the idea. Obviously it's predicated on the fantasy of an active server
with a decent number of players. I don't know how many it would need... I'd
guess a minimum of around 6.
Some thoughts on solving the problem of "victory" - that is, one player ending
up with all the money.
The first problem is how even to detect it, given that the money may be
distributed across multiple accounts owned by the same player. For this, I'm
thinking it could work to make it an *explicit* victory condition which
players are encouraged to aim for. That could be done just by showing players
how close they are to the goal - if an account has a significant proportion of
the total cash in the economy, then when showing them their balance, show it
along with the total, e.g. as "$33423/$100000". This should encourage them to
get it to the maximum if they can. Then, replace the 'suicide' button with a
'retire' button.
If a player retires, they can get some sort of "you have won" message, and
then the problem is how to distribute their money to other players. I don't
think there's any neat solution to that; here's my less-than-neat solution.
Once a player retires their house becomes 'abandoned'. Abandoned houses can
only be entered without a backpack, can only be entered toollessly, and
multiple simultaneous checkouts are allowed. On becoming abandoned, the family
moves out and the wife loot is transferred to the vault. Moreover, some/all of
the vault cash is randomly scattered around the house (placed on the path of
the self-test solution) in the form of "mini-vaults" - implemented as an
overlay rather than a tile or a mobile, lest they interfere with the operation
of the house's traps. The first to reach a mini-vault gets a proportion of the
house's vault cash, and it's then deleted from subsequent checkouts. The house
layout is not saved on successful robbery, even of the main vault.
The idea is that players will race to explore the house toollessly, working
out piece-by-piece the original solution, and being rewarded as they manage to
explore more of the house.
Of course the original owner, now playing from a fresh start, could go in and
clear out their old house... but hopefully the futility of that will quickly
become apparent!
Retired houses can be marked as such in the house list, and shown with the
amount of loot left in them. So once they're cleared out, they can remain
permanently at the bottom of the list for people to have fun trying to beat
toollessly - having your house preserved in this way is the reward for
"winning".
The mechanism can be adapted to handle the related problem that all the cash
in the game could end up in the hands of players who've stopped actually
playing the game - after N days of absence, a player's house could become
'abandoned' with similar effects to the above, but with tool use allowed and
with the house deleted from the list once cleared out. It's still important
not to save damage, lest that leave the house in an unsolvable state.
With these changes implemented, it looks like the game could once again be
maintenance-free for the server operator. Maybe I'll have a go at implementing
it if I get bored some time...
Isn't that always the way? For now I've just hand-reset the total cash to 10000, and will give out small grants to any other genuine humans who want to give this version of the game a go.
As a lure to them - it seems Jason has left a genuine Rohrer Original on the server! I explored it a little, enough to see that there's quite a bit to it, but spending more than $2000 on scouting felt like cheating.
Yep, you've quite thoroughly won!
I don't know what should be done in such a situation... I can't see a way to redistribute your wealth which wouldn't advantage sock puppeteers.
As it is, there's still one thing I can do, which I probably will just because I want to see your fortress: I can edit the database to gift myself some of your money.
Anyway, I guess we've learnt that $100000 is far too big an economy when there are only two players. It could automatically scale to the number of active players; that's gameable, Sybil attacking yet again, but maybe it wouldn't matter too much.
Anyway, thanks for playing!
Well I guess I could have cheated... but actually I just observed. The timing mechanism was in plain view. Terribly sporting of you.
Yes, I was worried about it feeling unresponsive if nothing happened when you pressed a key. The arrow is a good idea though, that could work.
"Someone else is in that house" is the error message it gives, due to my inexcusable laziness, if the headless server doesn't respond. So I guess that's probably a bug, sorry!
EDIT: But actually, I checked my logs, and it doesn't seem to have been the headless server misbehaving. So I don't have an explanation.
Yes, initial houses have to be able to kill... I haven't done any rebalancing of costs, I don't know if that would be necessary.
The house list shows only the money sunk into the house itself, not what's in the vault.
Value is destroyed, and the periodic rescaling of the economy is in place. The "steady state" thing was a blind alley.
And yes, I gave you 25 backpacks, and you repaid my generosity by robbing me blind ;)
So how playable is it from across the ocean?
The red -200 should be the reserve you're forced to leave in your house for others to rob.
There's no elegant mechanism for bootstrapping implemented - currently I have all the money! If you leave your house checked in, I'll suicide in there to give you some.
No real activity thus far.
Hi Cullman. Yes, feel free to use the modified headless client. Although
there's no copyleft licence to require it, I would appreciate it if you made
public any improvements you might make to it which aren't specific to TH.
I'm not interested in working on TH directly, but thanks for the offer!
Good luck with the project.
I've implemented the ideas in the "sockproofing" thread, and have set up a
server.
The intention is to adapt the game to make cheating impossible, while
preserving as much as possible of the core of the original.
In short: robberies take place on the server, so map hack and undo cheats are
impossible. Then there are a variety of changes to make it unproblematic for
players to have multiple accounts. The most dramatic changes to keep in mind
are:
* The initial $2000 is for building only; any leftover will disappear once
you've designed your initial house.
* In order to go robbing, you need to equip a "backpack", a new tool at
the start of the tool list.
* If you "die" while robbing, you only lose your tools (backpack
included), not your life or house.
* If you "die" during self-test, there's no consequence at all. You can
just try again. You can still be ashamed.
It would be great if people tested it out. To do so, please go to
http://thegonz.net/~tcd/
and register.
You'll need to obtain the modified client - you can find a windows build from
the above link, and instructions for obtaining the source.
Once on the server, you're very welcome to try to cheat. You should fail.
You can also just try to play the game properly. You should succeed.
cullman:
> - 100% server side play (the client is just a dumb interface).
Actually I've just finished a first stab at this.
Branch 'serverSideProcessing' at gitlab.com/zugz/tcd/ .
EDIT: polished it off a bit; could do with thorough testing, but as far as I
can tell it works fine.
It's using an expanded threaded version of the "headless client".
I'm keeping to Jason's "no copyright" public domain policy for this work, so
feel free to make use of this for TH.
I realised that the "one remaining problem" with "Conservation of Value" which
I mentioned in my original post is more serious than I thought. Conservation
of Value implies you must be able to sell off the contents of your house,
getting back what you put into it. But then you can effectively remodel your
house at any time, by performing such a sale and transferring the money to a
fresh account. It's possible to make this annoying to perform, but not to
prevent it.
I think this is enough of a problem to make it worth ditching "Conservation of
Value". Luckily there was a get-out clause in the justification I gave for it
- it's actually ok to have sinks in the economy, you just can't have sources.
So we can retain the current phenomenon that money spent on a house can never
be reclaimed.
The consequence is that we have a deflationary economy - money gets scarcer
over time, and hence more valuable. Rather than representing this literally by
reducing prices exponentially over time, which would quickly get ridiculous,
we can instead intermittently simultaneously rescale everyone's cash reserves,
multiplying the money in each vault by the same number, so as to make the sum
a fixed constant (say $100000). This should probably be done at random times
(Poissonically) to stop it being gamed, say on average once per day.
Although it isn't actually historically accurate, having a deflationary
economy actually feels quite in keeping with the game's theme... it finally
gives a reason for everyone to be hiding their money at home rather than in a
bank!
It also gives players a clear reason to keep money in their vaults - if they
can just hold on to it, it'll grow in value over time. EDIT: sadly this isn't
enough to mean we can do away with Reserves - it doesn't matter which of your
houses you store your money in, so you're motivated to store it in your best
protected house. Then without reserves, it would make sense to maintain a pool
of empty-vault starter houses on sock-puppet accounts, which feed anything
they make to one main account. So we still need reserves.
So although it would take some experimentation to see if it really works,
here's an updated proposal:
Keep safe self-tests, server-side processing, costly backpacks in place of
permadeath, listing the cost of a house rather than its contents, reserves,
the "loan"/"voucher" for new spawns in place of actual money; but forget the
rest of (iii), replacing with:
(iii') Deflationary Economy: money in players' vaults is frequently revalued,
i.e. globally rescaled to keep the sum constant.
Would anyone actually be interested in testing this scheme? I think I wouldn't
mind doing the necessary coding work, then I could run a test server on my
computer.
> Wouldn't it be better to make simple changes in order to try to preserve the
> current nature of the game? The 2000 at the start would be better if it was
> a loan and that only 1/4 of that loan would show up in your vault.
> [...]
> Adding starter loans to the game would preserve everything about the game
> and mitigate the side effects significantly.
Well I'm working here from the assumption that players can get as many
accounts as they want. Then this kind of mitigation doesn't help at all - even
the smallest advantage can be magnified arbitrarily.
It's true that on the main server, this assumption isn't quite right, because
players have to give Jason money for each account. But that wouldn't be true
on a third-party server.
As for preserving the current nature of the game - see my next post, which I
think gets us much closer to that!
What version of PHP are you using? The server code is written for an old
version, and is broken in a few ways for more recent versions. I've just
edited it to work with PHP 7; I can send you the diffs if you think that might
be the problem.
In particular, if the ticketserver gives any "deprecated" warnings, that'll
confuse the server. s/\<mysql_/@mysql_/g is a hacky way to quickly handle
that.