Discuss the massively-multiplayer home defense game.
You are not logged in.
Josh, why would 5 slots be too tight? What do you envision happening if I limited people to 5 slots?
I suppose that the less-used, less-necessary items would become even less attractive to carry, which might make creative robbery play (like using a brick in a clever way) less likely.
Right... v26 drew less tiles, I think. But it had some major problems with visual consistency (walls being cut off abruptly, etc.) v28 focuses on the space in between where slightly more stuff is drawn, but it never looks bad, and the extra stuff that is drawn isn't THAT big of a deal (like you'll never see a dog or vault or family member completely through a wall like you could in v25). Yes, you can sometimes see connected walls peeking through, but that isn't so huge. If you really want to make invisible dead-ends behind doors, you can put the end cap 3 back. That's much more practical than having to make EVERY wall in the game 3 thick like before!
I should really fix some aspects of this. First, you should automatically receive the bounty in this case (when the robbery finally times out). Also, you should automatically receive all of their carried tools (we don't know which ones they used, but we can assume the best case for you, the owner).
I'm also thinking about creating a "dummy" tape in these cases that just shows them suiciding on your doormat with a backpack full of tools. That would clear up the confusion about the missing tapes.
Or maybe a special case where they die of a heart attack or something, just so you can tell the difference between a disconnect and a true doormat suicide (though true doormat suicides are pretty rare).
Good thinking here! I forgot about self-test forbidding fully-walled-off houses.
So... in that case, it seems like 5 backpack slots would be pretty interesting. Lower than that, and everyone would just build Josh's house there.
Obviously, if you COULD use a brick instead of a ladder, you'd much rather carry a brick. But in some cases, you'd need a ladder.
I just feel like there are not quite enough "difficult decision" present in the "what to carry" question, because you have so much room... pretty much room for everything but the usually-useless items. So, a rich player can just fill up the backpack without much thought.
8 Slots was a serious, brain-busting limit back when each slot only held one item.
Well, the idea with the timer would be that you'd have to come back later and scout another time if you really want to explore for 20 minutes. Robbing a house would be more of a calculated, note-taking, drawn-out effort. Casing the joint several times, in little bursts. You know, walk into the bank and take a quick look around. Come back next week and repeat.
You don't spend all day in the bank snooping around!
Well, for the moment, I'm focused on robbery, not self-test. It's simply not as bad if someone cheats on a self-test, because it doesn't unfairly steal the work of another player. Besides, in a self test, you already have the starting-state map, and knowing the game logic, a "hacked" client could predict where the map will change after that, step-by-step, even if the server tries to hide those changes from the client.
SO... stepping self-test server-side would mainly be there to prevent "cheating death" by modded clients that ignore a failed self-test and dump you back to the edit screen. HOWEVER, even if we were stepping server-side, a modded client (which has the whole map, unavoidably) could step locally first, without sending ANY steps to the server, cheat death, and then in the end send a "safe" set of steps to the server (like... 2 steps, where you walk right back out the door). The player actually died during the self test, but the modded client ignores this and reports to the server that the player walked safely out the door instead.
SO... moving self-test server side buys us no real security against a determined cheater anyway!
But moving robbery stepping server-side buys us everything, because the robber does not have the whole map. If the vault is hidden, it will become truly hidden to the robber (as in, there is no way for the robber to discover where the vault is by cheating).
JCWilk:
Great ideas there! The problem with any kind of client-side "prediction" (like, allowing the player to move without messaging the server if the map hasn't changed) is that the client won't have the whole map, so they cannot compute whether the map has changed or not. Just because nothing VISIBLE should move, from what the client can see, doesn't mean than nothing off-screen is moving or changing. The thing that makes this such a pain (for me as a dev) are the cross-map effects through wires. Making that work, without giving the client the whole map, requires full-map sim server-side, relegating the client to being unable to simulate anything. For example, a visible light could be on for the client, with no known, visible power source (so far, from what the client has seen). Just a wire running off screen somewhere. If the player moves, with no change to what the player can see, should that light remain on or not? Only the server knows the answer in all cases.
Well.. the hard part is CATCHING the cheaters at this point. Are you peeking at the map, or just really lucky? There's no way to tell, server-side.
The other problem is that stopping MOST cheaters isn't good enough... even one cheater can sweep the server quickly and destroy the top houses. That would ruin the game for everyone. So... you're right that the "blessed" binary idea won't work. If even one person bypasses it, then every other player in the game will be angry.
So... as far as "moving everything to the server" goes, this means simulating the whole map server-side (because there are cross-map effects that can't be simulated on the client with only a portion of the map).
The client would get just the states of the visible tiles, and then ask the server to move North. The server would take the full map, simulate that move, and the return to the client with the states of newly-visible tiles. The client would just be drawing those tiles.
Client would mirror the game logic to make that drawing easier, and also for self-tests and tape playback (which don't need to be simulated server-side, because the client already has the full map in those cases).
So, every move would require a complete round-trip to the server to resolve. I'm pretty sure the server would have to maintain an open socket with each client to pull this off (and this part of the protocol wouldn't be http, but compact binary for speed). So, client sends move to the socket, server responds on socket with 169 bytes representing visible objects (13x13) and 169 bytes representing the states of those objects and maybe a sparse list of mobiles.
I've been worried about how slow this round-trip would be... but then I remember that typing over SSH requires similar round trips (or paging through a text document over ssh).
In a network hiccup, it would be really annoying, of course. Press UP and wait... then a few seconds later, your guy moves.
I also have concerns about RAM (for storing current map states) and CPU (for simulating each move) server-side, especially as we get more players.
I'm becoming more convinced that doing this hard work will be necessary on my part. I hope you folks can pitch some ideas in here... what am I missing? How could I do it with less overhead?
On the other hand... if I cut it down more than that, like down to X slots, it would be a challenge to try to build a house that REQUIRES X+1 tools to break.
I mean, can anyone draft a house that would require 7 tool types to bypass? Is there enough room for that on the map?
Explosives don't hurt metal walls (only wood and concrete).
By a "wall of doors" I meant a wall from one end of the house to the other. If the doors are closed... Oh, well, but if they start open and then close, the animals could see you and then start a magic dance behind the closed wall-of-doors. So then a crowbar can be necessary to break a house.
So.... then the question is: should I cut down the backpack slots to 7? Seems like such a puny change that it might not even be worth doing.
Stuff you steal while out is put in a "holding bay" that no one (including you) can access until you return home and deposit it. It's not in your backpack... it's in a separate bin.
If your house is being robbed and you can't get back in, you might rob 5 houses while you wait... and all that money and loot builds up in this untouchable holding bay until you return home.
This release further refines the new visibility system in the game, correcting various visual inconsistencies that arose when non-visible objects are not drawn.
A Sell All button has also been added to the backpack screen.
A full list of changes can be found here:
Thinking again about 8 backpack slots being too many (given that you can have infinite items, and the slots limit how many types you can carry.
Of course, if I lower it too much, impossible-to-force houses may come back.
I think that 7 item types is the minimum to break any house. A house in theory could require you to:
--bypass metal walls (torch 1)
--bypass concrete walls (explosives 2)
--bypass wooden walls (already have torch)
--Force open a door (crowbar 3)
--Disable an electric floor on (water 4)
--Disable an electric floor off (wire cutters 5)
--Shoot a dog (gun 6)
--Cross pits and trapdoors (ladder 7)
The ultimate theoretical house could require all 7 item types to force-enter.
As far as I'm aware, there's no way for a house to force you to use a brick, drugged meat, a club, a doorstop, or a saw.
I'm not sure about the crowbar... could you have a whole "wall of doors" that you could not cut around? If so, how would it be triggered? If externally, then you could cut the power. If internally, then how would it be triggered? Maybe by a timer?
If this is not possible, then you can always cut around a door, making the crowbar redundant in this calculation. 6 mandatory item types is possible, then?
Am I missing something here? Should I bring the backpack slots down to 6?
The Van!
Well, the problem is that people would use this to protect their stuff from being stolen while they are out. Why not put everything in the van?
You can already put "everything" in your backpack, but then you risk losing it all when you need to flee a house (which is the balance point to an otherwise unlimited backpack).
Unlimited backpack is needed so that you can eventually cut through the hardest possible house.
Would be weird to have the van MORE limited than the backpack.
Maybe some way to buy tools into the backpack while you are out... But where does the money come from?
Okay, fixed this. Stuff is no longer visible through these very narrow gaps. Will appear in next release.
The super-easy cheats (like reading house maps from the recorded game files, or walking through walls to reach a vault) were sealed off long ago.
There are a few more lingering issues:
1. Yes, starting-state house maps are encrypted as they come from the server, but at the end of a robbery, you send back the finished house map in the clear. A simple packet sniff will get the map for you, and if you just peek in the front door before ending the robbery, the end map is very similar to the supposedly-secret start map. Yes, that sent-back map can be encrypted (and will be). In fact, the server can verify the move list without even receiving the end-state map at all (though I will probably keep the sent-back map in there as an extra check to making modding harder).
2. The server verifies your moves at the end of the robbery and kills you if you walk through a wall or if a dog that isn't supposed to see you sees you. But if you're using a second account to do this, so what? Even without modding the client, you can mod the data files to change the properties of walls. Then, you can walk through walls and get a good look at a house's internals, maybe to use later (after the chill wears off) or maybe to use in a second, non-cheat account. Yes, I can detect clients that walk through walls on the server and auto-ban those accounts. But then the clients would just quit before the end of the robbery and never submit the suspicious move list to avoid my detection. Clearly, the gameElements folder needs to be verified at start-up to prevent this. The game should refuse to run if the sigs on the various object properties don't match. The problem is that a modded client could skip this verification, or simply change the embedded key that is used to check the sigs (thus allowing modded wall properties to be falsely signed).
3. A modded client can turn off the shroud during robbery entirely, or implement changes that allow panning around the whole map without moving the robber. There would be no way for the server to detect this.
Yes, I can make it harder for people who don't want to do full-blown mods to cheat. I can make packet-sniffing useless. I can make basic fiddling in the gameElements folder useless.
But this is an open source game, and on one platform (Linux), the game currently ships as source. Meaning that a substantial chunk of players are ALREADY compiling their own version of the game on a regular basis. Thus, full-blown mods aren't just likely---they are inevitable.
And with a real mod, encrypting the protocol won't stop you. Signing stuff in the gameElements folder won't stop you. Drawing a visual shroud on the screen won't stop you.
The REAL way of doing this would be to have everything happen on the server, with the client just acting as a dumb tile display. You ask the server if you can take a step. The server sends back the tiles you can currently see. You ask to step forward onto a button, and the server tells you that the door opens.
But, as many of you have experienced, during peak load times, or internet outages, or whatever, several seconds of latency for a server request are common. That's okay when you're waiting to check in a house. You can watch the progress icon for a bit. That's not okay when you're waiting to take a step in a house. This is the reality of an indie MMO hosted inexpensively on a web server.
So, that brings me back to trusting the client. But how can I do that?
It seems that having a list of "trusted" binary builds will be necessary. The main server would only allow connections from those binaries.
But how can the server know what binary it's talking to? If you embed a private key in the binary, that key can be located and extracted, and then compiled into a modded binary.
There are various methods of obscuring keys in the binary (spreading the bytes of the key around, etc). But they aren't very satisfying. Also, since the code will eventually need to assemble the hidden key to use it at runtime, it seems like a RAM analyzer could grab that key out of memory at runtime.
The idea that I've come up with is to embed a secret algorithm itself in the binary, and mirror that same secret algorithm on the server. The request signatures attached to each client request would then be passed through that secret algorithm, and the server would use the same secret algorithm to verify these request signatures.
So, this is really the same "shared secret" idea as hiding a key in a binary, except that it's a block of machine code, which is much harder to extract and replicate from an EXE than a simple key string (and also just as hard to pull out of RAM).
Just as various encryption parts of the game ship with "placeholder" key values in the code now, the source would include "placeholder" secret algorithms as examples. To run your own server, you'd plug in your own algorithm (or just stick with the stubs, if you don't care about untrusted clients).
Each new version of the game could ship with a changed secret algorithm, making the server rejection of old versions of the game more robust than just trusting the client to report its version honestly.
Anyway, in order to trick the server in this scheme, you'd need to:
1. Study and decompile the EXE to find the secret algorithm.
2. Figure out how to re-code that secret algorithm into your own modded client.
Both things are many rungs above "sniff packets" or "tweak data files" or even "open EXE in a hex editor." And even if you accomplished that, you'd have to do it all over again when the next version comes out and the algorithms change.
The main downside of this approach is the death of flexible, compile-from-source distribution on the Linux side. Yes, I can supply Ubuntu LTS binaries.... but that won't help people on other Linux platforms.
Something like this.... though I'd want to keep it pretty simple. I'm not sure that the owner should have any influence over the time of a robbery...
Good point about the owner dread/suspense part!
Still, I imagine that robbing houses in real life has a very tense sensation of time pressure, which this game currently does not have at all. Yes, I too have wandered carefully around a house, but in a real robbery, you wouldn't have time to be that careful.
The problem is that if I put the timer at 30 minutes on the screen, there will be no feeling of time pressure for the vast majority of robbers... it would feel like all the time in the world. And a half hour is a long time to be without any supplies for robbing others, on the owner's part.
Obviously, whatever I do would be tweakable server-side, so we could experiment with various times.
Also, I like the idea of the "owner coming home" being the thing that catches you... and also the idea of that being a surprise (trying to guess how long the owner would be away). BUT... I also see how that would be endlessly abused by owners to ambush people in their houses. Just try to come home over and over all day and make every robbery really short. Still... "You hear the owner coming.... 3 minutes left" would be pretty cool. And then at night, while the owner is sleeping, you could do longer robberies. Though I imagine owners would just build bots to come home over and over all night long. Hmm....
I'm reworking the vision-fading stuff from the ground up to address many of the visual/logical shortcomings of the recently-added system. It's almost done, and I'm pretty sure it fixes everything, so hold off on reporting more visual glitches until I get this new one out the door.
So... This is an interesting issue, and one that has never been foregrounded in this way before.
Obviously, there is currently nothing stopping a robbery from literally blocking your house FOREVER, if they want.
A timer is an interesting idea. I would be tempted to keep it pretty tight... maybe even 5 or 10 minutes. If you want to poke around more... well, come back later, right? That will give other people a chance at the house, too, as well as the owner.
Obviously, this would be a pretty big change to the feel of the game. But otherwise, this "griefing" technique would be wide open.
Simoon... as it turns out, a similar issue to "pits being drawn on top of player" was causing pits to be visible behind doors. In v27, the were marked as "walls," which gave them special status in terms of when they get drawn when they are technically invisible. I've now switched them to being structural (so that windows orient around them" but not walls. If you want to change this yourself, edit the properties.txt files and remove the "wall" property from each one.
Okay, Arakira---thanks SO much for taking the time to send me that recording. Indeed, there was a bug in the way that pits were being drawn in the latest code. I've fixed it for v28.
(Anyone annoyed by this can edit their gameElements/houseObjects/pit and open the various "properties.txt" files in the sub-folders 0, 1, and 3. Add "forceUnderShadows" to each of those property files. Pits will stop floating above the floor!
How about a SELL EVERYTHING button on the backpack/vault screen that sells everything you have in both vault and backpack? Then the Undo button could undo that with one press.
arakira:
ARGGGG.... damn keyboard differences! Sorry about that. Yes, I got your email and will watch (and hints about what you remember are great, because I can often look through the recording with a text editor first and look for the name of a house owner, etc).
Simoon:
Yes, I see that on that tape. More strange stuff that needs to be fixed with visibility. I'm on it!
Well, crowbar is the cost of 6 saws, and 4 torches. Cutting around a door is much cheaper, unless the door has concrete walls around.
BUT, the door/dog combo is weakened by the fact that a dog must see you first and then be able to navigate to the door. So, it's not a total surprise. If you haven't seen a dog, it's safe to open a door.
Well... there's never a bad reason to install Linux, right? :-)
But really, don't do it unless you want to install it anyway. I do have one other Linux tester who emailed me.