Flow Graph is CRYENGINE's visual scripting interface, and it will be one of our primary tools for creating single player content in Sandbox. It is a powerful tool that offers a huge amount of control over the world, and it's easily possible to create interesting and flexible gameplay setups that respond believably to player interaction. Before we start scripting actual events, we are going to see how to create clean and flexible Flow Graphs that are easy to read, maintain, and iterate on as we develop our map. We will cover the following topics:
- Using Flow Graph containers
- Using Game Tokens to create cleaner Flow Graphs
- Laying out Flow Graphs to aid readability
- Thinking modularly to future-proof our work
When authoring any work in CRYENGINE, the resulting data has to be saved somewhere. In most cases when working with editor objects in Sandbox, this data is stored on entities: Flow Graphs are no exception. Every entity in Sandbox has a Flow Graph section in its RollupBar parameters, where you are able to host Flow Graph scripting on that entity. Here, we will cover good practices for creating these Flow Graph containers and how they can be used to organize your scripting.
For most projects, it's a good idea to store Flow Graphs on the FlowgraphEntity entities. This is to ensure that it's clear what the purpose of the entity is to you and others viewing the level; it can be easy to accidentally delete entire Flow Graphs if they are stored on unrelated entities such as triggers or characters. It also serves no function other than to host Flow Graphs, so it's a very lightweight entity and much cheaper than spawning other more featured entities in the world just to store scripting. Having them on their own bespoke entities and storing them in a safe place in the world keeps them separate and safe from everyday entity placement and deletion, while still preserving the ability to assign Flow Graphs to separate layers so as to allow multiuser editing of the level. To create a Flow Graph in this fashion, FlowgraphEntities can be found at RollupBar | Objects Tab | Entity | FlowgraphEntity. From here, simply press Create on the FlowgraphEntity entity's Flow Graph section, as shown in the following figure:
Tip
As we have covered in the past, layer data is simply XML. Flow Graph is no different, and the source data for the Flow Graph we make can be found on the layer that the container object is assigned to. This can be useful if you want to perform mass find and replace operations on a Flow Graph script outside of the Editor. It's also invaluable if the flownode information in the layer goes out of sync with what is defined in the code if programmers rename things, as you can simply hand-edit the XML to amend the names to the correct updated version.
In larger productions with multiple playable areas, mission objectives, checkpoints, and other types of logic, you can easily become bogged down in one vast script that's difficult to navigate. This practice also stores all your Flow Graph data on one entity, which makes working with multiple users in the same level difficult. As such, it can often be useful to split different types of Flow Graph logic up into multiple containers for easier editing. It's a good idea to take the large sections of logic that can be easily consolidated and store them on separate entities, which can then be assigned to different layers if you need to support multiuser editing.
For example, in the fishing village level, we have multiple action bubbles that stretch across one large space. This is already delineated nicely and would be a good way to approach splitting logic. We will later have additional logic such as checkpoints and objectives that span all action bubbles in the scope. An example of how to work with containers that fit the setup of this level is shown in the following screenshot:
As you can see, this puts the Action_Bubbles specific scripting in its own logic containers with other logic types that affect the whole mission stored in their own mission category. This is by no means the only way to organize levels, and it is very much governed by personal preference. But this gives an indication of the kind of organization that can be achieved with a few extra named containers within your level. Anyone editing the level will now be able to find exactly where logic pertaining to certain sections is without having to search through a mass of scripting.