Dungeon Meta

[Roots]

Just FYI it seems that the SP actors recover each turn pays no heed to their SP-fatigue.

It should. If it's not, it's likely because the max SP values and current SP are too low that the regeneration formula don't change the result very much. This was one of the two things I forgot to list in my changes post earlier:

1) The amount of SP regenerated per turn is equal to 10% * (max SP - SP fatigue). We could possibly change this to 10% * max SP (ie, don't factor in SP fatigue as part of the regeneration formula), but I decided on the spot that I'd rather factor in SP to the regeneration equation. It's another way to make sure the player knows that accumulated SP fatigue is not something to be ignored.

2) The cooldown period for skills and abilities has been completely removed from the game. There is still the warmup period, however, and this will most certainly remain a feature of skills.

[gorogorosama]

First balancing pass done
https://bitbucket.org/gorogorosama/allacrost_goro

We'll definitely go through and adjust everything, but at this point it is hopefully fun, and the battles put you into some interesting decisions.

It's the first level, so it's not life or death

[Roots]

Awesome, thanks for getting this done so quickly. Send in a pull request and I'll integrate it into the central repository for others to try out.

[Atypikal_Arkitect]

I think the idea of applying fatigue to SP as well seems fine to me. Easier to understand with the player needing to consider to manage fatigue.

I'm interested in the implications (particularly at higher levels of play) of removing any wear and tear associated with lower cost spells and damage. Testing will reveal more on the matter

[Roots]

Yeah, I think we're going to have fun with this fatigue feature. The hardest part is still ahead of us though, which is balancing the game so fatigue is neither too punishing nor has too little of an impact. I'm looking really forward to seeing where we go with this concept.


I want to move the meta discussion to bring attention to another feature of our combat. It's already partly implemented, and you may have noticed it. When you strike an enemy, if you look at the stamina bar their icon stalls for a very brief moment. This design was inspired by Grandia II, which had a really excellent battle system. This game had an action bar very similar to ours, and actions had a warm-up period. There were certain skills that could be used to "cancel" an enemy's action when it was in the warm-up period. You had to time this carefully, because you select the action, then you have to wait your warm-up period, and then (you hope) that the enemy is in their warm-up phase and you can cancel their action before they execute it.

This is best seen visually. Have a look at this fight from Grandia II.



(Skip to 2:35 in the video to see the "cancel" action take place)


Using a skill with this "cancel" ability was the only way to do that (and most characters had at least one skill that could do a cancel, IIRC). This works really well when: 1) you can make it apparent that an enemy is "charging up" for a big attack, 2) the warm up time for big attacks is significantly longer than their normal actions, 3) the warm up period for the "cancel" skill is pretty short (because you're not going to see when an enemy is charging up until they are already in the warm up state, so you have to act quickly).


At the moment, we don't have the "cancel" feature implemented. We do have the very short "stun" from being hit implemented. If we do go ahead with this feature, I don't think our next release will have a skill with the cancel ability (too early in the game to be introducing that mechanic when there's already so much). How do you guys feel about this one?

[Djinn_in_Tonic]

This is best seen visually. Have a look at this fight from Grandia II.

Using a skill with this "cancel" ability was the only way to do that (and most characters had at least one skill that could do a cancel, IIRC). This works really well when: 1) you can make it apparent that an enemy is "charging up" for a big attack, 2) the warm up time for big attacks is significantly longer than their normal actions, 3) the warm up period for the "cancel" skill is pretty short (because you're not going to see when an enemy is charging up until they are already in the warm up state, so you have to act quickly).

While I quite like the feature suggested, I'll point out an important difference between their ability bar and ours: theirs is divided into visual "ticks," effectively. I.e. there is a point after which you have an easy visual way to tell how long PRECISELY it will be before a character acts, and how long it will be before their ability begins warming up.

We'd definitely need to add that if this were to be the case. It doesn't have to be turn-based, but we'd need a way to let you know how long an ability will warm up, and how quickly you'll be acting compared to your opponent.

That Said: I do think this would play right into the strategic and tactical battle system we're aiming to build. We might want to make some canceling moves instantly warm-up though: that might gives us some nice easy introduction to the mechanic.

[Roots]

That is an excellent point about the ticks, and one that is thankfully easy to change. Perhaps we could also consider adding a second counter over an actor's portrait once they reach the warmup state? (ie an action with 3 second warmup would count down 3...2...1... as it gets closer to the end of the warmup period). I don't disagree with the idea to make skills that can cancel others have no-warmup either.


I don't think this is a feature we should implement or worry about much right now, however. I merely wanted to put this out there to let you guys know "this has been in our plans for a while" and make sure you agree with the general idea. I don't want players new to our game to be overwhelmed, because our battle system is quite complex and "non-conformist" with battle fatigue, the ability to select multiple points of attack on an enemy, status effect intensities, pre-selecting commands, etc. I think the cancel system is a fairly advanced feature from a player's perspective, and something we can add in a later part of the game.


Speaking of which, let's talk about which features to include/not include in the first dungeon (the cave). Anything in this list would be material covered in that first battle tutorial dialogue that we have. I propose:

INCLUDE

• Battle fatigue/SP regeneration
• Status effect intensities (and the fact that statuses naturally heal over time)
• Pre-selecting commands for characters
• Retry attempts (when player loses a battle)

EXCLUDE

• Multiple attack points (ie, don't have any character skills that target specific points)
• Action cancel feature explained above
• Elemental effects (they're not implemented yet anyway )

I could go either way with pre-selecting commands though, if we feel this is too much to throw the player into right away.

[Djinn_in_Tonic]

• Battle fatigue/SP regeneration
• Status effect intensities (and the fact that statuses naturally heal over time)
• Pre-selecting commands for characters
• Retry attempts (when player loses a battle)

I bolded the ones I agree with. I don't feel pre-selecting commands adds anything to the game though, and it some ways it just increases confusion, since we don't have a way to show queued actions, what those actions are, or which character you're commanding currently. It also plays poorly with our tactical approach where timing matters -- you're likely to reconsider the command prior to it being executed anyway, to see if something like a counter-attack is more appropriate.


Edit: Here's a suggested change to the action bar. As presented it shows the 9-10 seconds before a character can act: we could easily adjust this to show any value. The darker cool-down period is for times over that (allowing us to put in very powerful moves with long cool-downs if we so desired) -- it dynamically adjusts, so a character's progress across it corresponds to their time over 10 seconds. If they're at 11 seconds they'll traverse the black-to-purple area in 1 second, if they're at 14 seconds they'll traverse it in 4 seconds. The warm-up area afterwards is flexible as well, allowing us to have moves with longer or shorter warm-up times -- again, only if we want. Making that bar have a maximum of, say, 4 seconds and jumping people foward to the proper time point might be better for clarity.

[Roots]

I know you're not a fan of the pre-select command feature, and I don't disagree with you that it can be confusing. Let me explain the motivation behind why this feature was added to the game in the first place. But first, I want to clear up something.

we don't have a way to show queued actions, what those actions are, or which character you're commanding currently

None of these claims is is true. Queued actions and what those actions are is shown in the lower right area of the screen when no commands are currently being entered by the player.



This is a screenshot taken two days ago. This screenshot shows that the player has pre-selected a skill for Claudius (which is why the little circle icon is greyed out instead of white). The queued action is the "Sword Slash" skill and is targeting the head of one of the spiders (which one is not apparent, but UI improvements I've suggested elsewhere fix this). The other two characters can have an action pre-selected if the player wishes to do so, or the player can simply wait until the battle pauses and prompts the player for an action. As for which character you are commanding, when the command window is active, the character you are selecting for is highlighted in the lower area (there's a red boundary behind the character's name and HP/SP bars).

There's certainly room for improvement for these visual elements (maybe the selected character name should be bolded/yellow to make it more apparent who is selected). And it is true that you can't see queued actions if the command window is up (and you can't hide the window if one or more characters are at the little green notch on the action bar and waiting for a command).


Motivation
One thing I noticed in the past while playing RPGs similar to Allacrost is there's a lot of time spent in battle "waiting and watching". The player enters commands, then they sit and wait until another character is ready, then they enter commands again, then they wait again, and it repeats. How much time does the player spend watching the battle as opposed to fighting the battle? And does a player really enjoy having the battle pause for a few seconds over and over, especially in the fights against simple enemies that aren't very interesting or challenging. I began referring to this period of watching and waiting as "downtime".

Solution
So to reduce downtime, we allow the player to enter commands for characters as soon as they are finished executing their last action. And we allow the player to change that pre-selected action as well. This results in the battle moving at a faster pace and keeps the player more active and engaged during the battle. And at the same time, this feature is completely optional to use. If a player prefers the standard RPG battle expectation of having a lot of downtime, that option is available. The battle will still stop and wait for a player to issue commands when a character is ready and waiting for an action to be decided for them. The expectation is that the player will forgo pre-selecting commands in battles which are more intense and difficult, or where they are trying to work out timing if they are aiming to cancel an enemy's action.


So that's why that feature exists. I wouldn't mind removing it if we get a lot of negative feedback on it, but since it is (and will remain) optional to use, I would rather leave it in the game for now. I think it's a worthwhile attempt at solving a chronic problem of RPG battles.

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

So with your action bar changes, I'm assuming that in the idle state where the notches are, every actor moves at the same speed? And therefore when an actor finishes their last action and resets to the idle state, their initial position will be determined based on their agility (which determines the amount of time the actor spends in the idle state)? My major concern is the warm-up and "extra idle" space, because there the icons would move at a variable speed, and it might be confusing to the player to see icons moving the same speed on one part of the bar and not the other parts.

I need to think about this some more, but I think I like it.

[Djinn_in_Tonic]

None of these claims is is true. Queued actions and what those actions are is shown in the lower right area of the screen when no commands are currently being entered by the player.

Fair enough: I guess I just found them to be overly subtle, and wasn't always 100% sure which name matched up to which character. My bad.

Motivation
One thing I noticed in the past while playing RPGs similar to Allacrost is there's a lot of time spent in battle "waiting and watching". The player enters commands, then they sit and wait until another character is ready, then they enter commands again, then they wait again, and it repeats. How much time does the player spend watching the battle as opposed to fighting the battle? And does a player really enjoy having the battle pause for a few seconds over and over, especially in the fights against simple enemies that aren't very interesting or challenging. I began referring to this period of watching and waiting as "downtime".

Completely understandable...I guess I just don't see any gameplay benefit to being able to queue these actions up ahead of time if we want players making strategic decisions based on the state of the battle at the time they can act. Sure, it gives you more buttons to press...but you're always going to have to (optimally) reconsider the state of the battle anyway, so it feels like a false choice. It's also "optional," but, as someone who didn't WANT that option, I kept accidentally opening it during gameplay.

So with your action bar changes, I'm assuming that in the idle state where the notches are, every actor moves at the same speed? And therefore when an actor finishes their last action and resets to the idle state, their initial position will be determined based on their agility (which determines the amount of time the actor spends in the idle state)? My major concern is the warm-up and "extra idle" space, because there the icons would move at a variable speed, and it might be confusing to the player to see icons moving the same speed on one part of the bar and not the other parts.

Exactly. I think the notched areas make it very clear which part of the bar is consistent though: you could even add faint numbers to that section to increase clarity.

I need to think about this some more, but I think I like it.

It may definitely have a few issues, but I think it's going to be a good way to present timing while allowing large variables, which is crucial if we want a strategic game with counter-actions possible.

[Roots]

Fair enough: I guess I just found them to be overly subtle, and wasn't always 100% sure which name matched up to which character. My bad.

No worries. The fact that you didn't notice them is important. I certainly think our UI needs to be improved to make this information more obvious.

Completely understandable...I guess I just don't see any gameplay benefit to being able to queue these actions up ahead of time if we want players making strategic decisions based on the state of the battle at the time they can act. Sure, it gives you more buttons to press...but you're always going to have to (optimally) reconsider the state of the battle anyway, so it feels like a false choice. It's also "optional," but, as someone who didn't WANT that option, I kept accidentally opening it during gameplay.

It's not so much of a gameplay benefit as meeting our design goal of "removing tediousness and meaningless aspects". Yes, strategy is much much more important than this. But battles won't be 100% strategic all the time. Sometimes you just have a single weakened enemy left that you want to finish off and move forward. I believe you can press the cancel key to exit the command menu if you accidentally open it (although you can't exit out of it when a character needs a command and the battle is paused until you enter one). But this isn't apparent or explained anywhere currently. We could certainly consider adding an option that the player can select to disable the feature completely to prevent accidentally using it.

Exactly. I think the notched areas make it very clear which part of the bar is consistent though: you could even add faint numbers to that section to increase clarity.

It may definitely have a few issues, but I think it's going to be a good way to present timing while allowing large variables, which is crucial if we want a strategic game with counter-actions possible.

I don't think numbers are necessary, although maybe a more distinct/larger notch at the five second mark would be nice since it's a pretty long bar. Yeah, we can give this a try. It will require some code changes of course, so it's not trivial to implement.

[Djinn_in_Tonic]

I don't think numbers are necessary, although maybe a more distinct/larger notch at the five second mark would be nice since it's a pretty long bar. Yeah, we can give this a try. It will require some code changes of course, so it's not trivial to implement.

Yeah...and that lack of triviality is unfortunate. I think it's worth it though: the clarity of the warm-up / warm-down period as well as opening the door for counter-attacks and strategic defense moves is a huge benefit. It can also give us the ability to use short-duration effects which might otherwise be difficult to convey.

[Atypikal_Arkitect]

Sure, it gives you more buttons to press...but you're always going to have to (optimally) reconsider the state of the battle anyway, so it feels like a false choice. It's also "optional," but, as someone who didn't WANT that option, I kept accidentally opening it during gameplay.

I agree with the reasoning for having the option to pre-select actions. I'd add on the matter that if we get enough negative feedback we could include an option somewhere in the menu's to disable it. Its in the players hands then.

[Djinn_in_Tonic]

I agree with the reasoning for having the option to pre-select actions. I'd add on the matter that if we get enough negative feedback we could include an option somewhere in the menu's to disable it. Its in the players hands then.

If we keep this in, I'd like to see some benefit to using it then...something to make it more than a way to occupy yourself ahead of time. This was my single biggest gripe with "feature bloat" in the game, since it isn't tied to any real gameplay. Maybe I'm just being picky, but I absolutely hated this feature.

[Roots]

I suppose we could add some sort of benefit to using it, like maybe pre-selecting your actions reduces the action's warm up time slightly or something. But honestly I like it just the way it is. Not a feature, not a strategy, just a way to keep the battle moving along at a nice pace instead of having it pause to wait for you to tell it what you already knew you wanted your character to do. We can do some playtesting in the next release perhaps and gather feedback on it.

[Djinn_in_Tonic]

Not a feature, not a strategy, just a way to keep the battle moving along at a nice pace instead of having it pause to wait for you to tell it what you already knew you wanted your character to do. We can do some playtesting in the next release perhaps and gather feedback on it.

Fair enough. I'll let that mechanic go until we get some playtest feedback on it.

[Roots]

Random Shower Thought


You've probably seen that enemy sprites change as they receive damage. The way we do this is to figure out the enemy's current HP% and use that to take two of these four frames and blend them together. From left to right, the frames are supposed to represent the enemy at: 100% HP, 75% HP, 50% HP, 25% HP. So for example if an enemy has 60% HP, you'd blend the 75% and 50% images together. This creates a nice, seamless damage progression of the sprite, instead of instantly switching the frames (which would be jarring to look at). The problem here is that it's too seamless, and as a result it's hard to really tell how badly an enemy is hurt. This is a problem, because being able to look at their sprite and estimate an enemy's damage is exactly what this feature is supposed to do (and is much nicer than having no idea of their health at all, or having HP bars all over the screen for enemies).

So here's the idea I thought of. Most of the time, we just display one of the enemy's four damage frames and don't blend it with anything else. When an enemy receives damage that crosses those 25% HP boundary, we detect it and do a "quick transition" of our current blending code and progress the enemy from one frame to the next gradually over a small period (probably one second). This way we avoid the jarring transition and it is clear to the player when the enemy reaches a new damage state. Of course healing an enemy would cause us to go in reverse if we heal past those 25% boundary. Finally when an enemy dies, instead of just making it grayscale and leaving it there on the battle, we can transition it to grayscale from it's final damage frame in the same way, then transition it again to fade away entirely. The only limitation right now is I'm not sure if we have the ability to "fade to grayscale".

Thoughts?

[Djinn_in_Tonic]

Random Shower ThoughtThoughts?

Absolutely. One other problem though: for many of the sprites (like the Skeleton linked above, actually) the "damage" is almost impossible to spot unless you're looking VERY closely. Again: my initial playtest was played without that information that sprites were damaged, and it wasn't until about the 75% damage mark that I started noticing anything. Yes, it was something I then looked for--but it required close attention, and I still sometimes missed it.

Not a dealbreaker, and your suggestion would DEFINITELY help resolve the issue. Just something we may want to keep in the back of our heads if damage levels become important.

[Roots]

Cool. I think I'll work on this change in the next couple of days then. My hope is that this feature is something that is "naturally obvious" to the player and we don't have to spell it out for them in some sort of tutorial or dialogue. And yes, changes between sprite frames can be subtle sometimes. Some enemy damage is more obvious than others. Here's one of the more obvious types:



EDIT: I got this feature implemented last night but am currently working on debugging it. I expect to have it available in the central repository this weekend. One of the tricky issues was what to do if another transition occurs when one is already active. For example: Enemy goes from 80% health to 60% health due to damage, and then during this transition period a second attack reduces it from 60% damage to 0%. The way I handled this is after each transition ends, the code re-checks if a new transition should start and starts the next transition if so. We never prematurely abort a transition. In the example, we would go from the +75% health frame to the +50% frame, then the +50% frame to the +0% grayscale frame.

Each transition period lasts the same amount of time (currently 1 second, which may be changed if we find it too long). The only exception is the death transition, which is a two-part transition where each part is the same length as the standard transition. In the first part the sprite fades to grayscale. in the second part, the grayscale fades away completely (becomes transparent). Let me know if you have any concerns about this implementation.

[Roots]

Alright, the new enemy sprite transition code is live. And it looks incredibly better compared to the old way we handled enemy sprite damage and enemy deaths. I'm kind of wondering what the hell took me so long to realize how much better this system would be (the old enemy sprite drawing code has been in there since probably 2006 or so...crazy). Anyway, it's pretty clear that this new draw code is superior to the first, so I don't think there will be anything more to worry about there for now. Again, the transitions take 1 second each (except for death transition, which takes 2 seconds), and we can easily adjust this timing by changing a single constant if we feel it is too short or too long.