As a 2018 summer holiday programming activity, I developed a programming flowchart tool that I’ll introduce in this blog post.

Application Brief

The flowchart tool, dubbed C#ffeeFlow / CoffeeFlow allows you to string together a set of methods and set a trigger for when these methods should be called consecutively. When loading the flowchart into an application you’re developing, you can fire these triggers and traverse through their related nodes. These nodes each link to a method in code and this method will be called with the correct parameters. The example in the video below is fairly simple, but in larger setups having a visual image of application flow and the ability to quickly alter this can prove to be meaningful and a big time-saver.

There are generally 3 steps to this application

  1. You open C# source files. These files will be parsed and nodes based on them will be dynamically generated.
  2. You create a flowchart by adding methods and variables from the C# file to the grid along with triggers when they should be fired.
  3. You save the flowchart to disk (as .XML) and traverse them in a different application, with the correct functions being called on the correct classes with the correct parameters. When you want to alter the flow, you open it up in the editor and make the changes you need.

As an example, we use Unity to showcase how this system could be used to globalize complex flows in a game into a single view that can be easily edited and adjusted, but as long as it’s C# it can be incorporated into any application:

 

Methodology

Originally I made a XAML code-behind node editor  (I’m sorry I was not good at blogging back then) during my game development course. However I was really unsatisfied with how it turned out. It would need a lot of work to be practical and even then, its use would still be limited. Due to exam time constraints, it had some really sloppy code and was difficult to use because there was lots of trouble with the grid navigation and node handling. I like tool development and WPF but I was ashamed to put something like that on my portfolio. I kept saying “I’ll get back to this and fix it” but never did… until now. For a week and half during the Summer holiday I completely refactored the project and made a lot of improvements, and really tried to make something that had basic functionality but done right and in an usable fashion, and which could show that I can work with WPF.

Code bases can become large and complex, code is all over the place and sometimes it’s hard to make changes or see the flow of what exactly is happening. While not fully replacing a code editor, the tool allows you to define complex behaviors in an easy and iterative fashion. With this tool you can configure and alter the flow of events and easily see what’s going on. It’s great for prototyping a puzzle game where you want to test out various situations for example. I personally made it because I felt Unity was inadequately equipped to handle RPG development where sometimes a large set of events had to be chained together. You might talk to an NPC, they might give you an item, a quest, the quest needs to open up a new area, the camera needs to pan to that area and then several NPCs need to change dialogue and behavior. Maybe there’s 50 such quest and doing this all in code is not fun if you want to rapidly iterate little changes to see what works best. This tool can provide a solution for that.

Instead of making a full visual code editor I wanted to enforce functionalization of code, but leave the order of these functions to the flowchart.  Similarly (although super basic here) I wanted the end user, who is a programmer, to be able to control how exactly the nodes are read. This gives a little more freedom and ensures the tool can be used and adapted to many scenarios. Want to add a delay to when every function is called? Want to link it up to an UI and step through it with buttons? You can!

Technicalities

The editor is made with WPF in C#. My original aim was to closely link it to Unity, but I also wanted to do something in WPF and show that I can work with that. It might be a bit sadistic to not design this node editor within Unity itself. However, doing it like this allows for wider use beyond game engines like Unity.

I’ve tried to adhere to the model-view-viewmodel principle and used databinding and custom controls extensively to create this tool. The cool thing about it is that it inputs code, analyzes it and then dynamically create nodes corresponding to the C# method and its parameters to use on the grid. Simple values like text and floats can be edited, while complex objects (such as Vector3/GameObject can be linked to an existing variable). The system keeps track from which C# class these things belong to, and when traversing the flowchart in your own application, the correct methods are called with the right parameters and variables. To parse C#, Roslyn was used and to call the methods after they’ve been saved to XML, standard Reflection was used.

Using WPF and its many systems was interesting but also challenging at times. I like the whole concept of separating data from logic and using the MVVM pattern and databinding/commands and it definitely allows for some powerful features, it also was a pain to rapidly iterate and make changes sometimes. I think the framework works best if you’re working with multiple people on one project, but not when it’s just me that’s constantly jumping between all the files to make changes.

I’m really happy how the application turned out in a relatively short amount of time, I reacquired my WPF skills a little and it’s finally a tool that I’m a little proud of. I put a focus on usability and customer experience and when I compare it with my tool development exam from several years ago, it’s quite the improvement. I’ve also learned a lot about how to approach projects like that and its sometimes peculiar bugs and oddities. There’s still some smaller usability features left such as node grouping and filtering the display of certain classes. I also think it would be cool to have a tighter link with Unity or UnrealEngine and allow for more programming operations (such as creating new variables, calling custom Unity methods,…). Maybe I’ll slowly try to implement these things later down the line.

The tool is open-source and can be used, the code inspected and altered for non-commercial use. It offers basic but powerful functionality that can be expanded upon in the future. It can be found over at Github. The project itself contains the editor code, a DLL library to handle parsing and example code files for Unity that deal with traversal of this flowchart as well as a barebones event manager that can be used as a starting point in game development with Unity.