Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transition cleanly to and from combat instances #217

Merged
merged 9 commits into from
May 7, 2024

Conversation

food-please
Copy link
Contributor

@food-please food-please commented Apr 30, 2024

A first step towards the Combat issue. This is (hopefully) a much smaller PR than previously, merely introducing the ability to transition to and from a combat instance.

** Please note that both combat instances that you want to test are found in the town area. One is close to the player at the bottom of the area, leaving town. The other is found in the top-left corner of the map. Both of these may be seen in-editor and have a 'scowly-face' popup for their interactions. **

A couple notes on design/architecture:

  • Combats are currently designed as a PackedScene. AI battlers, music, background, etc. are all built-in, while the player battlers will be injected. As it is, AI battlers are currently nothing more than a sprite demonstrating where they may go.
  • GFX from the 2D Secrets course have been reused (for now).
  • Main has been split into two children: Field and Combat. The Field works as it did in the previous demo, whereas Combat steals focus/input/etc. when started. Currently, everything in the Field is paused (no longer accepts input or processes AI or responds to signals, etc.) and hidden (with the assumption that Godot does some behind-the-scenes magic to free up GPU/CPU cycles). Both of these are demonstrated with GIFs in follow up posts.
    • Other options considered were pulling the Field out of the scene tree (to prevent accepting input and being drawn) or saving and unloading/reloading the state from disk. Both options were not chosen because they appeared to be more difficult to implement.
  • Right now, combat may be resolved into victory or loss for the player by pressing 'space' or 'escape', respectively. Of course, this will be changed in future updates.
  • This is intended to be the first of many 0.3.X releases, each one corresponding to a milestone in the combat system. I'm currently anticipating re-writing the 2D Secrets JRPG course for Godot 4 since that will provide its own documentation and rationale (i.e. devs can refer to the course if they want more info or wish to be walked through the design).
  • I wanted to consider multiple win/loss outcomes. That is, loss in JRPGs does not ALWAYS lead to game-over. For example, FF2 opens with the player party losing a combat to a group of knights at which point they are revived by the rebel army. Or, for example, some victories may lead to a speech or cutscene, whereas others may simply lead to an offending AI Field Gamepiece being freed.
    • Examples of both of these conditions are shown in the two combats in the demo. Game-over is not yet implemented, but will be in a subsequent PR.

An example combat transition in this demo, courtesy of Monty Python's Flying Circus
combat_example

What kind of change does this PR introduce?
The demo scene has been reworked to include combat.

The demo introduces:

  • A Main scene separated into two main gameplay objects, the Field and Combat.

  • 2 example combat scenes, broken up into:

    • 1 additional template Cutscene:
    • Combat Trigger, that runs when colliding with the player. This is designed to be used with roaming encounters that may pounce on the player in the field. Winning removes the encounter from the Field, whereas losing will lead to a game-over.
    • An example combat that is run from a conversation. Winning or losing leads to different dialogue options.
  • Combat-related music.

  • Smooth transitions to and from combat.

  • Added a handful of combat events that allow objects to hook into changes in a given combat.

  • Refactored ScreenTransition into an autoload, since only one should ever be active at a given moment anyways.

  • Updated Dialogic 2 to the most recent build. Note that input has been modified to respond to the input events being released, rather than pressed.

  • Miscellaneous fixes to the demo.

Does this PR introduce a breaking change?
ScreenTransition objects are now an autoload.

This PR is ready for review and the feedback/editing cycle.

@food-please
Copy link
Contributor Author

In the following two GIFs I've enlarged the game window a bit to show what's going on in the background. First of all, the combat screen is centered to accommodate multiple resolutions. Note that this is done since the Field can be as large or small as desired, whereas combat backgrounds are designed at 1920x1080.

The Field is paused during combat. AI ceases, player input is not registered, etc.
combat_pause_field

The Field is hidden during combat to prevent Godot from redundant drawing beneath the combat background.
combat_hide_field

@NathanLovato
Copy link
Contributor

NathanLovato commented May 2, 2024

Thanks much for your work once more! The PR seems to have duplicate changes from a previous PR. Do you need a hand to exclude them? This tends to happen when submitting changes from the same branch on a fork.

I'll review everything in detail and get back to you by the end of the week.

@food-please
Copy link
Contributor Author

The PR seems to have duplicate changes from a previous PR.

I believe you're referring to the first commit and the renaming of two references inside main.tscn? Please do check that out, something peculiar is going on there. I had built off of virtuoushub's PR, so I thought that I had incorporated the most recent changes.

Either way, I can't quite figure out what's going on. I don't know if it's because I'm on Windows, but I was having issues with the filename case. In Godot everything appeared consistent - all lowercase. As in, interactions.tscn rather than Interactions.tscn. But in my filesystem those two files and only those two files were uppercase. I don't fully understand what changed in that PR, since the project convention was for all scene files (*.tscn files) to begin with a lowercase letter.

Do you need a hand to exclude them?

Everything now on my end is copacetic, so I have no idea what or when it those two files changed. So, yes please, feel free to iron out any oddness between the two PRs.

@NathanLovato
Copy link
Contributor

Just reviewed the changes, it's all good! And I was mistaken with the duplicate changes, there's a bunch of stuff from Dialogic having been updated notably.

As before, I invite you to keep going. It's too early to say if we were to need or want structural changes down the line regarding the combat and connection between the field and combat system. Your plan sounds great so far!

Let me know if you need anything.

@food-please
Copy link
Contributor Author

Let me know if you need anything.

Great, thanks. Will do.

I'll try to get the next one in early June, since I anticipate being busy the rest of the month. Would you like me to append to this PR or start a new PR for the next feature?

@NathanLovato
Copy link
Contributor

We can merge this now then and you can submit the next batch of changes when you have time. Does that sound good for you?

@food-please
Copy link
Contributor Author

Sounds great. Thanks again.

@NathanLovato NathanLovato merged commit f3f3df4 into gdquest-demos:main May 7, 2024
@NathanLovato
Copy link
Contributor

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants