Day: <span>May 18, 2005</span>

My Latest Project

Okay, purely for my own edification, I intend to write an RPG in 40 hours.

I was, of course, inspired by this blog post, and also by the fact that I really, really wanted to participate in the most recent Ludum Dare challenge, but couldn’t. So I’m sort of doing it on my own. Now you know why I was researching Roguelikes; 40 hours is too short to do just about anything graphical. Text mode will allow me to get the most out of my time.

Here’s the rules:

1. This will be a project created in Visual Studio .NET, using C++. It will be a console application, and it should run on both Win2K and Win9x.

2. The timer starts when I first create the project (which I haven’t yet).

3. Since I am a father of three and employed full-time, I can’t do something stupid like work on this for 40 hours straight. Instead, I will work on it whenever I have time, rigorously keeping track of my time. When the 40 hours is up, I will post whatever I’ve got, even if it’s not playable (though I will do my best to make sure that it is).

4. Time designing, coding and creating content counts against my 40 hours; time thinking about the project and writing blog entries about its progress do not. Thus, I can do some “mental preproduction” work on it as long as I don’t code anything or write any design down.

5. Failsafe. I have 40 hours to do this project, and I can spread them as thin as I want, but if the project is not done within 30 days (that is, it is not done by midnight, June 18th, 2005) the rest of my time is forfeited and I must post what I have.

Currently my thinking is that I will break the project up into two 20-hour chunks – one for coding the engine and one for creating content that runs on the engine. This should (note the word “should”) ensure that I ship something a bit more robust than just a hack & slash engine. My fears are that I will either overestimate the difficulty of the project and set my sights too low, resulting in a completed game so simplictic that no one wants to play it, or that I will conversely bite off far more than I can chew, resulting in no functioning game at all.

Oooh, this is going to be fun. I think.


Roguelikes

I’ve had a real love/hate relationship with Roguelikes. (Quick definition if you don’t want to follow that link: a Roguelike is a turn-based RPG with a map that is usually constructed from the ASCII character set. They derive their name from Rogue, the first game of this type on record.) The thing is, now that I’ve thought about it, most of the advantages of a Roguelike are inherent, and most of the things I don’t like about them are a part of how they’ve been constructed.

The main advantage of Roguelikes is that while they do have a map, they are not rigorously representational. They inherit this from text adventures. If you want the player to be attacked by a gorgeous bird with a six-foot wingspan, a pearl beak, feathers that shift colors as it moves, and glowing white eyes, you can simply put a B on the screen (or whatever letter or symbol you decide represents “birds”) and say, “You see a gorgeous bird with a six-foot wingspan, a pearl beak, feathers that shift colors as it moves, and glowing white eyes.” This takes all of 30 seconds, unlike the two weeks actually creating such a bird in a 3D game would take.

This also means that you can code tons of interactions that can only exist in text. Sure, let the player wield lockpicks or dead monster bodies as weapons! Let the player drink from fountains, fill canteens from fountains, dip swords from fountains, kick fountains! Let them wear hats on their feet! It’s all just text! You’re not required for it to make any visual sense!

Another way Roguelikes aren’t rigorously representational is that the player is not bound to any sort of normal walking speed. A square on a Roguelike map typically represents six to ten square feet, and you move by jumping from one square to another (and typically you can move as fast as you can press a key). Thus, it doesn’t take long to get places in a Roguelike.

So Roguelikes can avoid lots of the annoyances of modern RPGs and stimulate the imagination, at the cost of a lack of visual…impact. What are the downsides?

Like I said, most of the downsides of Roguelikes I’ve played stem from how they are implemented, not the style itself. Roguelikes are typically arbitrary, difficult and frustrating, but that’s only because that’s how they’ve been programmed. One true downside of Roguelikes is that the user will have to constantly refer back to the manual or a cheatsheet to figure out exactly what symbol means what on the screen, but this can, perhaps, be minimized.

So why exactly am I analyzing Roguelikes? Ah, see the next post.