The Castle Doctrine Forums

Good point!  Maybe dropping down to $1 eventually is too low...  It seems that starting out at $100K (out of reach for everyone) and dropping down to $10K (reachable for the rich, but it's not like they could afford 50 of them) would be good.  A poor player could still get one by stealing it from the rich.

Running the whole game server-side, step-by-step, is not feasible for loads of reasons.  Yeah, it's a ton of work, but it's also really protocol heavy.  The server currently runs as a PHP/MySQL on a web server.  That means each message is an HTTP request/response.  This is an amazingly simple and easy way to handle this.  I'm not sure if this is the world's first MMO written from the ground up by one person, but if not, it's one of the first.  I was able to get this done in one year by myself because of this approach to client/server communication.

But if you need a message sent for every move that every player makes in the game, I don't think that HTTP request/responses would be feasible for that.  I think you'd need to have an open socket connection for every player in the game.  And that means moving away from PHP/MySQL, most likely.

The win would be... stopping a few people from cheating, assuming that some houses do not have blueprints.  Much more sane to just have blueprints for every house.  Something is lost there (sneaking around a maze), yes.

I'm not convinced that this game is as hard on new players as it seems to be.  I mean, yeah, it is a BRUTAL game, in terms of what it expects from you, but it's brutal even if you're playing by yourself, on a server of one person.

So, in that way, it scares away new players.

But, in terms of interacting with other players, the interaction is so limited.  I mean, in the beginning, for your first few hours, you could fiddle around in your own house, testing it and dying, without ever being influenced by expert players.  (I've seen game recordings of people doing this.  They play FOREVER without even realizing that there are other houses out there.  Then they finally get to the menu, and think, "Whoa, what's this?")

Then you finally leave your house, try robbing someone, and die.  Then you come back and fiddle around some more.  Then you leave again, try robbing, back out, try to come home, and find yourself robbed.  You watch your tape.  One guy robbed you.  Was it an expert player?  It doesn't really matter.  You get to watch how it happened, and you can learn from that at your own pace.  With each "failure," it happens once, and then you have as much time as you want to react to it.

FPS deathmatch is much more brutal on new players... you're constantly beat down by experts.  You hardly even get to play, and spend most of the game waiting to respawn.

I'm thinking that we need a quick video to give new players basic tips.  Like the fact that you can always back out the front door... or that you can test your house with non-lethal stand-ins before you install the lethal stuff...

When you die, you lose everything.  That's core to the game.

Amazing!

Great points here.

Obviously, this space needs a lot of exploration before we can find the right combination of game mechanics that makes the game work on all levels.

The simplest thing is just a value threshold for blueprints.  Hard houses accumulate money over time very quickly, both through dropped loot and salaries that are paid as long as the house remains unbroken.  At the current rate of $140 + $280 (if wife is alive), you earn $10K in a day if your house is not broken.

So, houses with less money simply wouldn't have blueprints, ever.  Of course, if they were actually hard, they would gain more money and get blueprints.

This would also let us bring starting money back down to $2000, and the creepy maze house would return as a viable low-level house strategy.  Then it would rise in value, eventually cross the blueprint threshold, and then get broken instantly.

Also, this would bring back the joy of watching tapes to see people fall for tricks.  That's kindof gone from the current experience.

There's still the lurking problem of cheaters peeking at the map anyway for these low-level houses.  How do we stop expert players from doing this and "ruining" the game for beginning players?  Maybe ignore this edge case?  Ugg...

Certainly, disabling the protocol print-out would make it a bit harder for most people (would require a real mod to see the map).

I've also thought a LOT about segregating the community into two servers, etc.  The problem is that the community isn't large enough yet to make this viable.

In the last 24 hours, 125 people have visited their house.  In the last hour, 8 people have visited their house.

Okay, upped it to $140 + $280.  We'll see what that does.

From the code:

.
        // make sure that all looping elements "settle down" into a 
        // consistent state (otherwise, we see various flip-flops due
        // to propagation times elsewhere in the map)
        
        // in case of looping, all elements involved in the loop settle
        // down into the lowest-seen state number that they encounter 
        // during execution of the loop

So, when a loop is detected in power transmission (state keeps changing with each propagation step, but keeps returning to the same house-wide state somewhere in there over and over), then the transmission simulation is run a few more times through the loop, and all elements are watched for their lowest-seen state number during the looping process.  That is the state they are set to, individually.  So, in this case, the inverted switches here are set to their "untripped" state, and the wires and things on the other side of them are set to their "unpowered" state (those happen to be their lowest state numbers as seen through the looping process).

Yeah, it looks inconsistent.  But the point is that ANY visualization of this would look inconsistent.  Let's' say the light past the north-most inverted voltage-triggered switch (IVTS) was ON instead.  Well, that would mean that there was power on that wire that loops back, which would mean the north-most IVTS should be tripped (so that part would be inconsistent looking).  And if we tripped the switch visually AND had the light on, that would look inconsistent too (how is that light and IVTS getting power?).  And if we tripped the switch visually and had the light off (how is that IVTS getting tripped)?

So, the code says:  if we have to display something inconsistent, at least make it predictable (everything drops down into its lowest-seen state in the loop... which is always its powered-off state).

I agree that this stuff is REALLY confusing.  Then again, low-level electronics in real life is quite a bit more confusing than this....

Something much less confusing is using a non-inverted VTS to make a simple set-and-hold flip-flop.  This doesn't involve any inconsistencies.

I also realize that some people (ahem, Mr. Zed) are using some of these "nuances" to make really hard houses that have remained unbroken for days.  I'm pretty sure that the only way to make progress in cracking such houses is to replicate pieces of the circuitry in your own house and play around with it to figure out how it works.

Yeah, something like this is coming.  I just need to figure out how to do it to make it legible.  I've thought about doing it with a different color, but I'm not sure that I like that (because I like the consistent look of the blueprints).

Good points!

Interesting that (iv) is only a problem for paintings if someone "tripped" the only-rob-once house by reaching the family (thus saving the house state but not getting the paintings).  If a house becomes unsolvable after a vault run, then the paintings aren't there anymore.

I like the rich/poor binary that you suggest.  Thematically rich.  However, it might be harder for people to get their head around.  A slow decay with each new life would be noticed gradually... like, "Hey, didn't I start with $6000 last time?"

Yeah, dog must step off first, then step back on.

Obviously, this means some houses can only be robbed once (but they must be fixed up by their owner before the owner can resume playing the game).