Page 1 of 1

Minor design modifications and renamings for 1.0.0 release

Posted: Tue Aug 16, 2016 7:25 am
by Roots
There are a number of different small changes I feel we should make before the next official release related. These are things that are easy to change now, but will be much more difficult to change in future releases. I'll add to this list as I think of or discover aspects that I think fit this list.

1) Remove evade stat and combine it with agility stat
Evade has always been a weird stat, because its the only one that is a floating point (percentage) and not an integer like the rest. It's just always been an oddball and no one has ever really liked having it. I think instead, we should look to the agility stat to also calculate evasion, since speed and evasion are related. I'm not sure exactly what formula to use there, but it's something we can think about.

2) Rename health points and skill points
HP/SP has been around since the beginning and has mostly been fine. But now we have HP fatigue and SP fatigue, which is kind of a mouthful. It also becomes confusing when you talk about attack points (areas on enemies you can target), because the "points" mean completely different things. So, I think we should change hit points to simply"health"/"health fatigue". For skill though, the naming is a bit harder. I'm thinking of calling that stat either stamina/stamina fatigue or ability/ability fatigue.

3) Battle stamina bar renamed to action bar
We've actually been referring to this as the action bar for a long time, even though technically its named the stamina bar. With the possible renaming of skill points as stamina, there's all the more reason to rename it. It won't be very much work to do it either.

4) Map stamina renamed to endurance
Map mode also uses the word stamina to describe the run bar. To avoid confusion of having multiple uses of this word throughout the game, I think endurance is a better alternative.

Re: Minor design modifications and renamings for 1.0.0 release

Posted: Fri Oct 20, 2017 3:31 am
by Roots
Somewhat off-topic, but I wanted a place to write out some thoughts I've had for a while and this thread seemed appropriate. I'm worried about feature creep. That is, that we have too many substantial features that they are making the gameplay needlessly complex. I've had some external discussions about our feature set with other game designers who shared their concern about this, which really got me thinking. Particularly I'm thinking about our battle mechanics here.

Here's a list of all the "unique" aspects of our battle system compared to a very standard/average RPG:

  • There is no generic "attack" command. Physical and ethereal skills consume SP, except for maybe one innate skill
  • SP slowly regenerates throughout battle automatically
  • Status effects are automatically removed at the end of a battle
  • Status effects have an intensity property. For example, a poison status can drain either 2% HP up to 15% HP
  • HP/SP are restored automatically when the battle ends (avoids the need for the player to go to a menu and heal their characters)
  • Max HP/SP reduce as you take damage and use abilities, and can only be restored at an inn (requires abilities)
  • Character growth is done gradually (you gain a few stat points as you gain experience, then a big bonus once you reach the next level)
  • Enemies have multiple "targets" on their bodies that may be selected for different effects. Examples: targeting the head deals more damage, but has a higher miss rate. Targeting the legs reduces the foe's speed

That's quite a lot. The one that I'm considering to cut is the multiple targets feature. This one has been around since pretty much day 1. The idea was that a player has more ability to influence the strategy they take. (Go for the head to try and inflict critical damage, or go for the legs to slow down a fast opponent). Seemed okay in theory. In practice, it's messier than that. Here are some reasons why:

1) Battles are usually short enough that selecting a target doesn't make much, if any, difference in the outcome
2) It was yet another "click" that the player had to take in selecting an action to take (players potentially had to select: action category, type, target (whole enemy), sub-target (enemy body part))
3) With some skills that require selecting a sub-target and others that only required selecting the ally or enemy itself. This was confusion
4) It wasn't easily apparent to players what attacking a specific sub-target would do and why they might choose one over the other

Basically, I just don't think the system is working out as we hoped it would, and I think it makes sense to cut it. In fact, I'd like to cut it now that I typed all that out. I think there are some inspirations we can draw from it though and keep the spirit of this feature. Here are some examples of what I mean:

A) We keep the sub-target feature, but hide it from the player. When a the player selects a target, a random body part on that target gets chosen to be attacked, which may lead to more damage, a status effect, etc.

B) Instead, we assign skills themselves the ability to have an impact similar to what we would see for the status effect. For example: "Blade Swipe: A swift swipe to an enemy's extremities that has a chance of reducing their speed".

I actually really like (B). This allows for a couple of design controls. The player has an easy understanding of what effects a skill could provide. Also by controlling which characters learn what skills, we can customize them different ways (player X is good at reducing speed or defense, while Y has skills that deal a lot of damage and could inflict confusion or poison).

I'll end my ramblings here. This is really the direction I think we should move, however. It brings better focus and clarity in player decisions, while reducing confusion and extra commands to select an action.

Re: Minor design modifications and renamings for 1.0.0 release

Posted: Sat Oct 21, 2017 1:58 am
by Roots
Shared the above post in the chat channel and Jetryl agreed with this direction. That was really all the confirmation that I needed, so I went ahead and got to work on it today. I've successfully pulled out the feature completely and I'll be merging that change in as soon as I do a little more testing. Removing this simplified a lot of our code and design parameters by quite a lot. :approve:

Jetryl also agreed that approach B was the way to go. Adding this in shouldn't be too difficult to do, but I will do that work separately. Might even get it done this weekend. The harder part will be figuring out how to convey to the player in menus, etc. what status effects a skill could induce.


Feature removal is now completed. I think this is also going to make balancing easier, although some balance re-adjustment work is definitely needed after this. Also "approach B" looks like it's already in use and functional for at least one skill. I forgot we have this ability. See the skill script code below. No real major work required here, although it might be nice to have a common function that code can call that says "X% of the time, apply this status effect to the target". So I could say this skill has a 10% chance of applying a poison effect with a weak intensity pretty easily.

Code: Select all

skills[3] = {
   name = hoa_system.Translate("Stun Strike"),
   description = hoa_system.Translate("A blow which targets vital areas and temporarily stun its target."),
   sp_required = 6,
   warmup_time = 2000,
   target_type = hoa_global.GameGlobal.GLOBAL_TARGET_FOE,

   BattleExecute = function(user, target)
      target_actor = target:GetActor();

      if (hoa_battle.CalculateStandardEvasionAdder(target, 0) == false) then
         target_actor:RegisterDamage(hoa_battle.CalculatePhysicalDamageMultiplier(user, target, 0.75));
         -- TODO: Calculate chance for paralysis effect and activate it
         target_actor:RegisterStatusChange(hoa_global.GameGlobal.GLOBAL_STATUS_PARALYSIS, hoa_global.GameGlobal.GLOBAL_INTENSITY_POS_LESSER);