• Add Review
  • Subscribe
  • Nominate
  • Submit Media
  • RSS

Taret Blade Development Diary - Chapter 1: An Introduction, and an Outline of Engine Design

Taret Blade Development Diary

September 24, 2007 - Chapter 1: An Introduction, and an Outline of Engine Design


I've had Taret Blade sitting on my backburners for some time now. I haven't made progress in months. But I've recently had some time and inspiration, and felt like picking it up again. I thought that maybe a good way to keep my attention on the project would be to bring your attention to it.

So in light of that thought, I've decided to run something of a development blog through this process. I'll carry on a running monologue of the design decisions and the development of the project, and maybe some of you will be able to learn from it. And maybe others will like what they see, and bug me about continuing the project. Who knows if that'll be enough, but maybe I'll get a bit further on this one.

So, this being the first entry in the series, I'll run you through what has happened so far.

My plan for Taret Blade was always to make a Tactical RPG exploring the history of a subplot in an earlier game. And I decided to use RPG Maker XP for this project. About a year ago, I released an early technical demo of the engine for the game. The data from that has since been scrapped. The old pathfinding routines were sort of crap, and overall I was just getting overly ambitious in trying to provide a toolkit for everyone to make tactical games in RPG Maker XP.

So I started over. My new goal is simply to make Taret Blade. I'll try to keep my code documented and keeping this development blog, in the hopes that others will be able to learn from what I do....but I'm not going to try to anticipate other people's needs.

So I fixed the pathfinding, and generally tightened everything up. I added a custom window class, and I always kept in mind limitations of RPG Maker XP. One of my watchwords for this project is economy. RPG Maker XP has problems with lag and resource usage, so I need to code like we did in the old days--keep recursive loops as small as possible, have routines in place to keep the game from appearing to freeze just because it's working, and never ask it to do more than it needs to.

So....going into this project, what are my assets?

* I've got the Skeleton of a Battle System in place.
* I can pick units from my party's reserve and put them on the field when the battle starts.
* The places that I can place units at the beginning of the battle are determined by placing events with a certain name in the regular RPG Maker XP Map Editor. This was important, because if I had to hardcode every map to make it work, I was probably going to end up killing someone.
* Enemies are also placed based on events with a certain name. They are randomly distributed, but can also be forced if I choose to. This allows me to have random battles, but also hard coded story battles.
* Pathfinding works just fine. When the "Move" command is selected, the game checks where the active unit can move based on walkability.
* Characters move on the grid properly and interact with the cursor and mouse just fine.
* The user interface works fairly well, especially for testing purposes. Since I'll almost certainly end up replacing things later, it only needs to be functional right now.
* I've got full mouse and keyboard support in place, so I can control the whole thing with my mouse. There's really no need to use the keyboard or even a controller with a tactical game--almost everything should be able to be done with a mouse.

So that's where I'm starting from. This makes the basic skeleton of a Tactical Engine. What I don't have right now are attributes, abilities, or really any actions. I have a blank slate, so to speak.

The Engine Design Phase

So now I start on the Engine Design Phase. Actually, I've already done quite a bit of design. But I'm going to walk you through some of the more significant decisions I make as I make them, and the thinking behind them.

This is going to be a long section, and it only covers game systems--not plot, characters, graphics, scenarios, side quests, or specific items in the game. This is laying the groundwork for the engine as a whole. I'm going to cover basically all of it in one go. First off this keeps the design feeling more consistent, since I lay it all out while my mind's in the same place. Secondly, it means I only have to write one entry on the design phase. And thirdly, it might give you a good idea of just how much you have to have in your head before you're even ready to start on the programming aspect. A few of these decisions I'm making are based on the setting I've devised for the place.

This is probably a risky business. Deciding how a game plays based on the setting is probably to be avoided if you're not making a licensed or fan game of some existing work. If anything, one should probably allow the game to affect the setting. In this case, I'm not. Partially this is because when I do world design for games, I try to keep gaming aspects of the world in mind, rather than just trying to hit what I convince myself is a strong narrative or a "realistic world." I might do an entry on the world design aspect later on, and go into my thinking on that aspect then. But that won't be this entry.

Remember kiddos, there's more to designing games than coming up with characters and stories and cities and military factions. This stuff right here is probably some of the most important stuff in the whole game, and will be a huge part of deciding what the game plays like later on. The other stuff will go a long way for keeping the players interested if you're lucky, but you should endeavor to keep them interested in all aspects of the game.

Core Concepts

The first thing I decide to do is figure out a few core concepts to unite the design of the whole thing.

The first will be "Apparent simplicity without sacrificing depth." The game should be as simple as possible for a player to play. But there while a player should have no trouble understanding the basic rules of the system or the interface, emergent depth will make for a large part of the strategy in the title. And we know strategy is going to be important to a tactical game. However, I should point out that when I say simplicity, I only mean simplicity for the player. If I have to code an extremely complex system to make the player think that things are very simple, so be it. I'll handle it, and if I can't I'll just change my mind.

I've been playing (or at least reading up on) a lot of Pen and Paper games lately, and some of their designs are quite impressive and likeable to me. They allow for a lot of variation and some of them are quite deceptively simple. I'm especially fond of the Tristat system (as seen in Tristat dX, BESM, and Silver Age Sentinels), but there are also lovely aspects to the World of Darkness system, and even the d20 system from Dungeons and Dragons 3rd Edition has its advantages. So I decide my second concept is going to be to try to bring a lot of these sorts of concepts into Taret Blade.

I'm a big believer in the Rule of Three, so I figure that I need one more core concept to keep in mind throughout the design phase. I decide on "Freedom and Customization." I want the player to be free to customize units, special techniques, and equipment. And anything else that they have control over. I'm not going to let them edit maps as part of the game, I think, but since I'm releasing this open source, that's obviously going to be an option.

Turn Progression

By Turn Progression, I mean "How are turns going to take place?"

I have two basic options here. I can either go turn based, like Fire Emblem, Super Robot Wars, or the Nippon Ichi Tactical games, or I can go with ATB like Final Fantasy Tactics. First off, it's clear from the start that most of my experience seems to be with turn based games.

I look at the advantages of the two methods.

In favor of Turn Based:

* Simpler for the player to keep track of who goes when.
* Teamwork is emphasized by allowing the player to coordinate how each of his units will move in a single go. So you can gang up to destroy your most dangerous opponent, and he won't get a chance to run away in between your units' turns.
* No unit will ever be so slow as to never get a turn.

In favor of ATB:

* Gives faster characters an advantage in battle, so that combat won't be so dependent on a unit's strength alone.
* Less waiting while the AI moves.
* Easier to suspend disbelief.

Both of them have advantages that seem important to me. I definitely don't like waiting for the AI. It's tedious, and that really hurts suspension of disbelief. If you've seen me talking on this board before, there's a good chance you've heard me talk about the importance of suspension of disbelief, so you know how significant that is to me. But on the other hand, I really like the teamwork aspect that can be found in Turn Based games, and I hate having characters that are all sorts of fun to use but never get a chance to move (I'm looking at you, Calculators). And simplicity (for the player at least) is important to me....as long as simplicity doesn't make for a shallower experience.

But keeping my second Core Concept in mind, I think back to PnP games, and decide to make a compromise. I'm going to use an initiative system. Units will roll initiative at the beginning of a turn, and based on modifiers from their stats, will get bonuses or penalties to their initiative rolls. But I'm also going to give units with a high enough initiative to go more than once per turn. There will be a "maximum initiative" that a unit can have, and any initiative higher than that will get to use the leftover as a second initiative. Presumably this could be used for a third, fourth, fifth, or even more initiative with a high enough value, but it'd probably be best to keep this capped. Two initiatives is already a good advantage, and it might be wise to keep the cap right there. Keeping in mind my first Core Concept, this will be invisible to the player, but the system will know the results and work things out.

Character Creation and Advancement

At first I was going to use Tristat as the system for Character Creation. I've since decided to make a few changes to that, though. I'm going to go with a point-buy system, but rather than having to buy stats, then attributes, and decide on equipment and things like that, I'm going to make it simpler and just have everything about a character defined by attributes. Stats will be defined by how many levels the unit has in the given stat attribute. Abilities will be attributes.

Right now I'm thinking that I'll make an exception for items. Items will be attribute containers themselves, that grant their bearer access to all of their attributes. These will stack with the user's own attributes. I'm not certain about all of this, just yet, so I might change my mind later. We'll see how it plays out and if it turns out unwieldy later. It sort of breaks my rule about Universal Rules.

So thinking about stats, I like to go with Numbers of Power, which tend to be primes. While I tend to prefer three, I decide to go with five in this case. I'll have five stats (which are, as we mentioned earlier, defined by attributes).

* Power - The unit's physical strength.
* Finesse - The unit's fine control over his body and mind.
* Wit - The unit's mental ability.
* Will - The unit's determination and stubbornness.
* Vigor - The unit's energy and drive.

These stats will be further used to make derived values. The player may or may not ever see these derived values (simplicity, remember?), but they will be used by the system to figure out more specific capabilities. Each combination of two stats will make one derived value. For example, Health and Energy (which is to say, HP and MP) will be derived from "Power and Vigor", and "Will and Vigor" respectively. I've made up a list of each of these, but I won't bother going through them now. So I've got ten effective stats now. The character can't directly control any of these, but can control the stats that make them up. By leveling up Vigor, for example, the player's Health and Energy will both improve.

Characters will gain experience from each successful action, but they won't level up. Instead experience points will be used to buy new attributes. Attributes can be Special Techniques, or they might be more passive attributes such as attributes that boost a stat, give bonuses to certain attack rolls or damage, or maybe even allow the unit to teleport.

Character Races and Classes

The world that I'm using has character races and certain abilities that can only be used by people with special training. So how do I reconcile that with this engine, where the players can put the character down the paths he wants?

I decide to give some attributes prerequisites in the form of Background attributes, which come in two forms: Birthrights, and Training Attributes. Both of these can only be taken during character creation, and no attribute that requires them as a prerequisite will be available to the unit afterwards.

Birthrights represent genetic abilities of the character, such as racial traits. All faeries, for example, have the "Dreamtouched" attribute which shows the potency of a character's faerie blood. Some Birthrights might have multiple levels available--for instance, Dreamtouched Level 1 would represent a character who only has distance faerie ancestry and no particular attachment to the faerie world, while maximum level would represent a character who was as powerful as any full blooded fae. Since this represents the potency of the character's ancestral traits, rather than the degree of relation, I decide that these can be leveled after character creation, so long as the character has at least one level in the Birthright.

Training represents training that the character has had during the course of his life up until this point. For example, all Acar Knights have gone through a long apprenticeship. So a character who is an Acar Knight will take "the Way of Acari." The level of a training attribute represents how far the character has progressed in their training. As long as the character has at least one level in a Training attribute, he can level it up later on. This will represent "On the Job Training" so to speak.

These attributes will grant the units some bonuses to various stats or rolls, but their main purpose will be to open up more advanced attributes. Some Techniques from Galadia Acari, for example, require that "the Way of Acari" be at a certain level before it can be taken, or before it can be taken beyond a certain level.

I also decide that some story events, or maybe even some side quests, might grant a character access to Background Attributes that they haven't taken, or level up ones that they have for free. I don't go into too much detail yet, but one thought that occurs to me is that I can have a side quest that will give any one unit of the player's choosing a special, unique background that will give that unit access to a whole class of attributes that no other unit can have. It's only a thought, though, and I don't worry about it for now.

Special Techniques

Since everything is attributes with a character, Special Techniques will each be attributes as well. Tristat has an attribute called "Special Attack" that a player can take and customize to their heart's content to make the attack they want. That's all well and good, but it's sort of beyond the scope of a video game. So I decide that I'll use similar rules for Special Techniques in Taret Blade, but I'll make each technique a separate attribute. These attacks can be leveled up just like many other attributes, so even if a unit has only a few techniques, they might prove to be very powerful ones.

Damage will be based on level as well as a base power for the attack. There'll be other aspects to the technique as well, such as the status effects it can cause, or how accurate it is.

I do like the idea of a character being able to customize the technique, though. So I consider allowing for further customization using Sub-Attributes. But I put it in the back of my mind for now, because that'll be sometime down the road.

I decide that Healing Techniques will be handled the same way. They'll be almost exactly the same as Special Attacks, but they'll work in reverse.

And Buffs and Debuffs will be similar, only they won't deal or heal damage.

I decide that all actions a unit can perform (except perhaps the "Wait" command) will be Special Techniques--including the standard attack techniques. All units will have a built-in, free special technique called "Unarmed Strike" or something that will do minimal damage. I don't know if I'll allow it to be leveled or not, yet. But I'm thinking I will. When the unit has a Weapon equipped, the unit will lose access to Unarmed Strike (although it'll still be in the unit, especially if it can be leveled), and gain the Weapon's built in technique(s) instead. We'll deal with that later.

I also think there will be Techniques that, rather than Attacking, Healing, or Buff/Debuffing, will steal items. There might be a few other utility techniques like these, and I imagine that leveling them up would essentially just improve their success rates.

I'm also considering combination attacks. Maybe if a unit goes to attack an enemy unit who is in attack range of an ally who has used the "Wait" command, or hasn't acted yet this turn, a more powerful attack can be selected and both units will be treated as having made their actions for the turn. I'm not certain about this, and I decide to explore it later.

That basically takes care of Special Techniques for now.

Items and Equipment

As I said earlier, Items and Equipment will be handled the same way as characters. They will have attributes that define their abilities. The person holding the item gets access to all of its attributes, which will stack with his own where appropriate. There might be some exceptions where it would be insane. Weapons will basically just be items with Special Techniques built in. The basic Special Technique should have no Energy cost, and its base power and level will represent how powerful the weapon itself is. Equipment will gain experience the same way (and at the same time) that a unit does. I'm thinking maybe they will split the experience. A character who goes into battle with no items would gain experience faster this way, but would obviously be weaker.

Armor would just be any item that doesn't have a Special Technique built in. Items will be weapons that are consumed when used--these can be weapons with healing or buff/debuff effects rather than attacks, though.

Non-character Aspects of Battle

Will there be aspects of battle besides the units involved? Heroes, Enemies, and Neutral units already offer a large depth pool.

However, I decide that I will implement a "Time of Day" and "Weather" system into the thing. This has to do with the setting itself, which has a strong emphasis on Day vs. Night, Light vs. Shadow (but not necessarily Good vs. Evil), and the Weather can affect how much light is available. As I said earlier, deciding on systems to fit the world might be doing it backwards, but I explained my thoughts on that above, though. Since battles are generally not going to take more than an hour or two of game time (as opposed to real time), Time of day probably won't progress during battles, but be decided when a map is first loaded up. Weather, though, can change. It's fudging things a bit, but it makes things slightly more dynamic.

Weather and Time of Day will affect character abilities. I'm considering having the attributes "Diurnal," "Nocturnal," and "Crepuscular" that are assigned automatically to units that determine how the character is affected by how much light is available on the field. I also decide that I'll allow weather to have some more universal affects than that, though--it would be silly to have play be the same in rain or snow as it is in sunlight. I don't specify the changes, but there will be some stat bonuses and penalties associated with various weather, as well as maybe strengthening and weakening some Special Techniques. That part is taken more or less directly from Final Fantasy Tactics, but I don't care--it's an obvious mechanic that sensible.

Other than that, I want to keep things simple, so I figure I'll leave outside forces there.

Wrapping Up

Whew. Notice how long that was? I was explaining what I see to be a fairly simple battle engine. I explained it in-depth, because that's what this series of articles (or journal, or whatever you want to call it) is about, but you'll notice that it's quite a lot that goes into it.

Most of you will have already been through this and realized how much goes into even the simplest things. Some of you newbies might want to take stock, though. There's a lot of work ahead of you, if you're going to make a game, especially if it's more or less from scratch. RPG Maker XP handles a lot of things natively, so I don't have to worry about designing a Graphics or Sound engine, although I have already tweaked those a bit (And will tweak them more later on, once I start making graphics. That's a future entry, though.)

There's also a lot of stuff I haven't covered yet that's still necessary for the Engine Design. I haven't figured out what the maximum level for an attribute is going to be yet. I haven't figured out what the damage/healing algorithm is yet, either. Nor have I come up with an algorithm for figuring out the experience point cost of attributes, or how much experience enemies are going to give. There are reasons I haven't handled these yet. In a lot of ways, they're not really going to be final until I get to the game balancing part anyway. Even if I give arbitrary ones now, those would have to be changed later on.

It's also important to note that this early on, there's a good chance that a lot of this is going to change. What I've just written up here is nothing more than an outline for the future design, when I start actually coming up with attributes, items, units, maps and scenarios.