First Week: Update

Since it's been roughly a week since I've started development on Mirage, I figured it was time for a status report. Of course real life interferes with development so I haven't really gotten as much work done as I'd like. However, I am pleased with my progress so far.

The first thing I started doing was coding my Display Model. Details of that creation can be found in my previous post. I'm happy to note that this model is serving me nicely as I move forward with production. It is an excellent base that (so far) handles everything I'm throwing at it nicely.

The next thing I worked on was Tiles. Tiles are my base object in the game, and is the base for objects that are put into my display model. They are essentially any object that can be displayed within the game. On top of this base class I derived two classes, Terrain and Actor. An Actor is any tile that can move around the grid. Upon further thought I think I'm going to rename this base class to Entity, since I'm using it for things other than the player and enemies.

The Actor base class has been fully fleshed out, and from that I've got an initial Hero, Enemy, and Projectile. You can interact with the Hero through the keyboard, you can move it around the board, and shoot Projectiles around the grid. All Actors have hit detection so the Projectiles work just as you'd expect. Enemies also move around the screen randomly, but that's all they do currently. The structure is there to add AI and more complex logic to them though, so once I feel the need to give them a little more life I'll be able to move on that.

After laying the ground work I started to work on some initial dungeon creation. I've just been playing around, but I've had the chance to implement two algorithms. The first I implemented was a cavern algorithm, that with the right parameters could also be used for other environmental features (lakes). The other algorithm implemented is just for a basic dungeon. It's nothing special and just adds about 16 rooms to the dungeon, but it's something to start with for now. I'm still working out the structure in my head on how dungeon generation is going to work. This is especially important at this stage, because I want anything even remotely content related to be in flat files outside of the code. I'm trying to think of the best way of doing this, so if anyone has any ideas I would love to hear them!

So that's essentially what I've worked on. It's mostly just the base stuff to build the game upon, and I'll start to develop some of the more specific stuff soon. My next focus is some early dungeon and map generation. This will include saving of the created maps, and html output as well. Once I've got that going I want to add some logic to my actual Terrain tiles, since currently the only difference is the look and all Actors can walk through "walls." I'm trying to think of a way to represent this logic so that it makes the most sense to me as well.

So that's where I'm at. It's been a ramble, so I hope you could follow along. I'd love to hear peoples thoughts on my progress. Any input would be much appreciated.

Why Real-Time?

Probably the most major design decision I've made is the choice to go real-time instead of turn-based. It is the most unroguelike decision I can make, if I'm aiming to be a classic roguelike game. It introduces additional complexity, but it will add to the feeling of a real, living, breathing world. I've always thought that the random created worlds are what really give roguelike games their charm.

I don't want to make the game twitch based because of this design decision. I don't want to make it into a hack-n-slash game like Diablo. I'll have to thoroughly test the gameplay to ensure that I am getting the benefits of real-time play, while retaining the naturally strategic play of a classic roguelike game.

This design decision also introduces a few other wrinkles that will make the game differ from a normal roguelike. The main difference will be that maps will have to be completely visible by default. If you couldn't see what is coming and/or how fast it is coming then you won't be able to react appropriately. This could lead to a very frustrating, and very difficult game. I'll still retain some dungeons that are unlit on entry, but I will ensure that the dungeon is populated in such a way that the real-time nature of the game doesn't effect the lack of visible area.

Our hero stands beneath a cloud and shoots a projectile at his enemy.

So the question begs to be asked. Why the choice of real-time over turn-based? I previously mentioned that it will add to the feeling of a real, living, breathing world. I plan to accomplish this by adding as much as I can to take advantage of the design choice. I will have creatures that move by themselves, independent of player input. I will have spells that animate when cast, projectiles that travel in the direction they are shot, and status affecting clouds that will drift through the map. These are only a few of the examples (and currently the only things implemented showcasing real-time effects), but they go a long way to show what this could bring to the genre.

So far my prototype that is showcasing my real-time effects is going pretty well. I'm curious as to what peoples thoughts are on this matter. I know it's pretty established within the community that classic roguelikes are not real-time, but I figure I would give it a shot. I never claimed to be a classic roguelike after all.

What are peoples thoughts on a real-time roguelike? What do you think the advantages or disadvantages of such a system are? Most importantly, if you were making a real-time roguelike, what kinds of features would you add to take advantage of it?