Chris Holmes Online

In early 2004 Atari released a Troika game called The Temple of Elemental Evil. It was subtitled as “A Classic Greyhawk Adventure.” Originally, The Temple of Elemental Evil (abbreviated as TOEE) was a module, released in 1985, for the pencil and paper Dugeons & Dragons game. Fans of the pencil and paper version of D&D always loved the TOEE module, and hoped it would one day be reincarnated as a video game, especially given the success of certain roleplaying computer games like the Baldur’s Gate series.

The catch in all of this was that many pencil and paper roleplayers often disliked the way computer games translated the D&D universe.

Video games are a different animal than traditional pencil and paper roleplaying games. P&P games were designed to be played at a table, with friends, and often involved long nights, lots of pizza and Mountain Dew. D&D in the pencil and paper era was as much a social event (if not more) as it was a game.

Video games changed all of that. Baldur’s Gate, and it’s wildly successful sequel, Baldur’s Gate 2, were single-player games. The social aspect of D&D was dropped and computerization took over. The result was a mixed bag. While Baldur’s Gate was a really fun video game (and one of my favorites as well), it was not what many old school players considered as true D&D. The biggest complaint from D&D fans was that the combat happend in real-time, as opposed to the turn-based nature of a P&P game. Yet, because of the success of games like Baldur’s Gate, nearly every other roleplaying game to hit the PC has utilized a real-time combat engine.

Enter Troika and The Temple of Elemental Evil. The developers for TOEE decided that it was time for a computer roleplaying game to finally deliver a product that emulated the pencil and paper experience. Combat in TOEE is turn-based, and as much as possible, every single rule and detail in the Dungeons and Dragons handbook was coded into the TOEE engine.

There was just one problem. Atari wanted to publish the game too quickly, and it flat-out was not ready. With their feet held to the fire, Troika pushed the game out the door in an unfinished state. What resulted was one of the worst game publishing nightmares of all time. TOEE was one of the most bug-ridden pieces of software ever to hit store shelves.

Fans who had waited for a turn-based Dungeons and Dragons game were at once elated, and then mortified. The game had the mechanics correct; it was a thing of beauty from a purist point of view. But it was littered with so many bugs, flaws and glitches that it was virtually unplayable, even after several patches from Atari. The Temple Of Elemental Evil looked like it could have been one of the greatest roleplaying games of all time, but a poor decision to publish it before it was ready killed the potential for the game.

But the story isn’t over.

Just when things looked grim, the Circle of Eight showed up, a group of fans with coding and hacking skills and a passion for Atari’s butchered game. They loved the game so much, and realize it had so much potential, that they spent their free time trying to reverse engineer and demystify the TOEE game engine. They worked tirelessly to modify it, and in the process turn a turd of a game into something worthy of every D&D fan’s PC gaming shelf.

The end result? This past July the Circle of Eight released their final patch to update The Temple of Elemental Evil. While they weren’t able to fix every bug (you can only tweak things so far without access to the source code) they did a fine job of modifying the game and bringing it out of the deep hole that Atari had cast it into.

I just finished playing through the game with the Circle of Eight’s final patch, and the improvements are amazing.

For the longest time I’ve considered the Baldur’s Gate series of games to be the best Dungeons and Dragons roleplaying games ever made for the PC. And in terms of story and character they still are. But The Temple Of Elemental Evil is the only game I’ve ever played that gets the turn-based combat engine correct. It is perfect in every way.

I know in our fast-paced, reward-me-now, instant-gratification society, turn-based combat isn’t as popular or stylish as real-time combat. But after playing through The Temple of Elemental Evil with the Circle of Eight patch, I can honestly say I prefer roleplaying games, at least in the Dungeons and Dragons universe, to utilize a turn-based combat system. It saddens me a bit to know that future games (for instance, the upcoming Neverwinter Nights 2) will not be utilizing a turn-based engine for combat.

My hope is that somewhere a roleplaying developer gets a chance to play this patched version of The Temple of Elemental Evil. In fact, every developer working on a roleplaying game for the PC ought to play this game. At least see how it feels. It’s a totally different experience.

Which brings me to my last point. In the latest issue of PC Gamer Magazine, one of their columnists wrote an article about (paraphrasing the exact title here) “Five things the developers of Fallout 3 can do so it doesn’t suck.” He had some basic, common-sense advice for the developers of Fallout 3. But nowhere in the five suggestions did he mention turn-based combat.

So, let me do it. Fallout, and it’s sequel, Fallout 2, are generally regarded as some of the best Roleplaying Games to ever hit the PC screen. And those games exclusively used a turn-based combat system. Due largely to this design decision, the Fallout games provided a much more strategic and rich combat experience.

Please, whoever you are, whoever is responsible for developing Fallout 3, strongly consider utilizing a turn-based combat engine. Moreover, please take a look at the way The Temple Of Elemental Evil handles things like Area of Effect and in-combat distance.

It would be a shame if the maligned, patched version of Atari’s game is the last, good turn-based game we PC gamers ever see…

I was on my way out the door today, Friday, the most enjoyable work day of the week because it’s the last one, when I decided to give ESPN.com one more pass. I stumbled upon this column written by Scoop Jackson, the same Scoop Jackson that I took issue with last year.

Scoop is upset because one of his idols, Jason Whitlock, a famous black writer for the Kansas City Star, ripped him publicly. Scoop doesn’t try to understand why Whitlock takes issue with him and his work, and instead takes the approach that Whitlock doesn’t “get” his “words”.

Wrong conclusion Scoop.

Here’s my guess as to why Whitlock dismisses Scoop so harshly and in such a public fashion. It’s probably the same reason I dislike him too: Because he makes race an issue every single time he puts his thoughts down on paper. Scoop sees the world through tinted glasses; a world where black people are always at a disadvantage and white people are to blame. When Scoop Jackson writes about sports, he writes about race, and one doesn’t even have to read between the lines to understand the sheer venom and hatred Scoop has for the white race – it oozes off the page like ectoplasm.

Some of us white people grew up in households where we were taught that race didn’t matter. We grew up colorblind, believing that the good or evil of the person, the intelligence or ignorance, kindness or selfishness, had nothing to do with skin color. Yes, I’ve experienced racism; I’ve heard white people say things that made me very angry to be of the same color. But I recognize that for exactly what it is: ignorance. And just like there are white people who hate based on color, there are black people who hate based on color as well. I’ve experienced that too; I’ve had a black man want to beat me down simply because I was white. The thing about racism is, it doesn’t discriminate. Anyone is free to hate anyone else based on color or nationality, and unfortunately, some people do just that.

But the issue here is Scoop. When he writes, it reads like racism. It smacks of hate. It’s not sports that Scoop is writing about, it’s racism, 24/7. And for a lot of us who grew up colorblind, listening to our ignorant bretheren flap their jaws with racist remarks, the words of a person like Scoop Jackson make us pause. More than anything, they make us aware that hate based on color still exists, and the door swings both ways. Hateful, hurtful words from Scoop, whether blatant or veiled, feed the cancer of racism that permeates our nation.

I honestly want to forget about race. I want my kids to not even recognize that someone is of a different nationality or color. I just want them to see people. Good or bad, good hearts or meanspirited, but I want them to see people and not color. I want race to be a non-issue. And the only way that’s ever going to happen is if we work collectively, as a species, to ignore race. Journalists like Jason Whitlock have done that; they’ve moved beyond race. Whitlock isn’t a great black sports journalist – he’s just a great sports journalist.

Scoop Jackson is still staring the “black” part of his title; he can’t decide whether to be proud, angry, or both.

As long as Scoop Jackson keeps making race the focal point of every article he writes, racism won’t go away. And Scoop will continue to be perceived by people like me as a racist. And journalists like Whitlock will continue to dislike what Scoop does professionally.

So here’s my advice, Mr. Scoop Jackson: turn off the internal hate machine. Whatever it is at your core that’s made you see the world through racist eyes, just get rid of it. Quit making race an issue every time you fire up your world processor. Think about sports, and not race, when you write. Most importantly: just stop seeing color. Because the more people quit seeing color, the faster we’ll get out of this barbaric social stage we’re in.

Kent Boogart just released his first drop on an implementation for CAB and WPF. As cool as that is, that’s not what this post is about.

This is my first time reading Kent’s blog, and he brings up an interesting topic: Unit Testing in .Net. He shines the light on some troubling areas regarding unit testing in the .Net framework, and offers up a wish for a potential solution. I’ve had the same concerns he’s voiced, but in recent weeks certain tools have come across my desk that have helped me solve these problems.

First, Kent talks about unit testing internal methods:

Inevitably I’ve found the need to expose internal members for testing purposes only.

Anyone who’s been around this Unit Testing circle for a little while knows there’s been a huge debate about whether to unit test private/protected/internal methods or not. Protected members are easy enough to unit test – just subclass the class under test and expose the method you want to test. But private & internal methods are a bit tougher. Part of the debate isn’t just “should you” test private methods, but “how can you test” private methods.

Well, there’s a solution, and it turns out it’s pretty elegent. Tim Stall has written an article over at CodeProject that shows just how you can unit test private methods without any alteration to your production code at all. With a slick use of Reflection, you can unit test private methods until your heart is content. It also works for internal methods.

I simply took Tim’s methods and wrapped them in a class I call TestClass, and then all subsequent NUnit test fixture classes inherit from it. At any time, if I want to test a private or internal method in the class under test, I just need to make a call to the RunInstanceMethod or RunStaticMethod in the base test fixture class, passing along the proper type, method name and parameters. Very slick, very easy. Sample code:


// In class MyObject...
private string GetMyName(string first, string last)
{
return first + " " + last;
}



[Test]
public void Test()
{
MyObject myObject = new MyObject();
object obj = RunInstanceMethod(typeof (MyObject), "GetMyName", myObject, "Chris", "Holmes");
Assert.AreEqual("Chris Holmes", obj);
}


Now for a personal commentary on this approach: I’ve long wanted to be able to unit test private methods directly. I felt like ultimately it would (a) make the code writing process easier and (b) give me more confidence in the code. However, after actually doing it with the Reflection method, I find myself torn between this way and the “test private methods through the public interface” camp.

I’ll explain.

The reason I don’t like testing private methods is twofold. First, I really am only interested in the public API and whether it works or not. I don’t care how my private methods manipulate their variables or data, only that they arrive at the correct results, and I can test that through the public interface. Now, the downside to that is the intagibles that testing brings to an application: confidence that the code has been exercised/tested and works. That said, with a code coverage tool like NCover I can achieve that confidence. It allows me to see the lines of code being tested, and that lets me know if I’m not reaching any code (and thus I need to write additional tests to reach those lines). In fact, I rather like the code coverage tool because I find it aids me in writing test cases against the public API to ensure I’m exercising the private methods.

However, I can see a benefit to testing private methods directly, and it is this: decoupled methods. I don’t see a lot written on this topic but I think it’s important. Inside a class you can end up with a lot of private methods manipulating member variables without having them passed as parameters. This leads to high method coupling, something that seems like a “code smell” to me.

When you’re testing through the public API and only the public API, you can write some very highly coupled private methods. You’ve probably seen classes like this; you may have even written a few (I know I’ve written my fair share). Assuming you think that’s a bad thing (and I sort of do) then being able to test those private methods directly will steer you toward loosly coupled private methods that take explicit parameters and provide explicit return values. So, in that sense, I really like the idea of testing privite methods.

Bottom line: At least now there’s an answer to testing private methods. With Reflection, you can unit test private methods until your heart is content. Whether you want to do that or not is now truly a philosophical debate. At least the “how” part has been answered

This subject somewhat leads into the next thing that Kent laments about, which is code coverage:

What’s more, no combination of frameworks and techniques I’ve found allows you to perform close to 100% code coverage without hacking your code base.

Well, with the Reflection capability, I think it’s now possible to get there without hacking your code base. But maybe more importantly, I think you can get 100% code coverage simply by unit testing through the public interface, and utilizing a variety of custom mock objects to reach all possible cases (more on mocks further down). The big issue here, as I see it, is: do I have a test case to exercise these particular lines of code, and if I don’t, then why not? Most often this seems to me to be related to not having a mock object in a state that will actually cause those lines of code to execute, and thus test if they work.

Another point Kent raises is this:

In other cases I’ve found mock libraries limited in what they can mock because of the fact that they typically generate a separate assembly at runtime.

Like Kent, I’ve tried most mock frameworks. After working with them, I’ve decided on the following: Mock frameworks stink. It’s not that they’re bad, faulty or don’t work – they do exactly what the authors describe and that’s theoretically a great thing in this bold new world of automated testing. But the reason why I think they stink is because of the setup involved with making a single mock object work. It just takes too darn much code to setup a mock object under test with all the expected results, and even then you’re really limited in the information you can get out of the mock object, because it’s going to match the signature of whatever it is mocking.

Why not just use the real object with a bunch of dummy data? Better yet, let’s use the real object and add to it, providing properties that give us information on changes made to the state of the data. We can track method calls, state changes, anything our heart desires, and with little effort. I see this approach used a lot when people are testing views in an MVP/MVC scenario, where they will implement a quick boolean flag to ensure some aspect of the view is properly called at a certain point in time, or expose a public property so they can check data that is passed. But when it comes to testing other objects in their application they seem to turn to a mock framework instead, which through my experience has been more complicated.

And so what we’ve started doing is mocking our own objects, and not relying on a dynamic mock framework to provide us our mocks. Our application, like many real world business applications, is very data centric. Lots of domain objects and services being used by the parts of our application that we would like to test. Instead of mocking these things with a mock framework and setting up every expected result in tedious fashion, we just build the actual mock objects ourselves in a testing library using the interfaces, abstractions and classes we’ve written. It doesn’t eliminate the tedium of setting those objects up, but it does give us the power to do more with those mock objects.

Since we have 100% control of the “mock” objects we’re implementing, we have access to the internal guts of the things; we can expose additional properties and methods that allow us to check and ensure state changes happen when they’re supposed to happen, at the moment they’re suppose to happen. We can, in essence, create the real object with additional capabilities that make it more valuable as a testing tool. It’s like adding the utility belt to Batman.

To me, that’s where the real power lies in a mock object. Being able to snatch the data and examine it at various points along the way; it lets me know my code is doing the right thing.

And the cool thing is, creating these objects takes hardly any more time than working with a mock object framework and setting up expecations. Since we’ve written the objects to begin with (or are using 3rd party objects we’re familiar with) then there’s no confusion over what we expect the object to do, or contain. Design patterns can aid us too; we can quickly churn out several different flavors of an object with a factory pattern, then utilize these flavors with a couple lines of code in our test fixtures. The flexibility of this approach allows us to test boundary cases and seldom-hit lines of code with ease. When you couple this with a good coverage tool, like NCover, 100% coverage is feasible. At least, in my opinion

Anyway, the point of this post is, more than anything, to give some props to Tim Stall for highlighting the Reflection method of testing private fields, and to throw another opinion out there in the testing sphere.