The GridWorker!

This post is going to be more software development related rather than roguelike related, but it is still applicable in many cases. I'm going to talk about the importance of, and my obsession with, naming classes appropriately. Since this is my own project, not one I'm getting payed to do, I spend more time on these design issues than normal. You'll see this in my over analysis below.

I've been holding off on dungeon creation so far (except for a few small tests) for one reason, and one reason only. Because I couldn't decide on a name for any classes related to the task. I have a particularly interesting quirk. I can never decide on a name for a class, and in most cases it takes me longer to name a class than to actually write it. Even once written I end up renaming the class multiple times until I feel it suits it completely. Even though I admit this is weird, I do also think this is necessary (to a certain extent).

We all know that you're supposed to name a class logically. In this case I could've just named my class DungeonCreator and I would've been done with it. This seemed too specialized though, after all if this was my base class it wouldn't feel right if down the line I was deriving from this to fill the grid with terrain as well. Having thought about it more I decided I should make a generic base class that DungeonCreator could derive from.

The first thing that popped into my head was GridBuilder. It makes sense, but it didn't sit well with me. Mostly because the class wouldn't actually be building the grid, that would be done sometime during the initialization of the game. I hit up the thesaurus and after many failed and overly complex names I decided on GridFiller. It seemed as if I'd finally found the right name and I could begin developing. Third time's a charm right? Wrong! The class wouldn't be filling the grid, just part of it. This is an extremely minor quibble, but it demonstrates how crazy I am about naming my classes.

I'll cut to the chase to save you from further boredom. I finally decided upon GridWorker as the name for my class (I'm sure you could've figured this out by now). It only has a constructor, a pointer to the grid object, and a virtual function entitled DoWork that can be derived from to do the actual work on the grid itself. So what was the benefit of all this naming and renaming you might ask? Well I now have a class that is completely abstract, and that doesn't shoehorn its derived classes into a specialized role. It reduces overall complexity of the code, and you can instantly know what a derived class is doing just by looking at the name of its base class.

The most obvious use of a GridWorker is to derive from it to create dungeons. I can also use it to place items and enemies upon a map. I could make a class that outputs a grid to html, or the state of a grid to a save file. Virtually (no pun intended) anything in the game that might want to look at or do something to the grid could derive from GridWorker. I can create a task that will get processed while the game runs that contains a list of GridWorker objects. It would then be trivial to iterate through the list and call their DoWork function, performing several different unrelated tasks, but still using the same structure.

This post was a window into my development style. I take a lot of time to create the base classes of the game in order to reduce complexity down the road. I'm a firm believer that the more time spent designing earlier on in the project will save much time in the end. The above example illustrates how just the naming of a class can simplify and streamline the entire structure of a program. In particular, roguelikes can benefit from this methodology because of the number of extremely similar objects that can have vastly different behavior.