[news] [forums] [wiki] [buy] [Steal Real Money]
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]