Interesting metric

Recently I did a search through some code for the expression "? true : false". Nearly 20 matches from several different developers. At least it's not breaking anything.

Thank you Michael Feathers

Michael Feathers's book Working Effectively With Legacy Code is probably the computer book I get the most use out of. There's a lot of books out there that will tell you the principles of good design but this is the very best book for the more tactical stuff, i.e. how to work with the messy code you're given. This book is full of real word scenarios and practical advice and you can tell it's written by a battle-scarred veteran. Because of Working Effectively, I've been able to improve the design of some of the biggest, messiest, and most convoluted static classes I've run into. When I think of which programing book has been the most useful and mind-expanding for me, this one is tied with the Structure and Interpretation of Computer Programs and anyone who programs should read both.

Postmortem for Twelve Hours

The 2011 7DRL challenge has come and gone and although I finished my entry Twelve Hours, it wasn't as fun or interesting as I expected. I learned some stuff about programming and design as well as game mechanics and gameplay - and I get to write a postmortem!

I knew from the beginning I wanted you to be one of many heroes but I wasn't sure if you'd be on the same team or rivals or what the story would be. It took a few days to come up with the 'defend the village' story and until then there was a lot of changing my mind and trying little changes and general aimlessness. The final game still feels unfocused and I believe much of that is because I was unsure what the story would be for the first %50 of the time. The survival theme also wasn't as fun as I expected. Once while playing Star Craft I remember a heart pounding, grueling, gut wrenching level that ended with me nervously watching the timer count down as the Zerg swarmed my Terran base, demolishing my major buildings and cutting through my inner defense, rushing toward my heroes as my last marines fell to give me the few seconds I needed to win. Playing Twelve hours should have been more like that, or any decent zombie movie right before the good guys bust in and save everyone, but it ended up with me either relaxing in the town center while the villagers fend off ghosts or with me trying to keep up with the fighter chasing down a few stray skeletons. I tried to emphasize the heroes and working together to save the weaker ones by de-emphasizing the stats and inventory options but I ended up with a game where those aspects just feel weak and only partially implemented.

As far as technical learning, this was the first time I used the A* algorithm (I had always used Dijkstra maps) and even though there's a lot of hard-coded junk in there, it went well and I can add that to my toolbox. Creating separate Creature and CreatureController classes was, I suppose, the textbook-correct thing to do, but I found that they are so tightly coupled that they might as well be rolled into one class. I've played around a bit with that and it seems much better. I also got to try deploying my second Java applet (the example for my AsciiPanel project being the first). I prefer C# but chose Java since it works better cross platform and because I found the C# silverlight api to be unbearable. The deployment didn't go perfectly and it seems like it isn't working now so I made it run as an applet or a standalone app - which was neat. The code itself is exactly what you'd expect from a 7 day project; it's thrown together, cut's corners, and has a lot of hard-coded junk, but it get's the job done and hints at how it could be improved.

The 7DRL challenge is a neat opportunity for a small project with a deadline that allows for creativity, comp-sci algorithms, storytelling, and trying new things with code design and game design. It's bigger than a code kata but small enough that it's still good for learning. I'm not sure if the 7DRL challenge is more for the players, the programmers, or the RL community, but I definitely benefit from it as a developer. A lot of neat ideas get explored and it can be great fun for the developer even if the end product is aimless and feels like it hints at more than it delivers.

Twelve Hours, my 2011 7DRL

My 7DRL, initially called Late Start but now called Twelve Hours, is done. You and the other heroes must save the villagers from swarms of undead and survive twelve hours (720 turns). There's 3 different weapons with different properties, 5 different enemies with different abilities, and 6 other heroes with different abilities as well.

Although it's technically complete, and can be entertaining to follow the other heros around, it it often possible to survive by hiding indoors and using villagers as meat-shields while the other heroes bust some undead skulls. That wasn't what I was going for, and you miss seeing what the heroes can do, but I guess that's what the other cowardly villagers are trying to do as well. I seemed to get the best score while protecting the priest or hanging with the samurai.

You can move (arrow keys, numpad, or vi keys) and swap your weapon or armor with what's on the ground ([g] or [,]). You should press [?] when you start to get a better idea of what's going on.



[edit]
It looks like sometimes the applet doesn't work. You can download the jar file and run it on your machine as a standalone app. Technically this was added after the 7 day limit, but it doesn't affect the gameplay.
[/edit]

The other heroes are:

• The Fighter has a better weapon and can go into a rage.
• The Monk can attack multiple times per turn and heal himself but doesn't use weapons.
• The Priest can turn undead and heal others.
• The Samurai has a katana and can do a circular attack that hits each adjacent opponent. The Samurai will also commit suicide rather than being turned into a zombie.
• The Slayer starts with a wooden stake that instantly kills vampires and she heals twice as fast as other heroes.
• The Wizard can teleport himself and attack others at a distance.

The source is on github at https://github.com/trystan/latestart7DRL.

It uses my previous project AsciiPanel for the old-school graphics.

late start for 2011 7DRL

I can't believe I almost missed this years 7RDL challenge.

(I removed the applet since the final version is now on http://trystans.blogspot.com/2011/03/twelve-hours-my-2011-7drl.html)

Nothing special; start screen, random scenery, walking around.

It uses my previous project AsciiPanel and the source can be found on github at https://github.com/trystan/latestart7drl.

Programming for fun

Hspec is fun; at least it has been for me. People are watching the github repository, adding issues, making suggestions, forking, and fixing it. I've even gotten a few emails asking about hspec! I've also learned more about BDD, git, github, good (and not so good) design, Haskell idioms, and the Haskell community.

Even if hspec doesn't make me a better programmer or improve what I write, it's reminded me of how exciting and fulfilling programming and collaboration can be.

Announcing hspec

Announcing hspec - BDD for Haskell

I've long been interested in Behavior Driven Design and it's something that is strangely missing from the Haskell community. QuickCheck is an amazing tool that I use whenever I can, but BDD has it's uses too, even in Haskell.

hspec aims to be simple and there's only three functions that most people will need to use; describe, it, and hspec. Requirements are always about something and describe is how you say what they are about. describe takes the name of something and a list of requirements for it. The requirements themselves have a plain english description of desired behavior and some Haskell code that verifies the behavior is implemented correctly. The function it takes the english description and the verifying code. So describe and it are the two functions that package up something's requirements and verifiers into a list of Specs.

specs :: IO [Spec]
specs = describe "quantify" [
  it "makes single quantities singular"
    (quantify 1 "thing" == "1 thing"),

  it "makes larger quantities plural"
    (quantify 2 "thing" == "2 things"),

  it "makes zero quantities plural"
    (quantify 0 "thing" == "0 things"),

  it "treats negative quantities just like positive quantities"
    (quantify (-1) "thing" = "-1 thing"),

  it "handles words that end with an 'x' (eg box -> boxes)"
    (pending "no need for this yet")
  ]

hspec aims to be extendable so it is part of a type class, making it easy to add your own verifiers such as hUnit. The currently supported verifiers are an expression that reduces to a Bool, or you can use "pending", or you can use a QuickCheck property. The last requirement's verifier is "pending", representing the fact that this requirement isn't expected to be implemented yet so it doesn't have verifier code. That's all you need right there. Since the Specs are just a Haskell data structure you can evaluate them yourself to see what is successful and what is failing, no need for a test runner.

hspec aims to be useful and if you'd like an easy to read report then there's two extra functions pureHspec and hHspec. pureHspec takes a list of Specs and returns a nicely formatted list of strings documenting each spec and it's status. hHspec takes a handle and IO [Specs] and writes to the handle (usually stdout but it could be a file handle)

>> hHspec stdout specs

quantify
 - makes single quantities singular
 - makes larger quantities plural
 - makes zero quantities plural
 x treats negative quantities just like positive quantities
 - handles words that end with an 'x' (eg box -> boxes)
    # no need for this yet

Finished in 0.00021 seconds

5 examples, 1 failure

We see from the '-' that most requirements for quantify are met, the one with an 'x' is failing, and the one with a '#' and extra details is pending since there's no need for it yet. We also get a summary of how long it took and how many specs failed.

I've got some more ideas for it but I think it's simple enough, extendable enough, and useful enough to release to the Haskell community now.

hspec can be found on github at https://github.com/trystan/hspec