On the Prototype to be programmed

Once again, I think back to the blogs I have been writing and I realize that I am not the best communicator. The last couple blogs are like sketches of tiny pieces of a great technical schematic, with little mention of what the schematic is for. This blog is attempt to remedy that. To give some kind of goal to what all those little sketches are for. For the programmers, after reading this, all of you can mention off a complete, ideal, and clear list of details that you need before you start programming.

The very first thing to be programmed, tested, and got "right" is a basic combat protype. The goal of this is to get the heart of the game fluid, balanced, workable. This is where players will be spending most of their time. When we get this part right, a solid third of the work on the game will be complete.

GUIThe Basic Combat Prototype needs a very limited GUI. The GUI will be for testers to create and customize characters. There will need to be a character creation screen, and a combat screen. In the character creation testers can 1)set levels, class and race. 2)set the fab-five attributes 3)set armor/weapons appropriate to their level. Experience points are not needed for the basic combat prototype. In the combat screen, the testers will be able to see 1)their character's mana, health, attack and def ratings. 2)the same for their opponents. 3) Buffs and de-buffs on all characters. 4) a way to pick what actions the characters will do during the round of combat. 5) color coded text, at the end of combat, indicated combat resolution.

Remember, combat in this game is entirely turned based. Just like the squaresoft games. The important difference is that no selected action resolves until all characters have chosen an action for a particular round.

Classes The details of each class are yet to be determined. For the sake of the BCP, we will create Fighters, Rangers, Rouges, and Mages. The classes will relate to each other in rock-paper-scissors relationship. Fighters will have the advantage against Rangers, Rangers against Rouges, Rouges against mages, and mages against fighters.

Priests will be excluded for now since healing is an imbalancing force. Hybrid classes (Druid, Paladin etc) will also be introduced later.

Vanilla Abilities/Calcualtions. There will, of course, be vanilla abilities that are needed in combat. Here they are: Damage(melee weapon), chance to hit/crit(melee weapon), initiative, damage(ranged weapon), chance to hit/crit(ranged weapon), damage(spell), chance to hit/crit(spell), chance to evade, chance to block

How all of this is determined is the subject of another blog.

Special abilities These are the class specific abilities like a wizard spell or a heavy strike with a weapon. All of this will be determined later. These abilities are important because they will help determine how the classes have advantages on each other.

Weapons and Armor Levels will limit what types of weapons characters can use. Like wise with weapons. Armor will be classified as cloth, light leather, heavy leather, and metal. Armor will have a numerical rating. When the rating is compared in a ratio of cloth : light leather : heavy leather : metal will be 1 : 1.5 : 2 : 3. For instance, if a level 1 wizard has armor that gives him a rating of ~10, than a warrior (wearing metal) will have armor rating of ~30. Higher levels will have access to stronger and strong armor, but the rating will always be in the same ratio. Armor will affect 1)chance to hit, 2)damage absorbed.

Weapons will be much easier. Thing of D&D 2.0 rules. All weapons have damage, speed, and type. we don't even need to worry about type of damage. All we need to list is that "Long sword deals 1-8 base points of damage." The base is multiplied by a character attribute. This will be discussed in another blog.

Initiative This is probably the most tricky part of the Basic Combat Prototype. Initiative will *not* determine what order a player chooses what he will do in a around. Rather initiative will determine a chain of events that resolve at the end of a round of combat.

Initiative will be first decided by a random roll between 1-20. Higher numbers, mean that the character's actions resolve first. Weapon speeds subtract numbers. Casting time subtract numbers. Speed potions add numbers. Magical buffs add numbers. Here's an example of how it works:

GoodRouge1, GoodFighter1 and Goodfighter2 are in a battle with Evilmage1 Evilmage2 and Evilranger1. All characters choose actions:

Goodrouge1 -> Attack(Evilmage2)
GoodFighter1 -> Cast KnockOutPunch(EvilRanger1)
GoodFighter2 -> Attack(EvilMage2)

EvilMage1 -> Cast FrostBolt(Goodfigther2)
EvilMage2 -> Cast PoisonCloud(GoodRouge1)
EvilRanger1 -> Attack(Goodfighter2)

Now that every has chosen their action, initiative is decided. The order is based on random rolls, weapon speeds, and casting times. After the rolls are decided, the order looks like this:

1. GoodFighter1 -> Cast KnockOutPunch(EvilRanger1)
2. EvilMage1 -> Cast FrostBolt(Goodfigther2)
3. EvilRanger1 -> Attack(Goodfighter2)
4. GoodFighter2 -> Attack(EvilMage2)
5. Evil Mage 2 -> Cast PoisonCloud(GoodRouge1)
6. Goodrouge1 -> Attack(Evilmage2)

Each step fully resolve before the rest of the chain. So GoodFighter1 -> Cast KnockOutPunch(EvilRanger1) resolves first. The Knock Out punch suceeds. The ranger is now unconsious for x rounds, and his actions this round are negated. The order now looks like this:

1. GoodFighter1 -> Cast KnockOutPunch(EvilRanger1) (Resolved)
2. EvilMage1 -> Cast FrostBolt(Goodfigther2)
3. EvilRanger1 -> Attack(Goodfighter2) (negated)
4. GoodFighter2 -> Attack(EvilMage2)
5. EvilMage2 -> Cast PoisonCloud(GoodRouge1)
6. Goodrouge1 -> Attack(Evilmage2)

Evilmage1 now cast frost bolt. It succeeds. Frost bolt does damage, and addition subtracts from all initiate rolls. In this case, the subtraction from initiative rolls. In this case, the subtraction from Goodfighter2's roll is enough that his original roll is now lower Evilmage2's roll, but still higher than Goodrouge1's roll. The new order looks like this.

1. GoodFighter1 -> Cast KnockOutPunch(EvilRanger1) (Resolved)
2. EvilMage1 -> Cast FrostBolt(Goodfigther2) (Resolved)
3. EvilRanger1 -> Attack(Goodfighter2) (negated)
4. EvilMage2 -> Cast PoisonCloud(GoodRouge1)
5. GoodFighter2 -> Attack(EvilMage2)
6. Goodrouge1 -> Attack(Evilmage2)

Evilmage2 casts PoisonCloud. The Rouge happens to have an item that makes him immune to poison. It fails. The next order looks like this.

1. GoodFighter1 -> Cast KnockOutPunch(EvilRanger1) (Resolved)
2. EvilMage1 -> Cast FrostBolt(Goodfigther2) (Resolved)
3. EvilRanger1 -> Attack(Goodfighter2) (negated)
4. EvilMage2 -> Cast PoisonCloud(GoodRouge1) (resolved)
5. GoodFighter2 -> Attack(EvilMage2)
6. Goodrouge1 -> Attack(Evilmage2)

You can see how this goes on and on. Now, the players will never actually see all this text as the chain resolves. That is just for the computer to work out for programmers to conceptually understand. Instead, they will only see the final result at the end of the round. The final output of this round of combat will look like this:

Goodfighter1 knocks out Evilranger1! for 233pts of damage
Evilmage1 fires Frostbolt at Goodfighter2 for 140pts of frost damage.
Evilranger1 is unconscious.
Evilmage2 casts Poison Cloud on EvilRouge1! Target is immune!
GoodFighter2 attacks EvilMage2 for 430pts of damage!
Goodrouge1 attacks evilmage1 for 230pts of damage!

The numbers for damage here are arbitrarily chosen, as this example was only meant to show how end-of-round combat resolution works with initiative. After this output, the players will again choose what their characters will do.

Fluidity One of the most important things in BCP is a sense of fluidity. Have you ever played a game where your character's NEVER hit their targets, and combat moves at a slow pace? That's annoying. Players need to feel that they are getting somewhere in combat, espeically PvP combat. Thus, no matter what kind of math we do to come to calculate formulas, the following things should be true between evenly matched characters.
1. Two evenly matched fighters should land hits against each other approx 60% of the time. Before armor de-buffs are considered.
2. A mage, when casting spells that have a chance to hit, (Frostbolts, fire bolts, magic missles) should hit evenly matched warriors approx 60% of the time, before armor de-buffs are considered.
3. Stealthed Rouges should have only a 10% chance getting spotted by a opposing character if the rouge's DEX matches the opposing character's PRC and they are of equivalent level.
4. Spells that do not use chance to hit (spells that do not act like thrown projectiles, such as a sleep or fear spell) should only be resisted approx 10% of the time among evenly matched characters.
5. Dueling between two evenly matched characters should not last aprrox 5-9 rounds, before healing is considered.

Wow. This turned out a lot longer than I expected. My hope is that all of you reading this will have a better understanding of what I am going for. I really want to give anyone who writes the program of this exactly what they need in order to understand how this program will be developed.

The Basic Combat Prototype will eventually be used to test, tweak, and just balance in the game. Before that happens though, I ask anyone to email me a list of things they need in order to write an algorithm, and eventually a program, that can run this.

This is goal of everything else posted in the blog for now. Lots of brainstorming and such will have to take place, and lots of feedback from programmers is needed before I can write up a final document.