tomraegan

Hi there.

I'm a n00b and just need some feedback on this question before plunging in.

From the 2D Turn Based Grid template, as battle commences, the UI Box Battle Menu allows me to choose combatants to use in battle. My question is about this Menu.

As my player travels around, I need for them to unlock additonal combatants they can use in battle. This happens non-linearly, or in a non-predicatable order. When battle begins, a particular player's list of available combatants to pick from would need to differ from another players.

Is it possible for the UI Box Battle Menu to procedurally reflect which combatants a player has unlocked?

I dont really need to know how to do this...I just want to make sure I can do this, before I get started.

I'm trying to be concise to avoid additional reading, but am happy to expand on the explanation if it's not clear what I'm asking :) Thanks!

tomraegan

Oh, wrong forum ;p

gamingislove

Well, that menu is set up to select which combatants of the player group participate in battle (and where they're placed on the grid).

Unlocking other combatants simply means joining them to the group later (as it's e.g. done in the start game schematic of that tutorial).

tomraegan

Thank you. I'll start learning the system.

Great community you've developed and maintained here. So many threads where people conclude by saying "Got it working!"

tomraegan

Just resurrecting this to ask a followup:

In relation to this schematic:


As explained, as my player travels around, they gather an army (of 30+ combatants) and can select any 6 of them for each battle. The 6 are selected in the UI Box Battle Menu at the start of battle and placed on the grid, just like the 2D Grid battles.

When the player starts the game, they have only 1 army to select. This needs to be reflected in the UI Box Battle Menu. When they have recruited 10 combatants (allies), they can select from that 10.

Here's the point - the 10 (or however many) they recruit will be different from game to game, player to player. The infantry recruited in 1 playthrough is overlooked in the next, for example, and is thus unavailable in the UI Box Battle Menu throughout the game.

As such, I need to be able to activate nodes in the Start Game schematic above, or my version of it, to allow an evolving (in-game) list of armies that have been recruited to join the battle. How would I best do this?

I admit that I'm still hesitant to plunge in (for various reasons...I do own the asset) and so am looking for expert advice before I do. I appreciate the help.

edit: You said "joining them to the group later" is the way to do it. Can that be done at runtime?

GeneralK

Hi @tomraegan, I'm not the expert but think I can help a bit on this.

The Start schematic is just that, for Starting the game. So at the start of a new game your player maybe gets 1 infantry via the Start Schematic.

Once combatants are in the group, the game is keeping track of all the combatants in the group automatically, including as you add more.

Then at the time of unlocking another infantry, that is when a Different schematic runs that has a Join Group node. This is what he meant by joining them later, is from a different schematic triggered by some method.

How that is done to run the schematic depends on how you want the player to obtain them, there are Tons of ways available. Perhaps it's when they win the battle or kill 10 enemy infantry etc etc.

The place the schematic is ran from will depend on that.

For example if it's when an enemy infantry is killed you gain an infantry, you could do it in looting the enemy infantry or in the death schematic of the enemy infantry.

Or perhaps it's when your general gains a level. You could have override on Level Up schematic for that combatant that has Join group nodes based on conditions and opens a UI Box / HUD to show what's going on.

As to the menus..

The menu settings themselves UI --> Menu Screens determine what is being shown in the menus (mostly)

The menu is showing combatants already in the groups, the schematics are adding/removing them from the game.

The UI Box is just the GUI that the menu is using. You could use the same UI Box for a bunch of different menus. For example the "UI Box Battle Menu" is just the name of that box. "Combatant Selection" for placing on a grid, is actually not a Battle Menu in the editor.

That's what GiL meant about that tutorial, was that the UI Box itself is being re-used in two different menus. It was used for selecting which combatants are going in to the Battle Group and also used to select which combatant (of the battle group) is being placed on which grid cell. Then using it again to display the actual Battle Menu (that shows spells and abilities)

Basically your Group is like All of your combatants, your Battle Group are the combatants going on the grid to fight.

It sounds like you want a group menu that lists the Battle Group on one side and then the remaining available combatants on the other side and swap between them.

The RPG playground tutorial has an example of setting that up, scroll down to Group part.
https://orkframework.com/guide/tutorials/3d-rpg-playground/menu-04-menu-screens/

You can make it drag and drop, doesn't have to be key based menu screens with choices.

You could have that menu open automatically when pressing the fight battle button / clicking on a map of towns, or always have it available via a main menu option, or whatever you want.

The part about limiting it to 6 in battle, you go to Game --> Game Settings --> Scroll down to Ork game Settings --> Player / Group Settings --> Battle Group Size

tomraegan

Wow, that's cool. I appreciate the most excellent feedback.

It's great that you extrapolate on scenarios that I'd be likely considering, as you've hit the proverbial nail on the head.

I get it now :) Thanks.

Just a ps: I've read a few older threads where experienced Unity campaigners get nervous about having to learn GiL's system...that's me. Given how much there is to do developing a game, it's always nice to have a plug and play solution you can implement without needing to understand it. It just does what it needs to do. From what you've described, of course it's possible to do what I was asking...multiple ways. Whilst that's great news, it also means I've got to go in and learn a new system, which I've been quite reluctant to do, given ORK's complexity.

Thanks for walking me through the door. (No veiled criticism of ORK intended...its turn-based grid combat is the only asset close to achieving what I, and many others, are after.)

GeneralK

Ah I see where you're coming from.

I also choose Ork when looking at RPG framework assets due to it's grid based combat.

Little did I understand at the time how much bang for my buck and time I was getting. I see all sorts of mini assets that do something that Ork has integrated and super happy I went this direction rather than piecing together a bunch of other smaller assets or attempting to create a ton of tools.

tomraegan

Reassuring to hear. I always tend to start a little falteringly, like with Playmaker, C#, Corgi and a few others, and after a year of stumbling round, it all starts to click. When I read the fundraising threads to have Grid battles expanded on these forums, from years back, it's obvious there's such tremendous depth to the framework that people (especially GiL) have been plumbing and expanding for years. This fact, combined with an old editor interface (I get it, ORK was designed when we were all on mIRC :)), and detailed, step by step ReadMe tutorials (hardened youtube learner here), my reluctance to suck it and see, so to speak, has lead to this thread. But I am definitely reassured, so many thanks once again.

gamingislove

tomraegan said: edit: You said "joining them to the group later" is the way to do it. Can that be done at runtime?

As @GeneralK explaind (thanks btw :D), yes, that can be done at any time.
The start schematic itself is also at runtime and is just for doing the start game stuff, e.g. setting the player, loading a scene and spawning the player. You can also use it to do a cut-scene, have the player do choice dialogues or whatever you want. At the end you usually need a combatant joined to the player group and spawn it somewhere to be able to move around (though you can also do a non-player game with e.g. point'n'click controls to navigate the scene).
You can also randomize which combatants you get at the start, e.g. via a Random node or a Chance node and have different combatants join.

Schematics are used for all kinds of mechanics beside that, e.g. animating your battle actions (where you can also make Pokemon-style systems to 'catch' enemies and have them join your group), talking to an NPC and join a new group member at that point, etc.
So, the Join Group node can be used at any time in your game.

tomraegan

Thanks. I've spent the last couple of days potterring about with your system and am feeling a whole lot more confident. Thanks for the response.

tomraegan

Just want to necro my first thread and express just how much I appreciate the ability of the ORK Framework to create games. After a few months of pottering about, and then a week of doing very little else, I'm starting to see what ORK actually does.

For anyone on the periphery, wondering if this asset does something, it very likely can do it. My issue was I just didn't understand what ORK was...I mean, I knew I wanted turn-based grid combat. My hesitation was built on ORK's UI. I just could not see past the way it presented menus. I now see how integral the UI is to leveraging the power of multiple game systems, including combat.

That process took some perseverance, but every day now, for the past week or so, I realise I want to express my gratitude to GiL for developing this system for Unity. Wow. ORK makes Unity something else...something much better.

Of course, I shall express my gratitude where it counts, mostly because I am able to and it hopefully allows greater longevity for the asset.

gamingislove

Thanks, I appreciate the feedback :)