Chapter 3: "Who's On First"
Some details, ideas, and
musings I've had experiencing effective RPGs and RPG Makers
© March Written by David Wicker
Please do
not reprint without permission
Hello and welcome back.
First, a bit of disclaimer. This book is not intended to teach you how to play video games or even RPGs. If you're interested in that, I have written a separate article that can be found HERE.
No, this book and its following chapters go in-depth and in-detail about the mechanics behind RPGs, the programming involved in building your own, and ultimately chapters that will deal with presentable subject matter, plots, stories, characters, and the like.
And even if you're not a programmer, you STILL might also enjoy reading these chapters if just to flesh out just what it is YOU want to play in a successful RPG, by being forewarned and forearmed with the knowledge of those existing already out there.
Let's begin.
This particular chapter is about any RPG where there is more than just one player in the roster.
In truth today it's rather difficult to find turn-based RPGs where there is only one player. An example of this would be early Dragon Warrior for the NES. S2 For Windows XP. And Great Greed for the Gameboy which although only had one player, it allowed you to have a "companion" which helped you in combat but did not actually have hit points of their own.
No, this will go into the mechanics of the classic 4-players, like you would see in Final Fantasy 1 for the NES, or as it was remastered later, Final Fantasy Anthology.
And of course the question on everyone's mind is, who's on first ? :)
In combat, there are many ways to handle this. The most popular is where you choose a set of commands for your 4- or more players and once you have done this, the computer will determine who goes first depending upon who has the highest SPEED and DEXTERITY of the attacker, and it might not just be the players.
The combatants you are fighting might have a high index and indeed get their move out before any of your players can. This is especially true when fighting BOSSES which invariably have uniquely high attributes compared to standard random encounters.
The problem with this is, let's say one of your players was killed in combat. Okay, you want to do a 2-stage regeneration to bring them back, which takes 2-players to do, but you can't guarantee the order in which their commands are carried out.
Thus you might have one player on his turn cast a healing spell on your dead character, which does nothing, and then after that, your other player's ability comes into play where they cast "Raise Dead."
Let's look at a possible command set.
[P1] [P2] [P3] [P4]
So you would need to enter commands for all 4-players in order, BUT when you actually get to the movements, it might be sorted like this, with a bit of random thrown in for flair:
[P2] [M3] [P1] [M1] [M2] [P4] [P3]
Consider the way Arcana did it for the SNES or Chrono Cross for the PS1. Really quite nice. They created a command BATCH which had all the players and monsters mixed up and then laid out, IE:
[P2] [M3] [P1] [M1] [M2] [P3]
For instance.
So when you first enter combat in Arcana, the 2nd player will get an option for a command and RIGHT THERE after it is chosen, that command is enacted, and yes, this is pretty non-standard in most RPGs.
But doing so you are guaranteed to do a successful "Raise Dead" and "Heal Player" in the order you want, as the command is done the instant you choose it, provided of course, a monster doesn't whack the player you just raised from the dead before you can get to the player's command that has the "Heal" ability.
So ... why do a queue if you can't know the order in which they are done ? Why not just always have the player or monster do the command right then and there ?
I think this hearkens back to good old strategy games like boxed and boarded Dungeons & Dragons. Everyone would tell the Dungeon Master what they wanted to do, and then the Dungeon Master would roll dice to see "Who Goes First" and then try to do all the commands that the players want.
There is a definite sense of uncertainty when you play it this way, but maybe that's where some of the fun comes in. Someone once mentioned a true adventurer, a really and true one "prefers their wounds well salted."
The advantage of doing a queue also instead of doing a command the instant you choose it is if you have say 15-players in a deep tactical game fighting say 30-monsters, then the player can hold (A) or whatever button does a select and hold it down for all 15 of their players to choose the last same combat option again.
And then sit back in their chair and relax a bit to watch the combat ensue.
And with 45 combatants, like you could have in Final Fantasy Tactics, that could take about a minute or so of true game playing time. Some people enjoy this kind of approach. Where they tell their team or army what to do and then they go and automatically do it, in the order they were chosen of course, and then just sit back and watch all the commands they chose earlier take place then.
Final Fantasy 1 for the NES when it first came out would ALSO make one of your 4-players MISS A TURN COMPLETELY if they chose to attack a monster that was already defeated. So now you have the added complexity of knowing whether a monster is defeated or not before choosing more than one player to attack them.
When I played FF1 for the NES, I would always divide my commands. So, for instance, if there were two monsters, I would have player 1 & 2 attack the first, and 3 & 4 attack the second. It wasn't very efficient as it's always better to gang up on one monster to defeat them so you have less monsters attack after, but you couldn't do that - not in FF1 for the NES.
This only happened for FF1 for the NES and nowhere else. Remastered FF1 for the Gameboy Advance, Sony Playstation, PSP, and so on always chose a random monster to hit if the player chose a slot where the monster was defeated earlier.
And choosing to attack a random monster could be devastating later if you have a monster, say, that is in a special mode where attacking them causes great damage to all players. But that's the price you pay for choosing a random attacker instead of missing one entirely.
I think you will find as you code your RPG or RPG Maker that combat is a very immersive element to the game. Some games rely on the delays random combat encounters create, like "Legend Of Lagoon" to puff the game out to ridiculous lengths.
Legend of Dragoon for instance has a 5-second screen fizzle for random encounter, 5-seconds to see the critters in the combat area, and a length 2-3-seconds to see each player attack, 5-seconds victory dance when you win, and 5-more seconds to show the animation of returning the player back to the mapper.
You add up all those precious seconds and simple random encounters that could've been quick actually take long minutes. And yes, this is a very bad practice. Let's hope when you write your combat engine, it will be fast, fun, and furious. Yes, I like those 3-words especially.
. . .
Next week we're going to cover the meat and potatoes. I know, these chapters are probably not in any particular order and it may require all of them to be written to see the whole picture.
But next week we'll cover what you've been waiting on. The graphics and music, and why text, yes, good old frames of dialogue, is so very terribly important in RPGs. If you don't have a good story, no amount of fine graphics or animation is going to save the strengths in your game.
Back in the dawn of computers you remember, graphics and sound were not even there. Not really, not for DOS. Good adventure games back then relied on solid stories, lovable characters, and depth of design. If you can guarantee those in your game today, you are that much further on from completing a masterpiece.
Until then, keep on thinking ... your brain will thank you for it later !
prev chapter
Share This
Email
Facebook
Twitter
Read Request
My Library
Subscribe
Flag Writing
