Discuss the massively-multiplayer home defense game.
You are not logged in.
Ok, I can see know that tool dumping on a successful vault robbery allows for extra finesse when swapping tools and the ability to feed a dummy account a small amount of tools to add to their starting $2000 could be quite powerful for taking out a large number of houses that are designed to resist the $2000 starting cash.
From my experience top houses have been happy to save up until they have enough money to have a crack at another top house and spend it all. The ability to then give all of these tools to a second account so that the top house never has to risk its own neck is a big problem. When a starter account comes into your house with $32,000 worth of tools you feel cheated, especially if it is after numerous suicidal house scouts by the same player. The fact that doing this will clear out at least half of the players safe house cash will not stop them from doing this. It would be great if there was some kind of solution.
I can see why exploit detection is something you want to avoid but it is possible you could do it to some extend without too much effort on your behalf to weed out the worst offenders. The simplest way would be to track how much each account is feeding each other account and also check to see which accounts regularly use the same IP address to access the server. If accounts that share IP addresses feed each other more than everyone else then have a look at specific activity and if any standard exploit behaviour is happening block the accounts from seeing each other. This won't catch every case of exploitation (especially those who read this kind of thing in the forums) but I would wager it would cull the majority and require very little effort (how many accounts will regularly use the same IP address and keep feeding each other will turn out not to be exploiting?).
Offline
On the other hand, I really like the freedom players have to scorch another player's earth with repeated visits (and a tape list filled with one name that clearly is asking for revenge). And the threat of that, after the first breach, makes a homeowner all that more nervous. I don't want to change the game in a way that is "kinder" to the homeowner. Also, I want to allow quick, back and forth revenge cycles, etc.
Its funny you say that, because this is the 2nd time today that Ive gotten my revenge on an account thats most likely being boosted. Their response both times? completely take themselves out of the neighborhood list by staying in build mode while having their dummy account feed them money for hours on end. Any scorched earth policy i have is checked by this combination of exploits. So that police cool down might be a good idea, if there is no other way to check such an exploit.
Last edited by awesomebill (2013-10-29 18:14:11)
Offline
Josh — I think the biggest problem with detecting that kind of behaviour is that it's largely indistinguishable from legit behaviour. Many times I've robbed a wealthy house and then spent the money on taking out someone else, or even just dumped it in tools in a random house before logging off.
Offline
Yes, I agree that a lot of the time it won't be obvious, but I think that there are times when it is and this is where you can have an effect. For instance, you would at least be using a different IP address than the account you robbed. Also, I'm sure you either a) scouted the first house or spent some time walking around to figure it out or b) brought some tools along to help. The naive dual account abuser will do neither of these things, they'll simply solve it as if it was a self test. Also, random tool dumping will look quite different to regular tool dumping into the same account. Yes in the case of isolated instances it might be impossible to decide whether it is dual account exploitation, but sustained dumping over time should be fairly obvious.
As I stated above I think the combination of IP address doubling and sustained dumping/feeding will be enough to weed out most real exploiters although it won't necessarily get all of them. If the only punishment is that the linked accounts never see each other than a false positive under these restricted circumstances won't be too bad a consequence.
Last edited by joshwithguitar (2013-10-30 00:43:00)
Offline
Josh, I don't think you were here back in the "major exploit" days when people were modding their clients to allow them to walk through walls, etc.
My original policy was to threaten people with account loss for doing this. The problem is that it hinges on me as an admin to investigate each case. This turned out to be an endless nightmare and timesink for me.
Eventually, I bit the bullet and implemented server-side robbery simulation (the server runs a headless version of the client, and feeds every robbery move list to that headless client to make sure the client agrees with the robbery outcome submitted by the player).
What you're suggesting seems like it would involve some kind of manual intervention.... where accounts might be flagged as suspicious. I mean, I can't just automatically block accounts from seeing each other forever based on a heuristic. Imagine if that happened to you accidentally, which meant that you would NEVER be able to see the top house on the list that everyone in the forums was talking about...
And the IP address thing really doesn't help. All it would take would be two people playing in the same office or even same Starbucks to trigger a false positive.
Even if I could come up with a really good heuristic for flagging accounts for investigation.... well, I simply don't want to be tied to moderating this game manually forever. I've made 17 games. At some point, I will need to make game 18.
The server-side simulator is a great example of something that has essentially been working and running itself for many months now. The issue of client mods vanished quietly because of it.
Anyway, by going down the "auto-detection" route, we'll become blinded the the possibility of other solutions to the problem that are more oblique (cool inventions like chills, etc.)
A "forced ignore" is now in place (to be released soon) after someone you rob dies, to prevent you from seeing their next lives' houses for an hour. This deals with farming a second account for starting money repeatedly.
Going back to the idea of police blocking a house from you after you rob it.... I'm a little mentally fried right now. Can someone spell it out for me in terms of how it would help with the final issue? Robbing the main house with the dummy account is now the only way for the dummy to get tools from the main house. So, the dummy does this, and then is blocked by police for one hour. But then the dummy uses the tools to rob the target house, getting the target loot.... and then the main house robs the dummy to get the target loot. Now the main house is blocked from robbing the dummy (by police) for one hour.
So... are we saying that we could just slow this tool sharing down to once per hour? But with all the planning and scouting that would have to go into such a robbery anyway, limiting it to once an hour isn't much of a hurdle (you'd spend at least an hour plotting out the next one anyway). AND, it would have a huge cost (limiting back-and-forth revenge cycles, limiting legit multi-visit robberies).
Offline
Going back to the idea of police blocking a house from you after you rob it.... I'm a little mentally fried right now. Can someone spell it out for me in terms of how it would help with the final issue?
I think this was to stop people from using a second account to pump up the bounty on the first.
Offline
I should add that in my opinion these issues will be relatively minor when the game is rolling with a large player base.
Even this last week my house has several times acquired ~$15000 in bounties within an hour, and usually stolen before I log back in. That's several legit instances where a player could turn up at your house with $15000 of tools out of nowhere.
Offline
Well.... with what I'm putting in place now (house force-ignored by you for a while if the owner respawns), you're already limited in your ability to build up bounties on yourself by committing crimes in a dummy house, right?
Go in, kill 3 people and hit the vault. The bounty on your is now $4k.
But then when the dummy suicides to get a new family and new vault, their house is invisible to you for 1 hour (in what I'm about to release). So, there's potential bounty-building waiting there, but you can't touch it for 1 hour. Same for the respawned player's starting cash. Note that the force-ignore ONLY affects players who have robbed the respawned player during the respawned player's previous lives.
So, I think these problems are now solved (in that, I have a knob I can turn at any time to make the exploit as inconvenient as I want to make it by increasing timeout):
--Robbing a respawned dummy account for starting cash (force-ignore on respawn).
--Robbing a respawned dummy account to build up a bounty on yourself for whatever reason (force-ignore on respawn).
--Dumping starter tools from a dummy account into a main account (chills)
--Dumping starting bounty ($500) from a dummy account into a main account (chills)
The "final problem" that I'm talking about is the ability of a main account to "feed" tools and money to a second account (by "letting" the second account rob the main account), thus letting a second account become powerful unfairly to commit a risky robbery. So far, that problem has not been address, and I don't see how the "police blocking" idea solves this particular problem.
One other problem that I just thought of:
--Rob dummy account's vault, your bounty goes up by $500.
--Have dummy do minor edit, 50% of remaining money goes back into vault, making it robbable again.
--Repeat Log2( 2000 ) times.
The police blocking would fix this, but I don't think it's necessary... could just have bounty go up on *first* vault reach in a given house.
Offline
The police blocking would fix this, but I don't think it's necessary... could just have bounty go up on *first* vault reach in a given house..
I think the police blocking would be a better fix, otherwise your bounty only goes up once per the lifetime of a house.
Some houses change many times and hang around for weeks. It seems a shame to cut all of that to-and-fro out of the economy.
Last edited by ukuko (2013-10-30 12:45:16)
Offline
Well, I could also have the bounty increment for vault-reaches in a given house just have a silent one-hour cooldown period (adjustable time, just like everything else).
I agree... if an owner comes back and fixes up a house for real, and you breach to the vault again, that is a new crime on your part and should be matched with a bounty increase. I mean, especially if this happens next week or whatever.
Offline
Okay, I've fixed it (in unreleased version) to work this way. Your bounty only goes up for vault reaches in a given house once per hour. If you keep pegging the same dummy-house vault over and over, your bounty will stop going up.
Offline
Josh, I don't think you were here back in the "major exploit" days when people were modding their clients to allow them to walk through walls, etc.
My original policy was to threaten people with account loss for doing this. The problem is that it hinges on me as an admin to investigate each case. This turned out to be an endless nightmare and timesink for me.
Eventually, I bit the bullet and implemented server-side robbery simulation (the server runs a headless version of the client, and feeds every robbery move list to that headless client to make sure the client agrees with the robbery outcome submitted by the player).
What you're suggesting seems like it would involve some kind of manual intervention.... where accounts might be flagged as suspicious. I mean, I can't just automatically block accounts from seeing each other forever based on a heuristic. Imagine if that happened to you accidentally, which meant that you would NEVER be able to see the top house on the list that everyone in the forums was talking about...
And the IP address thing really doesn't help. All it would take would be two people playing in the same office or even same Starbucks to trigger a false positive.
Even if I could come up with a really good heuristic for flagging accounts for investigation.... well, I simply don't want to be tied to moderating this game manually forever. I've made 17 games. At some point, I will need to make game 18.
The server-side simulator is a great example of something that has essentially been working and running itself for many months now. The issue of client mods vanished quietly because of it.
Anyway, by going down the "auto-detection" route, we'll become blinded the the possibility of other solutions to the problem that are more oblique (cool inventions like chills, etc.)
A "forced ignore" is now in place (to be released soon) after someone you rob dies, to prevent you from seeing their next lives' houses for an hour. This deals with farming a second account for starting money repeatedly.
No, I wasn't around when major exploits were around and I completely agree that you should try your hardest to find non-intervention workarounds to exploits. I think what you have already come up with over the past few days will go a long way to fixing multi-account abuse.
I am worried about the "final problem" though as it looks identical to normal, encouraged behaviour - that is people will and should be able to break into one house, steal the money and then spend it on tools to raid another house. Because of this I think it might be impossible to find any "cool" interventions to stop this one. And when the top houses all have dummy accounts that help them lord it over the lower houses risk free it will be a major issue, although whether this will happen remains to be seen.
One last suggestion. Implement multi-client detection so that if one client detects that a second account is running on the same computer using a different account it silently reports this to the server which will then block the accounts from each other. This is an "auto-detect" method for which it is hard to think up cases of false positives and would probably catch the majority of exploiters as long as it wasn't broadcast that this occurred. Yes, there is a good chance that people who use dual accounts in a non-exploitative way will be blocked from robbing their own accounts, but this is not a bad thing.
Offline
Hmmm.... so.... how would this work?
I guess clients could try opening a connection to localhost on some port, and see if another client on the same computer is listening for a connection....
The problem with this is that I think that Windows Firewall generally blocks applications from opening server ports like this, or at least throws up a warning about it (or maybe blocks it silently, depending on how Firewall is set). I'm pretty sure the block happens at a low level, which means that even local (intra-computer) requests would be blocked.
Also, anyone who really wanted to do this would work around it by running two clients on separate computers.
One more thing that I forgot to mention: for the Steam version, accounts will be tied to unique Steam accounts (just like accounts now are tied to unique email addresses). It's pretty easy to get a second email address. I don't think it's so easy to have two Steam accounts. Granted, someone could just come over to the website and buy a second account there.
Finally, this isn't as big of a problem as the other exploit problems, because it doesn't allow someone to get "free money" in a skill-free way. They would STILL have to figure out how to rob a target house, and still be subject to chills while doing that (albeit chills on the dummy account). They would be sparing themselves the stress and tension of committing robbery when they have a lot to lose.... but their house would still be just as vulnerable to robbery as anyone else's, and all of the money they had would be earned through their own skill, just like everyone else.
And regardless of what we do, there is NOTHING to stop information sharing between accounts... scouting with one account, and using that gained knowledge in another account. People could even collaborate via forums to do this, sharing bits of the house map that they have discovered, etc. So, there will ALWAYS be some advantage to a second account, even if we magically completely block resource sharing between the two accounts (because the second account can be used for extra scouting).
Point is, the final problem is a kind of meta-advantage, not a pure, resource-gaining advantage.
Offline
I'm sure there must be lots of ways for programs to communicate, here is a page I found listing a number of ways to do it in windows: http://msdn.microsoft.com/en-us/library … s.85).aspx
Sure, it would be easy to work around but the hope would be that most people trying wouldn't know this was going to happen. After trying once and finding that they cannot access the second house I imagine they will be reluctant to fork out another $16 to see if they can work around whatever measures you've put in place.
I just think that if putting such a thing in place was not too much a hassle it could be positive and come with no real down side.
Offline
Here's an idea. The other player's names are generated based on each player's key.
So, you cannot share the name of the house with another player or account, because your name for B is not the same as your friend's name for player B. The only correlation is the amount of cash.
Or just completely random each server query:
Change line 4948 in server.php from:
$character_name = mysql_result( $result, $i, "character_name" );
to:
$character_name = cd_pickFullName();
Last edited by smilingrob (2014-01-31 22:32:25)
Offline
Well, the point is, there is literally nothing I can do about it!
I can't track IP addresses, because that would mean two people playing from behind the same NAT (one shared external address) would block each other. And even if I did that, people could play the game through a proxy or TOR or other means to give their second account a second address.
All I can do is make it a pain to use a second account. Chills help somewhat with this (can't keep using suicide to pass money between accounts more than once per hour). The timeout before a new house shows up on the house list also helps.
And, with more players, figuring out the name on your second account will be much harder (and I'm fixing the protocol to hide the user ID form the house list---I just noticed this).
Maybe get it with HWID, where server checks if the current HWID is used for another The Castle Doctrine existence, the other ones will be disconnected.
and make sure the program doesn't run at VMs.
Offline
Ok here's some better code for unique names for each of the other player's names, that are still consistent. So you can do revenge.
This makes it "impossible" for people to lan hack, or multi-account hack based on the character name, but it still lets them hack based on the money, so it just makes things more difficult.
in cd_listHouses around 4961 instead of
$house_user_id = mysql_result( $result, $i, "user_id" );
$character_name = mysql_result( $result, $i, "character_name" );
do something like
$house_user_id = mysql_result( $result, $i, "user_id" );
$character_name = mysql_result( $result, $i, "character_name" );
$seedRand = crc32( $user_id . " ". $house_user_id . " " . $character_name);
$character_name = cd_pickFullName( $seedRand );
and then bubble that $seedRand up into the actual random like this:
function cd_pickName( $inTableName, $seedRand = null ) {
global $tableNamePrefix;
$tableName = $tableNamePrefix . $inTableName;
if ($seedRand === null) {
// get a rand from MySQL
$query = "SELECT FLOOR( RAND() * MAX( cumulative_count) ) FROM ".
$tableName .";";
} else {
// rand seed passed in, potentially different for every player player combo.
mt_srand($seedRand);
$rand = floatval(mt_rand(1, 1000000)) / 1000000.0;
$query = "SELECT FLOOR( $rand * MAX( cumulative_count) ) FROM ".
$tableName .";";
}
$result = cd_queryDatabase( $query );
$cumulativeTarget = mysql_result( $result, 0, 0 );
...
Last edited by smilingrob (2014-01-31 23:55:19)
Offline
Ok here's some better code for unique names for each of the other player's names, that are still consistent. So you can do revenge.
This makes it "impossible" for people to lan hack, or multi-account hack based on the character name, but it still lets them hack based on the money, so it just makes things more difficult.
in cd_listHouses around 4961 instead of
$house_user_id = mysql_result( $result, $i, "user_id" ); $character_name = mysql_result( $result, $i, "character_name" );
do something like
$house_user_id = mysql_result( $result, $i, "user_id" ); $character_name = mysql_result( $result, $i, "character_name" ); $seedRand = crc32( $user_id . " ". $house_user_id . " " . $character_name); $character_name = cd_pickFullName( $seedRand );
and then bubble that $seedRand up into the actual random like this:
function cd_pickName( $inTableName, $seedRand = null ) { global $tableNamePrefix; $tableName = $tableNamePrefix . $inTableName; if ($seedRand === null) { // get a rand from MySQL $query = "SELECT FLOOR( RAND() * MAX( cumulative_count) ) FROM ". $tableName .";"; } else { // rand seed passed in, potentially different for every player player combo. mt_srand($seedRand); $rand = floatval(mt_rand(1, 1000000)) / 1000000.0; $query = "SELECT FLOOR( $rand * MAX( cumulative_count) ) FROM ". $tableName .";"; } $result = cd_queryDatabase( $query ); $cumulativeTarget = mysql_result( $result, 0, 0 ); ...
So a client can send a MySQL query?
What if they send a query to dump the whole DB?
What I said can make it hard enough: "Maybe get it with HWID, where server checks if the current HWID is used for another The Castle Doctrine existence, the other ones will be disconnected.
and make sure the program doesn't run at VMs."
But yeah, your game is open-source. You can't stop the cheating, they can overwrite it.
Last edited by DaVinci (2014-02-01 00:00:18)
Offline
aww go away with everyone having different names..
we wouldn't have infamous villains such as adrian ernest pounds if everyone saw a different list!
also, with 24 hour chills, knowing the name of your other house is not that useful at all.
Offline
aww go away with everyone having different names..
we wouldn't have infamous villains such as adrian ernest pounds if everyone saw a different list!
Agreed.
also, with 24 hour chills, knowing the name of your other house is not that useful at all.
It is.
His system wouldn't do anything though. A cd-key based name gathering would not do much as the guy who has multiple accounts could easily have the names reverted,
OR
could build himself a new copy without this feature// Encrypting upon 1 key.
Offline
we wouldn't have infamous villains such as adrian ernest pounds if everyone saw a different list!
also, with 24 hour chills, knowing the name of your other house is not that useful at all.
good points
His system wouldn't do anything though. A cd-key based name gathering would not do much as the guy who has multiple accounts could easily have the names reverted
Easily correlated yes, reverted no. Not that there's much practical difference.
OR could build himself a new copy without this feature// Encrypting upon 1 key.
Because it's server side, it doesn't matter what client you use, the crc32 of the player id and the house player id will be different for every client, the names are generated at the server not the client.
The main weakness is that, looking at other information, like the $, visits, and deaths you could just identify each house on those attributes without looking at the name. But full day chills would make it impractical anyway. And it makes the names meaningless.
I actually like the idea of increasing the chills length best, because it limits the number of attempts, and encourages addictive behaviour to come back and repair every few hours.
Offline