Monday, January 28, 2008

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.

7 comments:

The Mud Hutter said...

Out of interest, what kind of method did you use to connect dungeon rooms? Placing rooms is easy, but I found connecting them AND guaranteeing that they were all connected to be difficult. (read:I'm stuck on that part!)

rsalsman said...

I haven't actually connected any rooms yet. This is also something I've been trying to figure out the best way to do this as well.

I think it depends on the algorithm you're using. Some algorithms would be able to handle connectivity very well. The algorithms that start at a point and then tunnel through the dungeon until they've built would easy to keep connected. Other algorithms would be not so trivial to add support for connectivity.

For the most part I plan to have each map have a list of entrance/exit points, and I'll need to make sure my creation algorithms are smart enough to ensure that adjacent rooms remain connected.

Did you have any ideas for implementing connectivity?

Dirk Kok said...

Another approach is to place your tunnels first and then place the rooms over them.

Rooms are placed using some scoring algorithm where for example locations with tunnels intersecting rooms would have a better score.

The Mud Hutter said...

It shouldn't bee too hard to make an algorithm that digs a corridor from point A to B and have it look like a corridor (ie, mostly long, straight lines), and have it finish the corridor as soon as it hits any gap (be it the destination room or a corridor in-between). So it should be straightforward to do this from one room to the next, in placed order. And from there it should be fairly easy to have it occasionally create more than 1 corridor leaving a room going to a random other room. But, I'm not sure how good this will actually look when executed - I'll let you know when I've got it working ;)

The Mud Hutter said...

Also, there are some really excellent articles on the subject of dungeon generation generally - I found http://www.aarg.net/~minam/dungeon.cgi really good because you got a working example with variables to fiddle - although, as a previous poster suggested doing, it's a corridor first, rooms second method.

Joshua Smyth said...

Hi, just found your blog. I'm also developing a RL. You might be interested in a quick article I wrote on my blog about how I handle random dungeon generation

http://www.peachysoft.com/?p=84

rsalsman said...

That's a good article. I'll have to implement some of those ideas into my dungeon creation algorithms. Do you have any other RL related articles?