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.
Monday, January 28, 2008
Tuesday, January 22, 2008
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.
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.
Monday, January 21, 2008
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?
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 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?
Sunday, January 20, 2008
Display Model
The first thing I decided to code for Mirage was my display model. This is what I call how I store my tile objects internally, and how I use that model to display the tiles to the screen. I figured this would be important to decide early on, as it creates the base on which the entire game will grow.
I initially stored tiles in a two-dimensional array. This made the most sense from an initial standpoint since most if not all roguelikes appear to the user as a two-dimensional grid. Things worked fine and I soon had the hero moving around a screen of empty tiles. I realized early on that a two-dimensional grid would create a lot of problems. When the hero (or any actor for that matter) moved from one position to the other I had to change the old position's graphic back to what it was previously. The new position would have the same problem once I moved off of it. In and of itself this is a simple problem, and one that could be solved in numerous ways. I knew going on that this would create some headaches for me down the road, so I decided to take a little extra time and think about the problem.
After much internal struggle I decided that instead of a two-dimensional grid, I could move to a three-dimensional grid. I'm not sure of most other roguelike's display models, but having typed that it may seem like throwing an extra dimension at the problem was asking for even more headache.
I'll explain why I have chosen this solution. Imagine a cube of tiles. Imagine also that the terrain tiles are on the bottom layer of this cube. Somewhere on the second layer the hero is stored. If the three-dimensional grid is traversed by column, and from the top down, then the problem above disappears. Once a tile is encountered and drawn during traversal then we just go to the next column, instead of drawing any tiles underneath it. Of course I could also add some logic to each tile so that you could ask it whether we should draw tiles beneath it, instead of just assuming.
I have an enumerator that represents my layers. I can easily add to this enumerator to add more layers to the system. Since I access layers using this enumerator, adding new layers has no effect to preexisting code, neither does changing the order of the layers within the enumerator. In essence this enumerator controls completely how objects are drawn within the game.
I have an environment layer that I hope to use to implement clouds. Clouds will be on the top layer (at a reduced alpha value), and will allow drawing of tiles beneath themselves. This will give tiles below the clouds a nice bluish tint. This is just one of many ideas that could be added to this system with little trouble and consequence to existing code.
I'm anxious to hear what others think about this solution to my problem. I would also like to know how others have implemented display models in their games, in the hopes that I can make mine more robust. I think it is a simple solution that provides great flexibility.
I initially stored tiles in a two-dimensional array. This made the most sense from an initial standpoint since most if not all roguelikes appear to the user as a two-dimensional grid. Things worked fine and I soon had the hero moving around a screen of empty tiles. I realized early on that a two-dimensional grid would create a lot of problems. When the hero (or any actor for that matter) moved from one position to the other I had to change the old position's graphic back to what it was previously. The new position would have the same problem once I moved off of it. In and of itself this is a simple problem, and one that could be solved in numerous ways. I knew going on that this would create some headaches for me down the road, so I decided to take a little extra time and think about the problem.
After much internal struggle I decided that instead of a two-dimensional grid, I could move to a three-dimensional grid. I'm not sure of most other roguelike's display models, but having typed that it may seem like throwing an extra dimension at the problem was asking for even more headache.
I'll explain why I have chosen this solution. Imagine a cube of tiles. Imagine also that the terrain tiles are on the bottom layer of this cube. Somewhere on the second layer the hero is stored. If the three-dimensional grid is traversed by column, and from the top down, then the problem above disappears. Once a tile is encountered and drawn during traversal then we just go to the next column, instead of drawing any tiles underneath it. Of course I could also add some logic to each tile so that you could ask it whether we should draw tiles beneath it, instead of just assuming.
I have an enumerator that represents my layers. I can easily add to this enumerator to add more layers to the system. Since I access layers using this enumerator, adding new layers has no effect to preexisting code, neither does changing the order of the layers within the enumerator. In essence this enumerator controls completely how objects are drawn within the game.
I have an environment layer that I hope to use to implement clouds. Clouds will be on the top layer (at a reduced alpha value), and will allow drawing of tiles beneath themselves. This will give tiles below the clouds a nice bluish tint. This is just one of many ideas that could be added to this system with little trouble and consequence to existing code.
I'm anxious to hear what others think about this solution to my problem. I would also like to know how others have implemented display models in their games, in the hopes that I can make mine more robust. I think it is a simple solution that provides great flexibility.
Forgive Me, I'm New At This...
I've recently come to the realization that I need to create a game.
I'm a 24 year old software developer. I've been in the industry for only a year and a half. Since then I've been the lead developer on three commercial games, and I've helped with several others. I've made games sure, but I haven't felt like I've made my game. I hope this is what Mirage can become.
I'm new to roguelikes. Not only is this blog a window into development, but I'll also be using it as a place to bounce ideas off people. I'll be updating rec.games.roguelike.development with my progress. I think I'll be able to add to their community, and I know that I'll be able to benefit from their knowledge.
I'm a 24 year old software developer. I've been in the industry for only a year and a half. Since then I've been the lead developer on three commercial games, and I've helped with several others. I've made games sure, but I haven't felt like I've made my game. I hope this is what Mirage can become.
I'm new to roguelikes. Not only is this blog a window into development, but I'll also be using it as a place to bounce ideas off people. I'll be updating rec.games.roguelike.development with my progress. I think I'll be able to add to their community, and I know that I'll be able to benefit from their knowledge.
Subscribe to:
Posts (Atom)