This looks really interesting! What I'm not clear on is, what does this fix or make easier? I'm not trying to give you a hard time, I'm a newbie with Unity, so everything is hard for me right now, but I'm also a programmer by trade too, so working with statefull systems and normal programming metaphors aren't foreign to me, either. So I guess I don't know what the hard parts are that need to be fixed yet.
6 years ago(+1)
I think it's the visual programming environment, similar to Construct, GDevelop and Clickteam Fusion. At least that's what it looks to me like.
As Dariusz mentioned, it is a visual scripting tool at its core. CAT runs within the Unity3D editor. I'm not familiar with the examples Dariusz mentioned, but with CAT comes with a set of Conditions, Actions, and Triggers that you can assemble like building blocks to make your game. Unlike a lot of other visual scripting systems, it doesn't use a node based flow graph as those tend to turn into a mess of spaghetti once you try to do anything complicated. It also works with higher level building blocks, so you aren't just using Unity's C# API in visual form.
CAT also includes several game systems (and more will be included in the future through updates and add-ons). These systems work with the Conditions, Actions, and Triggers to amplify their usefulness. For example, it includes a quest / mission system, and you define each quest step using one or more Triggers. Triggers in CAT listen for some state to change (like the player colliding with an enemy) and then they fire. So, for example, you might use a Proximity Trigger in a quest step in order to complete the step when the player reaches some area of the game.
As a programmer, I find CAT makes code I write much more reusable. Once you get the hang of it, if you need to create a custom Condition, Action, or Trigger, it's pretty easy to make one that's fairly widely applicable. I'd also say that one place where it really does shine is when building new systems around CAT or integrating existing ones with it. Say you wanted to integrate some specific analytics package. You might just have to write one short Action which fires off a configurable analytics event, and then you could insert that anywhere that Actions were allowed.
Prototyping, iteration, and content generation are also much faster with CAT. These are the main reasons we built it originally. We needed some way to meet some insane deadlines and this was our answer. Anyway, I'm happy to go into more detail if you're interested!
6 years ago(+1)
based on what you've described, it sounds like you've mashed up more traditional model-driven design and Scratch, as a direct competitor to the blueprint/flowchart thing that Unity does. THAT IS SO INTERESTING PLEASE CONTINUE TO NERD OUT AT LENGTH OVER THIS IF YOU PLEASE THANK YOU :)
6 years ago(+1)
Scratch is a bit similar, yeah. We tried to use higher level building blocks so that you have to use less of them. As an example, here's all there is to the player controlled paddle in our Pong clone example:
So, it's a State Machine with two states: Reset and Playing. The initial / default state is Reset. In the Reset State, all it does is move the paddle instantly to its starting position and then change state to Playing. In Playing, there's just a single Move Action which follows the mouse continuously on the Y axis. That's it! Pretty simple.
You can definitely do more complex things. On another thread, I went through the Pursue state on the enemy NPC in our RPG example. That NPC has a pretty standard enemy AI. It normally patrols around a specific area. If the player comes within range, it switches to its Pursue state where it paths toward the player. Once it gets in melee range, it switches to the Attack state and keeps attacking the player. If the player moves out of melee range, it goes back to Pursue, and if they successfully run far enough away, it returns to patrolling. Pretty standard stuff and very easy to build in CAT.