Best way to build a dialog based "combat system"

[shakume]

First a disclaimer:
I am 100% noob, both here on the forum and to AGS at all. I mean this wholeheartedly, as I didn't know AGS existed two months ago... So I'm sorry if I commit any faux pas or otherwise make a fool of myself. I'm not intending any offense at any point in this thread or from here on out if I stick around...


Short version: How would I make a "combat system" wherein I have two characters each choosing a phrase to say (so two statements then the NPC takes a "turn" to respond based on what was said). There will hopefully have an option for both to "skip a turn" and use their "team up" power (which can only be used once per "fight"). Then a point value is calculated by using (hidden) values from each character's response

For example: Character1Option1 is worth -5 and Character2Option1 is worth 10, so the overall score is 5pts added to the overall "HP" of the "Boss" in the "fight". Then Round 2 starts and the "enemy" "HP" is at +5. The player chooses to use their team-up power to automatically getting +10. Round 3 starts and the opponent is at +15. Then in Round 3 the player chooses two options and gets an overall -10. If there are 3 rounds (I'm debating 3v5), and now at the end of Round 3 the NPC is at positive 5, the game would then check the "win condition" and in this case the requirement is "at least +10." This means the character ends the "boss fight" with 5 out of a needed 10 points and so they get a game over screen (or just a "try again?" Y/N screen).

If they had hit the goal, then the player would "win the fight" and the NPC will perform whatever plot action is needed (giving an item, telling an honest truth they asked about, allowing entry to a room, etc). I'm currently thinking of creating a GUI for each "boss round," creating GUI buttons (one for each option, including the team up if it hasn't been used yet), then somehow assigning the point values to the chosen option and then calculating the plus or minus the player achieved each round. Trick is, I don't really know how to do that. I haven't done much coding beyond HTML since HS.

Any thoughts?





Bonus "Longer Game Theory Version" Round -

Hookay. So, the quick backstory.

I have spent much of the last 15 years slowly creating an in-depth game setting for our TTRPG sessions. It started based on system lore with some tweaks, but each game drove it deeper in its own direction until it became something I think is truly unique. Sadly, my RP friends have drifted in the last few years and the pandemic finally just killed our ongoing game. Since then, I've been itching to preserve this world in some way and while I started out with the idea of writing a series of books based on the setting and some of the lore points we mentioned in the setting, but never actually played through. I even wrote about 6 chapters of said book, but I kept feeling like there was something missing... In this case, it was missing player input. My spouse is an artist and has been itching to find a big project (and indeed, as a co-creator of the setting, had found similar frustration in an attempt to make a comic). We were nostalgia bombing different channels on youtube and eventually hit a mini-binge-athon of modern reviews of our favorite adventure games of our childhoods. I'm not sure which of us first suggest we revive our ideas for sharing our universe as an adventure game, but we both have since dived in. I am writing the dialogue and designing scenarios whilst she hand draws images to use as "sprites" and backgrounds, I've also volunteered to spearhead the majority of the actual game design.

I've been playing around with AGS for a little over a month now and I think I'm kinda getting a vibe for how the default stuff in this program works. And I'm loving it. I'm already understanding most of the basics so far, especially the emphasis on this project is the artistry of its design and the storytelling combining to tell a great tale. So, for the most part, the default "vibes" are totally fine with a bit of a graphic swap. That brings me to the issue at hand. See, the primary way we were thinking of engaging the player and helping them forge their own twist on the story through the game. Since we started out with this world in the TTRPG realm, I still kinda want to keep the general feel of that RPG-ness while still being easy to navigate.

We chose not to bother with trying to include combat for two main reasons: First, it didn't fit the characters being children and most NPCs being adults. Second, it felt like the wrong kind of RPG for this. If/when we make a sequel continuing the story, I'm thinking of using RPGMaker to borrow the feeling of JRPGs since that fits the character that game would follow. But this one, it didn't feel right to take it in the direction of QfG, but instead wanted to lean closer to Gabriel Knight approach. But we wanted to retain the idea of "bosses" in some fashion. Each chapter would have only one "combat" sequence against that "boss" (plus a shorter and simpler one as a tutorial at the start of the game). Talking their way and manipulating adults felt like the best approach, thus where the concept of this "dialogue combat" came from in the first place. We wanted each of the main characters to take an action (mostly talking, but this could also include gestures or physical actions to achieve a similar effect), then the "Boss HP" is altered by those actions to result in a final score which is compared to a "win condition" to determine if they "beat the boss" to progress the story. Basically, this is why I come to the fine folks of this forum: Can this system concept even work? Even if it can, would it be impossibly complicated for a coding dinosaur who hasn't coded anything other than HTML since High School when she was taught BASIC and C++?

I really am more a writer than a coder, but AGS makes me feel like 90% of my concepts will be super easy to implement and tweak. This little bit, which I feel is super important for the right vibe to come across, is tripping me up. I simply don't want to write out all the dialogue and such assuming I can somehow get this "combat system" working, then find out I can't and have to wholly rewrite the parts using a concept that won't work as envisioned. So... What do y'all think?

[Snarky]

Welcome!

You can certainly implement something like this in AGS, and it doesn't sound like it would be too difficult in principle.

Of course, when you hear "dialog-based combat" in an adventure game, everyone immediately thinks of insult swordfighting, and this sounds potentially quite similar, except with explicit HP (rather than the implicit advance/retreat score of insult swordfighting).

The big decision, as I see it, is whether to build it on top of the existing dialog system, or outside of that. I think that depends on exactly how the dialogs fit together, which you didn't really explain.

Like, are the dialog options static? Do they depend on what has been said earlier in the dialog? Can the same dialog option be used more than once? Do the options change depending on what kind of skills (or equipment, etc.) your character has, or do you need to unlock them somehow? How many possible options are there in total, and how many will you have to choose from each time? (All of them?) Is there a random component at all?

[shakume]

Between the two, my first instinct is "whichever is easiest to implement, so I don't get overwhelmed too much."

And BTW, having watched some reviews of Monkey Island games for her sake, I have never played any of them. Though increasingly I think I should... ^_^;

That said, valid point. I didn't mention those things and I only didn't because I thought my post was probably already too long...  ^_^

The dialog options are not quite static, but they aren't (currently) planned to be necessarily "reactive" from round to round.

In short:
- I am envisioning this as an alternate "quiz game" kind of thing.
- I had planned to keep "normal" dialog with all characters, but some select ones the "normal" dialogue ends with an option of either "Enter Combat" (or whatever I end up calling it) or "Leave Dialogue". The latter leads back to the room and you can always come back to initiate the Combat when you feel better prepared.
- I plan to write a premade set of options in each round (i.e. Round 2 of this fight will always have the same 2 options for Char 1: (Friendly: Handshake, Aggro: say "Nice cue ball baldie") regardless of what options are chosen in round 1. The next round the options change, but always to the same options.)
- Trick is, some NPCs like blunt/aggro responses and give positive HP for rudeness, while others are deeply offended by harsh words/gestures.
- The Team Up option is ALWAYS a positive HP gain
- I honestly hadn't considered an "unlock" process, either inventory or otherwise. I like this idea though, either by replacing the default options (like the +5 option becomes a +10 or something) or showing up as a "third option" under the character's default 2. Even better if it could be tied to (normal) dialogue options selected. Like, if you ask them a question and they tell you, you can use that to boost your chances! If this adds too much complexity though, I would skip it for my simpler version.
- You always choose 1 from two pools of options (character 1 has 2 options and so does Character 2, you choose two options: one from each char's options). So you pick two (one from each) or the team up (which cancels out the two sets of options, and can only be used once in all 5 rounds.
- No random component in the computer sense. Some characters like randomness in their responses from the player, but nothing scripted as random.
- And I was envisioning all this as a window that pops up over or otherwise masks over the room enough to make sure focus is on the "fight."

All of this is pretty flexible on my end. If making it more random would be beneficial without muddying up the concept of learning the characters and what they like, then I'm always down with more choices and permutations. I just don't want to create something that feels random to the player if they take the time to explore and discover other information. Like, if you figure out the NPC is a belligerent alcoholic, then choosing your options will be easier than if you had skipped straight to the "combat" screen.

Edited to add a link to a quick sketch of what I'm thinking: https://i.imgur.com/lT5Wh94.png

[Snarky]

Edited to add a link to a quick sketch of what I'm thinking:

OK, so given that description and sketch, I wouldn't use the AGS dialog system for the combat. The UI is too different, for one thing.

The way I would write it, I would have a struct that stores all the details for a boss:

-The name of the boss, any related graphics you need to display
-What the dialog options are in each round (for example as four string arrays, one for each button—or six if you have a third unlockable option for each character)
-What the outcome of each dialog option is, i.e. the effect on HP and any kind of comeback or response the boss has—either a dialog response or animation (if the outcome depends on the combination of Char 1 and Char 2's options, it gets more complicated, but still doable)
-The win condition for this boss

I would make an array of this struct, with one entry for each boss in the game. Then you need to initialize it: set it up with all the data for each boss. You'd normally do this as a function that gets called at game startup.

I would have some variables to store the current state of the combat (which boss you're currently "fighting", the current round, how many hitpoints the boss currently has, whether you have used the special combi option already, etc.; to keep things organized I would add all these variables to a struct, but that's more a personal preference than an architectural requirement), and then I would have a function that does the combat logic: based on the dialog options chosen and the data in the current boss's struct, update the state of the combat. I would also have functions to do whatever the feedback to the player should be (e.g. play animation/music), and to set up the screen appropriately (show the boss's NPC pic, fill in the right text in the option buttons, etc.). Also a function to start the combat and one to end it. Finally you just hook up the button handlers to run these functions when appropriate.

Oh, and about the graphics: I would strongly recommend you make a View for each boss, set up the same way for all of them. That way, you can just save which view to use for each boss (as part of its struct), and then use the same code to display different expressions, animations, etc. (Or if the bosses are already characters, you could use their Normal or Speech view, and just save a pointer to the character in the struct.)

Essentially, this is more like a combat system than a dialog system, so you can search for any posts that explain how to code a combat/battle system.

[shakume]

So, I've spent a few days looking around the forums and everything I look at regarding battle systems is far too complicated for what I wanted. My initial conception would look like a combat window, but as I think about it the actual "structure" of the combat is more like a simple math puzzle.

From what I understand of coding/scripting, these are the variables I need to be able to set into a template:
- Define each boss's current HP
- Define each boss's "success" HP
- Create buttons for the options the player can use
- Duplicate/modify buttons for each round of each fight
- Script each button to either add or subtract from the boss's HP
- Script Team Up button to only be usable once per puzzle
- Define a variable for whether the boss is "complete"
- Script to make dialogue system to lead into each puzzle
- Script the dialogue option to initiate combat to disappear if boss is "complete"

Trick is: everything I can find on making a "combat system" includes large sections about weapons, mana, or any of dozens of other variables I don't need... This makes it quite difficult for me to tease out the definitions/scripting/etc that I actually need to do to make this simple +/- score based puzzle combat. I'd be happy to follow a scripting tutorial or even just educate myself from scratch on how to do this without breaking the code (which I've already done a few times since I started this endeavor). I just can't find the info I need without getting lost in a muddy swamp like QfG4. Any suggestions on where I start looking? If I even had a series to follow through the help files would be awesome! As it is, I'm finding myself battling analysis paralysis and just staring blankly at my screen in confusion. ^_^;

Also, I now find myself confused... The "Battle Screen" collection of buttons and sprites... Should I build a room to overlay with button templates? Or build a pop up window over the screen? Or try to build a full GUI overlay for the room that only appears for combat? Would one work better than the others?

 

[Snarky]

just can't find the info I need without getting lost in a muddy swamp like QfG4. Any suggestions on where I start looking?

I was thinking more of general hints like this thread. So, think about how you can break down the problem and work on each part individually, and how you can iterate from a very simple version to a complete system.

For your case, I would start by setting up the GUI with the essential buttons. Then the functions and variables to keep track of the combat. All the rest could be hardcoded for the first version. Now you'd have a placeholder you could plug into the game, to work out for example how to trigger it from a dialog.

Once you have that working, you could start to write the structs that will store the data for each fight, and write the functions to fill the template you've set up with that data.

Also, I now find myself confused... The "Battle Screen" collection of buttons and sprites... Should I build a room to overlay with button templates? Or build a pop up window over the screen? Or try to build a full GUI overlay for the room that only appears for combat? Would one work better than the others?

You will probably want to make it as a GUI with Buttons and perhaps Labels. You can make it full-screen and with a transparent background. To display character portraits, you'd again use Buttons.

[shakume]

Thank you so much for all your help and suggestions! I'll start there and work things out one by one from there! Thanks!

[Khris]

Hey, I made a small demo game that shows how to connect a GUI, a module and a room.

Places of note:
GUIs -> 9: gBattleMain (the used GUI and its buttons and label, check the GUI elements' names and on click event functions)
Scripts -> BattleGUI (the header and script for the module I used to keep things tidy)
- the header shows enums, a basic struct to store boss info and one to group functions for outside access
- the main script shows handling buttons, updating the GUI, providing module info to the room script, setting up bosses
Scripts -> GlobalScript -> Edit Script, scroll to the very end (since GUI buttons clicks are handled by the global script, we forward them to the module)
Rooms -> 1 -> Room Script (function call that starts a battle)
Rooms -> 2 -> Room Script (script for room used for battles)

When you run the game, simply click the glowing orb to start the "battle"

Source Download for AGS 3.6.0: https://drive.google.com/file/d/1QkXihSpB-AMSYBNzGKKtHiPU6jPsDq_i/view?usp=sharing

[shakume]

Hey, I made a small demo game that shows how to connect a GUI, a module and a room.

OMG! Thank you! This is amazingly helpful! I'm now off to fiddle with this to help figure out how this all works and how to implement everything!