This feature is still in beta and subject to constant change. We encourage you to use it in test projects and provide your feedback to us.
However, DO NOT use it in production where it creates dependencies! Always back up your projects to make sure that you can go back to a previous version.
The primary goal of Schematyc is to change the way we build gameplay systems at Crytek, giving designers the power to construct new and reusable objects from a set of building blocks provided by programmers. At first glance, the editor looks a little like Flow Graph, but the two systems were built with very different purposes in mind. Whereas Flow Graphs are great for level scripting, Schematyc is designed to provide a finite control of the objects within those levels.
Visual scripting tools let you script your own logic. State machines help to break up and structure logic, making objects easier to debug and simplifying the process of network synchronization. Determinism and reduced latency make it possible to take new gameplay systems beyond the prototyping stage without the need to re-write them in C++.
Context is king in Schematyc and our aim is to only present users with relevant information, keeping the UI from becoming too cluttered and overwhelming.
For more information on the Schematyc Editor, please refer here: Schematyc Editor
The basic concepts you need to understand before using Schematyc are:
In addition to more traditional logic graphs for visual scripting, Schematyc also introduces the concept of a transition graph. This is where we control how and when you switch from one state to another. It is impossible to trigger transitions from anywhere else and while this may not seem quite as convenient as simply being able to link up a 'switch state' node, it makes it much easier to view the overall picture and track down issues when designs become more complex.
Two of the biggest issues we run into when scripting in Flow Graph are latency and lack of determinism. Because the flow is determined on a per-node input/output basis and programmers can implement new nodes in pretty much any way they like, it is difficult (sometimes impossible) to predict the order in which nodes will be called and perhaps more importantly, when a node will be called. This problem becomes particularly troublesome when evaluating transitions for a state machine because if you don't get an immediate response you have to defer evaluation until one or two frames later, by which time previously evaluated conditions may no longer be valid.
Schematyc solves these issues by creating a clear distinction between nodes that can trigger scripted logic and nodes that are part of scripted logic. The flow of execution must be defined explicitly and any nodes not part of the execution path will be grayed out to indicate that they will never be called.
With Schematyc 5.4 we introduce two types of Schematyc assets.
There are two ways to create a Schematyc Asset. You can go through the Asset Browser or do it in Schematyc.
Content can be added through the Add menu right to Search bar. It can be seen as the context menu of the whole object and therefore adds new items on the top level of the object.
Child content can be added through the item context menu:
For a series of videos about Schematic, follow this link.