New account registration is temporarily disabled.
  • Add Review
  • Subscribe
  • Nominate
  • Submit Media
  • RSS

Miscellaneous

Solidiication and Liquifaction

As is always the case with a design, sometimes things that you think are going to be important in the beginning sort of end up unimportant in the end. That's part of the process, but it's also why a good outline is important. I've done very little actual coding, but spent a lot of time on planning....other than a little bit of playing around here and there (mostly to make sure concepts I've got now in theory will work in practice), I've barely touched the code of Taret Blade.

Okay, so what's new?

I'm sticking to my same spirit of the original concept, but tweaking things here and there. Some of the early work on Dungeons and Dragons 4th Edition has given me a new way of looking at units, and that's a big part of what my restructuring of the units and their attributes is focused on. There's other stuff, too.

Before I get into that, I've shelved (for now) the idea of having attributes heavily customizable. I might still allow them to be levelled up, but adding sub-attributes or suchlike is off the table for the moment. This should simplify things, both for the player and for me.

Putting the Role in Roleplaying
Okay, sort of a misleading title, because this has little to do with roleplaying in the traditional sense, though it does go right back to D&D, like I said before.

4th Edition is introducing (or rather, codifying) the idea of characters playing roles in the party (as opposed to roles in the story). MMORPG fans are already familiar with the idea--Tanks, Nukes, Healers, etc. The talk they had about it really made me realize how big a help that sort of thing could be for AI, and for introducing players who aren't used to tactical games and the necessity of building specialist units.

So I've got five roles now for any unit to fill. A player might obviously use any unit for any purpose, but the game's AI will play enemy units the way the roles are expected to behave.

Breacher - Breachers are units designed to deal massive damage to single targets, and to avoid getting hit in the process. Like ninjas! In addition to strong attacks, Breachers get abilities that let them avoid getting hit or that let them slip around enemy defenses.
Keeper - As in "Gatekeeper." Keepers are about getting in enemies' ways and drawing enemy fire away from weaker teammates. They're classic tanks, but they also tend to get neato counterattack abilities, and a lot of movement potential, so they can get to the units that need protecting.
Peacemaker - Peacemakers are about keeping the enemy from overwhelming the hero party. They get attacks that hit a lot of enemies for okay damage, and also debuffs and trap-like abilities, so that the person controlling the Peacemaker can control the battlefield.
Mender - Menders are healers and buffers. Their abilities are primarily devoted to keeping allies and themselves alive when a Keeper just isn't enough.
Coordinator - This is the one that doesn't have an easy corallary to other games I'm familiar with. Let me rephrase that....they don't have an easy named corallary. The idea is universal to RPGs--the main character in most games is a Coordinator.
Coordinators are sort of jacks of all trade, but their focus is teamwork. A coordinator involved in a combo attack can increase damage by tons. In place of Buffs, Coordinators get Aura effects. If you've played Warcraft III, you should have some idea how this will work. Unlike WC3, though, auras have to be activated for Coordinators, since they might have the Attribute for more than one, and with enough stacking, those could become pretty game breaking.
Coordinators also get the summoning spells--which aren't just fancy magic (sometimes they're not even magic at all), but techniques that bring new units onto the field.

AI, Ai, AI yAI...
So how does the AI tell how to use a unit, if there aren't classes and the like?

Each attribute has a set of five hidden scores, each respectively representing one of the roles. These values are added together for all the unit's attributes (including ones on items he has equipped) and then he gets assigned a "Suggested Role," which will appear on the status menu. Enemies and Neutral units have five different AI scripts and will use the one that corresponds to the correct Suggested Role.
Player units will also get a field called "Favored Role." This will just be an indicator of how you have tended to use the unit in the past, and won't have an effect on gameplay.

It sounds complicated, but I think once it's actually seen in the context of the game, it'll be surprisingly simple for the player.

Some Other Possible Changes
I'm considering what to do about the "Background" attributes. In the context of story/gameworld they make sense, but in the context of the game they really limit the player's choices of how to use their characters.

In Closing
So yeah. Those are my thoughts for now. These posts are really meandering, huh? Shows you what happens when you work without an outline, I guess. I need to start making them more frequently so I can make each post shorter.

Miscellaneous

Taret Blade Development Diary - Chapter 3: Databaserie

Okay, I lied. This one is not about which technique to use. This is about my custom database.

So anyway, I started playing around with Microsoft Access, and realized that since it could output in XML, I could pretty easily just use Ruby's REXML script to convert the XML into a a Ruby object, then marshall it out into a database file like those in the "Project/Data/" directory.

This trick requires using Ruby, and not just RGSS, but luckily REXML is an extremely intuitive little class. This is a lot easier than my old way of doing it, but it still takes a bit of time, since I've got to set up the databases in Access, then add a routine to my "xml.rb" script to convert it. On the other hand, once I've got the converter up, it's really only two steps to update the thing (output the XML, then run the script), which isn't bad at all.

Miscellaneous

Taret Blade Development Diary - Chapter 2: Intelligent Artificing

I got back to work on Taret Blade for the first time in forever today. Today's focus was Artificial Intelligence. I already had pathfinding taken care of, so this part is just figuring out how enemies and neutrals (and maybe AI-allies) will decide to move.

Determining the Target
The first thing I decided was that units were going to have to have a limit to how far ahead they could think. I figured that they would need to have an opponent within a certain range to even bother trying to attack. The range would be based on the unit's movement range, and expand depending whether the AI was set to offensive, defensive or cowardly.

I was trying to figure out how to let them decide what the best target would be. I considered having the enemy measure the unit's stats or abilities....but since I'm not using traditional levelling, that could be quite a challenge. Luckily, an idea presented itself.

I was never that into Final Fantasy 11, but I did play for a while, and a concept that I picked up from playing it was "Hate." The actions a character take adds to a hidden hate meter, and enemies would go after whoever had the most hate. Different actions drew different amounts of hate based on how dangerous they were to the enemy. Healers were considered among the most dangerous, for example, because they kept the party going. It's a great little concept, and I decided to steal it.

So here's how it works in Taret Blade: each unit has a "hate" variable. It's a simple integer that starts at zero. Each action has a "hate" stat as well, and when the unit uses the action, that action's hate stat is added to the unit's hate variable. Thus, hate increases every time the hero takes an action.

I figured that it'd be good to also have hate constantly deplete, so I set up a constant HATE_DECAY_RATE and decrease the unit's Hate by that amount each turn, to a minimum of zero. For now I'll set HATE_DECAY_RATE to 1, but that's an arbitrary amount and will likely change during play testing.

So here's what happens:
1.) The AI unit determines which units are in its "awareness range."
2.) It checks which faction each of these units belongs to.
3.) If it's an enemy faction, the unit is added to an array of targets.
4.) The array is sorted by each unit's Hate level, highest to lowest.
5.) The AI determines if it can attack any of the units on the array this turn, and if so, targets whichever one of these has the highest Hate.
6.) If there is no enemy unit in attack range, the AI moves to the point nearest its most hated enemy.
7.) The AI checks to see if it has any buffs it can cast on itself.
8.) If not, it defends.

There'll probably also be a rule that takes precedence stating that if the AI can heal itself and its HP is below a certain threshold, it will do that instead, and move as far away from all enemies as possible.

Multiple Targets
I don't know exactly how I'm going to handle this just yet. It'd be a lot easier to just have the most hated enemy get targetted and then figure out if there's a way to hit any other enemies at the same time....the other option trying to figure out what combinations are available and which ones have the highest combined Hate, which would be processor intensive and also potentially brain melting.

Factions
I mentioned this earlier, so I thought I'd cover what it meant. There are several factions in the game, each with an entry in the Faction database. Each unit has a faction that it belongs to, and its faction determines whether other units are enemies, allies, or neutrals to it.

While each faction has some flavor text associated with it, as far as system stuff goes the Faction object is just an object that has an array with a value for each of the factions (including itself, though this value is mostly ignored), and this value can be FTUDE_FRIENDLY, FTUDE_NEUTRAL, or FTUDE_AGGRESSIVE. I'll let you guess what these constants signify.


Of course this just determines who will be attacked, not how they'll be attacked. I'll cover that next time.

Miscellaneous

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

Prologue

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.



Pages: 1