I'm making this post because Action Graph is currently being depreciated and I earnestly believe this is a huge mistake.

For those who don't know, ActionGraph is planned to be removed and replaced entirely with Doo. You might not have known this (or even know what Doo is) because ActionGraph is currently listed on the s&box home page, and it says noting about being depreciated in the docs.

The intended replacement, Doo, has no dedicated documentation page and exists only on months old blogposts from before release.

So, before I get into the merits of why I think ActionGraph is worth the effort to keep, I want to say this communication sucks. People could be putting in a LOT of work with this system, all while not knowing it is planned to be removed. 

Now, onto the argument.

I have been working in s&box ever since I got access in 2021 and have 11 thousand hours clocked in on Steam.

I created Dark Descent, which I have been working on ever since the scene system first replaced the old Source 2 entity system.

So when I say that ActionGraph fulfills an extremely useful and powerful niche in game development, I would hope that it is at least worth hearing me out.

Firstly, I want to address some of the points Garry made when I asked him about why ActionGraph was being removed.

I know that taking the time to write up a response to some off-the-cuff discord messages is somewhat disingenuous. I am not necessarily fairly representing Garry's opinions and reasoning, but I want to try and give some tangible arguments for keeping ActionGraph, that address the concerns provided to me.

The argument is that actiongraph is over complicated for what it was intended for, and that Doo is more inline with what was intended out of the system. This may be true, but I do not believe that is actually a good reason to remove ActionGraph.

ActionGraph may have been intended to be something simpler but people found it incredibly powerful and useful. It could achieve a lot and so people wanted it to be fleshed out, requested features and ultimately explored what was even possible while using it.

From the moment ActionGraph was first implemented people were using it, something that has comparatively not happened with Doo.

The reasoning here is that ActionGraph is only being used because it exists and that it has limitations that people will be fighting.

When you have people engaging with a feature that strongly, I would argue that is a sign of its usefulness and potential.

Yes, people were using it in ways that were never intended, but people do that with literally any feature all the time. It is not a problem unique to ActionGraph and Doo is going to have the same issue.

I understand maintaining a complicated feature is annoying, and asking someone to do something complicated and annoying is doubly annoying, but I'm going to try anyway.

s&box is a game engine. The people actually making games in your engine were heavily using ActionGraph. Even people like me, a very competent programmer, were using ActionGraph. It is worth interrogating why that is the case, rather than dismissing it because it's not as nice as writing C#.

The reason I think is simple - ActionGraph is a game designers tool, not a programming replacement. It provides an incredibly powerful interfacing layer between the s&box editor and the underlying code.

In theory Doo offers the same benefits, but in reality, I think Doos usefulness is completely eclipsed by ActionGraph. I understand that ActionGraph is more complicated, bigger and harder to maintain, but I believe it is worth that extra effort. 

Again, s&box is a game engine. Why would you want to remove the things people are actually finding useful for making games?

I want to give some concrete examples here of how I use ActionGraph in Dark Descent in the hopes of making a more persuasive argument than just typing.

Here is a clip from my game Dark Descent:

So, pretty random clip right? I want to break down all the ways ActionGraph is used in this short clip to give you an idea of why I think it's so powerful and why I don't think it should be discarded so easily.

As the player is casting a spell, I use ActionGraph to scale the particle effect on their casting implement.
This action lives on the particle effects prefab, which is created when the player begins casting a spell.

I designed it this way, to use ActionGraph to be specific, for good reason! By using ActionGraph on the particle effect itself, I allow the effect to choose how it should behave during the casting animation.

Obviously, I could have written some code for this. I could have a class called ArcaneCastParticleComponent and have it implement the same functionality. But I have dozens of effects like this! I don't want to make a new class for every individual particle effect.

I created the system this way so that the designers, that is, people making the game in the editor, would be able to customize the individual effects however they want, without having to open a code editor.

So far, so simple. 

You can implement this functionality with Doo, but it sucks. It is clunky and unwieldy and even for something this simple it is tedious and frustrating.

When the spell Mage Armor is cast, you can see a post processing effect cover the screen momentarily. This is also implemented with ActionGraph.

When the Mage Armor spell is cast it applies the MageArmor status effect to the player. This status effect, then, applies the MageArmorApplied status effect upon its initial creation:

Now, when this new  MageArmorApplied status is added to the player, it creates a post processing prefab on the players camera.

As you can see, lots of random post processing effects all layed on there.
But I want the effect to be dynamic!

So, I have a component that runs an action every update (the Driver component) in order to scale each of these effects independently:

The driver argument here is just a normalized float of how long our post processing effect has left in its lifespan. So 1 -> 0, decaying as the effect ends.

This is pretty cool right? I've created a completely dynamic post processing effect entirely from generic components in the editor.

Again - I could use code for this, but there's a reason I didn't! The MageArmor spell alone has 4 separate post processing effects that all work similarly to this, but with different numbers, different effects and different scalings for those effects. I do not want to write a C# class for every new post processing effect.

You so far could also do this in Doo. But again, it's tedious.

The thunderwave spell also, similarly, has the same setup for its post processing after you cast the spell:

Cool. It's repeatable, extendible and useful. It's doing things I want. It's so powerful and so flexible, it informed how I even designed these systems in the first place.

In the clip the player is using the mage's staff:

Pretty complex effect right?

The whole thing is implemented with ActionGraph!  This one is a little more complex, so let me break it down.

On the staff is an enchantment prefab. It's fairly small:

But importantly, it's modular. You can just drag and drop this onto any melee weapon and it will work.

The meat of this set up is the conditional_incrementor:

This is what reacts to the player casting spells.

When we cast a spell, this action is run:

We check if the tier of the spell cast is above 0, and if it is, we increment our conditional counter.

This represents the "charges" the staff has.

When the conditional counter changes, another action is run on the conditional counter:

This is what is responsible for attaching our enchantment effect to the staff. It causes it to glow when it has charges, and removes the glow when the charges run out.

Finally, when the staff damages an enemy AND it has charges, another action is run:

 
We decrement our counter and restore our mana.

Awesome, cool, great.

Obviously, I know I could implement this in code. Of course I could, but there's a reason I chose not to. Being able to do ALL of this from the editor is incredibly powerful! I have been building Dark Descent with modding/addons in mind from the beginning. 

Having this level of power available to anyone using the editor, even if they've never touched code in their life, is awesome!

Dark Descent has dozens and dozens of particles, effects, items, weapons, enchantments, skills, that make use of ActionGraph in this way.  If I wanted to hard code all of these effects, I would be adding quite literally over 100 new C# classes to the project.

This is also the first example that literally cannot be done in Doo. You cannot do comparison checks in Doo. I would like to point out Doo was released over 4 months ago.

Do any of these examples only work solely because of action graph? No. I could replace it with code. I certainly will not be using Doo.

I am trying to hold back from ranting too much about Doo, but as someone who has been using ActionGraph extensively, it feels like such an unbelievable downgrade. It is infantile. It is inflexible. It sucks. It treats the people making games on your engine like a child.

Maybe ActionGraph isn't what you intended, maybe it got bigger than what you wanted, maybe it's overscoped, but so what?

Look at what it can be used for! That's incredible! Why are we evaluating this feature by some abstract ideal instead of just recognizing it for what it is? People aren't using it 'because it exists', they're using it because it solves problems and opens up design spaces.

I really truly feel like ActionGraph is one of the best parts of the engine. As someone who has been working in s&box for nearly 5 years at this point, and  as someone actually is making an honest attempt at a  game, a game with real content and real features, I think removing it would be a huge mistake.

I haven't even covered all the ways I use ActionGraph in Dark Descent, not even close. The Fighter class has over 30 unique skills, and nearly all of them were implemented using ActionGraph.

These are just a few examples.

The NPC system I wrote also heavily uses ActionGraph. For creating effects, triggering certain events, choosing what actions to take, etc. It's used all over the place.

Cleary I'm biased, clearly I have a lot of work tied up in ActionGraph. But the reason that work is there is because this feature is good. I never expected it to just get discarded.

I do not understand why I need to convince you to keep what I see as one of the best features. 

I think something that might be a solution for both parties is for Facepunch to convert Actiongraph to a library; or maybe even work with you to make a library version of Actiongraph that you're in charge of, as a fairly large figure in the community who feels most strongly about it and has a large amount of work tied up in it, which is one of the most impressive games on the platform.

Welp, that sucks.

ActionGraph is cool, but if its too unwieldy to maintain than I can understand from the FP team the WHY.

This is same situation as all other valve tools, they are getting deprecated with more "intuitive" solutions integrated into the engine.
About 2 months ago I told my team to REMAKE all maps from Hammer using Scene Hammer, no conversions or model porting. This was during the time that Hammer was having issues compiling.
Hammer bugs got to a point of a nonfunctional mess for workflows, so I turned to the future FP had set out for us and communicate with them on issues relating to Scene Hammer.

I'd say we've gotten far experimenting with Scene Hammer and scene tools in general:

This applies to a lot of other systems that FP wants to rework, I believe preservation is important for porting reasons and modernizing your project often is part of having it on the platform.
I decided and accepted a long time ago that S&Box IS NOT mature software and is bound to have massive issues. Going into projects with that mindset taught me to support long term solutions that have strong support of FP developers, kinda going with the flow of S&Box development as much as I can without massive friction.

You had made a decision to use ActionGraph just like I made the decision to use Hammer at the beginnings of our projects. It fucking sucks and results in many pain days but I believe its worth knowing the tech you have and try to adapt to events like this. FP made their decision and that isnt changing.

Hopefully you find the motivation to convert over your resources from ActionGraph to Doo or code...
and good luck, Fortune. Dark Descent is peak. ❤️

chneck out my playfund noob

I understand the frustration, because you've built so much around it already.

Doo isn't a failed version of Actiongraph, it's a refusal to become Actiongraph. It's wiring. I've said it before, lots and lots. Actiongraph was meant to be EntityIO. It was meant to be "when this happens, do this". It grew arms and legs and people started making games in it. It's not the best solution. Even for a designer it's not the best solution.

The fact is that I believe we can do better. We haven't done better yet. But basically this example you posted,

Is this

ChromaticAberration.Scale = t;
Vignette.Intensity = t;
ScreenOverlay.NormalBlend = t;
ScreenOverlay.Alpha = t; 

And I get that it feels great to define these things on resources and GameObject like you are, I get that this dynamic behaviour kicks ass.. but you can't get around the fact that it's horrible to use, and that we can do much much better here.

We don't have a solution yet, there's no ActionGraph escape hatch, I can appreciate that - it's why it still exists. I am sure that when we get there you will be happier. But I do know there is a better solution than this.

inline code in a field would be cool, i used actiongraph a lot for similar purposes in the past but stopped when talks were about deprecating it, i do miss it

I feel like we're letting perfect be the enemy of good here, but I want to believe you're right.

The only thing I'd consider an objective upgrade over action graph right now is if I could somehow write C# directly into my Action properties.

I know what you mean, and I agree. There is always room for improvement, but there is also a "good enough for now" too. My reason for liking visual scripting is that it makes sense to me as an artist. I can't really understand programming that well, but visual scripting helped me figure things out and was my go-to way for making games. Most Unreal Engine devs were able to make their games because of Blueprints and probably wouldn't be able to do it without it. I know that ActionGraph was never intended for making games in the first place; when you give restrictions, the first thing that people will do is break them. A good example of this is RPG Maker. People have constantly broken its limitations on what could be made in that engine. Why punish those that think outside the box? Should people just learn how to program? Yes, but opening up the game logic to non-programmers is a valuable thing too. Saying, "Just learn how to code" isn't really a good way to encourage people to do it. People normally don't like being told what to do by others anyway. Everyone will have different opinions and visions, but that's what makes us human. In the end, we all want what's best for S&box and for S&box to succeed. Whether there will be a better thing than Actiongraph or not is up to you. Another compromise can be to allow the community to make their own fork of Actiongraph as an addon/library. Thank you for reading this.

Writing a more flexible version of c# into an action is 100% the goal

That's a good compromise, I'd be fine with that.