Proposal - Combat system

[food-please]

Feature implementation: v 0.3 - JRPG Combat

I'm hoping that we can create a simple (J)RPG combat system, similar to what is outlined in the 2D Secret's course.

I think the goals should be as follows:

• Transition smoothly to and from the combat state, keeping player/npc/etc. position on the overworld in place.
  • Allow combat in the middle of a dialogue. A prototypical example would be a boss battle that starts with unnecessary villanous pontification and ends with the villain running away, tail between legs.
  • Transition to combat typically from contact with overworld monster NPCs. Clean up the NPCs on player victory.
• Keep a persistent player party between combats. Allow healing on the overworld to demonstrate persistence.
  • This includes battler stats, as mentioned in this overlapping issue.
• Allow for a variety of enemy formations, including changes to music, background, enemy types, etc.
• Include combat results/game over screens as necessary.

Implementation and Scope
TBD. Will edit once I know others' vision for project. Basically, this will describe the model we want (what stats to include, what visuals are needed, real-time/turn-based, etc.).

Discussion and Feedback
So, we've mentioned this tangentially in other issues/PRs, but I would like to nail down the combat system. In my mind, I think it's a good idea to implement the prototypical combat model, perhaps with a simple resource system (Action pointss, as in the 2D Secrets course?).

Do you have any particular thoughts on combat design? I would find it helpful, I think, to know what the GDQuest folks would like the final product to look like. We can re-implement the 2D Secrets course, or we can do something entirely so that folks visiting the repository can look at multiple combat implementations.

Speaking of appearances, I'm running out of free art and will probably need to start drawing. It would also be good to hear of your thoughts for project visuals. I've included a few mockups below, not sure what you think of any of them. I remember reading somewhere that you're preferring vector over pixel art, which I'm able to work with. I know that you also were using Krita-painted assets, which I could revisit as well.

Pixel-boy at https://2pblog.tumblr.com/image/182081376051. Retrieved 2023-09-23.

[NathanLovato]

Thank you for taking the time to write this!

We have a couple of topics here:

1. Reviewing the goals for this project.
2. Art style and assets.
3. Deciding on the combat system's design.

1. Reviewing the goals for this project

The goals sound great. Note that I think this time instead of doing a really big PR, the work could be broken down into smaller chunks. For instance, the transition to and from the combat state is a separate piece of code from the combat system itself. Character stats and keeping a party around is also a separate piece of code.

The reason for this suggestion is that it makes it easier to review, test, and merge the code, and allows us to give you feedback much faster.

2. Art style and assets

When it comes to art, in all transparency, there's a good chance that, in the future, we'll commission professional artists to (re-)create the assets, sound effects, and music for the project.

I can't be 100% sure now as we unfortunately don't have the budget for that right now, but it's something I'd like to do in the future to make this look as appealing and consistent as possible.

I think the pixel art mockups you've shared are great. If you want to make rough assets, or even have fun with some to put in a personal portfolio, that's great. But I'd suggest not to spend too much time on it, because making all the battlers, mobs, and backgrounds is a lot of work, and there's a solid chance that all the project's art will be replaced in the future.

Regarding the references, I'd say the mockups of Pixel Boy are the most in line with the project's current art style. The other two would stand out a bit too much, I think.

3. Deciding on the combat system's design

Making a classic combat system sounds great. I think it would be good to base it on a proven reference, be it classic Final Fantasy or Suikoden or the likes.

It's so that users can easily understand the project, its code, and learn from it, and adapt it to their own projects.

You don't have to base the work on the 2D Secrets course, though you're welcome to do so (and even to port and improve the code if you feel it can help you save time).

While it had a particular presentation, it's actually like old Final Fantasy, it's an Active Time Battle system. Just, with the character turn order presented on a line as in Grandia games instead of each having their own gauge.

So, ATB or purely turn-based, either is fine by me. Having mana or action points is also fine by me. What I'd avoid is having too many systems and unique mechanics to avoid making the combat system too difficult to learn from.

I hope this helps! Let me know if you have any questions or comments on any of these points.

[food-please]

TLDR: thanks, I think we're on the same page. I'll draw up a quick design and implement things in little chunks. Also, anything else in this issue will fall under 3. Deciding on the combat system's design.

I hope this helps! Let me know if you have any questions or comments on any of these points.

Thank you, this is very helpful. I'm looking forward to seeing how the project keeps moving forward.

1. Reviewing the goals for this project

...Note that I think this time instead of doing a really big PR, the work could be broken down into smaller chunks...

Agreed 110%. Sorry about the overload last time, I was having difficulty breaking it down into reasonable chunks. You should hear from me much sooner this time around.

When it comes to art, in all transparency, there's a good chance that, in the future, we'll commission professional artists to (re-)create the assets, sound effects, and music for the project.

Thanks, that's what I would expect. Personally, I wouldn't commit into it until the project is more or less wrapped.

I'm playing around with Inkscape at the moment, trying to imitate some of Tibo or Kay's work. I'll probably start 0.3 with existing CC0 assets and then do a (quick) asset update before the final 0.3.X release to bring everything together.

I'm having a hard time wrapping my head around good Skeleton2D practice, namely swapping out body parts in real time (e.g. 8-directional character faces away from camera rather than towards it. Might be just as easy to have 2 separate skeletons and use the proper one depending on the direction). Are you aware of any good resources other than the official docs?

Regarding the references, I'd say the mockups of Pixel Boy are the most in line with the project's current art style. The other two would stand out a bit too much, I think.

Great, thanks!

3. Deciding on the combat system's design

Making a classic combat system sounds great. I think it would be good to base it on a proven reference, be it classic Final Fantasy or Suikoden or the likes.

...What I'd avoid is having too many systems and unique mechanics to avoid making the combat system too difficult to learn from.

Agreed as well. I'll try to do a first pass at the system soon and update the OP.

[food-please]

I'm not fully aware of GitHub etiquette, so I thought it worth responding here rather than in a closed PR.

I would agree with what you've written. This was much more complex than I had initially expected. I think the model here is good for posterity. I think it would be improved immensely if the UI opened automatically once a player is ready, if no menu is already open.

I rewrote the code multiple times and I think that it's flexible enough to re-work to either of those options (mentioned at the bottom of the PR above) fairly easily.

So, I'll take another look at it at some point once my semester is less busy. Thanks @NathanLovato, as always, for the feedback and for looking through the code.

I'll probably try to wrap it up into a combat resolution update (you win + xp bars or game over), which should hopefully close this issue as being feature complete.

[NathanLovato]

Definitely I think just a battle results view or piece of UI will close the issue and the full game systems will be pretty much complete! The repository is a great reference already thanks to you.

[PassaroDeFerro]

Definitely I think just a battle results view or piece of UI will close the issue and the full game systems will be pretty much complete!

I opened a Pull Request to do it.

I still think the combat could have some changes and fixes, but I think they should go in a different issue.

[NathanLovato]

Thank you very much for the contribution! Regarding combat, we can differently discuss. Let's just make sure to sync with @food-please who sometimes is working on big changes at a time.

Educationally speaking I would change the presentation at least to go back either to a basic ATB (think working and presenting it like final fantasy 5-6) or change the system to something plain turn-based like Dragon Quest. Most likely the latter is the most useful to the community because it provides an example not only for people making RPGs but also strategy games, board games, and other kinds of turn-based games.

[food-please]

Hey, thanks for taking a look at this!

Looks good to me. I have nothing that would block it. It could work well as a placeholder, or as the final thing that gives a series of messages (something like Golden sun?, see below) detailing the outcome. Either way, I think the dialogue integration is a good idea, opens up the doors for interesting encounters.

My hope was to replace the current ATB system with a much simpler turn-based system, similar to the original Final Fantasies or Dragon Quest. It will require a bit of a re-write, but should be much simpler for new users to understand. I'm hoping to do it in two PRs: introduce the new code and then integrate it with the existing engine. I have something drafted, but I've been waiting for some free time (on my end) to run it by Nathan.

Message-based results example:

[NathanLovato]

Thank you for the update @food-please , and as always for contributing so much to this project! Looking forward to your next PR. If I can help in any way please let me know!

[PassaroDeFerro]

The ATB

@food-please the currently implemented ATB is mostly confusing because your chosen actions are just scheduled and don't start as soon as you pick them. And when they do happen, you're already not paying attention to them anymore.

If you wanted to keep it, it could be done by just automatically selecting battlers as soon as they fill their ATB bars and only letting you pick actions for the next one when the selected one has some action picked.

But I also think a turn based system would be simpler to understand and work with.

The battler actions

@NathanLovato Did this project pick some specific JRPGs as reference for always trying to replicate their mechanics? Or decisions for mechanics are done as needed?

For the battle actions themselves, I think they could have multiple execute() calls, for combining effects. As a reference, Pokemon moves often do more than one thing, and they would require multiple battler action derived classes for each combination. Some examples:

• Damages opponent, applies condition to opponent: Lick, Poison Sting, Thunderbolt
• Damages opponent, heals user: Absorb, Drain Punch
• Damages opponent, decreases opponent stat: Acid, Bubble, Mud Shot
• Damages opponent, decreases user stat: Close Combat, Overheat
• Damages opponent, increases user stat: Ancient Power, Flame Charge, Metal Claw
• Heals user, applies condition to user: Rest

Most examples are damage, then something else, so maybe they could extend the damage dealing action, but I think they being explicitly separate and inserted on a battle action step array, or something like it, would make it easier to freely chain steps without needing more code.

Modifiers and multipliers

I don't get them. How are they supposed to work?

From the comments on battler_stats.add_modifier(), they are supposed to be used by both equipment and actions (its only call comes from battler_action_modify_stats.gd). And from their code, they are supposed to track each individual stat changing effect (maybe for displaying them individually, or to be able to remomve specific ones whike keeping the rest?).

The equipment one looks weird to me: equipment (if it was already implemented) would be tracked by the equipment system and could have their stats taken from there, why put all their stat modifiers together with the much more volatile buffs/debuffs from battle actions? Also, if my guess about displaying stat changing effects is correct, wouldn't they need to be filtered (because I have never seen a game display alongside other effects that your weapon is increasing their attack, unless it explicitly has a buff condition effect, like "at the start of the battle, applies +1 ATK step to the user").

The action use, on the other hand, looks wrong. The modifiers have unique IDs, generated at each add_modifier() call and each stat has its own independent modifier list.

The battle_action_modify_stats.gd class calls it twice, for attack and hit chance.

Because the modifier lists are exclusive to each stat and are independent, it is possible that those two new modifiers end up with different IDs, and the battler_stats object doesn't track if they came from the same action.

Because the modifiers always internally generate new IDs, they also don't track if multiple modifiers of the same stat came from the same action. Unless the source of the modifier (in this case, the stat modifier move) handles that by itself, since the function returns the generated ID.

Also, what are the multipliers intended to do? Where are each (multipliers and modifiers) supposed to be used?

[food-please]

Hi, PassaroDeFerro. Thanks for taking the time to put this together. I wanted to try to address a few things specifically to see if I can help make more sense to it. Proposed changes, feedback, new code, etc. are very helpful.

The basic answer to most questions is "it's not implemented yet". Part of the issue may be that the existing code is too convoluted or complex for the purposes of this project, which is a simple starting point (inspirations are mainly Final Fantasy and Dragon Quest). Ideally, the emphasis would be on simple, though that's not always been the case, as you've pointed out.

Re: actions and ATB. Reworking the turn system to be a simple turn based system is going to greatly simplify actions, UI, Battlers, and the turn system itself. Everything becomes sequential, so all of the odd edge cases disappear. I'm hoping to upload a draft PR for the proposed implementation in the next 48-72 hours, so perhaps it might help to look over that code to see if it's easier to understand.

I'm not sure I fully understand the idea of chained execute() calls. The idea is that each action could be encapsulated in a single call, handling animation and effects from start to finish. I'm not sure why something like "Damages opponent, heals user" would benefit from split into two executions, but I've probably misunderstood what you've written.

Modifiers and multipliers

I don't get them. How are they supposed to work?

Nathan had mentioned (a while ago. Over a year?) cleaning this up. Part of the issue is that many of the systems aren't implemented yet. The stats system may need to be simplified or reworked once other features come into play.

The basic idea is that you have additive modifiers (equipment. I.e. A simple sword adds +10 attack, a fancy sword adds +20 attack, etc.) and multipliers (usually abilities. I.e. "Attack Up" increases attack by 10%). That's the general design. The current implementation might be more convoluted.

The equipment one looks weird to me

Equipment is not yet implemented. The stats system may need to be reworked to accommodate equipment.

The action use, on the other hand, looks wrong.

Actions currently don't really make use of stats other than health and energy. Except for battle_action_modify_stats.gd? Properly designed actions would need to fix this.

Because the modifier lists are exclusive to each stat and are independent...

The purpose of having IDs is that a status effect (Blind, for example, that reduces to-hit by 50%) could grab an ID and then remove the modifier when the status effect runs its course. Your note on all of the modifiers getting jumbled together is true! Please note that the design for the stats class was heavily influenced by GDQuest's earlier 2D Secrets course. I ported it over to Godot 4 and tried to add a few bells and whistles along the way.