UI Design Discussion

[srliao]

From @unleashurgeek

In HSR there a "rotation" concept that is traditionally used for Genshin will not work. Instead, how to play characters and teams should be explained in terms of "priorities." When it is a given character's turn, you want to be able to evalute their logic top down until you reach a described "action" that you can perform. This logic can still be complex with conditional behavior. As an example, you may want to define the "action priority" of Dan Heng's burst as "Only burst when Dan Heng's talent is active". Here is a random example from popular WoW guides that explain how to play builds using "action priorities" in the form of a simple bulleted list:

So with all the above, my idea for sim/defining "action priorities" is creating a super simple "blocks" system. A block can have one or more "actions" defined in it. You read the blocks from top to down, stopping on the first action that the character is capable of performing. After you perform the action, you restart from the top (when it is that character's turn again). Additional metadata can be defined with an action (the targetting logic so it's clear what targetting priority I should have when performing this action). Here is a super simple example of what a block may look like. With this block it is simply just the equivalent to:

• If burst is available, use it against lowest HP enemy.
• If Skill is available, use it against enemy that has weakness to wind.
• Otherwise, use your Attack against lowest HP enemy (base condition you are always able to do)

To add complexity to this block system, you will be able to chain multiple blocks together. For each block, an optional "condition header" can be defined to describe a condition to evalute. When defined, block actions are only evaluated iff the condition is true. If the condition evaluates to false, you skip that block and move onto the next one (this also means that the "bottom" block must never have a condition since you can never be in a situation where there is no action to perform). Here is a simple example of adding a condition for using burst. This logic would be equivalent to (targetting information is omitted because I'm doing this shit by hand and thats a lot of work):

• If Dan Heng's Talent is active and burst is available, use Burst
• If Skill is available, use skill
• Otherwise, use Attack

Now what about defining multiple characters? Because in this game, characters have their own speed and own turns, my naive thought is it might be best to define each character's "action priorities" as an independent chain of blocks. With them side by side, you can see the logic that each character should be performing within the team. If you are following a guide, when it is that characters turn you simple just follow the action priorities for that character top down to figure out what action would be best to perform.

This does present a problem however. Because bursts can be performed "out of turn order", having 4 independent "chains of blocks" will not tell you the priority/order you should perform bursts in. In the solution attached, I am adding a 5th chain dedicated to declaring your bursting logic for the team (downside of this is you now have to look at two places for the character logic, their blocks and burst blocks):

Want to get feedback and other thoughts on going this route. Some alternative thoughts we could also explore (but I am not going to mock up rn because the above 3 images took me way too long):

• A single chain of blocks for the entire team. This has the advantage of solving the order problem, but there will be a lot of "noise" (when it is a character's turn, you have to skip over all the actions that are not for that character)
• Omit the burst blocks and instead have bursts ordered by the order characters are defined (character 1 always bursts before character 2). The downside of this is more complex logic where you want the order to change based on certain conditions would no longer be possible

[Vessv]

I have a few thoughts. Firstly, it would be interesting to be able to chain multiple conditions together. For example, if my energy is lacking by 30 points and I have more than 1 action point, then use a skill. Additionally, other operators such as "OR" would be useful. Regarding ultimate abilities, it would be interesting to chain different conditions together. For example, only use Danhen's ultimate ability if my ultimate ability can break the enemy or if Bronya's ultimate ability is ready to use, then use Bronya's ultimate ability followed by Danhen's ultimate ability. I think it will be complex to simulate all the possibilities a player can take in a real combat situation, but if the necessary tools are provided, it could be very useful.

[Shibang]

Was working on my own sim, and have some thoughts towards your UI design since it wound up being similar to the way I was envisioning my back end design. Figured I would give some insight based on my backend's direction so far.

In my back end, everything is composed of "entities", "buffs", and "events". You can read more about my design here if interested. Entities were allies, summons, and enemies. Allies must have 3 events (ult, basic, skill) they provide. Buffs are anything that effect entity stats, like relics, normal buffs, certain talents, etc. Events were anything that "occurs" where a conditional buff applied may need to be resolved (like yanqing being dealt damage ends his talent buff, so conditional talent buff ends).

The UX described largely resolves around one of the things that my "ally" classes have needed so far: selector. In my backend, the selector was going to be the customizable logic for selecting targets for skills (the action priorities mentioned in your current post). There would be a single selector for all allies for ease of use, which probably corresponds to having a single UX for creating the action priorities for each character skill event.

The thing I find missing a little bit is the other key part that my ally classes seem to need: the controller. This comes down to resolving the bullet point for "[i]f Skill is available...". In other words, it is how the team's sp points are allocated for each character. You tried to resolve this with the "5th chain" mentioned in the post, but I think this will likely need be a little more separate, at least based on the scratch stuff I have made so far. The main thing of interest becomes how many skill points can any character use at any time. For example, QQ might be a high-priority skill user in your chain, but may be capped on how many skill points she can use. This becomes more noticeable in potential future characters that can use more than one skill point at a time.

I think all characters would use their skill if infinite skill points were available, so really the only thing that needs to be known is how many skill points is available for that character on their turn. So, even if there are currently 3 skill points available, if gepard's turn comes around he may still be stuck at 0 points allowed for him and so he uses basic.Then QQ burns up to 4 on her turn.

If you like that idea and wind up with a backend similar to mine, I think that the "5th chain" should instead be a skill-point allocation UI. This would contain how many skill points a character is allowed to use, perhaps increasing / decreasing after certain events (like letting Bailu use a skill point on healing if a "DamageTaken" event results in <50% hp on an ally). Whether the ally has any skill point(s) allocated to them decides if they skill, selecting a target based on the selector logic in your "Block".