Terminal Heist Forums

The place to discuss Terminal Heist, the space piracy and defense game.

You are not logged in.

#1 2016-02-24 00:05:51

zed
Member
Registered: 2016-02-24
Posts: 8

Preventing map hacks

Good to see that this is getting going.

I'm curious as to how in the end you plan to deal with map hacks. Is it going to be pure security-through-obscurity, or are you going to have all games running on the server?

Relatedly, will there be a source release?

Offline

#2 2016-02-24 03:26:21

cullman
Moderator
Registered: 2015-07-07
Posts: 127

Re: Preventing map hacks

My day job is in security, so I know the ultimate futility of security through obscurity.  That being said, there is no reason for us to be open source and make it dead simple for anyone to spend 5 minutes and write a map hacking client.  We've experimented with doing all the logic on server side, and there are ways we could make that work.  The downside of that model is worse performance for the end-user and higher cost for us to run it.  So we are going to encrypt the map better, and make it harder to intercept the map load call, but ultimately someone with enough time on their hands will be able to disassemble it and figure it out.  Ultimately, we plan to implement some analytics on the server side (likely using graph database technology) to look for cycles in terms of dual/multiple account usages, and outliers in terms of "luckiness".  That combined with the fact that we will have administrative oversight, will ban cheaters, and we no longer have random names (meaning that people will accurately talk about an individual user's unlikely luck - I hope will be enough to make cheating not worth the time or effort in this game.

Offline

#3 2016-02-24 11:53:37

zed
Member
Registered: 2016-02-24
Posts: 8

Re: Preventing map hacks

OK. My sensibilities are offended by any approach which involves forcing the
client to tell the user less than it knows, and as you know it can't truly
work (at least, without the monstrous police state apparatus of "Trusted
Computing"). But RTS's have been mostly getting away with it for decades, so
maybe you will too. I'll be interested to see how it turns out.

I wouldn't dismiss the possibility of having the games run on the server,
though. It's clearly the only full solution to the problem, and I'm not sure
it's infeasible. Consider that plenty of people happily play roguelikes on
remote systems, e.g. nethack on alt.org, where you have similar problems of
needing to react each turn to what's just entered into sight range. The
extra latency doesn't seem to be a problem in practice. As for processing
costs, certainly you'd need to optimise the server's handling of electronics -
which iirc is utterly naive in the original TCD code, I'd guess savings of an
order of magnitude or two would be fairly easy to incorporate. But with some
such optimisations, I'd have thought the costs could be pretty minimal.

There's also the possibility of a mixed solution: by default, trust the
players to play by the rules in a local client - but if your fancy statistics
indicate that someone might not be, force them to prove their honesty by
playing remotely.

If I were you, I'd plan for possible eventual introduction of remote play by
introducing an artificial lag in local play to vision reveal after a move, say
150ms. That way the average player wouldn't even notice a change if they later
get switched to remote play.

Anyway, for now, I'm disappointed that there won't be a source release, though
I understand the reasons. Will there be a linux binary release, at least?

Offline

#4 2016-02-24 16:32:11

cullman
Moderator
Registered: 2015-07-07
Posts: 127

Re: Preventing map hacks

Well part of the other reason for a non-open source release is at some point I would like to attempt to recoup my costs in this project which is a non-trivial number.  Though, monetizing the game is not the priority and it will never be a higher priority than getting the game popular again.  We are going to start out completely free to play to get an audience going.

Yes we will have a Linux release.

Max (TH's lead coder) actually wrote a proof of concept of a server side logic game using castledraft (I don't know if you saw this when I originally posted it on the TCD boards) :

http://ec2-54-197-125-240.compute-1.ama … mid=pq6U7O

(To start the game push the right arrow).

You can replace pq6U7O with the end of any castledraft share url, and play that map.

As you can see it's pretty playable.  What's interesting is it almost makes me wonder if the right approach wouldn't ultimately just make it a browser based game if the logic is happening server side.  Performance could actually be increased by the server sending not just the current viewable squares but also the potential visible squares that could happen in the next move (based on going any of the 4 directions or use of a tool) - so the client would immediately know what to reveal on the button click.

One thing we've considered is having server side play enabled in certain games.  Make it enabled in certain "galaxies" or in terminals over a certain price.  Or we could have a premium version of the game that you pay for that supports server side.

At the end of the day there is a ton of stuff we can do.  I think the first step is just having the game have some oversight with regard to cheating.  Jason didn't really have the time to enforce rules and they were hard to enforce with the random names.  The next step is to see if we can find an audience for this game, if the game population gets big enough and we can afford to do it, there are lots of things we can do to improve the game.  However, I don't think it makes sense to spend a ton of extra time building in anti-cheating measures and then discover no one wants to play the game anyway.

Great points, Zed, keep them coming.

Offline

#5 2016-02-24 20:32:04

zed
Member
Registered: 2016-02-24
Posts: 8

Re: Preventing map hacks

Re source release and getting money: I actually thought one of the most
interesting contributions of TCD was to show that these aren't incompatible.
The client, and even the server, can be free software, and yet you can still
be commercially successful by selling access to the default server. You have
to rely on goodwill and network effects to stop others successfully
undercutting you with their own cheaper servers, but I'd guess that would
typically suffice, at least until the game is so popular that you've made
enough money from it anyway.

I can understand you not wanting to repeat this brave experiment, of course.
Though unless you're putting a lot of work into obfuscation of the protocol, I
wouldn't have thought that releasing the code for just the client would make
it all that much easier for someone to write a competing server.

Anyway, good to hear that you're considering moving some games to the server
eventually, and that there'll be linux binaries. I'll test them when they
exist.

Offline

#6 2016-02-25 01:02:36

cullman
Moderator
Registered: 2015-07-07
Posts: 127

Re: Preventing map hacks

Well if Terminal Heist is remotely successful we already have many very cool ideas for expansion.  While the open source guy in me wants to give back, I also don't want to dilute the user population by creating competing servers and clients.  I agree Jason's experiment is useful, but what he considers a financial success is different than what I do.  If sold as much as he did in terms of dollars, I will break even - which would be great. I have mentioned this on the TCD boards before.  I was one of the original founders and CEO of Plex.  I don't know if you are familiar with Plex but we started out as an open source fork of XBMC that runs on Mac.  I would say that Plex still offers 90% of it's functionality absolutely for free.  Similarly, 90% of the Plex ecosystem was written from scratch by the Plex team (I think we will follow a similar path, we have already completely re-written the server from scratch.  If this game is successful at all, I suspect we will do a clean rewrite on the client too within a year).  Today the open source part of Plex is all but end of life'd, and the Plex team has written a huge amount of a closed source eco-system.  The advantage of it being closed source is Plex now has a team of 70+ people working on it full-time, and I personally believe it's a much better product than XBMC because it gets that full-time professional development focus (and in fact, I believe the user base of Plex exceeds that of XBMC/Kodi now).  That being said, the Plex team obviously shared all of our changes back on XBMC, and we (really me since it was my idea, and I was sole provider for the funding that got the coding done smile were the reason that there is an XBMC for Mac.  We were also the code base for the Boxee project, they started with our fork not XBMC's.  Ideally, I'd like to get to the same place with TH where it's a fremium model (not pay to win).  Where maybe 90% of our users play for free but the really hard core guys pay a little bit to play with server side computation protection, or an advanced house editor that allows you to save house snippets, and do things like cut and paste, etc.  Make sense?  Again, my first priority is to resurrect my favorite game, not make money.  If I could break even while doing it that would beg great.  Just like TH, Plex started out for me as a hobby, I wanted an XBMC that ran on a Mac Mini - the fact that it turned into a business was a happy accident.

Last edited by cullman (2016-02-25 01:10:35)

Offline

#7 2016-02-25 21:13:59

zed
Member
Registered: 2016-02-24
Posts: 8

Re: Preventing map hacks

OK. It isn't how I'd do it, but it isn't my game. And, I know from experience,
how I'd do it doesn't lead to any players, still less any money!

So good luck.

Offline

#8 2016-03-12 11:14:16

cullman
Moderator
Registered: 2015-07-07
Posts: 127

Re: Preventing map hacks

Zed,

You know discussing over here on server vs client logic and the cheating issue.  I think we will still plan on improving the full map download scenario. However, I think the team is increasingly thinking that we will probably support server side game logic.  Right now the game is free and there will always be a free to play version, but we are thinking the paid for version will have server side maps.  Thoughts?

Offline

#9 2016-03-13 08:46:20

zed
Member
Registered: 2016-02-24
Posts: 8

Re: Preventing map hacks

I don't know if you'll like my thoughts, but here they are anyway.

It seems strange to simultaneously go the route of obfuscating the protocol to
make maphacking difficult, and also selling true protection via server-side
processing. The only way you can pitch the second is by admitting failure on the
first.

If you're going to have both client-side and server-side processing, I'd be
more upfront about the reality of it. Forget technical means of making
maphacking challenging, trying to make the client work against the player, and
just accept that any time a player's client is put in the role of processing
the game, the client and hence the player has access to the map.

I see two ways of coming to terms with this. One is to roll with it, try to
make something out of what's left of the game once hidden information is
removed. We had a taste of that with the short-lived blueprints experiment in
TCD - a few of us loved it, but most seemed to be turned off by it.

A second is to try to keep hidden information as a core mechanic, but be
honest that this relies on the goodwill of players not to peek. So make it an
option in the client to "scan the ship", but try to make it clear that it goes
against every spacepirate's code of conduct to actually do it... I'm not
saying this would work, but it would be honest. And then it would be clear to
players why they should be interested in the "scan shielding" afforded by
server-side processing.

Offline

#10 2016-03-19 18:22:16

spacepirate
Member
Registered: 2016-03-01
Posts: 4

Re: Preventing map hacks

I think you have two problems.  First, map hacking is a big problem especially if the game takes off and generates a new community.  I think once the game gets more attention, map hacking will become more likely.

The first problem you face is getting people to play.  You have to look at what things destroyed TCD.

Multi account usage
Time expense

You could get rid of multi account usage in a few ways.

1. Bring in parallel universes (Fits in great with the space theme) - one account can play in different universes.  If I have an account, I can set up 1 or more terminals, each in their own universe.  Each universe simulates a different, separate life that cannot intertwine.  This may reduce multi accounting because it gives people more to do in the game with a single account.
2. Temporarily ban from a given neighborhood for multi account offense.  How do you detect an offense?  This is completely up to the community, but what is more important in the game is the perception by the community that it is detected, discouraged, and dealt with accordingly.  In this case, players would be more likely to avoid this type of cheating or the appearance of it all together.  Can I ask, how would you deal with two different legitimate people collaborating together against a house?  If you can find a way to give the community the warm fuzzy feeling that the game has a level playing field, perhaps you can get people to come back to the game.
3. Map hacking will be an issue if you get a lot of players.  Lets face it, if the player base expands, it will attract people who want to come in and trash everything.  In my opinion, server side processing is the only way to deal with it, but I would only think about how to solve this problem after 2 has been solved and people start returning to the game.

Last edited by spacepirate (2016-03-19 18:27:43)

Offline

#11 2016-03-22 06:27:59

cullman
Moderator
Registered: 2015-07-07
Posts: 127

Re: Preventing map hacks

Everyone's thoughts are welcome.  Yeah I like the sort of pressure relief valve idea once we get a bigger base to allow "legal dual accounting", basically allowing someone to have a clone in a separate universe or in the same universe where they share chills and force ignores and can't rob each other's houses.

I think we will eventually have server side processing, in fact, we have sort of rough versions of it almost working... but again, none of this matters unless we can get a big user base back.  TCD was at it's absolute best when there were 1,000s of people playing.

Unrelated : spacepirate, you are dangerously close to figuring out how my lock works! One I'm quite proud of, because even if you can see my map via map hack it's goal is to be pretty non-obvious.

Last edited by cullman (2016-03-22 06:29:16)

Offline

#12 2016-03-23 06:52:42

Amatiel
Member
Registered: 2015-12-23
Posts: 11

Re: Preventing map hacks

Ill share my thoughts...

- Preventing "dual account use" in a broad spectrum approach appears pointless to me. Whats the difference between one person using two accounts and two people cooperating? Tell me how is it fundamentally different to someone who's doing a santa run for example? That issue right there has always occurred to me as completely undermining of any attempt to apply the above broad spectrum approach.

- I think it would be far more effective to focus on the specific damaging behavior that one can do with dual accounts like broken house farming or (simplified) obtaining large amounts of wealth in a very short amount of time by exploiting the games mechanics.

- I think you have already mentioned something along these lines before, but it would be ideal if you had a security feature that could correlate rapid increases of wealth with dual account use. Think of it as dual account exploiter "profiling". Develop an accurate profile of what a dual account exploiter at its worst does and create a mechanic/feature that can recognize that profile. Even if it just "red flags" suspicious accounts and acts as a filter warranting a person to invest time in investigating further.

- A truly accurate profile and definition of what that damaging behavior is, IS CRUCIAL. Otherwise we are just flailing in the wind with generalizations and undefined goals. Solutions often present themselves once you have clearly defined a problem.

- Map hacks must be prevented at all costs as i think this was the straw that broke the camels back for TCD.

I have no background in computing, just problem solving... so im not sure but creating such a feature seems about as big of a task as making the game itself, yet the cancer of cheating must be minimized. In my view, it wasnt the cheating in and of itself that caused TCD to die out. It was the forum outcry, fear and frustration of people thinking they were being cheated (when often they weren't) that did the most damage.

Last edited by Amatiel (2016-03-23 07:00:57)

Offline

#13 2016-03-23 11:10:31

AMWhy
Member
Registered: 2015-09-08
Posts: 48

Re: Preventing map hacks

The issues with dual accounts were discussed heavily on the TCD forum.
The question is not if they should be stopped, it's how.
Here are a few ways they can be exploited:

1. Start with 5200 instead of 2000.
2. Suicide scout without consequences to your main house.
3. Raid the same person twice in a row without chills.
4. Fix your house instantly if it is raided.

1 means that a 2k safe house is not safe against dual account users.
2 means faster and cost free map progress on advanced players.
3 means a second chance to raid a house before the owner returns.
4 means instantly back in the game after being raided

The last one is the only one that doesn't directly affect other players.

Amatiel said:
"In my view, it wasnt the cheating in and of itself that caused TCD to die out. It was the forum outcry, fear and frustration of people thinking they were being cheated (when often they weren't) that did the most damage."

I'd rather not argue this again but regardless of whether it was cheating or paranoia, the possibility it could be cheating helped kill TCD.  If nothing is done to prevent it, the same will happen again.

The idea of tracking suspiscious behaviour could be achieved by recording the time between a new life starting and death occurring.  An account that has multiple deaths in a short time could be doing Santa runs.  But just the one death each time to the same player would flag as suspiscious. 

Another thing to record would be the name of the person dying in a house.  Particularly deaths within X steps.  Lots of short deaths (especially doorstep deaths) from the same player would flag as suspiscious. (But could be a player without a house learning someone else's place).

Also record the number of death/success partnerships.  For this, assume first Xavier does in Zachs house, then Yasmin robs Zachs house.  That would be one partnership.  If the same partnership occurs more than X times, both Xavier and Yasmin are flagged as suspiscious.

Depending on resources to monitor suspiscious behaviour, either 1, 2 or 3 flags would need to be triggered for human intervention. 


Regarding map hacks, aside from data encryption I'm not sure how you can prevent the possibility without lag.  If you can figure a way to only give part of the map each time (but not stop dog/cat movements and have full functionality with clocks, etc.) then that would be great.  I have no idea how you'd do that though.

Offline

#14 2016-03-23 14:43:06

cullman
Moderator
Registered: 2015-07-07
Posts: 127

Re: Preventing map hacks

Lot's to comment on here, and I have literally probably written 100s of posts on the subject back at the TCD forums.

Server side play is possible, and it possible with little lag.  Again, I invite you to check out :

http://ec2-54-197-125-240.compute-1.ama … mid=pq6U7O

Press right arrow, that is 100% server side computation and the squares are not being revealed until the server allows them to be revealed.  The lagginess of this can be improved further by having the server return which squares are visible for the next 2 moves. So if I press right the server could return the squares that are visible when I press right followed, by left, right, up and down really only 4 different combos for movement, so if the user presses right quickly the second set of view tiles are already client side.  That version was written very quickly, we could write a version that also is smarter about the networking part of it to speed it up as well.

I also don't want to rehash the whole was it cheating or the out cry of cheating on the boards that did the game in, but I can tell you cheating was very prevalent.  I'm not sure if you guys remember, but one of the ways I did research for TH was to offer to pay people to help me in game via paypal, this brought out all of the cheaters, and let me know exactly how they operated.

One of the first steps to stopping cheating and the easiest is the removal of random names that allows us to do some community policing. Just having a game administer that is willing to investigate cheating would be a step in the right direction compared to TCD.

I am confident that we can stop map hacking (whether we do server side game wide, or in certain premium galaxies, or for houses over a certain value remains to be seen), and that we can cut down on dual accounting (and for the record I consider two people helping each other cheating too, so I don't care if there is no difference there).  The bigger question is how do we make an account ban painful without charging a lot of money to play the game.  That's the one thing I haven't quite figured out.

Lastly, I think one of the most powerful things we can do is implement detail analytics and feed them through graph database technology (the same thing they use to detect credit card fraud, money laundering, etc).  In my mind, we can use this technology to detect whether or not two accounts seem to go into the same houses right after each other etc.  I also have this idea of calculating a "luck factor" where if we measure a robbery attempt as perfect if it uses 0 tools and the same number of steps as the recorded self test for a given house and call this a 1.0 and measure a robbery attempt as imperfect if the server calculated basically the number of steps and amount of tools to brute force a house if you were to brute force every square of the house call that a 0.  Then you basically factor in the number of scouts into the score.  Now if someone is getting .9 scores on every robbery they are probably cheating (especially if we do an analysis on the user base and see that the game average is .25 and the next best player has .6 as their highest average score, etc).  Just as many people pointed out on the old boards, that it is possible to guess an 8 bit combo lock on the first try, it's unlikely to do it on 3 different houses in a row.  So the machine could flag these accounts for review, or even auto ban.

As I've said before I think dual accounting is an interesting problem, because I am even guilty of this to some extent.  You get your perfect house built, and no you are too afraid to rob anyone else, and so now the game is basically dead for you.  So you start a second account with no intention of cheating but then your main gets broken and could be fixed if someone would just drop $1000 of tools in quickly and you could get it back on line, and a dual account cheater is born.  That's why I like the idea of allowing people to have a second user either in a different realm or a second user within the same account that shares chills and ignores - again to give people a sanctioned way to keep playing once they have their perfect main house.

I'm open to better ideas on all of these topics.

Offline

#15 2016-03-23 20:58:43

zed
Member
Registered: 2016-02-24
Posts: 8

Re: Preventing map hacks

Yes, getting your friend/sockpuppet to scout the map for you is a kind of
map-hacking which even server-side processing won't help with, and using money
as a way of keeping score is almost as exploitable as it is in the real world.

Making sockpuppetry give no advantage would certainly require a complete
redesign of the game. Actually I did this with my game Intricacy
(https://sdf.org/~mbays/intricacy); I started with a metagame design a lot like
TCD's, but thinking through the potential for abuse led me in a pretty
inevitable-seeming way to its current design. Sadly, adapting TCD to
use something similar would take a complete overhaul and lead to a very
different game.

Using statistical techniques to detect conspiracies is interesting. Obviously
there will be errors. I'd also worry about the potential for abuse of this
anti-abuse system; e.g. if it's set up such that A funnelling money to their
dual account B leads to both A and B being banned, that means A can instead
get their enemy C banned by funnelling money to C... (the solution in this
example is easy - only ban A).

You rightly worry that banning players won't be much of a punishment if they
can just easily create another account. In the age of tor and VPNs, banning by
IP isn't going to do much good. So how about making it mandatory for a new
account to play a significant chunk of single-player tutorial before being
allowed into the main game? That wouldn't really hurt genuine new players, and
hopefully having to play through the tutorial multiple times would be boring
enough that only the most disturbed griefers would do it. But I don't know how
to handle them.

Last edited by zed (2016-03-23 21:00:34)

Offline

#16 2016-03-24 03:08:05

cullman
Moderator
Registered: 2015-07-07
Posts: 127

Re: Preventing map hacks

Thanks for the ideas Zed, keep them coming - I like the idea of tutorials though someone could ultimately macro them.  One option if we got a big enough population is sort of have multiple "galaxies" maybe beginner, intermediate, and advanced.  And you could have to work your way up to the galaxies.  So we could make it so getting an account that is allowed to even play in the advanced arena has to log 10 hours of game play or something.  Max actually got server side working in the client today.  It's a little laggy, but that's with zero time spent optimizing.  I was doing some math and I bet we could handle 200 sessions per server at a time without having to rework the code much.  Assuming 5% of the population being active at any given point means we could handle an active population of 4k players per server, which is totally doable cost wise.  So I think this is likely the path we will go down.  As for the statistics idea, it's just an idea, I think initially anyway we could use statistics to call players out for human investigation.  I mean no game is cheat proof, the key here is to make it not worth the trouble.

Btw, I played your game intricacy, I definitely dug what you were trying to do and I fiddled with it a few hours.  I will have to dust it off again and check it out some more.

Offline

#17 2016-03-24 16:49:58

zed
Member
Registered: 2016-02-24
Posts: 8

Re: Preventing map hacks

I'm not sure that having persistent abusers trapped in the beginners section is a good idea - beginners are the last people you want to be abused!

Yes, to do the "obligatory tutorials" properly, you'd need some (server-side) procedural generation of the tutorial levels. I don't know if it's actually a good idea.

I've continued working on Intricacy since you'll have seen it, but only on superficial things. The basic design hasn't changed. That doesn't mean I wouldn't be very happy if you gave it another go!

Offline

#18 2016-03-25 07:57:37

Amatiel
Member
Registered: 2015-12-23
Posts: 11

Re: Preventing map hacks

Make the game free to download, tutorial free to play and require a purchased account with a listed credit card for multi-player at a price that will deter multi account users.

The credit card will act in lieu of a VPN ban, instead u get credit card banned. TOR and proxies wont help cheaters there.

However you would really want to go to extremes in protecting peoples credit card data, no doubt the now deprived cheaters would target that in retaliation for us stopping them ruining our fun.

Embracing my inner tyrant here... NSA is watching...
if that fails we could try social security numbers lol

Last edited by Amatiel (2016-03-25 08:08:31)

Offline

#19 2016-10-05 20:27:38

zed
Member
Registered: 2016-02-24
Posts: 8

Re: Preventing map hacks

A different (more drastic) approach to these problems:
http://thecastledoctrine.net/forums/vie … hp?id=3156

Offline

Board footer

Powered by FluxBB