General AC Best Practice/Strategy questions
Hi
I'd like to ask various Best Practice/Strategy questions WRT AC. That said, I realize you might not want to clutter the forums and/or are busy. If you would prefer me not to do this, thats completely fine (DM me)
Otherwise, I'll use this thread.
First: I'm porting an unfinished RPG that I created from scratch with Unity (which previously I created from scratch in C++/Monogame 
). I' m trying to strike a balance between using the power of ACs action lists to do things vs all through script.
For example: A NPC vendor sells Skills. Player chooses the party member to purchase the skill.
AC Implementation: Skill NPC with Hotspot, Subtitles to introduce what he sells, Conversation to select party member. Custom Actions to check party member status (dead, has skill), if party has gold, and ultimately grant skill with feedback to the player in subtitles. This works great. I used action lists assets as functions to avoid copy/paste of actions, but its also tending to get complex as Action lists dont support many programming concepts.
Given that brief back story, here is my first question:
Problem: How to sync code enums with variables in action lists.
Idea: Im considering doing this with a global popup "variable" to store enums. The GVar itself would likely never have a value. Label preset corresponds to an enum in script. For example, a preset for Skilltype, another for StatusType, etc.
The Label preset values match the order and values of the enum in script. I'll ensure they are kept in sync. I can then use action list parameters to pass in a Popup variable of label preset SkillType. IE, in the example, above a PopUp:SkillType variable could be used to pass in which skill to purchase and grant in an action list, or it could be supplied to a custom action that needs a skill.
This will work, but its also another layer of abstraction and a chance for bugs (proper use of the label number).
Does this make sense? it gives me (some) type safety in action lists.
Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Comments
The only way you could ensure type safety in that scenario would be to use custom Actions that reference the type explicitly.
That said, the alternative to using variables/enums for a skill system - if you wanted to use AC for it - would be to rely on Inventory items.
Items can be categorised and then filtered in Menus. You could, for example have "Regular", and "Skills" that show in different parts of your UI.
Items can also be given per-category Properties. These are treated much the same way as variables, only they can be modified from their default values on a per-item basis. You could, for example, have a "Skill level" int property that you can level up per-skill per-characer.
Hi Again
Another best practice question.
As I build more game and puzzle logic with action scripts I want to use sound programming patterns.
For example:
A torch can be on or off. Assume turning it on or off isn't as simple as hiding part of the game object (or I would just use that action). Perhaps turning the torch on or off requires changes to parts of its own hierarchy - for example Off still has a the smoke particle effect running, but not the flame, along with various other
"torch" things.
Then: I have puzzles that need to turn some torches on, some off, and toggle others. I quickly noticed I was copy pasting multiple actions multiple times each time I needed to turn a torch on.
My solution to this is to add three Hot Spot interactions setup in the torches hotspot: TurnOn, Turn Off and Toggle. Each call a corresponding action list asset to do that work, making use of SetInteraction and Component variables to pass information about the current torch instance into the action list(s).
Additionally, Toggle just checks the state and set params/runs the action list to TurnOn/Off - ie no logic is copy pasted or duplicated.
The torch also has a action list starter action list which also runs the correct on/off action lists based on the initial values/loaded serialized values.
Then, most importantly: Any scene based action list for - say a switch - can simply run the Hotspot:Run Interaction -> Use -> Toggle/TurnOn/Off to tell as many torches as it wants what to do (but the torch _knows _how to do it).
While it takes attention to setup correctly, once done this feels very clean to me.
It does have the limitation that you cant pass parameters to the target hotspot via Run Interaction, but that's ok (and I could probably use globals if I had to)
That big wall of text is just to get your opinion - does this approach make sense or would you suggest a different way? I feel this pattern could be used for many different 3 state objects.
Thanks!
PS: The architecture of how component variables and action lists and prefabs all work together - once I understood it - is very impressive. Id love to know how long it took you to come up with this design.
PPS: Setting multiple parameters on an action list and running it can be error prone. A single action to set a variable number of parameters and run, all at once might be nice. Probably tricky, especially given the parameters can come from so many sources.
I may not be picturing your setup exactly as it is, but from what I'm understanding - yes, sounds right. If you're using the full suite of Component variables, ActionList parameters, and helper components to compartmentalise logic, then that sounds all as intended.
Something of a hodgepodge of single ideas, user suggestions, and figuring out how to build upon an existing framework without breaking existing projects!
Sorry, I'm not quite following. Are you looking to assign parameters in bulk? The "ActionList: Run" Action lets you do that.
Sigh - No idea how I missed that option in the Run mode drop down - so much easier that setting parameters via multiple actions. Thank you!