Field of Vision

The past two nights I've spent some time on my Field of Vision algorithm. Last night I wrote the initial algorithm, and got it running inside the game. Today I fixed a bug in the algorithm (hard to believe there was only one), cleaned up, and comment the code. I'm using both the Midpoint Circle Algorithm and the Bresenham's Line Algorithm together to calculate the field. It stores the field with each point keyed based on how far away from the original point the field was calculated for. This will turn out to be extremely useful when I want to apply effects to different points based on how far away they are from the origin.

The algorithm is built as a grid worker. This allows it to be used by any other object in the system, and fields that have been calculated that may never change can be reused without recalculating. The grid worker class has grown to be immensely useful, and is now probably the most common base class in the system.

I'm writing this post because I don't know where I'm going to go from here. There is still a lot of ground to be laid, but I'm trying to figure out what gives me the most bang for my buck. The current goal is to get a basic working game going, so with that in mind I'll probably work on dungeon depth and persistence. Hopefully that goes as well as the field of vision code did!

Some Progress

I've been working on the game every now and then, and in the past week or so quite a bit. My new laptop is helping out with this increased productivity, as I can now code while watching television!

The main thing I've been focusing on is getting my code ready for being placed on a repository. As I may have mentioned I plan on open sourcing my code. Since I'm writing my game on the skeleton application that comes with the SDK I'm using, it has required me to rewrite a lot of things in skeleton application that don't really have much to do with the game. Mostly I'm talking about player saving and things like that. I'm happy to report that all the code in my game is now my own so it's ready to upload when I decide.

As far as the game itself I've only gotten hit detection to work. This was actually only a one line thing, and I'll need to revisit this one line later on. For now it's nice to see this working and it feels much more like a game. Now that I have a bunch of boring code out of the way I'll be able to add more to the actual game. There are still a few things I want to add before I make the code available to all. Once those are added I want to do a small code and comment review before uploading the first version.

Once it's uploaded I won't be publicly telling anyone about it, for now it's mostly so I have the code backed up on another server. Once I have a better represented game I'll probably point people in the direction of the code as well so they can see how it works. I'm hoping people can provide some feedback on the code as well, as I'm sure there are ways of doing things that I don't know about.

Back!

Summer has been quite busy. The last post I made was sometime before I went to Australia and since then I haven't had much time to work on Mirage. I have worked on it a little bit in the past week or so, and my interest has been revived.

A big problem I had earlier on was that I was being too ambitious and trying to think of everything I wanted to end up doing. This resulted in me not being able to focus on the little parts that I did need to do. I'm sure this will happen in waves but for now I've refocused on some smaller chunks that I can get done without having to think about the big picture.

The current state of the project is pretty good. I have a solid engine created that I can work off of and add to. Everything right now is very simple, but I have player and non-player characters working. The non-player characters that I do have just move around aimlessly, but that is something that I can work on later when I have a better base game worked out.

I've finished a cavern algorithm which is working very nicely. I still want make some tweaks to it because
occasionally I get maps with very small caverns. I might make some variables on the algorithm so I can set a minimum and maximum cavern size. This will give me more flexibility in the future if I want to re-use the algorithm for multiple types of caves.

I'm also working on a simple dungeon algorithm. Work on this one is very preliminary, but it's coming along nice. My plan is to work on many different dungeon generation algorithms so I get a lot of variety in the final game. Since I plan on open-sourcing the engine as well I feel the more different types of algorithms I have the better. The system is set up so that adding new dungeon generation algorithms is a breeze.

I have a short list of things that I want to implement next. They shouldn't be overly difficult but I just have to find time to do them. Everything is listed in the order I want to complete them.

• Collision detection


• Line of sight


• Dungeon Connection


• Dungeon Persistence

There are also a handful of other things that I want to implement as well. For the most part I have been doing whatever comes to mind, but I want to implement enough to have a playable game. Hopefully I find time to work more on the game once the summer is over.

Emotional Schools

I decided to come up with names for all of the possible schools of magic. This is just a first draft, but I think I did pretty good. As always, thoughts welcome!

Anger + Anger = Rage
Anger + Fear = Hatred
Anger + Sadness = Devastation
Anger + Love = Jealousy
Anger + Hope = Enmity
Anger + Joy = Malice
Fear + Fear = Terror
Fear + Sadness = Shame
Fear + Love = Anxiety
Fear + Hope = Distress
Fear + Joy = Hysteria
Sadness + Sadness = Anguish
Sadness + Love = Sorrow
Sadness + Hope = Pity
Sadness + Joy = Apathy
Love + Love = Adoration
Love + Hope = Lust
Love + Joy = Ecstacy
Hope + Hope = Desire
Hope + Joy = Bliss
Joy + Joy = Rapture

Emotional Magic

Long time no post! I've been pretty busy lately. I'm currently taking care of a bunch of things in preparation for my upcoming vacation. Australia here I come! I'm pretty excited, but there has been a lot that I've needed to wrap up around here before I can leave with an empty head.

I've still been thinking a lot about Mirage, and I've come up with a loose model for my magic system. I wanted to have a unique magic system that would still be familiar to those used to normal magic systems. What I decided on was to model my magic system against emotions. The magic users in the game would have to embrace a type of emotion to be able to use particular spells. Embracing different emotions could also affect your character, through status effects or stat modifications. A magic user could embrace up to two types of emotions at a time. The more someone embraces a particular emotion the better they get at using it. Higher proficiencies in a particular emotion would unlock new spells and either decrease or increase the way in which it effects them. High proficiencies in multiple schools would unlock spells that could only be reached by a mixture of emotions.

I decided on six basic emotions. They are Anger, Fear, Sadness, Love, Hope, and Joy. They create a wheel of emotions, with natural opposites. The mixed emotions would also have names as well. So if you mixed Anger with Sadness you would get Betrayal. Betrayal spells would only be active once you've reached significant proficiency in both Anger and Sadness schools. You would also be required to embrace both emotions. Certainly spells in these mixed schools would be more powerful than their base emotions.

Once you've reached a particular level in a particular emotion it's name might reflect that. Anger would become Rage, Fear would become Terror, and so on. I'm not sure if this particular twist would be too complicated or not. It might end up being confusing.

I mentioned that embracing emotions would effect your character in some way. If a player chose to embrace Anger, they might gradually lose hit points. If a player chose to embrace Love they might gradually gain hit points. Embracing both emotions would counteract each others effects, but the spells coming out of the mixture between Anger and Love might not be as strong as those coming from other emotional schools.

I designed the system in mind so that there would be benefits and losses to each emotion. It was also designed for a great amount of variety in the types of spells available to the player. The player would also have to make a decision on what emotions they are going to focus on, and this decision could impact them through the entire game. I'm curious to see what other people's thoughts on this type of magic system are. As always comments, suggestions, and improvements are always welcome!

Achievements

I've mostly been working on some miscellaneous things lately. I've implemented attributes, resistances, modifiers, and I'm starting to work on items and inventory. There is nothing really groundbreaking to say about any of that, but I may highlight my implementation in the future. For this post I'll be talking about what I plan for my achievements system.

I mentioned in a previous post my idea of the library, and how it would fill up independent if your current adventure. It would persist through all of your characters. Adding to that feeling is my achievements system (tentative title).

If anybody reading this has played any games on the Xbox360 you will notice every game has achievements. These are things you can do during the course of gameplay that give you some gamer points. Gamer points are pooled from multiple games, and each game has a hard limit on how many gamer points they can give out. This is nice in several ways. First it gives you tangible evidence of how much of the game you've experienced. It gives you goals that are independent of just finishing the game. They may highlight parts of the game you didn't know existed, or never thought about. They encourage you to play the game in different ways, or on higher difficulty levels. All in all they cater to the completionist in everyone that plays video games.

The most obvious achievements are those that are story related, beat a specific boss, finish the game, etc. These can easily be transferred over to mirage. I can have achievements related to the library as well. Find a certain book and get an achievement. Unlock the entire bestiary, obtain 75% of the library's knowledge, or even discover the library itself (since it won't be accessible from the beginning), and get an achievement. The possibilities are endless!

This system will provide tangible evidence to both the casual and hardcore player that they are indeed accomplishing something within the game. One of the primary complaints against roguelikes are that they are too hard. Most people lose patience and can't seem to progress very far into the game. With an achievements system it would push those types of players to achieve many small intermediate goals, which would naturally lead them into some of the harder to obtain achievements. If a player knows that if they kill 5 more goblins, or finally manage to unlock the power of the cursed ring and be emotionally awarded for that accomplishment, they will be more excited to continue playing.

There are several things I have to watch out for however. I can't add too many achievements or it will become overwhelming. Also, I can't add some super complex achievements or people may become frustrated. It's also my opinion that I can't have any "hidden" achievements, because if nobody knows about an achievement they won't strive to get it.

I'd like to hear people's comments about this system, and what they think its implications will be upon the game. It's a system that can be easily added to any game, and is basically completely independent of any actual game related code. I'm excited to see how it ends up working out.

The Library

I've still been too wrapped up with real life stuff to be able to do any heavy development (my girlfriend just left for Australia!), but I've still been kicking around some design ideas in my head. These ideas are mostly feature related at this point as I'm still trying to flesh out what the initial game will encompass.

The subject of this blog post will focus upon a mechanic I like to call the Library. As in the real world the Library will be a source of knowledge. It will contain information on enemies, items, spells, locations, and other yet to be determined topics. These will be categorized into different books within the Library, and will only be available if they contain some information. There will also be a book recounting the history and legends of your ancestors (previously played in game characters). There will be hidden books throughout the world that you can return to the Library to gain some benefit towards character.

So far the Library sounds pretty straightforward, so you might be wondering if there is anything unique about it. There is! The Library will be persistent across all of your characters. Information uncovered on one character will be available to all future characters, and discovered books will remain discovered. To gain the bonuses from a previous character you'll have to locate their burial place (where they died) and pray for them. You will then become imbued with their knowledge.

This will serve a few functions. It will add a sense of history to the game, and provide the feeling that your characters actions persist through generations. It provides an intermediate goal to the game, because if you find your previously created character you will instantly become more powerful. It also provides goals to any character, since finding a book inside or at the end of dungeons can be a powerful motivator. Also, it provides a different mechanism for improving your character and a collecting mechanism that may attract some gamers. The collection mechanic will tie into my achievements system, which will be the subject of a future post.

There you have it. I haven't gone into any specifics one what the books will contain, mostly because that hasn't been decided yet. Some surprise is always good I guess. I'd be interested in knowing other's thoughts on this game mechanic, and any additions people might find interesting.

The World Model

I've been thinking a lot about my implementation of the world, and how everything will fit together. I haven't decided on it yet, so I figured I would take the chance to go through my thought process "out loud" so anyone can benefit from it. Hopefully a coherent post will come through, since none of what I'm about to say is premeditated.

Before I begin I'll discuss some terminology. For the sake of this post the world is the entire game, and internally this is a collection of maps. A map is a single screen within the game. A dungeon is any vertical series of maps, this would include a tower since it's just an inverted dungeon.

I'll start by describing my goal for the system. I decided early on that each map in the game will be randomly generated. Once a map is generated it doesn't get recreated. I want to describe my world in such a way that it can be created randomly but retain a general look. So how do I go about doing that?

Since my maps will be both outdoor and indoor this lends itself to some interesting issues, the first of which is interconnectivity. Stated more clearly, I need to be able to determine that each of my maps are connected to any adjacent maps. Any given map can have connections from the north, south, east, west, up, and down. This lends itself well to a three dimensional coordinate system. Maps connected vertically will only need to be connected from a minimum of one point, but they could be connected by more. Maps connected horizontally can be connected by any number of points, and for most outdoor maps these connections are on each point on the outside of the grid.

Each map can be described in a text file by a list of grid workers used to create it, and the parameters for those grid workers. The only other thing the maps need to know is what maps are adjacent to it. They need this information for several reasons. Firstly, they need to know what connections to create. Secondly, they need to know what the adjacent maps look like, because we want to preserve the look across boundaries. For instance, if we have a forest map that borders a desert we don't want a harsh cut from forest to desert once the character travels to the next map. We'll want to organically blend these together so it looks natural.

This can be handled in a few different ways. I can generate the entire world at once, but that would take a long time and be a lot of useless processing up front. Also, I can look at the adjacent maps and use their creation algorithms to bleed the two maps together. This is a lot more difficult than it sounds, but probably the best solution. The bleed algorithms will have to be pretty intelligent, or a wide view of the world will just end up looking like a bunch of rectangles loosely connected. I'll probably need something in addition to bleeding, like the ability to set percentages on a given map. For instance, 25% of the north and west will be desert, while the remainder will be forest. I feel this is a problem I'll be fighting with for awhile.

This system will allow me to create a relatively complex world that is still randomly generated. Each map on subsequent plays will look slightly different. I'm worried that this will be stale, and if that lends itself to be true I'll have to think of a different system. The only other thing I can think of is instead of defining individual maps I would define regions. A forest could be anywhere from 2 to 5 maps large. There is a dungeon somewhere within a 5 map radius of this point. Stuff like that. Only time will tell.

I think I've said all I can say on this topic for now (or want to). As always, any comments are welcome!

The Technology

I've received several inquiries as to what sort of technology I'm using to create my roguelike. I've been busy lately (apparently coding games all day makes you less motivated to code your own game at night), so I figured I'd make a small post about it. I'm mostly kicking around design ideas in my head so a more game related post should soon follow.

The language I'm using is C++, and I use Visual Studio as my IDE. More specifically I'm using the Express Edition which is as fully featured as I need. There are many reasons I've chosen C++ and Visual Studio. The first is that it's what I use at my day job to create games, so I'm comfortable with the language and the environment. It also happens to work with the SDK that I'm building my game off of.

The SDK I'm using is the Playground SDK. This is also the technology I use during the day to make commercial games, so I'm extremely comfortable with it. Playground takes care of all of the heavy lifting, which allows me to focus on the actual game. There are many advantages to using Playground.

• Free to use
• Great support (developer forums)
• Multi-Platform (PC and Mac)
• Localization
• Lua Scripting

You can find more information at the website above. I know I might seem like a shill, but I encourage you to check out the SDK. It's allowed me to hit the ground running, especially since I'm comfortable within its framework. I can focus on writing the actual game instead of worrying about other things unrelated but still necessary. The support for Lua is also a big plus, but I'm not as comfortable using it as I hope to be. Hopefully I can integrate some more support for it within my game.

I also have the advantage of learning the technology while on the job, and applying it to what I do in my free time. This is especially useful as I learn different design patterns for different types of objects and then can apply them to Mirage. I can also add some neat tricks to the game that I wouldn't be able to do otherwise (think ascii particle effects)!

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.

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.

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?

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.

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.