Visual Informatics 5 (2021) 20–25

Contents lists available at ScienceDirect

Visual Informatics
journal homepage: www.elsevier.com/locate/visinf

Asyncflow: A visual programming tool for game artificial intelligence

∗
Zhipeng Hu a,b , , Changjie Fan b , Qiwei Zheng b , Wei Wu b , Bai Liu b
a
College of Computer Science and Technology, Zhejiang University, China
b
NetEase Inc., Hangzhou, China

article info a b s t r a c t

Article history: Visual programming tools are widely applied in the game industry to assist game designers in
Received 7 September 2021 developing game artificial intelligence (game AI) and gameplay. However, testing multiple game
Received in revised form 4 November 2021 engines is a time-consuming operation, which degrades development efficiency. To provide an
Accepted 4 November 2021
asynchronous platform for game designers, this paper introduces Asyncflow, an open-source visual
Available online 19 November 2021
programming solution. It consists of a flowchart maker for game logic explanation and a runtime
Keywords: framework integrating an asynchronous mechanism based on an event-driven architecture. Asyncflow
Visual programming supports multiple programming languages and can be easily embedded in various game engines to
Flowchart run flowcharts created by game designers.
Game Artificial Intelligence © 2021 The Authors. Published by Elsevier B.V. on behalf of Zhejiang University and Zhejiang University
Press Co. Ltd. This is an open access article under the CC BY-NC-ND license
(http://creativecommons.org/licenses/by-nc-nd/4.0/).

1. Introduction
Game AI is the intelligence behaviors of non-player characters
(NPCs) in the game. Most games use rule-based AI written by
game designers. During the development of the game industry,
multiple rule-based game AI programming architectures, such
as finite-state machine (Wagner, 2006), hierarchical-state ma-
chine (Girault et al., 1999) and behavior tree (Sekhavat, 2017)
have been proposed by developers to handle complex rules of
game AI. Meanwhile, numerous visual programming tools have
been developed to help game designers with limited program-
ming skills create rule-based game AI and gameplay (the rules
of interaction between player and game) through graphical user
interfaces.
However, the codes generated by existing tools can only be
used in game projects developed by their respective engines. For
example, Unity Visual Scripting 1 is designed only for the game en-
gine Unity. Behaviac 2 is a full-platform solution that supports C++
and C# languages, but most game servers use script languages
like Lua. Therefore, a full-platform visual programming tool that
supports more programming languages will be helpful for game
development.
Visual programming tools are used to combine game actions
into game AI. Most game actions are durative and will last a
∗ Corresponding author at: NetEase Inc., Hangzhou, China.
E-mail addresses: zphu@corp.netease.com (Z. Hu),
fanchangjie@corp.netease.com (C. Fan), hzzhengqiwei@corp.netease.com
(Q. Zheng), wuwei02@corp.netease.com (W. Wu), hzliubai@corp.netease.com
(B. Liu).
1 https://unity.com/cn/products/unity-visual-scripting.
2 https://github.com/Tencent/behaviac.
few seconds or longer, like walking from one place to another.
Game engines usually use a main loop to drive the game logic
frame by frame and the execution of durative actions will be split
into each frame. Visual programming tools need to simplify this
operation so that game designers do not need to pay attention
to the implementation details. Behaviac provides a special action
node with running status to implement durative actions. In each
frame, the action node will execute a part of the overall action
and be set to the running state, then other game logic can be
executed in the same frame. In each frame, Behaviac will check
whether these action nodes have finished running, which is a
polling-based method. In addition, an event-driven method can
also implement these action nodes, and it will be more efficient.
But there is no visual programming tool that uses an event-driven
method for now.
In this paper, we propose Asyncflow,3 a flowchart-based vi-
sual programming solution, which can support interactively de-
sign and inspect execution of game AI and gameplay very well.
Asyncflow integrates a universal runtime framework and various
nodes are compatible in the flowchart. Especially, event nodes
allow asynchronous logic in game AI to avoid blocking of durative
game actions. In summary, the contributions of this paper include
the following:
• We develop Asyncflow, an interface that supports visual
programming for development of game AI and gameplay
through the flowchart maker.
• We propose a runtime framework to manage the operation
of game AI, which breaks limitations of game AI codes on
specific engines.
3 See https://github.com/fuxi-asyncflow/asyncflow/ for details.

https://doi.org/10.1016/j.visinf.2021.11.001
2468-502X/© 2021 The Authors. Published by Elsevier B.V. on behalf of Zhejiang University and Zhejiang University Press Co. Ltd. This is an open access article under the
CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/).
Z. Hu, C. Fan, Q. Zheng et al.
• We use the runtime framework based on an event-driven
architecture to enable the nodes of the flowchart to be
executed asynchronously.
2. Related work
2.1. Flowchart application and interactive construction
Flowchart is extensively used to describe neural networks
(Kahng et al., 2017) and explain event sequences (Gotz and
Stavropoulos, 2014). TensorFlow Graph Visualizer (Wongsupha-
sawat et al., 2018) generates clustered graphs to summarize data
flow in neural networks. The compact flow representations sup-
port users to explore complicated model structures interactively.
Similarly, EventThread (Guo et al., 2017) extracts event flows by
clustering event sequences, from which evolution patterns can be
observed.
To support flowchart applications, related researchers and
developers put emphasis on interactive flowchart construction.
Microsoft’s visio4 provides different styles and types of nodes for
users, who can use the mouse to adjust the position of the nodes
flexibly to achieve a good layout effect. Open-source software
Graphviz (Ellson et al., 2001) automatically draws a flowchart
by reading a file in DOT format. The style of the nodes in the
flowchart needs to be defined in the DOT file. The flowchart
drawn by Graphviz is automatically laid out. Normally, it can
provide a good layout result, but if the drawing effect is not the
same as expected, making adjustments is very troublesome. In
the low-code platform Qingzhou5 of NetEase, the business process
of an enterprise can be drawn with a standardized flowchart
model based on the Business Process Model and Notation 2.0, and
enterprise resource planning (ERP) applications can be quickly
customized. In recent years, several companies have begun to
build platforms for running constructed flowcharts. For instance,
Microsoft’s Power Automate (Pearson et al., 2020) corresponds
nodes in flowcharts to operations or services.
2.2. Visual programming
Visual programming was first used in programming teach-
ing. Charntaweekhun and Wangsiripitak (2006) found that most
students were more willing to accept flowcharts as the car-
rier of programming instead of writing codes directly. There-
fore, they implemented a system that converts flowcharts into
executable codes. The logical judgment and sequence in the
codes are visually represented by the flowchart. RAPTOR (Carlisle
et al., 2004) is a programming environment specially designed
for students. Students can use RAPTOR to implement visual pro-
gramming by drawing flowcharts and class diagrams of Unified
Modeling Language. Yuan et al. (2008) identified the flowchart
sketch on the electronic whiteboard during programming teach-
ing and finally transformed it into a standard C language program.
Massachusetts Institute of Technology’s public project Scratch
(Resnick et al., 2009) can be applied to build programs like
building blocks.
To benefit from functions, like structure explanation and live
programming, visual programming is used in other scenarios. To
facilitate data wrangling, Wrex (Drosos et al., 2020) provided
users with visual examples during manual programming. Re-
sult verification can benefit from intuitive data representation.
Moreover, juxtaposing source codes and corresponding output
can assist code evaluation (Wood et al., 2018). Vis-a-Vis (Bolte
and Bruckner, 2020) can track output evolution during coding
4 https://www.microsoft.com/en-us/microsoft-365/visio/flowchart-software.
5 https://sf.163.com/product/lcap.
21
Visual Informatics 5 (2021) 20–25
optimization. Users can determine whether the modification is
necessary by comparing the outputs before and after code modi-
fication.
Game developers also have an urgent need to perform coding
tasks by visual programming. Several visual programming tools
create and express complex AI logic through visual graphic ele-
ments for game AI design. After classifying and layering states, the
hierarchical-state machine can clearly represent the structure of
massive states in game AI. Besides, the behavior tree manages the
logic modules through a tree structure. When the state is more
complex, the behavior tree is more conducive to maintaining
the behavior of roles than the traditional finite-state machine.
Topiary (Shoulson et al., 2011) support the flexible generation of
behavior tree through parameters specification. Unreal Engine 4
provides a visual programming tool Blueprints,6 which is widely
used in game development projects. It can implement all the
functions that need to be written in C++ before. Similar tools
are widely used in other industries. For example, aflak (Boussejra
et al., 2019) is a visual programming tool for astronomy data.
3. The flowchart maker
In order to help game designers easily convert their ideas into
executable codes, we provide a flowchart-based flowcharts maker
(as illustrated in Fig. 1). The conceptual model it uses is very con-
sistent with the conceptual model in game AI development; thus,
it greatly reduces the difficulty of game AI development. Through
special event nodes and timer nodes, the asynchronous opera-
tion of the process is implemented in an event-driven method,
avoiding the blocking phenomenon in the game, which is where
Asyncflow gets its name. The nodes in our flowchart are divided
into four types of nodes, namely, normal node, event node, timer
node, and control node. Details of these nodes and the lines
between them are as follows.
3.1. Normal node
Normal nodes are the most widely used nodes in Asyncflow
flowcharts (as illustrated in Fig. 2). Their content is a piece of code
expression, which can play two roles. Firstly, it performs several
calculation operations to determine the subsequent running child
nodes (see a in Fig. 2). Secondly, it serves as an interface to control
the behavior of the game object (see c in Fig. 2). Game objects
usually refer to some particular objects or elements in the game,
like characters, weapons and ambient objects.
The operations of normal nodes are independent. If the results
in one node need to be used in other nodes, then the internal
variables of the flowchart need to be used. The declaration (see
b in Fig. 2) and use (see d in Fig. 2) of these variables are limited
to the current flowchart.
The syntax of the expressions in the node is similar to Lua,
but the flowchart maker performs strict type checking and fi-
nally generates the function codes of the programming language
supported by Asyncflow.
3.2. Line
The directed lines are used to indicate the sequence of node
operation as well as to clarify the operating conditions of the
nodes. Three types of lines are distinguished by red, green and
blue colors. The normal node in the flowchart returns a Boolean
result after running. If the result is True, then the node connected
by the green line will be run; otherwise, the node connected
6 https://docs.unrealengine.com/4.27/en-US/ProgrammingAndScripting/
Blueprints/.
Z. Hu, C. Fan, Q. Zheng et al.
Fig. 1. The interface of flowchart maker. The main area is used to draw flowcharts. The left side is used to display the node types provided by Asyncflow, and the
lower left lists the game types that can be used in the flowchart maker. At the bottom is the output bar, which is used to display the output information. The right
side is used to display and edit some data information of the node.
Fig. 2. Examples of normal nodes. (a) Game function call. (b) Declaration of
variable. (c) Behavior of the game object. (d) Use of variable.
by the red line will be run; the node connected by the blue
line continues to be run regardless of the result. The number
of lines connected to and from each node has no limit. If a
node has multiple successor nodes, then the nodes that meet
the conditions will be run from left to right. This process occurs
within a game frame. Hence, from a macro perspective, these
nodes can be regarded as being executed concurrently.
3.3. Event node
An event node is a special node provided by the flowchart.
Event nodes are used to implement durative actions in the game,
such as a game object walking to a specified location, or behav-
iors that require specific trigger conditions, such as attacking an
enemy when the enemy enters the field of view. A polling-based
solution is to check the state of the game object in every frame of
the game (see a in Fig. 3), and then execute the subsequent code
when the condition is met.
In Asyncflow, the use of event nodes in the flowchart can
clearly achieve these requirements (see b in Fig. 3). When the
flowchart runs to an event node, the node enters the waiting
state, and then advances to run other normal nodes. Once the
specified game object generates an event of the corresponding
type, the event node is activated and then runs down, which is
more efficient than many checks and judgments in each frame.
The event type in Asyncflow can be freely defined by the user,
and each event includes a name and an arbitrary number of
parameters. These parameters can be used to transfer some state
22
Visual Informatics 5 (2021) 20–25
Fig. 3. Comparison between polling-based (a) and event-based (b) solution of
event nodes.
information when the event occurs, and they can be obtained and
used in subsequent nodes of the event node.
3.4. Timer node
The timer node only needs to set one parameter, which is the
waiting time of the timer. Similar to the event node, when the
timer node is executed, it enters the waiting state. It reactivates
and continues to run subsequent nodes only when the waiting
time has elapsed. When the timer nodes and event nodes are
running, they switch to other normal nodes to continue running.
Until their running ends, Asyncflow will return and run their
subsequent nodes. This behavior is very similar to the concept
of asynchronous programming. Thus, it is called an asynchronous
node in Asyncflow, and it is distinguished from normal nodes by
a different color.
3.5. Control node
Asyncflow also provides several nodes that change the running
flow of the flowchart, called control nodes. Control nodes can be
further divided into:
• StopNode can be used to cancel an asynchronous node in a
waiting state.
Z. Hu, C. Fan, Q. Zheng et al. Visual Informatics 5 (2021) 20–25

• WaitAll node continues to run after all its parent nodes are
running.
• WaitAny node continues to run if at least one parent node
is running; it only runs once if multiple parent nodes are
running.
These nodes make the flow of the flowchart more flexible and
allow for easier implementation of complex game logic.

3.6. Layout

Usually, when drawing a flowchart, the position of the node is

manually placed by dragging the components. When the
flowchart contains numerous nodes, such manual operation
would be laborious. Existing automatic layout algorithms based
on the Sugiyama method (Sugiyama et al., 1981) usually arrange
nodes from left to right for aesthetic requirements, resulting in
low robustness to the modifications.
Asyncflow uses a combination of global manual layout and
local automatic layout to solve layout difficulties. The user can
combine several nodes into a group, and the nodes inside can be
set to automatic layout. The position of the group and other nodes
can be flexibly adjusted by the user.
Fig. 4. Framework of Asyncflow Manager.
4. The Asyncflow runtime

Asyncflow is designed to be independent of the game engines.

Thus it can be used in games developed by different engines. This
goal is achieved through a runtime framework written by C++ and
exported to Lua, Python or C#. Asyncflow also provides generators
to convert flowcharts to the above programming languages. They
can be executed by the corresponding runtime embedded in
game engines. Therefore flowcharts can be migrated in different
games developed by different engines. For example, flowcharts
written for the personal computer (PC) game Justice Online7 de-
veloped by a custom game engine can be used in its mobile
version which is developed by Unity engine. It greatly improves
the efficiency of game development.
Asyncflow controls game objects in a non-intrusive way with-
out modifying the codes of game objects. Some classes are pro-
vided in Asyncflow runtime such as Agent, Chart, ChartData, etc.
Agent is the agent of game object in Asyncflow. The flowchart
will be transformed into a Chart instance and attached to an
Agent object to control its behavior. All of them are managed by
Manager (as illustrated in Fig. 4), which contains the following
modules:
• AgentManager manages the relationship between Agent and
game object. Agent includes the event nodes, the timer they
are waiting and the Charts they load.
• EventManager manages an Event Queue and all event infor-
mation in the game.
• ChartDataManager manages ChartData, which is the infor-
mation obtained by parsing the flowcharts made by the
maker.
• TimerManager schedules the timers of all Agents.
• Executor manages the execution of the running flowchart.
4.1. Agent and AgentManager
When each game object is registered in the Asyncflow runtime,
a corresponding Agent object is generated, and their relation-
ship is managed by AgentManager. When the game developer
performs flowchart-related operations on the game object, it
does not modify it. All operations take place on Agent, which
implements the decoupling between the flowchart and game.
7 https://n.163.com.
23
4.2. Chart, ChartData and ChartDataManager
After the flowchart is read by the runtime, the ChartData-
Manager generates the corresponding ChartData. When attaching
a flowchart to the game object, ChartData is obtained by the
name of the flowchart, and then a Chart is created and added
to the Agent corresponding to the game object. In Asyncflow,
multiple flowcharts can be mounted on a game object, and these
flowcharts collectively control the behavior of the game object.
Having multiple objects attached to the same flowchart is also
possible. Thus, they will have the same behavior.
4.3. Timer and TimerManager
A timer system is maintained in Asyncflow runtime, and the
said timer node will be added to TimerManager whenever it is
executed. Charts of the Agent could contain several timers. The
time in TimerManager does not use a real-world clock, but it is
advanced by the game. In this way, when TimerManager advances
faster than the real-time changes, it can speed up the operation.
This design is very useful for game testing.
4.4. Event, Event Queue and EventManager
The Asyncflow runtime framework adopts an event-based
asynchronous pattern to manage the operation of nodes. All event
information and processing are managed by EventManager. When
an event node is running, it is added to the waiting queue of
its Agent corresponding to the event. When an event occurs in
the game, it is placed in the Event Queue. In each frame, the
EventManager notifies the corresponding Agent of the event in the
current Event Queue. Two event queues are maintained in Event
Queue. One is the event currently being processed, the other is
the event that is newly generated in saving and processing. These
events will be processed in the next frame. This setup can avoid
the infinite loop of runtime caused by the durative generation of
new events during event processing, which causes the game to
freeze.
Z. Hu, C. Fan, Q. Zheng et al.
Table 1
Usage comparison among four visual programming tools.
Tools↓\Performance → Supported engines
Asyncflow Cross-platform
Blueprints Unreal
Behaviac Cross-platform
Behavior Designer Unity
Fig. 5. Node running flow of runtime framework.
4.5. Executor
The execution of flowchart nodes is completed in Executor, and
the running framework can be seen in Fig. 5. After the Agent of
the game object is registered, the complete flow process is driven
by events. Timer Manager raises Tick Event in each frame and
the game object triggers the game event in the flowchart. These
events will be added to the Event Queue. Agent will add the node
corresponding to the event in the Event Queue to the waiting
node and execute it by Executor. Timer Manager could directly
send the timer nodes that meet the conditions to Executor for
execution. Then, Executor deeply recursively traverses and runs
the descendants of the node.
Executor ensures that each node is executed only once in a
running process to prevent the flow of the flowchart from falling
into an infinite loop. When trying to execute a node repeatedly,
Executor adds it to the waiting queue for the Tick Event.
4.6. Remote debugging
Asyncflow provides the function of remote debugging. The
flowchart maker can connect to the game to view the operation
of the flowchart. Fig. 6 shows the debugging of a dungeon of the
game Justice Online when it is running. The runtime contains a
debugging server, which monitors a local network port to provide
debugging services to the outside world. After the flowchart
maker is connected to this port, then the debug module of the
maker can send several debugging commands and receive the
status information of the flowchart running. After the flowchart
maker receives the running data, it directly displays the node sta-
tus, the number of runs, and other information of the flowchart,
which is convenient for game designers to locate problems during
the running of the flowchart.
24
Visual Informatics 5 (2021) 20–25
Supported languages Asynchronous node
Lua, C#, Python ✓
C++ ✓
C++, C# ✓
C# ✗
5. Experiments
Table 1 shows the usage comparison among different visual
programming tools. Among them, Blueprints and Unity Behav-
ior Designer can only be used on specific game engines. Both
Asyncflow and Behaviac support cross-platform game AI devel-
opment, but compared with Behaviac which only supports C++
and C#, Asyncflow supports more languages. Blueprints, Behaviac
and Asyncflow all have asynchronous nodes for asynchronous
mechanisms. However, Blueprints needs to write asynchronous
logic separately and Behaviac will check the state of waiting
nodes the each frame, while Asyncflow only needs to use timer
nodes and event nodes, Asyncflow runtime will manage all events
automatically.
To verify the operating efficiency of Asyncflow, it is compared
with Behaviac and Unity Behavior Designer in flowcharts of dif-
ferent node sizes. Our experimental environment is a personal
computer with Intel Core i7-10700 CPU and 32 GB memory.
Fig. 7 shows that the time taken to execute the nodes sequen-
tially is linearly related to the scale of the nodes. The performance
of Asyncflow is slightly higher than that of Behaviac and re-
markably higher than that of Unity Behavior Designer. Generally,
the time-consuming requirement of the frame interval in the
game is 16 ms, and the time required for Asyncflow to run the
10000-node scale flowchart is only 0.3 ms, which can fully meet
the performance requirements of the game. In this experiment,
Asyncflow uses the Lua language, which is more efficient than
Behaviac using C++ language and Unity Behavior Designer using C#
in the coding period. Under normal circumstances, the running
performance of Lua is lower than that of C++. However, because
there are functional nodes such as selector, sequence and node
decorators in Behaviac, the execution of the node will take some
extra time. Asyncflow uses the simplest scheduling logic. This
allows us to bridge the performance gap between Lua and C++
while improving ease of use.
6. Conclusion and future work
This paper introduces Asyncflow, a visual programming tool for
game AI development. Asyncflow employs flowcharts consisting of
various types of nodes to describe distinctive game AI and game-
play. Actions in the flowchart can be run asynchronously based on
an event-driven runtime framework. Also, the debugging module
in Asyncflow allows users to easily check the running status of the
flowchart in the game. In summary, Asyncflow effectively reduces
the difficulty in game development.
Currently, Asyncflow has iterated two major versions, of which
the stable version has been used in several game development
processes, such as Justice Online. More than 10,000 flowcharts
are running in game servers and clients. In the future, we will
provide more types of nodes and integrate more structures, such
as random selection of sub-branches and switch cases into an
expandable built-in template. The upcoming version will allow
game designers to implement complex functions by filling param-
eters in corresponding templates. We also plan to apply Asyncflow
to other fields such as finance, automated production and ERP.
Z. Hu, C. Fan, Q. Zheng et al.
Fig. 6. Remote debugging in the game Justice Online.
Fig. 7. Performance comparison among three tools.
CRediT authorship contribution statement
Zhipeng Hu: Conceptualization, Methodology, Writing – orig-
inal draft. Changjie Fan: Supervision, Writing – reviewing and
editing. Qiwei Zheng: Investigation, Software. Wei Wu: Visual-
ization, Validation. Bai Liu: Resources, Formal analysis.
Declaration of competing interest
The authors declare that they have no known competing finan-
cial interests or personal relationships that could have appeared
to influence the work reported in this paper.
Ethical approval
The study does not involve human subjects. All data used in
the study are taken from public databases that were published in
the past
References
Bolte, F., Bruckner, S., 2020. Vis-a-vis: visual exploration of visualization source
code evolution. IEEE Trans. Vis. Comput. Graphics.
Boussejra, M.O., Uchiki, R., Takeshima, Y., Matsubayashi, K., Takekawa, S.,
Uemura, M., Fujishiro, I., 2019. aflak: Visual programming environment en-
abling end-to-end provenance management for the analysis of astronomical
datasets. Vis. Inform. 3 (1), 1–8.
25
Visual Informatics 5 (2021) 20–25
Carlisle, M.C., Wilson, T.A., Humphries, J.W., Hadfield, S.M., 2004. Raptor: intro-
ducing programming to non-majors with flowcharts. J. Comput. Sci. Coll. 19
(4), 52–60.
Charntaweekhun, K., Wangsiripitak, S., 2006. Visual programming using
flowchart. In: 2006 International Symposium on Communications and
Information Technologies. IEEE, pp. 1062–1065.
Drosos, I., Barik, T., Guo, P.J., DeLine, R., Gulwani, S., 2020. Wrex: A unified
programming-by-example interaction for synthesizing readable code for data
scientists. In: Proceedings of the 2020 CHI Conference on Human Factors in
Computing Systems. pp. 1–12.
Ellson, J., Gansner, E., Koutsofios, L., North, S.C., Woodhull, G., 2001. Graphviz—
open source graph drawing tools. In: International Symposium on Graph
Drawing. Springer, pp. 483–484.
Girault, A., Lee, B., Lee, E.A., 1999. Hierarchical finite state machines with
multiple concurrency models. IEEE Trans. Comput.-Aided Des. Integr. Circuits
Syst. 18 (6), 742–760.
Gotz, D., Stavropoulos, H., 2014. Decisionflow: Visual analytics for high-
dimensional temporal event sequence data. IEEE Trans. Vis. Comput. Graphics
20 (12), 1783–1792.
Guo, S., Xu, K., Zhao, R., Gotz, D., Zha, H., Cao, N., 2017. Eventthread: Visual
summarization and stage analysis of event sequence data. IEEE Trans. Vis.
Comput. Graphics 24 (1), 56–65.
Kahng, M., Andrews, P.Y., Kalro, A., Chau, D.H., 2017. Activis: Visual exploration
of industry-scale deep neural network models. IEEE Trans. Vis. Comput.
Graphics 24 (1), 88–97.
Pearson, M., Knight, B., Knight, D., Quintana, M., 2020. Introduction to power
automate. In: Pro Microsoft Power Platform. Springer, pp. 73–78.
Resnick, M., Maloney, J., Monroy-Hernández, A., Rusk, N., Eastmond, E., Bren-
nan, K., Millner, A., Rosenbaum, E., Silver, J., Silverman, B., et al., 2009.
Scratch: programming for all. Commun. ACM 52 (11), 60–67.
Sekhavat, Y.A., 2017. Behavior trees for computer games. Int. J. Artif. Intell. Tools
26 (02), 1730001.
Shoulson, A., Garcia, F.M., Jones, M., Mead, R., Badler, N.I., 2011. Parameterizing
behavior trees. In: International Conference on Motion in Games. Springer,
pp. 144–155.
Sugiyama, K., Tagawa, S., Toda, M., 1981. Methods for visual understanding of
hierarchical system structures. IEEE Trans. Syst. Man Cybern. 11 (2), 109–125.
Wagner, F., 2006. Modeling Software with Finite State Machines: A Practical
Approach. Auerbach Publications.
Wongsuphasawat, K., Smilkov, D., Wexler, J., Wilson, J., Mane, D., Fritz, D.,
Krishnan, D., Viégas, F.B., Wattenberg, M., 2018. Visualizing dataflow graphs
of deep learning models in tensorflow. IEEE Trans. Vis. Comput. Graphics 24
(1), 1–12.
Wood, J., Kachkaev, A., Dykes, J., 2018. Design exposition with literate
visualization. IEEE Trans. Vis. Comput. Graphics 25 (1), 759–768.
Yuan, Z., Pan, H., Zhang, L., 2008. A novel pen-based flowchart recognition system
for programming teaching. In: Workshop on Blended Learning. Springer, pp.
55–64.