0.1.0 Release Design Considerations

A discussion area for general design issues that staff would like detailed feedback on.

Moderator: Staff

User avatar
Roots
Dictator
Posts: 8643
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

0.1.0 Release Design Considerations

Postby Roots » Fri Dec 14, 2012 7:38 am

As I've been helping out with Valyria Tear's first release, I've gained some wisdom into things that I think we should consider for the design of the 0.1.0 release. I'll get right into it.


Keep the opening of the game as simple as possible
There's a lot of features in this game, and throwing the player out there when they don't have an understanding of them all can overwhelm them. In general, we should limit early gameplay to only the essential mechanics of the game. Then as the game goes on, we'll gradually introduce the player to concepts like attack points, status effects, elementals, shards, etc.

Initial skills should not target attack points
That said, I think that the first couple of skills available to Claudius should only target actors, not attack points. Don't confuse the player by allowing them to target various points and not understand what they mean.

Skill point regeneration
We have no way currently to regenerate skill points. This is very bad, because it encourages the player to only use skills that consume SP for critical fights (bosses) and to otherwise bash/grind the "fight" command (the attack skill that takes 0SP). I propose that we add a feature to the game where any skill that consumes 0SP will regenerate a small amount of SP if it is used successfully. I'm thinking a minimum of 1SP and a maximum of 5% of the character's max SP should be the amount generated. Of course there will be other ways to regenerate SP too, but for this release I think the primary means should be via this method, or through sleeping at an inn.

Reduce the initial party size from 4 to 3
I'm wondering if we should reduce the initial party by one character, just to reduce the amount of things that the player needs to keep track of. If you recall, FFVI had an initial party size of 3 as well, even though they could have fit in another character.

Make Claudius' allies non-controllable by the player
This is debatable. If Claudius' initial companions are controlled by the AI, then it's less information that the player needs to be concerned about, as they don't need to understand all of the more advanced skills that these higher level characters have. By only controlling a single character, the player can feel more comfortable. It also makes sense from a plot standpoint, since Claudius is the junior and not the party leader, he can't issue commands to the other characters. This will require some amount of work in the code to support this feature.

Also the player should not be allowed to change/remove the equipment of his companions. Otherwise the player could exploit this by removing the better equipment from the other characters and putting it on Claudius for later, or unequipping everything so that they can keep it in their inventory and sell it at a later time.

Make the cave map nearly impossible to lose
If the characters are AI-controlled, I think they should be able to heal whenever they detect that Claudius is low on HP. They take care of him, being his seniors and all. Before the first boss fight, I also think that a scripted event should have another knight restore the HP and SP of the entire party.

Eliminate enemy re-spawns from the cave and city siege maps
I'm wondering if for these first two hostile maps, we should let enemies who are defeated stay dead and not respawn. It would prevent the player from feeling that they have to "grind" early in the game and also make the maps a little easier to get through. My only concern is that the player might expect that the game behaves this way (no respawns) and would be perplexed when they come to a later map where enemies respawn infinitely.

Allow temporary invulnerability after winning a battle
One of the problems in Valyria Tear is that you could get cornered by multiple enemies on a map, and then you have to defeat them all in order to escape and keep moving. This could require 2-4 battles back to back, depending on the map. The way we solved this in VT was to erase all enemy sprites from the map after a battle ends, then they would begin respawning back in after 5 seconds. This got the job done, but I'd prefer we do things slightly different. I'd like to see all of the enemy sprites "frozen in place" for a short time and the player can manuever around them before they can move again. I think this is what Lufia 2 did actually.
Image
User avatar
Roots
Dictator
Posts: 8643
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Design Considerations

Postby Roots » Mon Dec 24, 2012 6:31 am

Portray Claudius a Normal Knight
I think it might be nice if Claudius does not initially have his own unique look. In other words, he has the same sprite animations as all of the other knights in the party. That way he does not appear "special" to the player in the beginning of the game in any way. As the first chain of events unfold and he distinguishes himself from his actions, we can then use his traditional sprite. I'm thinking either the next scene after the demon attack has ended, or after he receives his orders from the king.
Image
User avatar
Roots
Dictator
Posts: 8643
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Design Considerations

Postby Roots » Tue Dec 25, 2012 7:03 pm

Only Support One Battle Mode Type
This is more of an overall design consideration rather than something specific for this release. We currently have support for "wait" and "active" types of battles, with the intention that the player can choose which type of battle they like. I think we should just stick with supporting one mode. It's less work to support one mode, especially in terms of the balancing work involved. This is such a minor benefit for the players I can't really justify the amount of work it would take to make sure both modes play well.

Not to mention, our current battle mode brings the best of both active and wait modes. So I think we should just leave battles the way they are now, and remove any code in there that was meant to support both wait and active types of battles. If no one disagrees with this, at some point in the next week or so I will begin removing support for multiple battle types and remove the current support for active battles.
Image
rujasu
Developer
Posts: 757
Joined: Sun Feb 25, 2007 5:40 am
Location: Maryland, USA

Re: 0.1.0 Release Design Considerations

Postby rujasu » Wed Dec 26, 2012 2:18 am

Roots wrote:Portray Claudius a Normal Knight
I think it might be nice if Claudius does not initially have his own unique look. In other words, he has the same sprite animations as all of the other knights in the party. That way he does not appear "special" to the player in the beginning of the game in any way. As the first chain of events unfold and he distinguishes himself from his actions, we can then use his traditional sprite. I'm thinking either the next scene after the demon attack has ended, or after he receives his orders from the king.


I feel like we've had this discussion before.

First off, Claudius must be a unique sprite at all points in the game, because otherwise it isn't clear to you as the player, who you're playing as. This is essential. If we want to make Claudius blend with the other knights more, we can do two things, both of which involve additional art:

1. Make the NPC knight sprites more varied.
2. Make an initial version of the Claudius sprite which is more similar to the other knights.

We can't really do either of these things right now, because we don't have artists. Also, the second is tricky since you'd have to account for two possible versions of Claudius in the game. I'd put this option at very low priority, or better yet as something we won't do. #1 is something we want to do anyway, once we have an artist.

Roots wrote:Only Support One Battle Mode Type
This is more of an overall design consideration rather than something specific for this release. We currently have support for "wait" and "active" types of battles, with the intention that the player can choose which type of battle they like. I think we should just stick with supporting one mode. It's less work to support one mode, especially in terms of the balancing work involved. This is such a minor benefit for the players I can't really justify the amount of work it would take to make sure both modes play well.

Not to mention, our current battle mode brings the best of both active and wait modes. So I think we should just leave battles the way they are now, and remove any code in there that was meant to support both wait and active types of battles. If no one disagrees with this, at some point in the next week or so I will begin removing support for multiple battle types and remove the current support for active battles.


I don't agree, we've already done the legwork here, and it offers more benefit to the player than you're giving it credit for IMO. Besides, it's no work to keep as-is. The balancing thing is a non-issue, you do the balancing for one mode, and then the other mode is naturally just easier/harder than the one you did the balancing for.
User avatar
gorzuate
Developer
Posts: 2575
Joined: Thu Jun 17, 2004 3:03 am
Location: Hermosa Beach, CA
Contact:

Re: 0.1.0 Release Design Considerations

Postby gorzuate » Wed Dec 26, 2012 5:54 pm

I agree with rujasu, on both the battle mode type and Claudius' sprite.
User avatar
Roots
Dictator
Posts: 8643
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Design Considerations

Postby Roots » Wed Dec 26, 2012 7:27 pm

rujasu wrote:I feel like we've had this discussion before.


You're probably right. But it's been so long that I forgot.

rujasu wrote:First off, Claudius must be a unique sprite at all points in the game, because otherwise it isn't clear to you as the player, who you're playing as. This is essential.


This is not true. What if there is a part of the game where the party needs to infiltrate an enemy base, disguised as one of their soldiers? It would look pretty silly if they are running around talking to soldiers, dressed in their usual unique garb. It's easy enough to tell on a map which sprite you control as the map camera centers on the controlled sprite, and obviously any movement that corresponds with the player's input is going to obvious as well.

Although I will admit that if we implement the other feature I suggested where the other knights are AI controlled and the player can only choose commands for Claudius in battle, then it will seem a little weird and the player might not understand why they can only control Claudius. This can easily be cleaned up with a short in-battle dialogue on the first battle explaining this, however.


rujasu wrote:If we want to make Claudius blend with the other knights more, we can do two things, both of which involve additional art:

1. Make the NPC knight sprites more varied.
2. Make an initial version of the Claudius sprite which is more similar to the other knights.

We can't really do either of these things right now, because we don't have artists. Also, the second is tricky since you'd have to account for two possible versions of Claudius in the game. I'd put this option at very low priority, or better yet as something we won't do. #1 is something we want to do anyway, once we have an artist.


I agree. I do think that we will want to have support in the game to change out the character's sprite set for any special situations where we want them to wear certain clothing, be shown wearing bandages, etc. So in terms of the code to do this, I think that's pretty much an absolute requirement. Not something we need to do right now, but hopefully something to be done (and used) for this release.

Making variations of the knights is something that I would very much like us to do. It should be easy too, even for a non artist like myself. I might give it a shot after I'm done with this massive code import.

rujasu wrote:I don't agree, we've already done the legwork here, and it offers more benefit to the player than you're giving it credit for IMO. Besides, it's no work to keep as-is. The balancing thing is a non-issue, you do the balancing for one mode, and then the other mode is naturally just easier/harder than the one you did the balancing for.


Ok, I'll leave it alone for now. In VT there are actually three battle modes (I don't understand what the third is), and each have their own timings of the status bar. So active mode has a slower idle time to give the player more time to react, etc. I'm not suggesting that we do that, just pointing out that in their case, there is some balancing work involved. So yes, the balancing mode is minimal.

I do, however, want to put player-configurable battle modes as a low priority item to implement right now (we'd need to save/load this information, provide an interface somewhere to change it, explain the differences to the player, etc). Battles work fine currently, and there are a lot more important things to focus on right now.
Image
rujasu
Developer
Posts: 757
Joined: Sun Feb 25, 2007 5:40 am
Location: Maryland, USA

Re: 0.1.0 Release Design Considerations

Postby rujasu » Wed Dec 26, 2012 8:55 pm

Roots wrote:This is not true. What if there is a part of the game where the party needs to infiltrate an enemy base, disguised as one of their soldiers? It would look pretty silly if they are running around talking to soldiers, dressed in their usual unique garb. It's easy enough to tell on a map which sprite you control as the map camera centers on the controlled sprite, and obviously any movement that corresponds with the player's input is going to obvious as well.


If you want to disguise the party as the enemy, then you need new art for that, with the soldiers' armor and the player's face. Centering on the player isn't enough. It doesn't work well if there are similar NPC's near the centerpoint, and it doesn't work at all in cutscenes or battle. For example...

Although I will admit that if we implement the other feature I suggested where the other knights are AI controlled and the player can only choose commands for Claudius in battle, then it will seem a little weird and the player might not understand why they can only control Claudius. This can easily be cleaned up with a short in-battle dialogue on the first battle explaining this, however.


:disapprove: That will NOT clean things up. It will look shoddy, it will confuse the player, and no amount of dialogue will elegantly communicate "you're playing as the guy who looks like everyone else but is currently at the bottom of the screen." I cannot emphasize this enough, the player character(s) must be distinct from NPC's. This is fundamental game design as far as I'm concerned and cannot be compromised.

I agree. I do think that we will want to have support in the game to change out the character's sprite set for any special situations where we want them to wear certain clothing, be shown wearing bandages, etc. So in terms of the code to do this, I think that's pretty much an absolute requirement. Not something we need to do right now, but hopefully something to be done (and used) for this release.

Making variations of the knights is something that I would very much like us to do. It should be easy too, even for a non artist like myself. I might give it a shot after I'm done with this massive code import.


That's fine, you can work on supporting that if you want, but I think it falls very far low on the list of priorities, behind making quality maps, developing the skill trees, and creating any needed enemies/items.

I made the one or two variations of the knights we have now, but mainly only for walking animations. The combat animation is considerably harder.

Ok, I'll leave it alone for now. In VT there are actually three battle modes (I don't understand what the third is), and each have their own timings of the status bar. So active mode has a slower idle time to give the player more time to react, etc. I'm not suggesting that we do that, just pointing out that in their case, there is some balancing work involved. So yes, the balancing mode is minimal.

I do, however, want to put player-configurable battle modes as a low priority item to implement right now (we'd need to save/load this information, provide an interface somewhere to change it, explain the differences to the player, etc). Battles work fine currently, and there are a lot more important things to focus on right now.


Agreed, the whole thing is a non-priority for me.
User avatar
Roots
Dictator
Posts: 8643
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Design Considerations

Postby Roots » Fri Jan 11, 2013 2:07 pm

http://www.allacrost.org/wiki/index.php/Roadmap

I added a section to our roadmap listing all of the design proposals under consideration for this release. I thought having such a list would be beneficial for us since ideas may become sprinkled in this thread, or across other threads in the forum. At some point once we are further along with the releases, we can sit down and look over this list and discuss each point and accept/amend/reject it as we see fit.
Image
User avatar
Roots
Dictator
Posts: 8643
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Design Considerations

Postby Roots » Tue Jan 15, 2013 9:00 am

I'm going to go ahead and remove Dester from the game for now. rujasu agreed with me about making the initial party size 3 instead of 4, and Dester never really had much character to him so I feel he's the best one to take out. This leaves us with three initial characters:

- Claudius, the inexperienced rookie
- Mark, the snide and somewhat undisciplined senior to Claudius
- Lukar, the squad leader and a shining example of a proper knight

I'll leave Dester's data in there just in case we want to add him back in, but I want to try playing through with just three members for now. I'm working on the opening scene, cave, and return maps now so that's why I want to reduce the party size now instead of later.
Image
User avatar
Roots
Dictator
Posts: 8643
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Design Considerations

Postby Roots » Sat Mar 07, 2015 11:13 pm

Revisiting this topic as it has become relevant again to the work I'm doing. Here are some things that have been on my mind lately:

Make all "tutorials" cover just the basics
I'm finding myself guilty of adding tons of dialogue and events at the cave map explaining everything (even obvious crap like "use the arrow keys to move"). I'd like to minimize the amount of information we give the player to just the bare essentials and not include the obvious stuff. I want the player to get immersed in the game, not spend 3 minutes reading dialogues explaining everything.

The best solution, IMO, would be either a brief on-screen display showing all the controls, or a message saying press F1 for help that brings up that display. That would require some work to do though, and it's not a high priority right now. So I'm not planning to do that now (but maybe later).

Two initial skills: basic attack (consume SP) and basic defend (restore SP)
Instead of having a single basic attack with a 0SP cost, I think it would be better to have the basic attack consume a small amount of SP (1 or 2) and have a defend skill that reduces damage for a while and restores some amount of SP (4 to 6). This will make the beginning of the game at least somewhat interesting, as you can't just mash the attack button every turn. Maybe we could even allow for the defend skill to be useful in boss battles by using it when the boss is seen ready to execute a big attack.

As for any other forms of SP restoration, I'm still uncertain on how or if we should do that.

Knight's training room
There should be a "tutorial room" in the castle. We'll call it the knight's quarters or something and give the player more information about the game. Here we can explain things like status effects and other facts about battles and general game play.

Save points
We still haven't really addressed the issue of save points at all. When we were first starting out, I didn't want to have save points. But now I'm thinking otherwise. Allowing the player to "save anywhere" makes things really difficult. I think we should go ahead and just add save points, and be smart about where we put them in the game (ie: don't always put one right before a boss).
Image
User avatar
Roots
Dictator
Posts: 8643
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Design Considerations

Postby Roots » Sun Aug 09, 2015 6:18 pm

We have a new designer working for us (gorogorosama), so I thought we'd use this existing thread to talk about some near-term design issues for goro to work on. While map content/scripting is still kind of top priority, it's complicated and not the easiest thing to dive into right away. So goro, I thought we could start you off with working on making our battles more interesting. Let's focus on all the battles found in the cave map (not including the boss battle, which we'll pay special attention to later). Right now there's a number of issues to address:

Main design issue: Battles are too easy and simplistic
We still want early game battles to be easy and simple, but not so mindless that the player can keep selecting the same attack commands repeatedly until the battle is won. We'll need to take a look at a number of different properties to fix this and make early game battles more engaging and entertaining.

Initial Equipment
The stats of the initial equipment of the three characters needs to be examined. I'm thinking that we have too much diversity in the equipment (Claudius has the most basic/weakest set). I think that maybe only the type of sword and torso/helmet armor should differ between the two. I'm also not sure about the stats of our initial equipment.

Initial Skills
Right now our skills consist of four different attack skills (basic attack, slightly stronger attack, an attack with a "stun" effect, and a really strong attack). There's also some defense and self-healing skills I think, but those are never useful or needed. Worst of all, we have no means of regenerating SP (the resource that skills must consume to be used), so the best strategy is pretty much using your basic attack (0SP consumed) skill and saving your big attacks for the boss at the end. It's pretty boring, frankly. Also all these attack skills target attack points, but I think that perhaps only one skill should and the others should target a single enemy (attack points are like specific targets on an opponents body, FYI).

So we need to figure out:
  • How do we regenerate SP? Does it happen naturally in battle? Does it regenerate walking around on the map? Do we create special skills that regenerate SP (eg "Defense" or "Rest" type skills)? Do we restore any (or possibly all) SP once a battle ends?
  • How many skills should we have initially available to each character, and what should they do?
  • How do we design this so that it is easy for the player to figure out a strategy while not making it so mindless that they can execute the same skill repeatedly until the battle is won?

Initial Enemies
The enemies right now are not very well balanced, nor are they very interesting with their skills (I think they all have only a single basic attack). I'm also questioning if we have too many different enemies in the cave and should restrict that number a bit (we have: slimes, snakes, spiders, scorpions, bats, and dune crawlers I believe).

  • What's a good number of enemies to have in this cave?
  • How do we make the enemy stats and skills distinct enough so that the player can "feel" the difference between fighting a slime and fighting a bat, for instance?
  • How can we make it so that certain skills available to the characters are better suited for certain enemies here? (Ex: maybe we give scorpion strong armor, and design a character skill that has a property that halves the defense of an enemy when calculating the damage).

Initial Character Stats
Of course these numbers need to be analyzed as well. Claudius is a new recruit, so he's naturally the weakest character in the initial party. Lukar is the squad leader and should be seen as the strongest. Right now, I'm not sure if we're showing the difference in strengths well enough.



So that's some stuff to think about and get some discussion going here. Changing stat numbers around is easy. Implementing new skills is less so, but still not terribly difficult. I think designing the initial skill sets (for both characters and enemies) should be quite a bit of fun.
Image
User avatar
gorogorosama
Junior Member
Posts: 26
Joined: Sun Aug 09, 2015 4:12 pm
Contact:

Re: 0.1.0 Release Design Considerations

Postby gorogorosama » Sun Aug 09, 2015 9:44 pm

Hey! This is indeed my jam :)

The biggest issue is about the SP, because this will affect the entire game. And the answer all depends on the design philosophy!

Foremost I would decide whether or not SP should refill after each battle, as I noticed health does. Since you are wanting fewer, but more interesting battles, I would definitely recommend refilling the SP. If you don't refill the SP, basically you're going to be having players save all their SP for the boss, which makes every battle along the way incredibly boring.

If the "dungeon-meta" is important to the game (ie fighting through a gauntlet of enemies should be more of a challenge than a single battle, instead of just more time consuming) I would look at other ideas that don't force the player to play so reserved...

- Status ailments that last until the next "rest point"
- Losing stamina based on damage taken during battle, resulting in lower Max HP/SP until the next rest point, etc.

There's a lot of territory to explore here, but I don't think it's necessary for the "Official Release" at the end of the year. The main thing is just to take a decision about restoring SP after the battle.

Who all is involved in making this decision?


Assuming you do restore SP at the end of each battle, then there should definitely be some basic skill (chillax?) that helps to build up SP in the battle. I don't know what the long-term plan is, but this opens the door for a lot of interesting SP-management skills. Gain 2-SP if this skill kills an enemy. Burn 4-SP and give 4-SP to an ally. Incur a defense penalty for the rest of the battle (or until the next save-point?), but refill all your SP.


Okay, so that's the main issue. As for the small stuff...

I put together a quick sheet to help me visualize things:
https://docs.google.com/spreadsheets/d/1qIHUgXxKbuP8yXOXiomRWCML4cD58mEWC9oXlrkdQn4/edit?usp=sharing

Basically all the enemies are super-similar. No one cares how much HP a monster has, it matters how many times I have to hit it (and with who) before it dies. Since our weakest character Claudius deals like 16 damage, a difference of less than 16 HP is negligible. Since Claudius has 62 HP, dealing 12 damage or 14 damage is minuscule.

Basically you need your low-damage high-health monster, your high-health low-damage monster, etc. You need the monster that Claudius can one-shot (Lukar is just waiting his turn on these guys), and the monster you need everyone to take down as soon as possible before he kills you all (though not a lot of these). You need the monster that is so tough to hit that only Mark can manage (since obviously he's the best marksman. haha, MARKsman.)

I will happily go into the lua and do a rough pass that will at least get things feeling more interesting. But first can someone explain to me exactly what all the stats and calculations are? Where exactly do Vigor and Fortitude and Protection come into play?

And of course you shouldn't design your enemies without knowing about the player characters. Could you describe generally what types of skills would be easy-enough to implement? Then I'll go through a brainstorming phase of balances that won't bloat the scope.

Okay, that's probably enough for one thread. Let me know if there is a better place / format to discuss all these things? Also I'm in GMT+2 just FYI, so good night :)
User avatar
Roots
Dictator
Posts: 8643
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Design Considerations

Postby Roots » Sun Aug 09, 2015 10:31 pm

gorogorosama wrote:The biggest issue is about the SP, because this will affect the entire game. And the answer all depends on the design philosophy!

Foremost I would decide whether or not SP should refill after each battle, as I noticed health does. Since you are wanting fewer, but more interesting battles, I would definitely recommend refilling the SP. If you don't refill the SP, basically you're going to be having players save all their SP for the boss, which makes every battle along the way incredibly boring.

If the "dungeon-meta" is important to the game (ie fighting through a gauntlet of enemies should be more of a challenge than a single battle, instead of just more time consuming) I would look at other ideas that don't force the player to play so reserved...


Yes, this is a very important decision. I didn't know that health is automatically restored after each battle to be honest. :heh: I think that might have been added in temporarily and is not intended as a permanent design feature, although we can consider it. I concur with your thoughts about refilling SP at a battle's end. And at the same time, I'm going to play devil's advocate. :devil: If we refill SP at the end of each battle:
  • Players will continuously use only their strongest abilities in easier fights since they don't have to pay any sort of attention to resource conservation
  • There will certainly be skills that restore HP, so restoring SP to max at a battle's end may mean the player will weaken the enemy to the verge of death, then save up enough SP to heal the entire party before delivering the final blow (again, battle-end HP restoration is not meant to be a design feature)
  • Players will have much less of a sense of danger in a dungeon, since they are effectively restored to full after each battle

On the other end of the spectrum though, where we never restore SP at battle's end (except maybe through use of items) has the problem you pointed out that encourages a player to be ultra conservative with their skills. So I'm wondering if the sweet spot is somewhere in between? Maybe we restore something like 25% of max SP at the end of a battle? :shrug:

gorogorosama wrote:Who all is involved in making this decision?


We make decisions democratically here. Basically everyone on the team can lend their voice to whatever discussions they want, whether its about a design issue, works-in-progress for art or music, software architecture, and so on. People not on the team of course are able to read these discussions and share their opinions if they so choose. The reason behind this is that this should be everyone's game, since no one is paying anything. In cases of deadlock where people can't agree, I usually reserve the right to cast the deciding vote. :angel:

gorogorosama wrote:Assuming you do restore SP at the end of each battle, then there should definitely be some basic skill (chillax?) that helps to build up SP in the battle. I don't know what the long-term plan is, but this opens the door for a lot of interesting SP-management skills. Gain 2-SP if this skill kills an enemy. Burn 4-SP and give 4-SP to an ally. Incur a defense penalty for the rest of the battle (or until the next save-point?), but refill all your SP.


I really like those ideas, especially being able to use a skill (finishing blow?) that restores an amount of SP if it kills an enemy.


gorogorosama wrote:I will happily go into the lua and do a rough pass that will at least get things feeling more interesting. But first can someone explain to me exactly what all the stats and calculations are? Where exactly do Vigor and Fortitude and Protection come into play?


That would be awesome. :approve: I really like what you proposed and I say go for it. There are a couple wiki pages available for stats and formulas that can answer your questions:
http://www.allacrost.org/wiki/index.php/Attributes
http://www.allacrost.org/wiki/index.php/Formulas

Basically Vigor = magic attack power, and Fortitude/Protection = physical/magical defense. All these stats can be changed as needed (or renamed if we can come up with better names for them). The Evade stat I've never been a fan of personally because it's a percentage, unlike the rest of the stats. If you want to come up with a way to make evade more similar to the other type of integer stats, go for it.


For this first portion of the game, the characters and enemies are mostly physical-based, so the magical stats don't matter so much (also, we call magical "ethereal" in the game).

gorogorosama wrote:And of course you shouldn't design your enemies without knowing about the player characters. Could you describe generally what types of skills would be easy-enough to implement? Then I'll go through a brainstorming phase of balances that won't bloat the scope.


Right now we only have support for dealing instant damage (ie no poison status that deals damage over time). We have a few different status effects implemented, such as for the Stun Strike ability which deals a paralysis type of status for a short period of time. But if we want to have skills that have special properties, such as "doubles attack strength when another party member is KO" or "restores HP if it defeats an enemy" or something like that, that's completely within our ability to add at some point (just not immediately).

Our battle enemies and skills should be able to be fully scriptable, so I don't want you to worry too much about technical constraints. We have the technology to do whatever we desire to realize. And we do have a programmer who I believe is going to be joining the team in about a week who will be focused on battles, so they and/or I can work on adding support for these sorts of things.
Image
Djinn_in_Tonic
Member
Posts: 67
Joined: Sun Aug 09, 2015 10:36 pm

Re: 0.1.0 Release Design Considerations

Postby Djinn_in_Tonic » Sun Aug 09, 2015 11:05 pm

Make all "tutorials" cover just the basics
I want the player to get immersed in the game, not spend 3 minutes reading dialogues explaining everything.

You might be able to get the best of both worlds by careful construction. Take the opening Cave sequence, for example: if you redesigned the map flow so the cave collapse occurred almost immediately (before any actual combat), you could nicely introduce players to the “Interact / Confirm” button by making them assist in the removal (or attempted removal) of the obstacle. A brief dialogue asking for assistance followed by a “Press ‘F’ to interact with objects or confirm selections” pop-up would provide information in a way that involves the player with the world.
Another suggested simplification is to remove the ability to pre-load action commands. The game automatically pauses when a character without a pre-issued command comes up in the turn order, and that’s probably all that’s needed: given the lack of selection highlights and the almost identical skill selection, I found myself having trouble figuring out which character I was controlling, let alone having the system comprehensible enough that I could plan and chain together interesting attack sequences.

Two initial skills: basic attack (consume SP) and basic defend (restore SP)

This works, but is pretty simplistic and really only serves as a means of extending a battle…unless we work multi-turn moves into the system. An enemy who charges up an attack and then hits for massive damage encourages block moves to be used wisely, but otherwise having to fall back to a defensive maneuver is awkward at best.

Main design issue: Battles are too easy and simplistic
We still want early game battles to be easy and simple, but not so mindless that the player can keep selecting the same attack commands repeatedly until the battle is won. We'll need to take a look at a number of different properties to fix this and make early game battles more engaging and entertaining.

I think injecting the need for strategic choice is definitely important here. It’s currently most efficient to just focus-fire the thing with the most damage per hit point: there are no character or ability combos, no reward for splitting damage, and not a lot of player/enemy interaction points. We’ll need to build in at least SOME sort of feature to increase our strategic possibilities.

********************************************************************

The biggest issue is about the SP, because this will affect the entire game. And the answer all depends on the design philosophy!

I'm going to have to disagree with you here, gorogorosama. You're definitely right that the SP issue is hugely important, but I think we have a bigger combat design question to answer first:

What is our Combat Fantasy, and how much thought do we want players to have to put into combat encounters?

This will help tell us whether we need combo-based combat mechanics (and thus more intricate forms of SP recovery), gritty survivalist combat (in which case SP might only recover at key stages of longer fights), dramatic end-fight heroics (in which case SP might regenerate faster and faster the longer a fight goes on...or, in a more interesting twist, ability costs might start to drop as the fight progresses, forcing you to back-load your incredibly potent abilities instead of burning the boss down with them instantly).

After we resolve THAT decision we can definitely figure out how we want SP to be generated, but I think nailing down the theme of our battle mechanic is going to help us focus in on the right design.

(A bit about this: I come from a background of pen & paper RPG design, where mechanics are always designed to fit a specific fantasy. I think that for combat and gameplay systems a similar approach should always be taken to make sure the end result is thematically appropriate and immersive.)
User avatar
Roots
Dictator
Posts: 8643
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Design Considerations

Postby Roots » Sun Aug 09, 2015 11:48 pm

Djinn_in_Tonic wrote:Take the opening Cave sequence, for example: if you redesigned the map flow so the cave collapse occurred almost immediately (before any actual combat), you could nicely introduce players to the “Interact / Confirm” button by making them assist in the removal (or attempted removal) of the obstacle. A brief dialogue asking for assistance followed by a “Press ‘F’ to interact with objects or confirm selections” pop-up would provide information in a way that involves the player with the world.


Not an idea I'm opposed to, and honestly wish I would have thought of this before the cave map was made. Still, I'm a little :| about teaching the player something so basic as this. Maybe we could just display the help menu at the start of the cave map and the first battle in the game? Just a simple chart showing "These are the keys. These are what they do. Press F1 to dismiss this help menu. Press it again to bring it back". Just a thought.

Djinn_in_Tonic wrote:Another suggested simplification is to remove the ability to pre-load action commands. The game automatically pauses when a character without a pre-issued command comes up in the turn order, and that’s probably all that’s needed: given the lack of selection highlights and the almost identical skill selection, I found myself having trouble figuring out which character I was controlling, let alone having the system comprehensible enough that I could plan and chain together interesting attack sequences.


Yeah, I agree with you there about not being able to figure out which character you're controlling. The ability to pre-select actions is really optional (a player never has to use this if they don't want to), so we could just not tell the player that this feature is there until later in the chapter. That way the first battles will seem a little less frantic since the player won't feel the need to select commands one after the other.

Djinn_in_Tonic wrote:
Two initial skills: basic attack (consume SP) and basic defend (restore SP)

This works, but is pretty simplistic and really only serves as a means of extending a battle…unless we work multi-turn moves into the system. An enemy who charges up an attack and then hits for massive damage encourages block moves to be used wisely, but otherwise having to fall back to a defensive maneuver is awkward at best.


Agreed. I'm sure we can come up with something more interesting and fun together.

Djinn_in_Tonic wrote:What is our Combat Fantasy, and how much thought do we want players to have to put into combat encounters?


This is an idea that is definitely worth exploring (maybe in a new thread specifically for this topic?). Here are some of my personal preferences (we may or may not pursue these goals)

  • Dungeons should instill a sense of danger, not just be a grind fest with a somewhat challenging boss at the end. I want players to feel like "Oh shit, I hope I don't die in here". The early Dragon Warrior/Dragon Quest games did this really well I felt. Sometimes you felt a huge sense of relief after you managed to narrowly make it back to town alive.
  • I don't want a player to feel like they are free to go all-out in every battle (ie, don't auto restore HP and SP to max after every fight). I feel like resource conservation should be part of the strategy the player needs to consider. In other words, they aren't just thinking about the current fight, but the next ones as well.
  • I don't want the same battle strategy to be effective for the majority of standard encounters. Battles get boring real quick when you can win each one the same way.
  • I don't want to always have to go to the party menu and treat wounds and status afflictions after most battles. That's not really fun, it's just tedious. This is why we currently have status effects not persist once a battle is won. I'd also prefer that we create some way to see some sort of way to quickly and efficiently heal my characters and restore SP, if needed, once a battle is done.

On the topic of combo attacks involving one or more characters, in the very early stages of this project we considered something like that (similar to the battle system in Chrono Trigger). We rejected the idea because we thought that although it's cool, with a menu based system like Allacrost (where the characters and enemies don't move around the battlefield), we felt it wouldn't work as well. I really like combo attacks personally because it makes character selection for you party much more interesting and strategic, but I feel like our battle system already has a lot of "core" features (perhaps too many) and I don't want to further complicate it.

Also on that note, I just wanted to make sure you were both aware that if a player loses a battle, they have the ability to retry it. The player is given a total of three attempts for every battle in the game. If they lose all three attempts, it truly is "game over" and they have to reload from their last save point. If a player wins on the first attempt, they get full XP, drunes, and drop rewards. If they lose the first attempt and win the second, the rewards are decreased by a bit (say 30% or so). Losing two attempts and winning the third incurs an even steeper penalty (60%). This encourages the player to always try to win, instead of using their first attempt to intentionally lose as they try out different skills and probe the enemy party for weaknesses. Having this feature also gives us the freedom to make battles more difficult than they would be without it. We don't want to frustrate players by having them have to fight their way to a boss or other challenging encounter only to quickly perish and have to work their way back to that point again.
Image
Djinn_in_Tonic
Member
Posts: 67
Joined: Sun Aug 09, 2015 10:36 pm

Re: 0.1.0 Release Design Considerations

Postby Djinn_in_Tonic » Mon Aug 10, 2015 12:39 am

Roots wrote:Not an idea I'm opposed to, and honestly wish I would have thought of this before the cave map was made. Still, I'm a little :| about teaching the player something so basic as this. Maybe we could just display the help menu at the start of the cave map and the first battle in the game? Just a simple chart showing "These are the keys. These are what they do. Press F1 to dismiss this help menu. Press it again to bring it back". Just a thought.

I'm personally more in favor of contextual learning: being hit with a key chart at the beginning of the game requires you to remember all of it prior to actually having to use it. There's a reason that "learn-while-you-play" became prevalent in games with complex controls.

If our commands are exceedingly simple, then it's not an issue. But if we're looking at more than, say, a half-dozen features other than basic movement I think it's largely necessary (unless you're making something like an FPS, where key-bindings are largely similar across multiple titles).

Roots wrote:Yeah, I agree with you there about not being able to figure out which character you're controlling. The ability to pre-select actions is really optional (a player never has to use this if they don't want to), so we could just not tell the player that this feature is there until later in the chapter. That way the first battles will seem a little less frantic since the player won't feel the need to select commands one after the other.

The fact that it's optional is actually part of the issue: I pressed an arrow key at the wrong time and suddenly had no idea who I was controlling, and ended up getting really confused for a few seconds, since the system wasn't explained...and I couldn't actually back out without issuing a new command. The fact that characters have different speeds of action makes it worse: you always have to check to see who has a pre-existing command, who is executing a command, and who is available for a new command.

Roots wrote:
  • Dungeons should instill a sense of danger, not just be a grind fest with a somewhat challenging boss at the end. I want players to feel like "Oh shit, I hope I don't die in here". The early Dragon Warrior/Dragon Quest games did this really well I felt. Sometimes you felt a huge sense of relief after you managed to narrowly make it back to town alive.
  • I don't want a player to feel like they are free to go all-out in every battle (ie, don't auto restore HP and SP to max after every fight). I feel like resource conservation should be part of the strategy the player needs to consider. In other words, they aren't just thinking about the current fight, but the next ones as well.
  • I don't want the same battle strategy to be effective for the majority of standard encounters. Battles get boring real quick when you can win each one the same way.
  • I don't want to always have to go to the party menu and treat wounds and status afflictions after most battles. That's not really fun, it's just tedious. This is why we currently have status effects not persist once a battle is won. I'd also prefer that we create some way to see some sort of way to quickly and efficiently heal my characters and restore SP, if needed, once a battle is done.


Cool. This doesn't quite touch on our core fantasy though. Are these characters eventually going to become great heroes with incredible power? Are they more of a rag-tag group struggling to overcome the obstacles before them? I also think resource conservation without wound-treating between battles is going to be challenging -- we can't heal you over time or players will just stop moving, and we don't want too much menu interaction...there may be a nice solution, but it's evading me at this exact moment.

Given the constant sense of danger and the resource conservation, it sounds like our combat system should aim towards the strategically gritty: you should always feel like your choices are making a difference, and you should always be in at least some danger. A few suggestions along that line:

  • Body parts should be used only when they actually make a strategic difference that is apparent. Currently it's hard to tell the exact distinction between attacks on various parts of a target (often it's only slightly more damage), and experimentation is only fun the first time. If you have an enemy with target-able parts, make sure there's an advantage to be gained: a snail-like enemy who takes vastly reduced damage until their shell takes X damage, for instance. Or an enemy who has two potent attacks tied to two body parts, but whichever body part has suffered more damage recently can't use its attack. This keeps player choices meaningful in all instances.
  • Enemies should be able to prioritize injured targets, or otherwise pose an intelligent threat. This may help make Blocking more useful, and increases the threat of an encounter.
  • Enemies might be able to "lead" targets with effects that show where attacks will land in advance: this will allow players to use evasion abilities or blocking in an intelligent and strategic manner. Perhaps some sort of UI interface that can show a monster's current priority target?
  • Abilities may have internal time cooldowns (either alongside or in place of SP). This gives us a secondary limiting mechanic on, say, powerful evasion effects or potent spells, making them seem like more limited resources. You can use something powerful to evade an attack at a cost of no SP...but you may not have access to that ability again for the rest of the fight.
User avatar
Roots
Dictator
Posts: 8643
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Design Considerations

Postby Roots » Mon Aug 10, 2015 2:21 am

I pretty much agree with everything you said about everything :heh:. The controls are pretty simple for map mode (four directions, a Talk/Search command, run command, and open party menu command). I'm a fan of learn while you play as well, but I just want to make sure we're not doing a tutorial for something that is easily apparent, you know? (For example, I was going to have a little tutorial when the first NPC comes into view that said something like "Hey there's a dude. Walk up and press F to talk to said dude"). I think its reasonable to assume that most of our audience will have RPG experience or at the very least general gaming experience and can figure out that you can talk to sprites and open treasure chests.


A few notes on the current design related to things you said:
  • Currently there's no individual HP for different attack points on enemies (the enemy has only one HP stat). Attack points have bonuses to their defense and evasion capabilities, may have resistances to certain types of physical and elemental attacks (eg piercing, fire, etc), and dealing damage to them may cause a status affliction to occur. For example: striking the legs is a little bit harder because they have higher evasion than say the torso, but they have slightly weaker physical defense and may also cause the enemy's agility to decrease temporarily if they are struck (agility down status effect becomes active). The same kind of system holds true for the player characters.
  • Enemy AI is non-existent at this point. Enemies select an available skill at random and an available target at random. Of course we want AI to be more intelligent than this, but it's something that we haven't managed to get around to yet.
  • Each ability used by a character has two times associated with it: a warm-up time and a cool-down time. The warm-up period occurs between when the action is selected for execution but before it executes. The cool-down period takes effect after the action is executed, and needs to expire before the character begins building up stamina to execute their next action. We've tossed around the idea of making a character or enemy more vulnerable to attacks during either of these periods. In the graphic below, the action bar is on the right side of the battle screen. The "idle" state (building up stamina to attack_ is between the bottom of the bar and the green rectangle. Above that is the warm-up period.

Image
Image
Djinn_in_Tonic
Member
Posts: 67
Joined: Sun Aug 09, 2015 10:36 pm

Re: 0.1.0 Release Design Considerations

Postby Djinn_in_Tonic » Mon Aug 10, 2015 6:16 am

Roots wrote:The controls are pretty simple for map mode (four directions, a Talk/Search command, run command, and open party menu command).


Then I think we could probably use either method. I'd even consider a small bar in one corner with your running stamina + the associate button prompt, and a thing reminding you what button "Party Menu" is. Either that, or put a "Controls" panel somewhere early on and make it constantly accessible from the Escape menu.

I'm a fan of learn while you play as well, but I just want to make sure we're not doing a tutorial for something that is easily apparent, you know? (For example, I was going to have a little tutorial when the first NPC comes into view that said something like "Hey there's a dude. Walk up and press F to talk to said dude"). I think its reasonable to assume that most of our audience will have RPG experience or at the very least general gaming experience and can figure out that you can talk to sprites and open treasure chests.


Seems reasonable to me.


Currently there's no individual HP for different attack points on enemies (the enemy has only one HP stat). Attack points have bonuses to their defense and evasion capabilities, may have resistances to certain types of physical and elemental attacks (eg piercing, fire, etc), and dealing damage to them may cause a status affliction to occur. For example: striking the legs is a little bit harder because they have higher evasion than say the torso, but they have slightly weaker physical defense and may also cause the enemy's agility to decrease temporarily if they are struck (agility down status effect becomes active). The same kind of system holds true for the player characters.


This worries me, as it basically comes down to mathing out the correct target point and then hitting all enemies in the optimal point for that enemy. It's a solvable system, and not a particularly deep one. I like the idea of targeting different areas at least with certain attacks -- but I'm worried that deepening this system to the point where it's meaningful is going to put a lot of pressure on the coders.

Enemy AI is non-existent at this point. Enemies select an available skill at random and an available target at random. Of course we want AI to be more intelligent than this, but it's something that we haven't managed to get around to yet.


Cool. I'll continue with the discussion assuming that our AI won't have more intelligence than randomization currently...it's unlikely we'll have anything more than basic AI by the target release date. Out of curiosity, can we weight the probability of certain skills being selected?

Each ability used by a character has two times associated with it: a warm-up time and a cool-down time. The warm-up period occurs between when the action is selected for execution but before it executes. The cool-down period takes effect after the action is executed, and needs to expire before the character begins building up stamina to execute their next action. We've tossed around the idea of making a character or enemy more vulnerable to attacks during either of these periods. In the graphic below, the action bar is on the right side of the battle screen. The "idle" state (building up stamina to attack_ is between the bottom of the bar and the green rectangle. Above that is the warm-up period.


Got it. My suggestion was less of a cooldown time for the character and more of a cooldown on a per ability basis though.
I'd also stay away from creating vulnerability during cooldown / warm-up times though: it's a little hard to control your characters specific timing windows, I think.

Image
[/quote]

I messed around in Photoshop a bit (with a bunch of mock-up images and made up names) and turned out something I personally find a bit more readable in terms of UI clarity. Out of curiosity...would there be opposition to a flat UI theme for increased readability?

Image
User avatar
gorogorosama
Junior Member
Posts: 26
Joined: Sun Aug 09, 2015 4:12 pm
Contact:

Re: 0.1.0 Release Design Considerations

Postby gorogorosama » Mon Aug 10, 2015 11:52 am

Djinn_in_Tonic wrote:What is our Combat Fantasy, and how much thought do we want players to have to put into combat encounters?


Totally agree with this.

Created a new thread to discuss the SP issue, though we should settle on the Combat Fantasy first.

Also that UI looks great.
User avatar
Roots
Dictator
Posts: 8643
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: 0.1.0 Release Design Considerations

Postby Roots » Mon Aug 10, 2015 5:17 pm

Djinn_in_Tonic wrote:This worries me, as it basically comes down to mathing out the correct target point and then hitting all enemies in the optimal point for that enemy. It's a solvable system, and not a particularly deep one. I like the idea of targeting different areas at least with certain attacks -- but I'm worried that deepening this system to the point where it's meaningful is going to put a lot of pressure on the coders.


I understand your concerns and don't disagree with them. I'm more concerned about making this so complex that the player is overwhelmed with information. How would we indicate the HP of various body parts? How would we show that they are "dead" or disabled? How would a player know that "killing the arm" would prevent an enemy from using their most powerful attack?

We already have a relatively complex battle system with a lot of different features. I'm cautious about adding any more complexity unless we take away some at the same time. Still, I think your idea merits discussion and debate because it is by no means a poor one.

Djinn_in_Tonic wrote:Cool. I'll continue with the discussion assuming that our AI won't have more intelligence than randomization currently...it's unlikely we'll have anything more than basic AI by the target release date. Out of curiosity, can we weight the probability of certain skills being selected?


Weighting the skills being selected should be easy enough to do for the release next month. Definitely should be done at a minimum by the year end release. Assume that we'll have that ability in the near future.

Djinn_in_Tonic wrote:Got it. My suggestion was less of a cooldown time for the character and more of a cooldown on a per ability basis though.
I'd also stay away from creating vulnerability during cooldown / warm-up times though: it's a little hard to control your characters specific timing windows, I think.


Sorry, I guess I wasn't clear. Cool-down time is done on a per-ability basis. Warm-up time is also on a per ability basis. So we could have a skill that takes a long time to "charge up" but is relatively quick to recover from, or a powerful physical attack that can be executed quickly, but really tires out the character requiring a longer cool-down time.

The idea behind possibly having a vulnerability during these windows was to make it yet another piece of strategy that the player had to consider when selecting a skill. If they know that a character will have a window where they would take increased damage, they might consider not using powerful attacks while their character is in a low HP state. Again, this whole vulnerability concept is just an idea at this point and hasn't been implemented.

Djinn_in_Tonic wrote:I messed around in Photoshop a bit (with a bunch of mock-up images and made up names) and turned out something I personally find a bit more readable in terms of UI clarity. Out of curiosity...would there be opposition to a flat UI theme for increased readability?


Not at all. In fact I like your mockup very much. We've had some conversations about the battle screen layout in the past. The most recent one is here, and the top post in this thread includes a link to earlier discussions. Feel free to skim through these old threads to figure out what we discussed and how we ended up to where we are today.

If we want to have a serious discussion about changes to the battle UI, let's open up a new thread specifically for that. I'll let you do the honors of creating the thread (call it something like "Battle Layout Discussions, Part IV" so its apparent that it's a continuation of our iterative improvements over the battle UI). :D
Image

Return to “Design”

Who is online

Users browsing this forum: No registered users and 2 guests