[news] [forums] [wiki] [buy] [Steal Real Money] [Crypto Tokens]
Changing the direction of the game (and v9 released)
by jasonrohrerFriday, June 14, 2013 [10:57 pm]

Several public releases and several thousand players later, I took a hard look at what The Castle Doctrine had become, and I realized that it had veered off in a troubling, unsustainable direction.

My original goals for the game were as follows.

I wanted to make a game where players generated content, but where that content actually mattered to gameplay. Where that content was the gameplay.

The house design side would naturally be whatever it would be: players would strive to design a house that would keep robbers out in the most effective way possible. Designs would evolve over time as players discovered this or that emergent combination. I always imagined that the house design side of the game would quickly blossom into something beyond what I could imagine, so I didn't spend too much time trying to imagine it (people have built working CPU logic in Minecraft, so the sky is really the limit).

http://thecastledoctrine.net/newsImages/v9Announce/minecraftALU.jpg

But I had very specific goals for the robbery side of the game. Yes, the robbers would obviously be trying to overcome whatever fiendishness the best homeowners had devised, but they would be able to overcome it tactically. They'd sneak through a darkened house, peering around corners, and pressing their luck. A poke here, a cut there. Trying to find and exploit a weakness in the design. Cutting through in exactly the right spot and finding themselves behind the scenes, exploring the inner workings of the house, like going behind the walls at the end of Portal. With permadeath always one mistake away, this would be a tense experience. But with enough explorative poking and cutting, over multiple scouting trips, any house design would eventually be vulnerable to a successful break-in. "Aha! If I just cut through these wooden walls, snip this wire, and throw this brick across the pit to hit that switch, I can get to the vault."

And that's how I envisioned the two sides interacting. No homeowner would be safe forever. This would be a game about vulnerability and violation. Yes, some would rise to the top, but only for a short time, since being at the top would mean that the attention from robbers would increase. Through skill, opportunism, and some "right place at the right time" luck, a player might rob a few small houses, gaining enough money to buy tools to rob a few bigger houses, and so on, climbing carefully up through the ranks---a kind of meta-layer of tactical gameplay, a Roguelike where the dungeon-tower was built by other players. But they'd get to the top only to be knocked back down by another upstart with less to lose. Then they might climb again, building a house that would prevent the kind of break-in that got them last time. An endless, every-cycling arms race between robbers and homeowners, where the landscape is always changing and no optimum exists for either side.

http://thecastledoctrine.net/newsImages/v9Announce/cod1.png

As owners start building more wood walls, robbers start carrying more saws. Then some smart owner notices this and starts building metal walls. This trend builds, an then robbers start carrying more torches. In response, homeowners might move on to concrete, and robbers explosives. In which case owners would switch to dogs, and robbers to guns, and then back to wood versus saws, or pits versus ladders, or a mixture of dogs and wood versus a mixture of guns and saws.

http://thecastledoctrine.net/newsImages/v9Announce/metagame.png

The system would remained balanced by the fact that both obstacles and tools cost money, and money is scarce. Furthermore, since every homeowner needs to get through their security with no tools at all, every house would have certain vulnerabilities that skilled players could discover and exploit.

Okay, that sounded pretty cool to me! So, I tried to build that game.

It's pretty clear, though, that the current state (v8) of The Castle Doctrine does not match the above vision. So what happened over the past 3 months since the first public release?

Shortly after the initial alpha launch, things were pretty great. Homeowners were trying out this and that, discovering little emergent design combinations, and generally making really cool, clever, and interesting houses. Robbers were sneaking around nervously, poking this and cutting that, and eventually breaking through every house. Wealth and paintings were passing from player to player and different kingpins rose and fell.

But in less than a week, something very big happened. A rather wealth player made some wooden walls that were 9 tiles thick. Since a backpack only has 8 slots in it, and can thus carry only 8 saws, a robber cannot cut through such a wall. At first, this didn't seem like such a big problem. After all, every house has to be solvable without tools (as demonstrated by the owner). So, there's still a way to get to the vault in such a house---just not a way that involves cutting. Of course, the 9-wall-thick idea spread quickly.

http://thecastledoctrine.net/newsImages/v9Announce/cut8Deep.png

Shortly after that, however, something else big happened. A rather clever player devised the first push-button combination lock. 9-tile-thick walls protected the internal logic, and a robber would be faced with pressing the right subset of 16 buttons in order to pass through a 9-door-thick corridor to the vault. Yes, it's possible to reach the vault with no tools. But if you don't know the secret pattern, it might take you 65,536 guesses. This idea also spread quickly.

http://thecastledoctrine.net/newsImages/v9Announce/comboLock.png

Shortly after that, someone devised a 22-button combination lock (over 4 million possible combinations to try). This was essentially overkill, though, because the 16-button one was unbreakable, in practice (the top houses had a few hundred attempts, at most). You know, if each attempt takes even as little as one minute, you're looking at 44 days of non-stop, no-sleep trying to break a 16-button combination lock.

Finally, a very clever player figured out how to build an effective combination-style lock for only $1400 by exploiting an electric floor loophole. Given that each player receives $2000, for free, when they start from scratch after permadeath, this meant that unbreakable security was now available to even the least-wealthy players in the game.

http://thecastledoctrine.net/newsImages/v9Announce/cheapComboLock.png

A few weeks later, there were pages and pages of houses employing some variation on the combination lock, and they were all sitting there, unbroken. Yes, there were some lovely little innovations along the way, but they were all uncrackable, in practice.

For robbers, the experience of entering such a house involved very little sneaking, poking, or cutting. No tactics were employable. If you were foolish enough to even try, you'd push a few buttons before realizing hopelessness and facing your death (one lovely innovation: pushing any button at all traps you in the house, so you must enter the correct combination, or press nothing at all, to survive). The smarter players would see a combination lock and leave.

Thus, the robbing side of the game degenerated to picking away at the broken or abandoned houses lurking at the bottom of the list, and skipping pages and pages of houses to find them.

From my perspective, players had pushed the game in an interesting and unexpected direction: they were getting so good at the game that they seemed to be designing real locks, tile by tile. Security through puzzles. So this was a puzzle game, after all, and not a tactical game!

I was a little uncertain about this, but there seemed to be no way around it: even if I doubled the backpack size, puzzles would still be possible with 17-thick walls. And making the backpack even bigger than that (like 30, the width of the map) would be unwieldy and also completely subvert house design (if you could plow through any obstacle by cutting, what would be the point of designing a house at all?).

Still, there was a huge problem: hidden information (through limited visibility) meant that practically-impossible puzzles were easy to make.

Amid deep community worries about ruining the game, I thought about ways to reveal this information. I didn't want to spoil the "sneaking around a dark house" feel that the visibility shroud creates, so I wanted a source of information that was separate from the robbing view. Blueprints seemed thematically appropriate: suppose you could study a house design in its entirety, before you even stepped in the door?

http://farm9.staticflickr.com/8276/8882715330_1fe2192d26_o.png

Combination locks would be easy to bypass, since you could see the otherwise-hidden logic of their inner workings. But would this ruin puzzles in the game? I knew that the answer to this question was provably "no" through some very dusty memories from computer science classes long ago. Any suitably-powerful formal system can be used to encode expressions from other formal systems. Thus, provably hard-to-solve problems (from logic, for example) could be encoded into Castle Doctrine maps in a way such that reaching the vault on the map would provide a solution to the encoded problem. Essentially, there was no limit to how hard a Castle Doctrine puzzle could be, even with no hidden information.

And sure enough, with the advent of blueprints, top-house puzzle complexity exploded, getting harder as needed. At one point, a house remained at the top of the list for a full week before it was solved. So, the puzzle aspect of the game wasn't ruined by full information. At that point, I realized that puzzles rarely have hidden information, almost by definition. Hidden information turns a puzzle into a trial-and-error guessing game.

http://thecastledoctrine.net/newsImages/v9Announce/rubik_blindfold.jpg

But something else happened in response to blueprints: the game world was split in two, with one small portion pushed way up, and the rest of it pushed way down. If you were clever enough to design a really hard puzzle (basically requiring that you be a practicing electrical engineer---even I had trouble doing it), then you could keep people out for a long time and prosper in the game. Everyone else, however, would design a house that would be broken right away through the reveal of its internals. These players, who were also unable to crack the hard houses, had nothing worthwhile to do and left the game. The remaining engineer-type players were secure in their puzzle-fortresses with too much to lose, so they couldn't even risk robbing each other.

Every once in a while, after time passed for sufficient study, one of these top houses would be solved. But doing so required days of painstaking work on the part of the solver. I'm sure those final moments of victory were some of their most exquisite game experiences, but that experience was out of reach for almost everyone, including me (I spent several hours trying to figure out one of the top houses, only to eventually resign to the fact that it was beyond my capabilities).

http://thecastledoctrine.net/newsImages/v9Announce/crackingHardHouse.png

So, it was clear that something had to change, but what? I could remove this or that feature to limit puzzle design in this or that way, but it was clear that anything short of drastic limitations would still allow sufficient complexity for provably-hard puzzles to emerge. I certainly didn't want to make a game with no wiring, but even then, a maze with moving animals might be enough for provably-hard puzzles. Chipping away clearly wasn't going to work.

I was also uneasy about the way blueprints had changed the feel of the game. You were no longer sneaking your way through a mysterious house, coming around corners and being shocked by what you discovered. You saw it all up-front, so you knew exactly what to expect.

Still, without blueprints, combination locks would rear their heads again, right? And what about real puzzles, where hidden information has no place?

Then I realized something: I never wanted to make a puzzle game here. Looking back through my notes from the fall of 2011, the word "puzzle" does not occur. But the game grew into a puzzle game, and I fostered that. My original vision of a tactical, player-generated, Roguelike, every-cycling arms race was nowhere to be found, though. Was there some way to get it back?

The problem, it seemed, were puzzles. Puzzles aren't tactical and in-the-moment. They're about studying something from the outside and discovering the one, correct solution, and then applying it. But if players can design anything they want, won't they be able to make puzzles? Well, only if they can somehow force other players to solve the puzzles. The 9-thick wall trick was the first step taken in this direction: "You cannot bypass my buttons now. You must figure out how to press them correctly to pass."

What if there was some way to bypass anything, eventually? Then the keystone of the problem became clear: the 8-slot backpack (or the N-slot backpack). What if players had infinite backpacks? Well, then they'd just plow through everything and not even need to think. But what if there was a way to balance it so that there was an enormous cost to doing this?

First of all, what if tools were much more expensive? Then you'd certainly think before you'd use one. But still, you might as well fill the backpack to the brim for every outing. Then you'd have plenty of whatever you'd happen to need. You might think a bit in order to conserve tools, but every house would be crackable in one go, and you wouldn't make any hard choices about what to carry. No cycling arms race. That's what the original limit of 8 slots was for---to force hard choices. But house designers exploited that known limit to the point where tools became useless (no choices at all).

So, there has to be some cost to a brim-full backpack. What if unused tools are lost at the end of every robbery? So if you bring 100 saws, but there are nothing but concrete walls, you're really screwed. You'd need to scout, and plan, and think, and come in with just a few tools to scout some more, and then finally load up with exactly the right combination to get through the house (and then perhaps find that the owner made last-minute changes that screw you).

And thematically, this makes some sense. You need to empty your backpack to carry out the loot. And if you run out the door without taking anything, you're in such a hurry that you ditch your backpack. Even more interesting: what if the extra tools you ditch end up in the owner's vault?

This has the nice side-effect of bringing a cost to scouting that seemed to be missing. It also helps to grow the prize in a well-scouted house, and can leave a victimized owner with a little something as a bootstrap (the extra tools left by the robber who reached the vault).

Of course, there's a sticking point that prevented me from seeing this solution all along: an infinite backpack isn't realistic. But this game wasn't meant to be realistic, obviously.

http://thecastledoctrine.net/newsImages/v9Announce/infiniteBackpack.png

Thus, with a great hopefulness, I give you version 9 of The Castle Doctrine. A game with hidden information and soft puzzles, where with enough money, you can buy your way through anything, but where money is so scarce that you'll end up thinking your way through most things. Where you'll sneak around corners, make tactical decision, and try to take subtle advantage of current trends. And where you'll die. A lot. At least that part hasn't changed.

A full list of changes can be found here:

The Castle Doctrine Change Log



Discuss this post in the forums

[Link]



Try the new Perma-Permadeath Server
by jasonrohrerTuesday, June 4, 2013 [4:56 pm]

NOTE: the perma-permadeath server has been taken down for a bit while I focus on the version 9 release. It will be coming back at some point in the future.


Version 8 of The Castle Doctrine was released today. It adds a few minor improvements, like an "Un-Ignore All" button to reset your house-ignore list, and pencil scratch marks in blueprints to indicate objects that have been damaged.

But the biggest change is server support for perma-permadeath. As in, alternate-world servers where each user can only die once. I'm guessing that people will play the game differently on such a server, but I'm not quite sure how behavior will change.

I've set up a temporary perma-permadeath server to test this. As soon as you connect to this server, you will be given a single life and $6000. All other rules are the same. Note that this server operates a completely separate game world, including a separate set of paintings and a separate list of houses. Whatever happens on this server stays on this server, and it has no effect on the main server.

If you want to give it a try, here's how:

  1. Make a full copy of your v8 game folder to a different location.
  2. In the copied game folder, use Notepad (or TextEdit on Mac) to open settings/reflectorURL.ini
  3. Change the url in that file to http://thecastledoctrine.net/reflectorPerma/server.php (just add Perma after the word "reflector")
  4. Save the file.
  5. Launch the game from the copied folder.

At that point, you should see a brand new, empty house, and find yourself operating in a separate game world.

And as soon as you die, your time in that separate game world will be over, permanently.



Discuss this post in the forums

[Link]



Version 7 Released
by jasonrohrerWednesday, May 29, 2013 [8:28 pm]

This is a small update that fixes several issues that popped up in version 6. The most noticeable improvement here is in the shading of walls in the blueprints. Consider this blueprint from v6:

http://farm6.staticflickr.com/5458/8882715274_9c760a182f_o.png

See how the snaking walls are hard to read? What is wall, and what is empty floor? In v7, with wall shading, reading this blueprint is much easier:

http://farm9.staticflickr.com/8276/8882715330_1fe2192d26_o.png

There's also a new "Ignore House" button, which lets you hide an uninteresting house from the list. The house will reappear on your list whenever it changes in a substantial way.

A full list of changes can be found here:

The Castle Doctrine Change Log



Discuss this post in the forums

[Link]



Version 6 Released
by jasonrohrerFriday, May 24, 2013 [11:11 pm]

We're now a full two months into the public life of The Castle Doctrine, and over 3500 people have joined the alpha test so far.

With all this data about player behavior in hand, I've made some substantial changes to how the game works. Obviously, there are dozens of little tweaks and bug fixes that hardly deserve mention. But you'll certainly notice the following major changes right away:

  • Family members now wait in place until they spot the robber before they flee to the exit. This makes protecting them much more practical, since a determined robber cannot simply pace back and forth by the door until they come out.

  • Free blueprints are available for each and every house in the game. You can now study a house beforehand to plan your robbery or consult the blueprints during a robbery. Simple guessing-game houses (like the 16- and 24-bit combination locks) are no longer viable security strategies. Real puzzles are still viable, however.

  • Mod-based cheating has been thwarted by running a game client server-side to verify all submitted robberies and house self-tests. Cheats based on protocol sniffing (snatching the map of a house) has been thwarted through the availability of blueprints.

For an example of blueprints in action, consider this view from inside Michael Scott Lee's house:

http://farm8.staticflickr.com/7441/8821861716_504c18bbaf_o.png

Four doors. Which one to pick? Check the blueprint:

http://farm6.staticflickr.com/5461/8821861754_de698fa973_o.png

Aha! Pit bulls. Door number 3 it is.

Smaller improvements include updated wiring, new indicator lights, control-click to eyedropper a tile while editing, multi-word name search, selling multiple items in one click, and more intelligent paging through house lists. The full list of changes can be found here:

The Castle Doctrine Change Log



Discuss this post in the forums

[Link]



Calling all Cheaters
by jasonrohrerWednesday, May 1, 2013 [1:01 am]

The Castle Doctrine server is now using a robust robbery simulation and verification system.

The server is essentially running a copy of the game client itself, and for each robbery (and house self-test) submitted, it passes the move list and map to the server-side client. The client runs the robbery with that move list and computes the result, returning that result to the server.

This allows the server's simulation of a robbery to match the game's behavior exactly (because it's running exactly the same code). Furthermore, it means that when I want to modify the way the game behaves, I only have to change the code in one place (the game client). In other words, there is no duplication of the game rules in the client and the server.

This also means that if you mod your client in a way that substantially changes the rules of the game (in other words, you cheat), your robbery results will not match the results of the server-side simulation, and the server will reject your robbery results, killing you in the process.

Mod-based cheats that plagued the game are now a thing of the past---walking through walls, moving after death, and so on. Yeah, you can still do it, but the result is that you will steal nothing in the process and end up dead.

The server-side simulation even forbids tool use after death (possible through a bug in the v5 game client), so be careful if you're thinking about exploiting this v5 bug for gain or laughs (you'll end up dead).

Finally, I've had a change of heart regarding the eleven people who were banned for excessive cheating in the past. It was their activity that eventually motivated me to take on this rather daunting programming challenge. It's done now, and the game is much more robust, in part thanks to them. So, I'm inviting all the cheaters back and unbanning them.

It's possible that the server-side simulation misses some potential exploit (or that it wrongly rejects valid behavior). I'm hoping that the former cheaters will return with their modded clients and really try to punch some holes in the new system. If you find an exploit, please report it to me! You will no longer be banned for trying to cheat.

Cheating should now be impossible, so if you can cheat, that's a bug that I need to fix.

However, keep in mind that if you find a hole, you shouldn't try to exploit it repeatedly at the expense of other players. Remember that each person who was banned didn't just cheat---they each cheated excessively and hurt many other players in the process. Damage done in The Castle Doctrine represents real harm to someone else in the world (hours of hard work lost).

So, help me find it and fix it instead.

Discuss this post in the forums

[Link]



Starting work on Version 6
by jasonrohrerWednesday, April 17, 2013 [7:37 pm]

During the past month, over 3000 people have tested the living daylights out of The Castle Doctrine. Thank you all for your patience while I worked through various issues and growing pains, and thanks for all of the reports that you have sent me. I received over 400 emails, and I have now answered each and every one of you personally.

I've fixed a bunch of server-side issues already (those that don't require a client change), and there are a few more of these to deal with. The biggest one is server-side robbery verification, which will eliminate all problematic types of cheating. The server will be running a copy of the client and then pass that client robbery logs to verify (this eliminates duplicating game logic in the server code).

From all of the reports, I now have a long list of things to fix that will require client changes, and that means it's time for me to get busy working on version 6. Obviously, there are a bunch of little bugs that need fixing, but there are also some major overhauls in the works, including:

  • Improving family behavior so that it's actually possible to protect them.

  • House blueprints for robbers, to push house design away from the guessing-game realm and into the real-puzzle realm (and eliminate the viability of 24-bit combination locks).

  • Being able to watch security tapes without fixing up and re-testing your house first.

I've got a lot of work to do.

In the mean time, I'm still interested in hearing about bugs that you discover. Check the list of known bugs in the forum first, and if you've found a new one, please email me.

The same goes for incorrect server-side behavior. If the server is killing you because of an error, I want to know about it by email.

In all cases for bug reporting, please include your most recent recordedGame file and (if you're on Windows) your stdout.txt file.

Discuss this post in the forums

[Link]



Return from GDC
by jasonrohrerTuesday, April 2, 2013 [8:10 pm]

After a long and busy trip to San Francisco for the Game Developers Conference, I'm back home and working on The Castle Doctrine again.

I had a huge backlog of Castle Doctrine emails before leaving for the conference (300), but I'm making progress. I will write back to everyone soon.

In the mean time, I've set up forums and a wiki.

And, in setting up the forum software, which recommended an InnoDB database engine, I realized that my MySQL server installation had InnoDB disabled. Which means that all of the locks in my code (which prevent two players from checking out the same house simultaneously, among other things) were simply not working. Thus, there were a number of mysterious bugs happening on the server over the past few weeks that should have been prevented by locks (but weren't being prevented). Great that MySQL lets you request an InnoDB table, and silently creates a MyISAM one without warning you! On my test machine at home, InnoDB was enabled, and that's where I originally tested all my server code to make sure two players couldn't access the same house at the same time.

I've turned on InnoDB on the main server, and upgraded all the necessary tables to that engine. So, the mystery server bugs (like, robbing a house, but failing to complete the robbery at the end) should mostly be gone now. BUT, now that the database is supporting real locks, there are a few deadlocks happening, which results in unexpected responses from the server. If this happens to you, please quit immediately and email me your last recordedGame file.

[Link]