Questions about card game mechanics and custom battle system possibilities

polygonpro

Hello! I am considering purchasing ORK Framework 3. I was very impressed by the many glowing reviews on the Unity asset store, and by the trailer video showcasing the different types of battle systems included in the framework. Before I buy, I have some questions I'd like to ask to figure out if ORK is the right fit for my current project.

I have designed a turn-based RPG, that uses cards as the attacks/actions for characters on a tactical grid. Battles are duels between two opponents (the player vs. the A.I. or another player) each controlling one or more characters. Each character has a deck of cards associated with them, and each card has multiple ways it can be used (attack, defense, movement, etc...)

Each turn of battle, both opponents:
1) secretly select a card from their hand to play
2) then select an action for that card (Attack, Block, Move, Power-Up, etc...) 3) after both opponents have confirmed their selections, the cards are revealed and resolved
4) the order in which cards are resolved is determined by the types of actions that were selected 5) in the case of an Attack, every card has a specific area-of-effect of cells it can hit, relative to the attacker's position on the grid. If the opponent is in one of those cells, they get hit (see the concept image below) 6) after the cards are resolved and effects applied (damage, pushback, status effects, etc...), each opponent draws additional cards, and a new turn begins.

As seen in the image above, the grid is a side-view perspective, aligned to the X and Y axes. So, the characters can move forward and backward, jump into the air, and fall to the ground.

My questions are:

Is the custom battle system that I described above capable of being implemented with ORK?
If so, what parts of the framework would I have to change to implement this?
For this simultaneous select/reveal/resolve turn structure, which of the included Battle Systems would be the best starting point for modding?
Would it be better to try to implement this system from scratch using Makinom schematics, rather than build upon ORK?
Can a Battle Grid be oriented to XY, like in the concept image above? If not, how difficult/much work would it be to make it work that way?
I understand that multiplayer functionality is not provided in ORK, but is there anything about the framework which would hinder adding multiplayer functionality of my own?

Thank you very much in advance for answering these questions! If you need more information from me to better understand the details of what I'm asking, please let me know. :)

gamingislove

Hm, that's a tricky one - generally, card mechanics are possible (e.g. cards being items), but having multiple actions per card (item) is not. However, it might be possible by using combatants as cards, that gives them multiple actions.

1) Potentially, but I can't guarantee it'll be possible 100% out of the box. As said, I think it's doable by using combatants as cards for the multiple actions. The card grid could be using ORK's battle grids. UI-wise you'll probably need to do some custom work to make everything view/behave as needed in a card game.

2) That largely depends on the details. Probably a custom battle system implementation (more in #3). I think most should be doable by using schematics (e.g. turn start/end schematics for draw or shuffle your cards/combatants). UI will most likely need some custom implementations.

3) I'd say Phase battles - this one would allow you to freely select the combatant (card) you want to use instead of having them in a fix turn order as turn based battles would have. You'd just have to change it to have both factions select actions first and execute the actions after both are done. To add a custom system, e.g. just copy the phase battle system's source code and add a new script (naturally, renaming it) to your Unity project. The new battle system will be automatically available as a type.

4) Probably not :D

5) Yes, grids work in 2D and 3D.

6) Not really - it's just a complex undertaking. ORK 3's full version gives you access to the full source code to change to your liking. Also, ORK funnels a lot of functionality through a feature called the Access Handler, which allows you to somewhat implement your custom multiplayer solutions a bit easier. Using a custom access handler implementation lets you inject your functionality, e.g. using an action goes through the access handler, where you can instead of forwarding it to the battle system, forward it to your multiplayer functionality to process it. There's currently no ORK 3 documentation for it (scripting documentation is not available yet), but you can refer to the ORK 2 version for guidance, works basically the same.

polygonpro

Thank you very much for answering my questions, this is very helpful! I have more questions... :D

1) Setting up the cards as combatants sounds interesting. But what about the actual characters on the grid? Would they also be combatants (of a different type)? The character positions on the grid are where the attack cells will orient from, and those models will be playing the animations associated with the different actions and reactions. Would it have to be implemented some way where the "card combatants" send commands to the "character combatants" to make them perform/mimic their corresponding actions?

2) Another detail of the battle system for my game is that multiple cards can be played on the same turn, as combos - if either of the opponents' actions is an Attack (Attack Combo) or a Block (Block Combo). See image below. The additional cards played give the first card in the combo a stat boost (Damage stat in the case of Attack, Guard stat in the case of Block.) Also, for Attack Combos, the attack animations for each card in the combo will be played back-to-back when the attack is resolved, like combos in a fighting game. (I'm using Timeline for choreographing the animation sequences, instead of Mecanim.) Does this combo system of playing multiple cards together complicate or invalidate the potential card-combatant approach you suggested?

3) Would extending/modifying ORK's Item system, to allow Items to have multiple actions to choose from, be a valid alternative to the card-combatant approach? If so, what would be involved in that? (Schematics? Coding?)

4) I was already fully expecting that at least some, if not much, of what I want to do in my game would not be possible with ORK "out of the box", and that some custom changes would need to be made. Are such changes possible solely by using Schematics? Or would altering the source code also be necessary?

5) For the card and action selection/combos, if trying to find workarounds within ORK do not work out, would it be possible to use my own solution (either through coding, or through another 3rd party asset) for the card mechanics, and have that solution call on other features of ORK when needed (like status effects, damage formulas, grid movement and targeting, etc...)? So basically, outside scripts that can tell ORK to do things?

Thank you again for providing this information!

polygonpro

I thought of another question...

6) Since combatants can choose from and perform multiple actions in the ORK battle systems, would it work to implement the cards as actions? And the "actions" in my system as sub-actions within those action categories? So a player:

selects a card, like selecting a menu category in a normal turn-based battle (attack, use item, cast spell, etc...)
then, the player selects what to do with that card, such as Attack or Move, etc., like selecting an option within the menu category in a normal turn-based battle ("leap attack", "healing potion", "fireball spell", etc...)
so, instead of having standard actions with varying sub-options, it would be like having varying actions with standard sub-options.

I'm guessing there would be custom work needed to "draw" the available actions randomly each turn, and to display and select them in the UI as cards rather than through menus. But other than that, could it work to approach the card mechanics as just a fancy actions menu?

Solkyoshiro

I just stopped in to say this is very interesting and I'm looking forward to the results. That style card game looks pretty sweet @polygonpro

polygonpro

Solkyoshiro - Thank you! :)

gamingislove - here is a breakdown of an example turn, if this helps make what I said earlier make sense:

gamingislove

1) Basically, yeah - the characters on the grid would be the combatants/cards. Alternatively, you can naturally animate this however you want :)

2) Not really, when basing it off the Phase battle system, you can use as many combatants/cards in your phase as you want (same for the enemy). You'd need to control when to end the phase anyway, e.g. in the schematic animating the selected action.

3) Hm, that might be difficulty. An easier approach would be to just implement your own card system, where each card e.g. uses other items or abilities for their actions. You can add your custom settings, sections or sub-sections to the editor - ORK itself is implemented that way, since it's an extension for the Makinom editor. There's currently no documentation for that, but it'll come in the future (scripting with ORK/Makinom is somewhat of a niche topic, since most don't use it).

4) That's hard to say and mainly depends on the details. I'd say, most should be doable with schematics and extending the functionality - changing the source code shouldn't really be needed, unless you need to change something that can't be extended. E.g. adding a custom battle system doesn't require changing the source code, you can simply add your scripts to Unity and they're available in ORK.

5) Naturally, you can also do that - e.g. write your whole custom battle system not based on ORK, UI, etc. and just use ORK for the status system, item/ability setup for calculations, etc. If you're more of a programmer or already have a somewhat working system, it might even be the easier approach for you. E.g. using the combatants and items/abilities for the action calculations only requires a few lines of code.

6) Would probably also be possible, though I'm not sure how the card draw could work here ... unless you constantly switch out abilities (e.g. 3 abilities form a 'card' category, so you'd have to add/remove them as needed). ORK can add abilities as temporary abilities, which makes it easier to remove them in bulk (e.g. just removing all temporary abilities after a battle) - though you can also keep track of this via (global) selected data, where you store the items/abilities of a card in.

As for the system breakdown, yeah, that'll need some custom work - especially the attack preview. While ORK can preview status changes for actions (e.g. how much damage it'll make), previewing move patterns or cells like that isn't possible out of the box :)

polygonpro

Thank you very much for taking the time to answer my questions!

"You can add your custom settings, sections or sub-sections to the editor - ORK itself is implemented that way, since it's an extension for the Makinom editor. There's currently no documentation for that, but it'll come in the future (scripting with ORK/Makinom is somewhat of a niche topic, since most don't use it)."

I'll be looking forward to this documentation. :-)

I'm not much of a programmer, which is why I'm looking for ready-made systems like ORK, so I can do most of my development in the editor instead of with C#. But I understand that with a game as unique as the one I'm making, some specific features might require very specific custom work.

One thing I'm wondering, is if the UX of how I described the cards working - first choose a card, then choose an action for that card - makes the card system's implementation in ORK more complicated? What if I switched the order to be: the player first chooses an action, then chooses a card to perform that action? (I think ideally, I'd want the players to be able to do either way, as they prefer.)

Thank you again!

gamingislove

Switching the order would make it a lot easier - in that case you can simply set up different item types for the actions and each action can be an item (card).

That'd make it a regular 1 item 1 action kind of system.

polygonpro

In that case, would I need different versions of each card (different items) to represent each possible action?

What I'm understanding from my limited knowledge, is that it would be something like this:

Move (i.e. use move type item) -- Chain Slash (Chain Slash card Move variant item) -- Hurricane Kick (Hurricane Kick card Move variant item)
Attack (i.e. use attack type item) -- Chain Slash (Chain Slash card Attack variant item) -- Hurricane Kick (Hurricane Kick card Attack variant item)

etc...

And when a player draws a card from their deck, it needs to load the card's various corresponding variant items for each action type into the menus?

Is this what you are suggesting, or am I way off?

gamingislove

Yes, that's pretty much it.

polygonpro

Thank you again for your thorough and timely responses.

I wanted to let you know that I ended up buying the full version, and am now going through the tutorials.

gamingislove

Thanks for your purchase :) Let me know (or post in the forum) if you have any questions.

sivasilvan

ORK Framework 3 does sound impressive with all those glowing reviews and battle system variations. Your turn-based RPG concept with cards for actions sounds really innovative and strategic. However, I'm not entirely sure if ORK would seamlessly fit your unique mechanics. If you're still on the fence, I've got a suggestion. While I'm all for exploring different game development tools and frameworks, when it comes down to unwinding, solitaire is my reliable fallback. It's a classic that never fails to entertain, especially since you can play it online anytime.