Prologue Release -- Battle Changes and Features

[Roots]

There's a lot of incremental improvements that need to be made to our battle system for this next release. I wanted to maintain a list here of what I'm planning to add/remove/change and allow people to give their feedback in case they strongly oppose a change or have any sort of requests. Once the wiki is available again, I may move this list over there. I'll be editing the list in this first post periodically to account for any changes.

----------------------------

Additions
- Battle dialogue
We had this feature working for a short time during our work on demo 1.0, but then I changed a bunch of things and broke it, and we never fixed it in time for the release. I think it will be a requirement in order to effectively tell the story for this portion of the game

- Ability for skills/items to target an entire party
We'll have at least one usable skill that can target an entire party, thus this feature will be required.

- HP recovery text will appear as green while damage continues to appear as red
Obvious.

- Full support for status effects
Status effects mostly work already. There just needs to be more support for more variety of status effects and to have them be more obvious to the player

- Ability to quickly view information about selected skills, items, and targets
Support is already almost completely there. Just the draw code needs to be implemented here

- Enemies can execute more than one type of skill
Should be very simple to implement.

- Attack points have modifiers and possible status afflictions
This is one of our original features and we still have not implemented it entirely. In the prologue, I want there to be a purpose to having attack points on our enemies.

- Ability for actors to "stun" or "knock back" one another on the status bar
This is a feature borrowed from Grandia 2's battle system. Basically when you succesfully strike an enemy, they "pause" for a little bit on the stamina bar while they recover from the blow. And certain skills can cause a longer pause or even knock back an enemy's progress on the stamina bar, or cancel a skill that they have selected and are about to execute. This is a really awesome feature and makes battles much more dynamic and strategic.

- Battle retry feature
This feature allows the player to "start over" a battle that they lost immediately. The battle is restored to its initial state and the player gets to try again. They can do this a maximum of twice, and if they lose the third time its "game over" with no more retries. Each retry, though, takes a significant penalty on the XP and drunes earned once they win the battle (say, -33% for each retry). So they can choose between going back to their last save point and fighting to that spot again, or attempt the battle again and take the penalty should they win. (This shouldn't be too difficult to implement, especially with the current state of the battle code).

Removals
- Enemy's are "leveled up" to match player party strength
This feature was unpopular and made the game very difficult to balance. It has already been removed. Enemy stats are still applied to a random Gaussian distribution though, so two instances of the same enemy will vary slightly in their strength


Modifications
- Stamina regeneration slowed down among all actors
Right now I think battles go by way too fast and its too chaotic. I'm planning to slow things down a bit by changing the stamina timer algorithm. I was thinking of taking the actor with the highest stamina (the one that regenerates the fastest) and setting them as the baseline, say for 10 seconds. Therefore every other actor will take longer than 10 seconds to regenerate their stamina. This is just a rough idea at this point and I'll tweak it I'm sure, but I do think that some change to stamina regeneration rate is needed.

- Better animation flow
Example: right now if a character is in mid-swing of their sword while attacking and another character is available to select an action, the action will "pause" completely. I'll change this so that the actors executing their actions continue to do so while another skill is being selected for a different character.

- Cleaner victory sequence
The instant that the enemy party is defeated, the victory music immediately begins blaring and the XP/drunes/items dropped window pops up. I'll improve this so that there is a smoother transition from the end of the battle to the rewards screen.


Future Plans
This is a non-comprehensive list of features that we'll implement sometime in the future, but not for this release.

- Elemental effects
- Enemy AI (enemies will continue to choose a random action and a random target for now)
- Skill graphics (showing different graphical effects when skills are executed)
- HP/SP bars that change color based on current HP/SP values versus their maximum
- Display name of skill being executed by an actor (maybe)

----------------------------


Most of the features shouldn't be more than a few hours work, so I'm fairly confident that I'm not biting off more than I can chew.

[rujasu]

Mostly, I agree with this.

- Display name of skill being executed by an actor
Pretty much every RPG does this. I realized it makes it a lot easier to immediately know what is going on, especially since currently the execution of a lot of our skills look/sound the same. I may also add the actor executing the skill as well. So for example the top of the screen would say: "Claudius - Blade Rush" or something.

This, however, I'd really rather avoid. FF did it, a few others did it, but then again CT and plenty others didn't. I prefer not doing it.

[Roots]

Okay, that's fine with me if we leave that feature out. Its not that important anyway and I hadn't set my heart on it or anything. We can always add it at a later time if we find it would be better to have than not.

[Roots]

Added battle retry feature to the additions list. That's an important feature (that's also easy to add) that I just remembered tonight.

I'm also having some doubts about implementing the stamina bar stun/knock back feature. It may turn out to be a lot of work, though I'm not sure at this point. I'm putting it on my "may have to save it for later" list depending on how all the other work goes.

[Roots]

I'm going to hash out my current thoughts on possible algorithms for idle state wait time (ie stamina regeneration). If you have any proposals or ideas of your own, pleas share.


I recently changed the algorithm to be based around the fastest actor (the one with the highest agility). The fastest actor in a battle has a set idle state time (currently 10 seconds) and all other actors have slower times. So if actor X has the highest agility with a value of 100 and actor Y has an agility of 50, Y will have an idle state time of 20 seconds. This algorithm has problems though.

Problem #1) The algorithm doesn't scale naturally. For example, assume we have actors A-B-C-D with agility values of 100-75-50-25. You'd expect the difference between any two adjacent pairs of actors to have the same difference in idle wait time, wouldn't you? But this algorithm would give those actors wait times of: 10s-13.3s-20s-40s. It scales logarithmically instead of linearly.

Problem #2) If just one actor has a very high agility rating compared to all the others, then all the others are going to take a long time before they can select an action. A fast actor might be able to get 3-4 turns in before the slowest actor gets a chance to have their first turn.



So I'm thinking of an algorithm that would avoid these problems by using a linear scaling mechanism and one that takes both the fastest and the slowest actors into account. It might work something like this:

- Actor with highest agility set to a defined minimum idle state time (Tmin)
- Actor with lowest agility set to a defined maximum idle state time (Tmax)
- All other actors have a wait time between Tmin and Tmax. If we were to plot Tmin and Tmax on a 1-dimensional axis, the time values plotted for each actor would correspond directly with their agility values, were the highest/lowest agility be plotted on the same graph as Tmin/Tmax

But even this has its problems. What if the battle has only two actors (X and Y) with very close agility values (say, 102 to 100)? That means that the faster actor would have a much much faster idle state time (Tmin) than the slower actor (Tmax), even though the difference between their agility is only a value of 2. This algorithm would utterly fail this case.


Maybe the optimal solution would be one that analyzes the variance in the data set (comprised of actor agility values) and constructs different algorithms accordingly? I think I'm going to see what I can find online about this and see if I can find examples of what others have done. Or maybe ask for some advice at an online mathematics community.

[Roots]

Another tweak that I need to make is to the indicator graphics and text. What I mean by this is the little status icons that appear briefly to show status afflictions and the damage/healing text. Currently these indicators display to the left of characters and to the right of enemies. In another topic long ago, rujasu said he didn't like this and thought they should be drawn in the middle over the character instead. And I think he's right.


Take a look at how Secret of Mana did their indicators in battle:

http://www.youtube.com/watch?v=v66VSsNB4ME


I really want to do something very much along the lines of that. Currently our damage numbers are really hard to read because they are very small. I'm almost thinking we should declare special font sets specifically for battle indicators so we get nice, big, easy-to-read numbers. Plus I want to do the text size change like SoM does (in fact we already do this, but our various text sizes are all small and similar to each other so its difficult to tell).


The more difficult question to ask is what to do about our status indicators. Do they sit at the bottom as well? (Maybe a bit further below text, so that text and icons overlap only a little bit or never). If we have multiple status changes queued up, do we show multiple icons at once or force them to go by one at a time? Personally I think I'd like to see them appear on the bottom similar to text, and not have them scroll as much as they do now.

[Roots]

Status Update! These features are complete or nearly complete.

Additions
- Ability for skills/items to target an entire party
- HP recovery text will appear as green while damage continues to appear as red
- Full support for status effects
- Ability to quickly view information about selected skills, items, and targets
- Enemies can execute more than one type of skill
- Attack points have modifiers and possible status afflictions

Removals
- Enemy's are "leveled up" to match player party strength

Modifications
- Stamina regeneration slowed down among all actors

Not bad for 5 days of work!


These features remain:

Additions
- Battle dialogue
- Ability for actors to "stun" or "knock back" one another on the status bar
- Battle retry feature

Modifications
- Better animation flow
- Cleaner victory sequence

Battle dialogue will probably be the hardest. But there's lots of dialogue code in map mode that I can borrow to give me a boost on that one. There's a few nagging bugs in battle mode right now as well. None of them are terribly difficult to fix; I've just been putting them off as I work on these features. Off the top of my head:
- Sometimes the target text gets messed up and drawn at the incorrect position (I think extra line breaks are somehow being inserted in the text)
- The game lets you target a dead actor if they were your previous target
- "Critical hits" show up with black damage text instead of red
- You can still select skills even if you dont have enough SP to use them
- The item stock count doesn't seem to be updating when items are used
- Skills that can't be used because of insufficient SP requirements are not grayed out like they should be


Also one final design note. If you select to use skill A on target X, but target X dies or otherwise becomes "untargetable" during the warmup time to execute A, the code automatically selects another random target for the execution of skill A. Instead, I was wondering if we wanted to support an "interruption" pop-up when A is ready to execute and allow the player to select a new target manually, or give them the option to cancel using the skill and instead get to go back to the 50% mark on stamina bar (50% of their idle wait time that is). I think this is something that we should do because it can be really annoying when you select a fire skill and it ends up being used on an enemy with heavy fire resistance. Or you accidentally attack an enemy that is set to counter-attack every time it gets hit (believe me, I've been victim to both of these scenarios in RPGs of the past). If you all agree, I can put it on my feature list. It shouldn't be difficult to add at all.

[Roots]

Additions
- Battle dialogue
- Ability for actors to "stun" or "knock back" one another on the status bar
- Battle retry feature

Modifications
- Better animation flow
- Cleaner victory sequence

Battle retries, the victory sequence, and the "stun" ability have all been implemented. The "knock back" stamina feature remains to be done, but it will be pretty simple to do and I just have to implement a single function that is currently blank in the BattleTimer code to do that.


I've put my work on the battle code on hold lately as I've been busy working on other things. With the exception of the battle dialogue feature, all the work remaining on battle code are either bug fixes or cosmetic in nature (improving animations, layouts, and transitions). I consider the major work required done for now. Its certainly good enough for our first pre-release of the prologue (ie the "unstable" release).

[rujasu]

Also one final design note. If you select to use skill A on target X, but target X dies or otherwise becomes "untargetable" during the warmup time to execute A, the code automatically selects another random target for the execution of skill A. Instead, I was wondering if we wanted to support an "interruption" pop-up when A is ready to execute and allow the player to select a new target manually, or give them the option to cancel using the skill and instead get to go back to the 50% mark on stamina bar (50% of their idle wait time that is). I think this is something that we should do because it can be really annoying when you select a fire skill and it ends up being used on an enemy with heavy fire resistance. Or you accidentally attack an enemy that is set to counter-attack every time it gets hit (believe me, I've been victim to both of these scenarios in RPGs of the past). If you all agree, I can put it on my feature list. It shouldn't be difficult to add at all.

Forgot to comment; I say to this one. I think it should stay random or be cancelled altogether. I don't want us throwing popups at the user whenever this happens, that slows down the pace and could be confusing or distracting.

[gorzuate]

Also one final design note. If you select to use skill A on target X, but target X dies or otherwise becomes "untargetable" during the warmup time to execute A, the code automatically selects another random target for the execution of skill A. Instead, I was wondering if we wanted to support an "interruption" pop-up when A is ready to execute and allow the player to select a new target manually, or give them the option to cancel using the skill and instead get to go back to the 50% mark on stamina bar (50% of their idle wait time that is). I think this is something that we should do because it can be really annoying when you select a fire skill and it ends up being used on an enemy with heavy fire resistance. Or you accidentally attack an enemy that is set to counter-attack every time it gets hit (believe me, I've been victim to both of these scenarios in RPGs of the past). If you all agree, I can put it on my feature list. It shouldn't be difficult to add at all.

Forgot to comment; I say to this one. I think it should stay random or be cancelled altogether. I don't want us throwing popups at the user whenever this happens, that slows down the pace and could be confusing or distracting.

I kind of liked the idea when Roots first mentioned it. ...Yeah, nothing's changed since then.

[rujasu]

If you want, cancel the pending action and put the character's stamina at 80% so they can choose a new action. No special popups, though, that's going to be confusing and awkward. Either let them choose a new action or make them stick with the old one. One or the other, not both.

[Roots]

Yeah I was a little concerned about the re-select target popup as well. It wouldn't have the same contents as the normal action window and I could definitely see that confusing to the player. I just always hated in other RPGs where I'd select a target to attack, it would die before I attacked, and then the character would target a random living enemy, sometimes which had a special property which made me *not* want to attack it (such as: counter-attack or suicide explosion or something).


I think canceling the action and setting the stamina back to 80% is a good compromise. The only drawback to that is it will kind of suck if the player chose an action with a long warmup time, but I don't mean suck in terms of game design. I mean suck in terms of "oh crap" from the player. Its probably a good thing to have, because the player will pay more attention to their target. Maybe 50% would be a better "penalty" to apply. Definitely not 0% though, because that would just be aggravating.

[Roots]

I'm back to working on the battle code again and there are some changes I would like to make to the way the player selects actions and the information that is presented to them.

Add sounds to the menu
When the player inputs a key command, we should play an appropriate sound. For example: http://www.youtube.com/watch?v=NVYjVrEgCkA

Although I think I'd like to have different sounds for cursor movement, selection, back/cancel, and invalid command.


Attack Point-type targets require another level of confirmation
Right now if you select an attack point type skill to use, when you select the target you select both the actor (using up/down arrows) and the target (using left/right arrows) all in one screen. I want to change this so that first you select the actor, hit confirm, then you select the point on the target, and hit confirm again. The reason for this is that its a little more intuitive (I bet many people didn't even know you could select a point) and ties in with the suggestion below

List all the enemy/character actors in the target selection window
I want to put in an option box that shows the list of enemies (e.g., "Spider", "Snake", "Bat"). This will make it much easier for the player to select a target because it will be perfectly clear how to get to their desired target with the up/down keys. Currently its kind of a "guess" because enemy actors aren't sorted according to how they are displayed on the screen. This would also be done to the attack point selection window, where all the possible points on the actor would be listed and could be selected from.

* I realize that the window has a limited size and we could only fit 4-5 enemies in there. But no worries! Thanks to the magic of OptionBox, we can have the option box contain as many enemies as we want it to, and scroll arrows will appear if there are more enemies to select from than are currently displayed.

Remove HP/SP information on target from target selection window
Right now when you have the cursor over the target to select, it tells you the target's name, its current/max HP, and its current/max SP. If we implement the lists, there will be no room for this (although maybe hitting the "menu" key could toggle this information into view if we really want it). Plus, I don't feel that this is information that we should be giving the player in the first place. For character targets, they already have the HP/SP bars to give them this information. For enemy targets, why should they know this information anyway? They already have the enemy damage frames to give them a rough idea of the state of the enemy anyway.

In the target selection window, show target status effects alongside its name
When we display a list of enemies (or characters) to select from, on the right we can display any status icons that are currently affecting the target. This way the player can factor that information into their decision, making sure to not paralyze an enemy that's already paralyzed, for example.

Replace the "Attack" icon with the icon of the weapon that the character currently has equipped
Will make it a little easier to distinguish which character's turn it is. My only issue is that I sort of want to do something similar for defense and support skills (maybe have a special icon for defense/support abilities on a per-character basis?). Items can use the same icon though for all characters. Don't really see a need to change that one.


I may come up with more ideas, but I think this should be a good start. I'll wait for approval before beginning any work on these (even though I'm itching to do so ). I might go ahead and implement the sounds though since I don't see many people objecting to that, plus its pretty simple to add in there provided I have appropriate sounds.

[gorzuate]

It's all fine by me.

[rujasu]

<Roots> rujasu, what did you think about this: http://www.allacrost.org/forum/viewtopi ... 217#p31217 Any objections?
<rujasu> I don't like the idea of sounds for cursor movement. Confirm/cancel yes, but definite no on movement.
<rujasu> It's just something I find really annoying.
<rujasu> For target selection, I guess you can add another step, but if you're going to do that I'd have a box pop up in the bottom corner with a blown-up shot of the enemy that makes the target selection more obvious.
<rujasu> Also some enemies like slime shouldn't have multiple targets (though there should probably still be a confirm step if you're going to do that)
<rujasu> Agreed on not showing enemy HP/SP
<rujasu> (though I think we should have a way to keep that in debug mode)
<rujasu> and I'd lean toward no on having an OptionBox with the names of actors to choose from
<-- barra_home (barra@g225232078.adsl.alicedsl.de) has quit (Read error: Connection reset by peer)
<-- Bertram (~yohann@ADijon-259-1-141-127.w90-39.abo.wanadoo.fr) has quit (Remote host closed the connection)
<Roots> might want to write that in the forum post :/
<rujasu> Well, I will, but what are your thoughts?
--> gorzuate (~philip@pool-71-106-224-110.lsanca.dsl-w.verizon.net) has joined #allacrost
*** Mode #allacrost +o gorzuate by ChanServ
<Roots> The cursor movement sound I'm 50/50 on
<Roots> If its something real subtle and unannoying then I think I'd prefer it. I actually tried using the "bump.wav" sound, but it was too quiet over the music and I couldn't hear it at all
<Roots> For the point selection, I was going to put the name of the selected actor at the top of the box. A blown up shot of the enemy is possible too, but that's a bit more difficult to do
<Roots> Slime doesn't have multiple points as currently defined in the game, but it does have a single point (with no stat changes) because the code requires at least one point. Otherwise, we'd have to make some higher level changes to the code to allow for actors with no points
<Roots> Don't know if we should still allow point target-type skills to be used on enemies with only one point or not though
<rujasu> well, any sound would need to be subtler than "confirm.wav" IMO
<Roots> If the option box has no names of actors to choose from, its going to be pretty empty in there.
<Roots> I agree. I don't even like that sound that much to begin with
<Roots> I'd prefer our menu sounds are more metallic-like
<rujasu> for point selection, a blown-up shot might be a bit tricky but there needs to be something to make it very obvious that there is a target-selection step
<rujasu> A single point for slime is fine, couldn't remember how we were doing that.
<rujasu> and hello gorzuate
<Roots> the slime used to have 2 points in the demo, but it just made no sense so I changed it to a single point about a month ago

[Roots]

I have another thing I want to add to the battle command menu.

Target type indicator images in the skill/item selection lists
Right now when you scroll through the list of skills or items that you can use, you are given two pieces of information:
- For skills: Skill name + SP cost
- For items: Item name + Number in inventory

I'd like to add a third column to these tables in the middle with the heading "Type", short for "Target Type". We don't have space to type the full name of all the different types of targets (e.g. "All Allies" or "Enemy - Attack Point"). Instead, I want to create a new set of small icon images to represent the various types of targets. The icons would be 25x25 pixels, the same size as elemental/status icons. The reason I want this is that even with the limited number of skills we have in the game right now, I'm already forgetting which skills hit attack points and which ones hit actors. We have plenty of space to add this and I think it will be a nice piece of information that the players will welcome.


Like? Dislike?


--- EDIT ---

Threw together a quick draft of what these target type indicator icons could look like:



Green border = Self
Blue border = Ally
Red border = Enemy
White bullseye in top right corner = Attack point
Multiple actors in icon = party

And that covers all 8 types of targets.

[rujasu]

I dunno. From the party menu, it makes sense. In battle though, I've never seen skills/abilities tell me the target type right from the menu, instead you just click and see what ally/enemy/area the cursor points at. Or you press the help/info button, which I believe we now have implemented. I mean, it's not like it would be useless to have it there, but putting an icon like that into the menu might make it too busy. Anyone else have thoughts on this? It doesn't have to be just Roots and I arguing over everything.

[gorzuate]

Anyone else have thoughts on this? It doesn't have to be just Roots and I arguing over everything.

It's kinda hard to envision all these changes Roots is proposing without some mock-ups Half the time I read these design change posts I just get confused and promptly go off to do other things

[Roots]

Yeah, I've been focusing more on doing real work lately than spending time making mockups. Mockups work great for big changes, but these are a bunch of small ones that are not difficult to get running in the code, so I'd rather implement it, see how it looks, and if we don't like it we can strip it back out. Creating nice looking mockups is actually quite a bit of work.

I dunno. From the party menu, it makes sense. In battle though, I've never seen skills/abilities tell me the target type right from the menu, instead you just click and see what ally/enemy/area the cursor points at. Or you press the help/info button, which I believe we now have implemented. I mean, it's not like it would be useless to have it there, but putting an icon like that into the menu might make it too busy.

Yeah, the icons would definitely be more useful in the party menu than the battle menu. And yes, I realize that you can find out what target type a skill/item is just by trying to execute it, but that makes it cumbersome if you want to examine a large number of available skills. But since we agree that the icons would be useful in at least one context, I'll go ahead and commit the target type icons that I created to SVN. I don't think that the addition of these icons will make the battle command menu look too busy, but I don't know either. I think the best thing to do would be to actually implement it and see. If it looks bad, I'll take it back out.