[FEATURE] Trying to actually create logic with atoms in the editor is a nightmare
lgarczyn opened this issue · comments
A simple preface, I'm sorry if this message sounds aggressive. I want to love atoms. But I don't feel like I understand the philosophy.
Is your feature request related to a problem? Please describe.
Let's say I want my game to have 4 states, play, pause, won and lost.
The goal is to enable and disable 3 UI elements (pause, won, and lost)
So I need 3 bool variables (pause, won, lost)
And then I need 3 events, for each
And "UserPressedPause" and "UserPressedNextScene" events, because there's no link to the input system.
But I don't want to be able to pause during win or lost screen, so I need to filter out the events
I create 4 BoolCondition, instances of a custom BoolCondition script, to only pass the "User pressed escape" when the game is neither in neither won nor lost. And to check that you can't win once you've lost, and can't lose once you win.
=> IsWonTrue IsWonFalse IsLostTrue IsLostFalse
And a TimeScale.cs var, because that's not included.
And a custom changesceneaction, because the changesceneaction does not actually offer any out-of-the-box usage that I can find.
And a ToggleBoolVar scripts, because there's no way to toggle the vars from a unityevent
And a CheckWinState because I gave up on checking through the editor, and instead check through scripts with references to the vars.
In the end I have 9 scripts and 13 assets, to do what could be done in a single scripts and the 3 vars I started with.
I also got quite a lot of nasty surprises, like event replay on adding a listener, which I think is fired except for void events? Or was it? It's not mentioned in the docs for sure.
Another example!
I want to make an FOV system. The fov has a base setting, a user setting. It's affected by speed and overriden by weapon zoom.
9 assets ! Three scripts ! Absolutely no support for any kind of FloatMixer, or updating a var from different source.
Simply applying an AnimationCurve to a value and re-emitting it sounds simple. No support.
Want to make a var simply be a transformed version of another var ? You better believe you need scripts and assets. And those scripts better be monobehaviours, because listeners that live in assets? Who would need that?
All of this with a cool half hour searching through a maze of a type system. No I don't care about the touchscreen support.
And refactoring! Not only moving to the var system is difficult (no implicit casting of the vars to their value), but changing the type of an event is quite difficult without losing all references.
Describe the solution you'd like
I love atoms in one single case. Linking scripts in different prefabs, and storing basic settings. Any interaction between atoms requires absurd amounts of boilerplate. Actions, Functions, Conditions are mostly useless to me.
I want to understand if I'm missing a core element, if I'm just suppose to accept the bloat, if there was a simple solution all along, if I just suck at Data-drive design.
Describe alternatives you've considered
Right now I'll very much just stick to vars. Vars are cool. I mostly understand them I think.
In the end I have 9 scripts and 13 assets, to do what could be done in a single scripts and the 3 vars I started with.
Then you obviously used the wrong approach.
I don't feel like I understand the philosophy.
I think you're right. You need to understand that atoms IS NOT a VisualScripting framework. While it has some features which allow you to do similar things: it is not.
That's really crucial to understand in my opinion.
Next thing is: UnityAtoms is a tool. It has it's use cases, but you should NEVER try to do everything with it. Be pragmatic, sticking to it like a dogma won't give you any benefits.
What is UnityAtoms about? Well, if you consider the talk from Ryan Hipple it's about modularity. Does your example require any modularity? No, No it does not. Everything in your example lives in the same scene, so you don't need cross scene references. All the buttons and so on are within the same UI so you don't even need cross-object references.
There are no real singletons involved which is one use case of scriptable object architecture, except for the game states you mentioned. for that Atoms provides a FSM implementation. So all your scripts can work - across scenes/objects/prefabs - on the same global state - if necessary, without introducing a singleton.
if I'm just suppose to accept the bloat, if there was a simple solution all along,
no, bloat is not acceptable. if you find yourself creating bloat it's probably the wrong approach you're taking.
Nobody is forcing you to do EVERYTHING with atoms.
if you need a float mixer variable.... just create a FloatMixer type, generate a variable from it and use it in your scripts. 1(+1 generated) script, 1 asset. Nobody forces you to create 8-9 scripts for that.
I personally nearly never use any AtomEvents but stick mostly to pure Variable approaches. And only where I actually need them.
no implicit casting of the vars to their value
you might want to use References, instead of using vars directly. That's kinda a core concept of atoms. (Also highlighted in Ryan Hipples talk, and our docs)
if I just suck at Data-drive design.
if you think working with atoms adheres to data driven design, then: yes. Atoms has nothing to do with data driven design and I'm not sure what makes you think it would.
This is not really an issue, and would've been great in the discussions tab.
Yes one could argue that Atoms has trouble finding it's own philosophy and sticking to it and I would absolutely agree with it. There is a lot of things in it that address super specific use cases or shouldn't be used extensively or teach things I personally consider anti-patterns.
Also you're right: the documentation could be improved.
But what I don't understand: if you already have a simple solution ... why are you trying to force it into a shape that fits along with atoms. Not every problem is a nail, sometimes you don't need to use a hammer.
This is pretty much the answer I expected by the time I was done writing. Thanks for taking the time, I should have posted this somewhere else.
I think you're right. You need to understand that atoms IS NOT a VisualScripting framework
Yes, I've figured that part out by the end. But the examples and the presentation can lead to that belief, actions and conditions would fit the visual scripting pattern well.
talk from Ryan Hipple
That's what sent me here, like most people I think. And he's the one to mention data-driven design, where a designer can pop in and change a lot of the general behavior, on a meta level. He also pushed for adding modularity where it is not originally needed, to allow emergent design. In the end my solution did allow for handling the final win screen with no extra code, so point to atoms here.
References
Thanks, I don't know why I skipped over this
FSM
Will try next time I need actual states, it does make a lot more sense.
Yes one could argue that Atoms has trouble finding it's own philosophy and sticking to it and I would absolutely agree with it. There is a lot of things in it that address super specific use cases or shouldn't be used extensively or teach things I personally consider anti-patterns.
I think instead of realizing that, I thought that there was supposed to be an over-arching design philosophy that used all of these elements, and I just couldn't figure it out. Which led to frustration.
[Ryan Hipple is] the one to mention data-driven design,
Yes he mentions making your games data-driven. But that's not what the talk is about.
where a designer can pop in and change a lot of the general behavior, on a meta level
he calls that "emergent design".
He also pushed for adding modularity where it is not originally needed, to allow emergent design.
At the end of the day, you're making a game. If you have 3 buttons and each of the buttons gets it's own variable, event, .... stuff that is named after this button, is it become more modular? no, it's not.
If your feature needs 3 buttons, there is no benefit in making every button as modular as possible. YAGNI and KISS coming to my mind.
I think instead of realizing that, I thought that there was supposed to be an over-arching design philosophy that used all of these elements, and I just couldn't figure it out. Which led to frustration.
I'm sorry there is no well rounded framework philosophy that spans across all the features. When those Scriptable Object Architectures arose several years ago there was also a lot of hype and it is a grown community project. I'd do things differently today.
Duly noted, thanks for all the info. I kinda wish Ryan would have released their library, but I guess there wouldn't be so many options now