Using Game Creator actions from C# ?

mode80 10 months ago in Game Creator updated by Marti (Lead Developer) 10 months ago 5

I really like Game Creator as a sort of "batteries included" toolbox that Unity never included. I like not having to implement stuff like "follow character" in code myself. 

However, I'm not sure I like coding in the inspector window. It's fine for triggering a simple list of actions. But as soon as you add one or two branching Conditions and Local Variables, it gets messy fast. All the tiny buttons, labels, check boxes, etc add up fast and I find it hard to sift through all that visual noise to find the actual "programmer intent" (even when the programmer was me!). 

I'm wondering if it's feasible to access all the wonderful Game Creator Actions from C#? This would be programming against the high level API from code instead of the editor. 

For example, if I wanted to create the simplest MonoBehaviour script that used GC's ActionDebugMessage to print "Hello World" to the console, what would that look like? 

My fear is that this would require so much boilerplate for every action that it might not be very elegant. But I hope I'm wrong!

Unity version:
2018 LTS
Game Creator version:

Hi Mode80. Unfortunately we didn't architecture Game Creator to be used as an API that can be both used in visual and non-visual mode. Actions can't (for now) be created at runtime. Agree that it would be ideal to do something like:


I think it's something we could explore for Game Creator 2.0. If you have a reference API that works like this, we're open to discuss it. Right now it's not possible due to how Unity keeps references to polymorphic array data, but this is changing in 2019.3 and we might be able to take advantage of this for the next big version.

Another topic we would like to start a discussion is what you call "visual noise". We feel the same way but haven't found a suitable solution that follows Unity's UI theme (very black and white with minimal color hues). If you stumble upon a design that would fit, please share it with us! We're actively looking for ways to improve this. The Conditions component is probably the one the least readable.

This might not be the best place to discuss this but we were thinking about experimenting with Conditions inside Actions, indenting a bit the Actions that are part of a Condition. But we're still unsure whether this is the right way or it will add even more noise.

Anyway, I'm just voicing thoughts at this point. Please, feel free to send us any suggestions or ideas you may have! Even if they seem crazy :-)

Ok, I'm glad you're thinking about it. I'd go as far to say that the UI is biggest limitation to using Game Creator to its fullest. There's so much great functionality available but the "complexity limit" of what I can achieve is mostly constrained by the UI. 

I've seriously considered implementing a minimalist "horizontal UI" to Game Creator myself. My vision for this is that any action, trigger or condition would be made to fit on a single line of a landscape editor pane. It would require an alternative OnInspectorGUI function which removes all the static labels and turns them into "tooltips" instead, or else default values within the entry boxes (e.g. [First Name Goes Here] ). In this UI mode, each action would take up the same amount of vertical space as a typical line of C# code -- an action/method name followed by input boxes for all its parameters on the same line. This is a lot more compact and can be surprisingly readable because you're able to focus on just the essentials. There would be no helpful labels, but the text from those could be just a tooltip away whenever things aren't obvious from context. 

This "minimalist horizontal UI" could exist as an optional alternative view to the verbose vertical layout we have now. That way new users don't find it more difficult to get started, but a lot more complexity could be tacked by switching to horizontal mode as needs for the game's functionality grow. The new UIElements API from Unity holds promise for implementing this without the nastiness of IMGUI. 

If a minimalist horizontal UI existed, I wouldn't feel a need to call Game Creator as an API from C#. I'd actually prefer not to. But if that idea still appeals to you, the clean way in which Game Flow implements "Direct Execution" seems ideal: https://docs.evasiongames.com/api/direct-execution

Hi mode80. Sorry for the late reply, this Black Friday has given us a lot of work. I'm struggling to imagine the horizontal UI. Since nodes have a small description, wouldn't that make the UI stretch too much? Vertical layouts are (in my opinion) more natural.

As for executing Actions using static methods, looks like a good idea. I'll investigate this! Thanks!

I opened a separate topic about this yesterday with some screenshots of my own attempt at this. 

My thought was to do away with the short description and just use the name of the action (even though I didn't get to doing that for my screenshots). 

The idea is to be intentionally minimalist. Show the action name (only), followed by the values of the parameters (only). Everything else could be made available via tooltips as needed. 

Verbose vertical layouts are fine for a very simple lists of actions. Beyond that I find the UI too unwieldy and there are projects I just won't attempt in Game Creator because of this. That's a shame because it is otherwise capable and offers so much.

If this doesn't feel worthwhile, I'd still be happy to see the Actions using static methods. That would in fact be the kind of minimalist horizontal UI I'm talking about -- except it would exist as code -- meaning fiddly syntax errors, switching back and forth to Visual Studio, and waiting for builds. 

I like the idea of having static methods that do what the Action's Execute method does. There are some caveats, such as that there are two methods for executing an Action: Execute and InstantExecute. One is a coroutine and the other one is not.

However, with GC 2.0 we plan to move away from coroutines and use the Thread class (despite not using multithreaded code), which would allow what you mention.

I'll circle back once I start working on this. I really like the idea.