Battle Mode
From Hero of Allacrost
Contents |
Original Battle Concepts
While Hero of Allacrost is a traditional RPG at heart, the development staff has brought many unique ideas to the battle system, in hopes of redefining the tradition RPG battle. Driven by boredom and frustration, our system hopes to fix those issues.
ATB
ATB stands for Active Time Battle, which means that the battle will take place in real time. You can attack or be attacked at any time. No longer will you have to wait for your turn. For the sake of being able to follow the system, however, all attacks will be placed into a queue and done one at a time. However, they can be queued at any time.
MAPS
MAPS stands for Multiple Attack Points System. Each character in battle can be attacked at different points on their body. Each point has different weaknesses and chances of being hit. These points and their weaknesses and strengths are defined by the equipment a character is wearing; each piece has its own individual stats.
Every Enemy is Unique and Difficult
Every enemy encounter should be difficult. Gone are the days of pointless battles with weaker, identical enemies. Rather, every battle is unique. Enemies are leveled up, using a Gaussian randomizer, to the party’s average level. This not only puts each enemy at the same level of the player, but also makes each enemy have unique stats, making each battle different.
Swapping Characters
Disgusted by either lack of swapping ability and swap abuse, the Hero of Allacrost team has implemented a swapping system that uses “swap cards.” Only a certain amount of these cards can be held at a time, depending on your party size. As well, to swap a character, they must have >20% health.
This system is still very much in the design phases. Ideas include forcing the oncoming character on screen to defend the retreating character, making both characters unusuable for a certain period of time.
Losing a battle
Another concept the Hero of Allacrost team tired of was dieing in battle and being forced to your last save point. Rather, a loss in battle presents the player with a choice: 1) restart from the last save point, or 2) restart battle, with a 10% loss to experience and a 10% loss to gold, as well as the loss of any items used in battle.
Character Stats
These are the statistics each character has in battle.
HP
HP stands for Health Points. Once Health Points reaches 0, the player faints and is no longer usable in battle. When a team’s total HP reaches 0, the team loses.
SP
SP stands for Skill Points. Each skill (see skill section) requires a certain number of skill points to execute. The number of skill points required for each skill is deducted from the characters SP when the skill is performed.
Stamina
Stamina represents how tired a character is. Stamina is constantly increasing, while action makes it decrease. Stamina helps to calculate how effective a skill will be. If stamina is at 50%, a skill will only perform at 50% (whether it be deal 50% damage or heal another character 50%).
Skills
Every action taken by a character in battle is represented by a skill, which requires a certain amount of Skill Points and Stamina. There are three types of skills: Attack, Defense, and Support.
Attack
Attack skills are skills that cause damage to another player, whether it be through physical or magical means.
Defense
Defense skills place the character in some sort of defensive posture to increase his defensive capabilities. This concept has yet to be fully fleshed out.
Support
Support skills are skills that increase the status of a character, whether it be strength, agility, intelligence, et cetera. These are temporary effects.
Status Effects
There are several types of status effects. Some are beneficial to the character they are affecting while others are not. An example of a beneficial status effect would be an increment to strength. An example of a non-beneficial status effect would be something like poison. Beneficial status effects wear off over time, while non-beneficial status effects must be cured.
Range of Effects
Effects have different levels. These levels are: lesser, normal, greater, and ultimate. If a character is already under the effect of a “lesser” effect and an identical “lesser” effect is cast on them, the status of the effect goes to “normal.” On the other hand, if the effect was “lesser,” and a “normal” effect was to be cast on the character, the status of the effect would become “greater.” If you look at the screen shot below, these levels are represented by colors around the effect. The colors have yet to be finalized, but will probably range from green to yellow to red to black.
The system can be thought as numbers one through four. When two identical effects are cast on a character, the status of the effect becomes the sum of the two statuses, capped at four.
The system works backwards as well, with cures. If a “normal” status effect is afflicting a character and a “lesser” cure is used, the status of the effect will only be reduced to “lesser.” Once the status becomes equal to 0, the status is removed.
The levels correspond to the power of the effect. An ultimate poison would cause much more damage than a lesser poison, just as an ultimate strength boost would cause strength to increase far more than a lesser strength boost.
Attack and Defense Types
Each weapon and piece of armor has its own strengths and weaknesses, both elemental and physical, which in conjunction to a characters natural fortitude or intelligence defines the amount of damage done or prevented.
Elemental Types
There are four elemental types, which play a round robin with one another.
Volt
Volt is an electrical element. It is strong against water and weak against earth.
Earth
Earth is a ground element. It is strong against volt, but weak against fire.
Water
Water is both a water and ice element. It is strong against fire, but weak against volt.
Fire
Fire is just as its name says. It is strong against earth, but weak against water.
Physics Types
As well as elemental types, there are three physical types, which have a one-to-one correspondence, meaning that if I have armor that is strong to piece, and a slash attack is performed, no extra damage is done. However, if my armor is strong to slash, I would be protected extra.
Piercing
Piercing includes objects that use tips to perform their damage. Examples include daggers, arrows and spears.
Bludgeoning
Bludgeoning objects that do not use a sharp edge to perform damage. Examples are clubs and mallets.
Slashing
Slashing includes weapons that use sharp edges to perform damage. Examples are swords and axes.
The GUI
The GUI is still very much under development. Please check the Hero of Allacrost website forums to discuss the latest design.
Enemy damage blending
Certain things are concrete about the GUI. Enemy damage blending is an example. To show how much health an enemy has left, they are blended with a damage frame. There are four frames, which give the player an idea about how much damage the enemy has taken.
Example Screenshot
This is an example screen shot of what the battle system design currently looks like. It was designed by nunvuru.
Recent discussion held in IRC about Lua and its integration with the Battle Engine
[1:30pm] visage: okay, well there are two places I see Lua really coming in handy with the battle engine
[1:31pm] visage: the first is in the form of Skills (the damage done, the effects they have, et cetera)
[1:31pm] Zorbfish: data
[1:31pm] visage: The second place is in the form of effects
[1:31pm] visage: well, not just data. as well as saying "play this sound effect, play this animation, move this direction"
[1:31pm] visage: I think coroutines will come in handy. a lot.
[1:31pm] Zorbfish: ok
[1:32pm] visage: because I need to be able to say "during this whole scene, play this music, play this background animation, begin moving character to x,y, playing sword slash animation and play sound at the same time, move character back."
[1:32pm] visage: I think lua will give us great functionality as far as allowing designers to create any effect/skill they dream of
[1:32pm] Zorbfish: so probably a lot of that would be on Lua's side then
[1:33pm] visage: so the way I would like it to essentially work is me just say "skill->Run" and "effect->Update" or something like that, and have Lua take off
[1:33pm] visage: yeah, a lot on Luas side (which I would definitely be willing to do, by the way)
[1:33pm] visage: But to be quite honest, I don't know lua's limitations and capabilities.
[1:34pm] Zorbfish: ah so you prefer that you just hand off scripts and they run themselves
[1:34pm] visage: As well as how I would go about giving you getter and setter functions.
[1:34pm] visage: Yeah. Essentially. But I think the scripts should have access to functions in the battle code to make things easier
[1:34pm] visage: just like "PlayAnimation("RUN")" and that sort of thing
[1:34pm] Zorbfish: anything can be bound so dont worry about lua
[1:34pm] visage: do they need to be C style or C++ style?
[1:35pm] Zorbfish: well afaik Roots really wants control of binding so probably C++ style using a class
[1:35pm] visage: okay.
[1:35pm] Zorbfish: personally I'd rather skip that but, meh
[1:36pm] visage: well whatever is easiest for you. I have written C, so no big deal for me. I just need a general template to work with
[1:36pm] Zorbfish: ok so is there any situation you can think of where you'd need to call Lua yourself from the battle engine?
[1:36pm] visage: not that I can think of....not yet at least
[1:37pm] visage: just calling methods to get the scripts running
[1:37pm] visage: I basically just want all the scripts to be stored in a Map, and call the scripts by their names
[1:37pm] Zorbfish: so a self automated queue
[1:37pm] Zorbfish: k
[1:37pm] visage: so when I say "Claudius casts HEAL", I grab the script with the "HEAL" key, and just run it
[1:38pm] Zorbfish: k
[1:38pm] Zorbfish: was there anything you needed bound to the engine itself?
[1:38pm] visage: for skills, I would pass in the current character using the skill, and any argument characters
[1:39pm] visage: Herm, not that I can think of. I am pretty new with Lua and its integration
[1:39pm] Zorbfish: lemme get a link
[1:40pm] visage: is Lua OO capable?
[1:40pm] visage: like, are calls more like
[1:40pm] visage: "int xloc = e->getX();"
[1:40pm] visage: or "int xloc = getx(e)"
[1:40pm] visage: ?
[1:40pm] Zorbfish: yep
[1:41pm] Zorbfish: for instance it could be like PC:Move(x, y)
[1:41pm] Zorbfish: where we could bind PC right to Claudius data, etc
[1:41pm] visage: lemme send you an idea for how I want the scripts to look, and you tell me what you would make them look like
[1:41pm] Zorbfish: k
[1:42pm] visage: Im going to just make it in english so that you can translate it however you want (procedural or oo)
[1:42pm] Zorbfish: k from that I'll whip up a Lua interface for all scripts
[1:44pm] visage: nice nice
[1:45pm] Zorbfish: btw is current iteration of the battle engine still in design or have you started coding it yet
[1:46pm] visage: ive started coding
[1:46pm] visage: im well into coding
[1:46pm] Zorbfish: committed?
[1:46pm] visage: my biggest issue is that I need these lua scripts running while I am updating the rest of the battle as well, because all characters run concurrently
[1:46pm] visage: not yet. im going to commit soon
[1:48pm] visage: okay, ill send you the script in PM
[1:49pm] visage: its fairly complicated, but shows most of the features I would need
[1:49pm] Zorbfish: k
[1:51pm] Zorbfish: ok so lets break down and maybe list everything needed
[1:52pm] Zorbfish: animations, sounds, movement, data manip, and delays?
[1:53pm] visage: yeah...
[1:53pm] visage: basically
[1:53pm] visage: but data manip breaks down into the kind of thing where it is "apply"
[1:54pm] visage: and the actual manipulation is done in the battle engine
[1:54pm] Zorbfish: yea I just was categorizing it
[1:54pm] visage: yeah, but you got it for the most part
[1:55pm] Zorbfish: if at the start of battle every participant was bound to Lua that could simplify the argument passing
[1:56pm] visage: makes sense to me
[1:57pm] Zorbfish: k I'm gonna do a quick translation
[1:58pm] Zorbfish: show total damage would be like drawing the damage number like FF right?
[1:58pm] visage: exactly
[1:58pm] visage: I want showing damage and calculating damage to be seperate
[1:59pm] visage: so you could either show the damage after each slash or do all the slashes, then show the damage
[2:04pm] Zorbfish: i collapsed some of the commands to make it higher level
[2:05pm] Zorbfish: animations and sounds for skills would probably be best as like a data definition of the skill
[2:05pm] Zorbfish: those could be loaded when the battle begins and probably cached since skills dont change (at least for PCs)
[2:05pm] visage: sounds and animations will be preloaded
[2:05pm] visage: by the general game engine
[2:06pm] visage: consider all skills, animations and sounds to be preloaded
[2:06pm] Zorbfish: i mean like defining a slash
[2:06pm] Zorbfish: well that's true
[2:06pm] visage: okay, but something like "moveto"
[2:06pm] visage: is that another lua implemented thing?
[2:07pm] Zorbfish: yea it'd wrap the movement from one position to the next
[2:07pm] visage: because it would need to play sound, move, and show animation at the same time
[2:07pm] visage: cool
[2:07pm] Zorbfish: that's part of the actor itself
[2:07pm] visage: and thats the sort of thing you would use coroutines for?
[2:07pm] visage: okay, but here is an issue. I need to update other characters while this script is running
[2:07pm] visage: so what I would probably need to do is store "currently running scripts" and only have them update a little per frame
[2:08pm] visage: so the rest of the characters can do AI and update their animations while this guy is running
[2:08pm] Zorbfish: moveto would hide that basically it would like:
[2:09pm] Zorbfish: while not at destination do
[2:09pm] Zorbfish: move a bit
[2:09pm] Zorbfish: yield script
[2:09pm] Zorbfish: end
[2:09pm] Zorbfish: so it stops after moving the guy across the screen one step
[2:09pm] visage: yes. awesome.
[2:09pm] visage: but I don't want script writers to have to write "yield" every second, you know what I mean?
[2:10pm] Zorbfish: yes that's why I wrote moveto. Moveto would contain that loop for them
[2:10pm] visage: herm, okay. ill take your word for it
[2:11pm] Zorbfish: well what I'm going to try and do is just like you said remove yield
[2:11pm] Zorbfish: playing an animation would be the same just it would move to the next frame then yield
[2:11pm] visage: yeah. but I mean, what if the scripter writes a huge script without calling any yields or something like that?
[2:12pm] Zorbfish: ah
[2:12pm] visage: is there anyway I can yank if the script is taking too long?
[2:13pm] Zorbfish: well I know there is a way to tell Lua itself to stop running after so long. I planned on using it to make the engine act like a thread
[2:13pm] visage: that would be perfect
[2:13pm] Zorbfish: but as for individual coroutines I don't think so
[2:13pm] visage: oh, never mind.
[2:13pm] Zorbfish: like if Lua spends to much time running it can be suspended
[2:14pm] visage: okay.
[2:14pm] visage: well, basically the way I see it working in the battle engine is like this:
[2:14pm] Zorbfish: but most of the commands you mentioned probably would have yields anyway so it would be hard to keep them from hogging the frame
[2:14pm] visage: call Update on each character. if they are currently running a skill, call update on that. if they have any effects on them, and the time elapsed since the last update of the effect is greater than the update time, call the effect script to play the new animation and change stats
[2:15pm] visage: what I am trying to essentially do is put as much content management in the lua scripts while putting as much code reuse in the battle engine
[2:16pm] visage: how would I go about knowing when a scirpt is "done" running
[2:16pm] Zorbfish: yea im just trying to think that myself
[2:16pm] visage: like "keep updating the script every frame until it is done."
[2:16pm] visage: is there anyway each script could have a "is done" method, or something like that?
[2:16pm] visage: and just have the script writer set some boolean to true?
[2:16pm] visage: or are lua calls expensive?
[2:17pm] Zorbfish: no lua isn't expensive
[2:18pm] Zorbfish: the scripts automatically update themselves as long as they have code to run. So the only thing is notifying when done
[2:19pm] Zorbfish: i think a member variable attached to the character would be a good idea
[2:19pm] Zorbfish: this automatically gets reset when a script they're running dies
[2:20pm] Zorbfish: so probably a boolean done like you said
[2:20pm] Zorbfish: but it would be automatic so that the scripter wasn't responsible for resetting it
[2:20pm] visage: wait, a variable within the character?
[2:20pm] visage: so in the C++ code?
[2:21pm] Zorbfish: yea
[2:21pm] visage: also, its way sick that I dont have to call "update" on the scripts and things like that. I like that mucho
[2:21pm] Zorbfish: i agree. being able to drop a script and let it run is one of my goals for this
[2:22pm] Zorbfish: so basically when the battle engine says run X script on Claudius his script flag gets flipped. Then when the script is done it resets and you can run a new script. Kinda like a mutex actually
[2:23pm] visage: mmm....sexual
[2:23pm] visage: I like that
[2:23pm] visage: A lot.
[2:24pm] Zorbfish: ok so any other issues?
[2:25pm] visage: naw, not really at all.
[2:26pm] Zorbfish: k that gives me some direction on where the battle engine is headed.
[2:27pm] visage: awesome man
[2:27pm] visage: im gonna try to whip the code into shape and hopefully the next time we talk about this, we will be testing it out
[2:27pm] visage: because, you know, that would be awesome
[2:27pm] Zorbfish: yea
[2:28pm] Zorbfish: the binder is in data_bind.h or if you wanna go the C way I can send you some examples and links on how to do it via email
[2:28pm] visage: ill look into data_bind.h, if thats what Roots wants
[2:28pm] visage: no need to annoy the dictator
