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.