See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/364318691

Verifying Game Logic in Unreal Engine 5 Blueprint Visual Scripting System Using
Model Checking

Conference Paper · October 2022

DOI: 10.1145/3551349.3560505

CITATIONS READS
2 1,427

5 authors, including:

Tomoyuki Yokogawa Sousuke Amasaki

Okayama Prefectural University Okayama Prefectural University
82 PUBLICATIONS 311 CITATIONS 100 PUBLICATIONS 678 CITATIONS

SEE PROFILE SEE PROFILE

Hirohisa Aman Kazutami Arimoto

Ehime University Okayama Prefectural University
89 PUBLICATIONS 321 CITATIONS 128 PUBLICATIONS 828 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Tomoyuki Yokogawa on 10 December 2022.

The user has requested enhancement of the downloaded file.

 Verifying Game Logic in Unreal Engine 5 Blueprint Visual
Scripting System Using Model Checking
Kazuki Wayama Tomoyuki Yokogawa
sk621053@cse.oka-pu.ac.jp t-yokoga@cse.oka-pu.ac.jp
Okayama Prefectural University Okayama Prefectural University
Soja, Okayama, Japan Soja, Okayama, Japan
Hirohisa Aman
aman@ehime-u.ac.jp
Ehime University
Matsuyama, Ehime, Japan
ABSTRACT
This paper examines modeling methods for applying model check-
ing to game programs created with Unreal Engine 5 Blueprint script-
ing system (hereinafter UE5 Blueprint). UE5 Blueprint can visually
describe game logic by combining various processing nodes, but as
the size of the game grows, it becomes more difficult to find and fix
bugs that prevent the game from progressing. In this paper, a formal
verification technique, model checking, is used to automatically
detect game logic bugs. We convert a game program created in UE5
Blueprint into an input model for the model-checker NuSMV to
achieve verification by NuSMV. The proposed framework enables
the automatic generation of models by formally defining the seman-
tics of nodes. We also propose methods for data flow optimization
and abstraction of variable domain for the purpose of reducing the
number of states in the model. We applied the proposed method to a
blueprint containing a typical flag management bug and confirmed
that the bug was correctly detected by NuSMV. Furthermore, we
show that the number of states can be significantly reduced by the
optimization and abstraction.
CCS CONCEPTS
• Software and its engineering → Formal software verifica-
tion.
KEYWORDS
Unreal Engine 5, Video Game Program, NuSMV
ACM Reference Format:
Kazuki Wayama, Tomoyuki Yokogawa, Sousuke Amasaki, Hirohisa Aman,
and Kazutami Arimoto. 2022. Verifying Game Logic in Unreal Engine 5
Blueprint Visual Scripting System Using Model Checking. In Proceedings of
37th IEEE/ACM International Conference on Automated Software Engineering
Workshop (ASEW 2022). ACM, New York, NY, USA, 8 pages. https://doi.org/
XXXXXXX
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for components of this work owned by others than ACM
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
to post on servers or to redistribute to lists, requires prior specific permission and/or a
fee. Request permissions from permissions@acm.org.
ASEW 2022, October 10–14, 2022, Ann Arbor, Michigan
© 2022 Association for Computing Machinery.
ACM ISBN 978-1-4503-XXXX-X/18/06. . . $15.00
https://doi.org/XXXXXXX
Sousuke Amasaki
amasaki@cse.oka-pu.ac.jp
Okayama Prefectural University
Soja, Okayama, Japan
Kazutami Arimoto
arimoto@cse.oka-pu.ac.jp
Okayama Prefectural University
Soja, Okayama, Japan
1 INTRODUCTION
In modern video game development, game designers use visual
scripting languages to describe game logic. Since many game de-
signers are unfamiliar with coding in a programming language, the
use of visual scripting languages can improve productivity in video
game development. Particularly, visual scripting languages with
node-based interfaces, such as Unity [14] and Blender [3], have been
adopted in many video game development projects. However, game
development using visual scripting languages also suffers from
maintainability problems. Game logic written in visual scripting
languages quickly becomes large and complex during the develop-
ment process, making it difficult to verify and modify the logic, and
prone to human error.
Recently, the Unreal Engine 5 Blueprint visual scripting system
[15] (hereinafter UE5 Blueprint) has been widely used in the game
development. In UE5 Blueprint, variables and functions are treated
as visual blocks called nodes, which can be combined to represent
game logic. A graph that contains a set of nodes to represent game
logic, such as character movement and collision detection in a
game, is called a blueprint. As the size of the game scripts increases,
blueprints grow in complexity and size, making it difficult to find
and fix even simple bugs. Model checking [5], an automatic system
verification technique, has been attracting attention as an effective
method for solving these problems.
Video games essentially have numerous combinations of inter-
nal states and external stimuli. This makes it difficult to detect
problems that come out under specific conditions by testing. Model
checking has been applied to video game development since it can
solve such problems by exhaustive verification. Moreno-Ger et al.
[9] proposed a method for verifying game scripts created in ⟨e-
Adventure⟩ platform using NuSMV. Radomski and Neubacher [11]
showed a framework in which video game logics are modeled by
State Chart XML (SCXML) formalism and their properties can be
checked by the SPIN model checker. Rezin et al. [12] developed a
method to model a multi-player game design as a Kripke structure
and to verify it by NuSMV. Lester [8] presented a case study in
which CBMC model-checker is used to verify simple interactive
fiction games. These studies show that applying model checking
to video game development is very promising and application to
game logic described by node-based visual scripts is also expected.
Exhaustive state space exploration is one of the major advantages
of model checking. However, it is not feasible to completely model
ASEW 2022, October 10–14, 2022, Ann Arbor, Michigan
a large and complex game logic, because it would cause a state
explosion. By focusing on only certain aspects of a game script, the
costs involved in modeling and verification can be greatly reduced.
Igawa et al. [7] applied NuSMV to verification of game scripts
which are created in UE4 Blueprint. They provided a framework
for converting simple visual scripts that have only a single control
flow to the input model for NuSMV. Hasegawa and Yokogawa
[6] proposed a method for automatically detecting bugs by using
symbolic model checking. They applied the model-checker NuSMV
to scripts which are randomly selected from the ones used in the
production for FFXV [13] and detected several bugs in a practical
time. These methods intend to avoid state explosion by restricting
modeling to specific aspects of the game logic, such as control
flow that may affect flag management. Model checking has proved
successful in automatically detecting bugs that testing frequently
overlooks, even with such a restricted model.
In this paper, we propose a method for applying model checking
to game scripts created in UE5 Blueprint. NuSMV [4], a tool that
implements a fast symbolic model checking algorithm, is used as
the model-checker. To verify game scripts by NuSMV, we present a
method to convert blueprints created by UE5 Blueprint into models
in the input language of NuSMV. In modeling the blueprints, we
focus on the data flow and execution flow between nodes and
represent their behaviors as transitions of variables in the NuSMV
model. Our goal is to avoid increasing the model size and to detect
bugs efficiently by modeling only the data and control flows in
game logic, as in [7] and [6]. Similar to [6], we can automatically
generate the model to be verified by preliminarily specifying node
semantics for each node of the target blueprint. We also examined
ways to reduce the model size through optimization and abstraction
to avoid state explosion.
2 MODEL CHECKING BLUEPRINTS
2.1 NuSMV
NuSMV [4] is one of the implementations of symbolic model check-
ing. The models to be verified by NuSMV are written in a spe-
cific input language called the SMV language. The properties to
be checked are expressed by temporal logic, such as LTL (Linear
Temporal Logic) [10] and CTL (Computational Tree Logic) [1]. The
input model described in the SMV language consists of the vari-
able declarations described by VAR and the transition definitions
described by ASSIGN. LTL and CTL expressions, which are the prop-
erties to be examined, are annotated into the input model using
LTLSPEC and CTLSPEC.
2.2 UE5 Blueprint
UE5 Blueprint is a visual scripting system for Unreal Engine 5 that
visually describes game logic, such as player and enemy character
actions, score calculations, and game termination conditions by
connecting nodes. All elements such as variables and functions
used in programming languages such as C can be handled as nodes.
This makes it possible for users without programming expertise to
intuitively describe game logic. A graph representing a particular
behavior of game logic by connecting nodes is called a blueprint.
A blueprint consists of nodes and wires. Nodes represent game
elements such as variables, functions representing operations in
Wayama et al.
the game, and flow controls such as conditional branches and loops.
Wires connect nodes via pins and represent data and execution
flows. Pins assigned to a node are classified as data pins for connect-
ing wires representing data flow and execution pins for connecting
wires representing execution flow.
The nodes involved in this paper are event nodes, function nodes,
flow control nodes, and variable nodes. An event node is a node
that serves as the starting point for the execution of a blueprint.
Event nodes are classified into BeginPlay, EndPlay, Event Tick, Input
Event, Collision Event and Custom Event. BeginPlay and EndPlay are
invoked when the actor associated with the blueprint begins and
ends its operation, respectively. Event Tick is called at every frame
in the game. Input Event is triggered by input devices. Collision
Event is invoked when an actor collides or overlaps with another
actor. Custom Event is an event that can be called from any point in
a blueprint. A function node is a node that implements a function
for a value in a program or a node-graph that can be invoked from
other graphs. Function nodes are classified into non-pure function
nodes and pure function nodes. A non-pure function node has an
execution pin and is invoked when the execution pin of the input
becomes active. A pure function node does not have an execution
pin and is invoked when the input value is updated. A flow control
node is a node that controls the execution flow according to given
conditions. Flow control nodes enable branching, for/while loops,
gating, and sequential execution for execution flows. A variable
node is a node representing a variable for holding the value of an
object or actor. Variable types include Boolean, Integer, Float, String,
and references to other objects. A variable node is placed on the
blueprint as a get node or a set node. A get node is used to refer to
the value of a variable. A set node is used to update the value of a
variable and is invoked by the execution pin.
Pins are classified as execution pins and data pins. Pins located
on the left side of the node are used for inputs and pins located
on the right side are used for outputs. An execution pin defines the
order in which nodes are processed and is used to synchronize their
processing with that of other nodes. Processing of a node starts
when the node connected via its input execution pin completes
processing. Then, after the processing of that node is completed,
the processing of the node connected via its output execution pin
starts. A data pin is used for data input/output to/from a node.
A wire connects either only between the execution pins or be-
tween the data pins. Only connections between pins of the same
data type are allowed for the data pins. The flow of execution rep-
resented by the wires connecting the execution pins is called the
execution flow. Similarly, the flow of data represented by the wires
connecting data pins is called the data flow.
2.3 Motivating Example
Fig. 1 shows an example blueprint. This blueprint involves three
variables:
• Speed is an integer variable and stores the player’s speed in
11 steps from 0 to 10.
• IsSprint is a boolean variable and indicates whether or not
the player is in a sprint mode.
• IsMaxSpeed is a boolean variable and is activated when the
player’s speed has reached its maximum value.
Verifying Game Logic in Unreal Engine 5 Blueprint Visual Scripting System Using Model Checking
Figure 1: An example blueprint
This blueprint illustrates one execution flow: First, the variable
IsSprint is set to true, and then the variable Speed is incremented.
If IsMaxSpeed is evaluated to be true, then the SE is played and
Speed is set to 0 and IsSprint is set to false.
A typical bug lurks in this blueprint. If IsMaxSpeed is evaluated
to be false when the execution flow reaches the Branch node, the
execution flow of this blueprint terminates at that point. Thus, the
flow never reaches the following SET nodes, and the IsSprint flag
will remain set. Flags that should be unset remain set may prevent
the game from progressing or cause unexpected behavior. This is
a common error in flag management, but one that is very easy to
overlook.
2.4 Semantics of Nodes
As similar in [6], we define the semantics of a node as functions
over the elements involving the node. Each node in a blueprint has
input and/or output data pins; and the value of the output data pin
changes according to the value of the input data pins. The node can
also have input and output execution pins; and one of the output
execution pins is triggered according to the condition of the input
data and execution pins. Besides, a set variable node assigns the
value of the input data pin to the associated variable. Thus, the
transition relation of the value of the element 𝑒𝑙 ∈ 𝐸 involving the
node can be generally expressed by the following form:
′
𝑒𝑙 = 𝑓 (𝐸, 𝑒𝑥),
where 𝑒𝑥 denotes the triggered execution pin, and 𝑒𝑙 ′ denotes the
value of 𝑒𝑙 in the next state. (From now on, the primed variable 𝑣 ′
refers to the value of 𝑣 in the next state.) 𝐸 is composed of the input
and output data pins and the variables. Furthermore, the transition
relation of the triggered execution pin 𝑒𝑥 can be expressed by the
following formula:
𝑒𝑥 ′ = 𝑓 (𝐸, 𝑒𝑥).
The set of such functions is referred to as node semantics. We will
describe the node semantics for each type of node in detail below.
Variable Nodes As mentioned earlier, variable nodes are classi-
fied as get variable nodes and set variable nodes.
A get variable node has a single output data pin; and the value
of its single output data pin is always the same as the value of the
referred variable at that state. Therefore, its node semantics is given
ASEW 2022, October 10–14, 2022, Ann Arbor, Michigan
by the following formula:
𝑑𝑜𝑢𝑡 ′ = 𝑣𝑎𝑟,
where 𝑑𝑜𝑢𝑡 denotes the value of the output data pin, and 𝑣𝑎𝑟 denotes
the value of the variable. For example, the semantics of the get node
Speed in the Fig. 1 is defined as follows:
𝑑𝑜𝑢𝑡 ′ = Speed.
A set variable node has a single input data pin and input and
output execution pins. When the input execution pin is triggered,
the value of the input data pin is assigned to the variable associated
with the node, and the output execution pin is triggered. Thus, its
node semantics is given by the following formulas:
𝑣𝑎𝑟 ′ = if (𝑒𝑥 = 𝑒𝑖𝑛) then 𝑑𝑖𝑛,
𝑒𝑥 ′ = if (𝑒𝑥 = 𝑒𝑖𝑛) then 𝑒𝑜𝑢𝑡,
where 𝑑𝑖𝑛 denotes the value of the input data pin, and 𝑒𝑖𝑛 and
𝑒𝑜𝑢𝑡 denotes the input and output execution pin. For example,
the semantics of the rightmost set node in the Fig. 1 is defined as
follows:
IsSprint′ = if (𝑒𝑥 = 𝑒𝑖𝑛) then 𝑡𝑟𝑢𝑒,
𝑒𝑥 ′ = if (𝑒𝑥 = 𝑒𝑖𝑛) then 𝑒𝑜𝑢𝑡 .
Function Nodes A function node can be either a pure function
node without execution pins or a non-pure function node with
execution pins.
A pure function node has input and output data pins and has no
execution pin. The value of the output data pin is determined by
the value of the input data pins. Let 𝐼 = {𝑖𝑛 1, . . . , 𝑖𝑛𝑚 } is the set of
input data pins and 𝑂 = {𝑑𝑜𝑢𝑡 1, . . . , 𝑑𝑜𝑢𝑡𝑛 } is the set of output data
pins. The transition relation of the output pin 𝑑𝑜𝑢𝑡𝑖 ∈ 𝑂 is given
by the following formula:
𝑑𝑜𝑢𝑡𝑖′ = 𝑓𝑖 (𝐼 ),
where the function 𝑓𝑖 is defined according to the node. The node se-
mantics can be obtained as a set of formulas representing transition
relations for all output pins.
For example, the semantics of the Add node in the Fig. 1 is defined
as follows:
𝑑𝑜𝑢𝑡 ′ = if (𝑖𝑛 1 < 10) then 𝑖𝑛 1 + 1 else 10.
ASEW 2022, October 10–14, 2022, Ann Arbor, Michigan
A non-pure function node has input and output data pins, and
has input and output execution pin. Similar to a pure function node,
the value of the output data pin of a non-pure function node is
determined by the value of the input data pins. However, in contrast
to a pure function node, the non-pure function node performs the
computation when the input execution pin is triggered. Thus, the
transition relation of the output pin 𝑑𝑜𝑢𝑡𝑖 is modified as follows:
𝑑𝑜𝑢𝑡𝑖′ = if (𝑒𝑥 = 𝑒𝑖𝑛) then 𝑓𝑖 (𝐼 ),
𝑒𝑥 ′ = if (𝑒𝑥 = 𝑒𝑖𝑛) then 𝑒𝑜𝑢𝑡 .
Flow Control Nodes The flow control node triggers one of the
output execution pins depending on the values of the input data
pins and the triggered input execution pins. Thus, the transition
relation of 𝑒𝑥 involving the flow control node with output execution
pins {𝑒𝑜𝑢𝑡 1, 𝑒𝑜𝑢𝑡 2, . . . 𝑒𝑜𝑢𝑡𝑙 } is generally expressed as follows:
𝑒𝑥 ′ = if 𝑐𝑜𝑛𝑑 1 (𝐼, 𝑒𝑥) then 𝑒𝑜𝑢𝑡 1
else if 𝑐𝑜𝑛𝑑 2 (𝐼, 𝑒𝑥) then 𝑒𝑜𝑢𝑡 2
else if · · ·
else if 𝑐𝑜𝑛𝑑𝑙 (𝐼, 𝑒𝑥) then 𝑒𝑜𝑢𝑡𝑙 ,
where 𝑐𝑜𝑛𝑑𝑖 (𝐼, 𝑒𝑥) denotes the condition for 𝑒𝑜𝑢𝑡𝑖 to be triggered.
For example, the semantics of the Branch node in the Fig. 1 is
defined as follows:
𝑒𝑥 ′ = if 𝑐𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛 then 𝑇𝑟𝑢𝑒 else 𝐹𝑎𝑙𝑠𝑒.
2.5 Framework
In this study, we achieve verification by NuSMV by converting game
logic written as blueprints into SMV programs. The verification is
performed as following steps:
Step 1. Modeling the data and execution flows,
Step 2. Modeling the behavior of the nodes,
Step 3. Integrating the model fragments,
Step 4. Annotating the specifications, and
Step 5. Verifying the model by NuSMV.
In Step 1, the data flow and execution flow are represented by
declaring SMV program variables (hereinafter SMV variables) for
the input/output pins of each node in the blueprint. In Step 2,
the behavior of nodes is represented by separately describing the
changes in the value of the input/output pins at each node. In Step
3, the variable declarations and the behavior definitions obtained
in Steps 1 and 2 are concatenated to obtain a verification model. In
Step 4, the properties to be checked are expressed in CTL and LTL,
and are annotated to the model. Finally, in Step 5, the obtained SMV
program is verified by NuSMV. If the properties are not satisfied,
the script will be modified based on the counterexamples obtained.
2.6 Scope and Limitations
We mainly aim to detect bugs caused by incorrect control flow in
the blueprints. However, it is not intended for detailed data flow
analysis. Such an approach can also efficiently detect script bugs,
as reported in the work [6].
The proposed modeling method generates SMV programs for a
single blueprint and excludes in the model the behavior of other
event graphs invoked by the Call node or the node networks that
Wayama et al.
implement the functionality of the function nodes. Real time be-
havior described by Timeline and Delay nodes are also excluded
from the modeling. Besides, the proposed modeling method has
some limitations on the types of variables and operations that can
be handled due to the expressive power of the SMV language to be
converted. For example, only integer types and bit vectors can be
used as numerical values. As for arithmetic operations, only simple
arithmetic and logical operations are supported, and advanced and
complex operations such as those handled by the Math Expression
node in Unreal Engine are not available. These limitations are very
considerable and require significant abstraction to convert prac-
tical scripts, but it is possible to detect critical (and hard-to-find)
bugs even in abstracted scripts. On the other hand, the verification
with NuSMV can be easily extended to SAT-based bounded model
checking [2] because the model is handled internally as a sym-
bolic representation. By using an SMT solver as a constraint solver,
the limitations on data types and operations can be considerably
reduced.
3 VERIFYING BLUEPRINTS BY NUSMV
In this section, we describe the procedure for modeling the blueprint
shown in Figure 1 as an example into an SMV program.
3.1 Modeling the Data and Execution Flows
To model data flow, it is necessary to represent what data has
transitioned from which node via which pins and wires. For this
purpose, SMV program variables (hereafter simply referred to as
SMV variables) are assigned to each data pin at each node. Here, the
type of SMV variable to be assigned is determined by the type of the
corresponding data pin. For example, if the data pin is of the Boolean
type, the corresponding SMV variable should also be of the Boolean
type, and if it is of the Integer type, the SMV variable should also
be of the integer type. Since the SMV language requires a finite
domain to be allocated for integer variables, the domain must be
sufficient to express the behavior of the node. Note that two pins
connected via a wire have the same value with respect to data flow,
so it is sufficient to assign one variable. Variables are also defined
as SMV variables in the same way. Integer variables are defined
as SMV variables of integer type, Boolean variables are defined as
SMV variables of Boolean type, and so on for other types. The SMV
variables defined for the example data flow in Figure 1 are shown
below.
VAR w_Speed_Add : 0..10; w_Add_Set2 : 0..10;
w_IsMaxSpeed_Branch : boolean;
d_Speed_Add : boolean; d_Add_Set2 : boolean;
d_IsMaxSpeed_Branch : boolean;
v_Speed : 0..10; v_IsSprint : boolean; v_IsMaxSpeed : boolean;
The output data pin of the get variable node Speed and the upper
input data pin of the function node Add are of Integer type and take
values from 0 to 10, so the wire between them is defined as an inte-
ger variable w_Speed_Add in the domain 0..10. Similarly, the wire
between the output data pin of Add and the input data pin of the sec-
ond set variable node is defined as an integer variable w_Add_Set2.
The output data pin of the get variable node IsMaxSpeed and the
input data pin of the Branch node are of Boolean type, so the wire be-
tween them is defined as a Boolean variable w_IsMaxSpeed_Branch.
Note that there can be a state in which the value of a variable is
Verifying Game Logic in Unreal Engine 5 Blueprint Visual Scripting System Using Model Checking ASEW 2022, October 10–14, 2022, Ann Arbor, Michigan

not defined, such as at the beginning of blueprint execution. We TRUE : w_Add_Set2;

introduce a new flag variable to indicate that the variable is un-
defined. d_Speed_Add, d_Add_Set2, and d_IsMaxSpeed_Branch
are Boolean variables indicating that w_Speed_Add, w_Add_Set2,
and w_IsMaxSpeed_Branch are defined, respectively. The variables
Speed, IsSprint, and IsMaxSpeed are defined as v_Speed, v_IsSprint
and v_IsMaxSpeed, respectively.
To model the execution flow, it is necessary to represent which
execution pin is triggered in the next state. Similar to representing
data flow, two execution pins connected via a wire are triggered
simultaneously. Only one of the pairs of execution pins connected
by a wire is triggered at the same time. Therefore, to represent
the execution flow, it is sufficient to define one SMV variable that
has as its domain the execution pin pairs (i.e., wires). The SMV
variables defined for the example execution flow in Figure 1 are
shown below:
VAR _ex : {_undef, Beginplay_Set1, Set1_Set2, Set2_Branch,
Branch_PlaySE, PlaySE_Set3, Set3_Set4};
esac;
init(d_Add_Set2) := FALSE;
next(d_Add_Set2) := case
d_Speed_Add : TRUE;
TRUE : d_Add_Set2;
esac;
The initial value of the data pin is assigned nondeterministically.
Unlike a get variable node, the value of the output pin of a function
node also depends on whether its value or involving input pins’
values are already assigned. Specifically, if its value has already been
assigned or if the values of input pins have not yet been assigned,
its value is not changed. Additionally, the flag variable d_Add_Set2
is set to true when the values of input pins have been assigned.
output execution pins The transition relation of the output exe-
cution pin can be represented by integrating the transition relations
of nodes involving the execution flow. The transition relation of
the triggered execution pin 𝑒𝑥 can be represented as a change in
the value of the SMV variable _ex as follows:

The value _undef indicates that no execution pin is triggered. We ASSIGN init(_ex) := Beginplay_Set1;
next(_ex) := case
refer to the four set variable nodes of this blueprint as Set1, Set2, _ex = Beginplay_Set1 : Set1_Set2;
Set3, and Set4, from the leftmost node. _ex = Set1_Set2 & d_Add_Set2 : Set2_Branch;
_ex = Set2_Branch & d_IsMaxSpeed_Branch &
w_IsMaxSpeed_Branch : Branch_PlaySE;
3.2 Modeling the Behavior of the Nodes _ex = Set2_Branch & d_IsMaxSpeed_Branch & !
Next, the behavior of each node is modeled according to the node w_IsMaxSpeed_Branch : _undef;
_ex = Branch_PlaySE : PlaySE_Set3;
semantics. As stated in Section 2.4, the values of the output data _ex = PlaySE_Set3 : Set3_Set4;
pins and variables change according to the value of the input data _ex = Set3_Set4 : _undef;
TRUE : _ex;
pins. Besides, output execution pins are triggered depending on esac;
the value of the input data pins and the triggered input execution
pins. Thus, we can model the behavior of nodes by representing the The triggered execution pin in the initial states is that of the event
transition relation of the values of the output data and execution node. For nodes with input data pins, _ex is updated after the values
pins and the variables. of the pins are determined.
output data pins Since the value of each output data pin is variables The variables are classified into internal and exter-
changed by either a get variable node or a function node, we can nal variables, where internal variables are those whose values are
model the transition relation of the values of output data pins based assigned by set variable nodes and external variables are those
on the node semantics of the involving nodes. For the example in whose values are determined by external components such as other
Figure 1, the data wire w_Speed_Add and w_IsMaxSpeed_Branch blueprints or input devices. For the example in Figure 1, Speed
are respectively changed by Speed and IsMaxSpeed get variable and IsSprint are internal variables, and IsMaxSpeed is an external
node, and w_Add_Set2 is changed by Add function node. The tran- variable. The transition relation of the internal variable is repre-
sition relations of w_Speed_Add and w_IsMaxSpeed_Branch are sented by integrating the transition relations of the set variable
represented in the SMV program as follows: nodes referring to the variable. The transition relations of v_Speed
and v_IsSprint are represented as follows:
ASSIGN init(w_Speed_Add) := v_Speed;
next(w_Speed_Add) := v_Speed; ASSIGN init(v_Speed) := 0..10;
init(d_Speed_Add) := TRUE; next(v_Speed) := case
next(d_Speed_Add) := TRUE; _ex = Set1_Set2 & d_Add_Set2 : w_Add_Set2;
init(w_IsMaxSpeed_Branch) := v_IsMaxSpeed; _ex = PlaySE_Set3 : 0;
next(w_IsMaxSpeed_Branch) := v_IsMaxSpeed; TRUE : v_Speed;
init(d_IsMaxSpeed_Branch) := TRUE; esac;
next(d_IsMaxSpeed_Branch) := TRUE; init(v_IsSprint) := {TRUE, FALSE};
next(v_IsSprint) := case
According to the node semantics of a get variable node, the value _ex = Beginplay_Set1 : TRUE;
of the output pin is assigned the value of the variable; and the pin’s _ex = Set3_Set4 : FALSE;
value is predefined as the variable value in the initial states. TRUE : v_IsSprint;
esac;
The transition relation of w_Add_Set2 is represented as follows:
ASSIGN init(w_Add_Set2) := 0..10;
The initial value of the variable is assigned nondeterministically.
next(w_Add_Set2) := case Since Set2 and Set3 assign the value to the variable Speed, the
d_Add_Set2 : w_Add_Set2; transition relation is obtained from the node semantics of those
!d_Speed_Add : w_Add_Set2;
w_Speed_Add < 10 : w_Speed_Add + 1; nodes. If the input data pin of a set variable node is connected to
!(w_Speed_Add < 10) : 10; another data pin via a wire, the variable is assigned a value only if
ASEW 2022, October 10–14, 2022, Ann Arbor, Michigan Wayama et al.

the value of that data pin has already been determined. Similarly, 4 STATE SPACE REDUCTION
the transition relation of the variable IsSprint is obtained from the Since large-scale game logic consists of many blueprints, the num-
node semantics of Set1 and Set4. ber of states in the model can explode, making verification in a
In addition, because the behavior of external variables is deter- practical time difficult. Factors affecting the number of states in-
mined outside the blueprint, their values change nondeterminis- clude the number of nodes and the number of pins in each node,
tically. The transition relation of IsMaxSpeed is represented as which affect the number of SMV variables, as well as the range
follows: of the domain of SMV variables. In this section, we discuss the
ASSIGN init(v_IsMaxSpeed) := {TRUE, FALSE}; approaches for reducing the state space of the modeled blueprint.
next(v_IsMaxSpeed) := {TRUE, FALSE};
4.1 Data Flow Optimization
3.3 Verifying the Model by NuSMV The modeling method described above takes one-step transition
to propagate data from the input pins to the output pins of a node.
By integrating the fragments of the SMV program shown so far, a
By integrating the processing of multiple pure function nodes into
model for verification can be obtained. To perform verification by
one, the number of nodes to be modeled can be reduced. Consider
NuSMV, it is necessary to express the properties to be verified in
three pure function nodes connected as shown in Fig. 2. The node
temporal logic. The error in flag management, as shown in section
semantics of those nodes are given as 𝑜𝑢𝑡 ′ = 𝑓 (𝑖𝑛1, 𝑖𝑛2), 𝑜𝑢𝑡 ′ =
2.3, can be detected by the following CTL formula:
𝑔(𝑖𝑛1, 𝑖𝑛2) and 𝑜𝑢𝑡 ′ = ℎ(𝑖𝑛1, 𝑖𝑛2). Since the three function nodes
AG(IsSprint → AF¬IsSprint). are connected in series, the following three steps of transitions are
required for the SET node to obtain the result:
This CTL formula expresses the property that IsSprint will even-
tually be unset if IsSprint is set. That CTL formula is annotated to (1) 𝑜𝑢𝑡1′ = 𝑓 (𝑣1, 𝑣2),
the SMV program as follows: (2) 𝑜𝑢𝑡2′ = 𝑔(𝑜𝑢𝑡1, 𝑣3), and
(3) 𝑜𝑢𝑡3′ = ℎ(𝑜𝑢𝑡2, 𝑣4).
CTLSPEC AG (v_IsSprint -> AF (! v_IsSprint))
By integrating these processes, the result can be obtained in a single
The resulting SMV program was model-checked using NuSMV. step transition of 𝑜𝑢𝑡3′ = ℎ(𝑔(𝑓 (𝑣1, 𝑣2), 𝑣3), 𝑣4).
The obtained verification result is as follows:
-- specification AG (v_IsSprint -> AF !v_IsSprint) is false v1
in1
-- as demonstrated by the following execution sequence 𝑓 out
in1
SET
Trace Description: CTL Counterexample in2
𝑔 out
in1 var
Trace Type: Counterexample v2 in2
ℎ out
-> State: 1.1 <- v3 in2
_ex = Beginplay_Set1 v4
w_Speed_Add = 7
w_Add_Set2 = 0
w_IsMaxSpeed_Branch = TRUE Figure 2: Nodes for optimization
d_Speed_Add = TRUE
d_Add_Set2 = FALSE
d_IsMaxSpeed_Branch = TRUE
v_Speed = 7 For the example in Fig. 1, we can reduce the Add node by the
v_IsSprint = FALSE
v_IsMaxSpeed = TRUE optimization. By integrating the node semantics of the SET node
-> State: 1.2 <- with that of the Add node, we obtain the following semantics:
_ex = Set1_Set2
w_Add_Set2 = 8
d_Add_Set2 = TRUE
Speed′ = if (𝑒𝑥 = 𝑒𝑖𝑛 ∧ Speed < 10) then Speed + 1
v_IsSprint = TRUE else if (𝑒𝑥 = 𝑒𝑖𝑛) then 10.
v_IsMaxSpeed = FALSE
-> State: 1.3 <-
_ex = Set2_Branch Based on the semantics obtained, the transition relation of the
w_IsMaxSpeed_Branch = FALSE variable Speed is modified as follows:
v_Speed = 8
-- Loop starts here
ASSIGN init(v_Speed) := 0..10;
-> State: 1.4 <-
next(v_Speed) := case
_ex = _undef
_ex = Set1_Set2 & v_Speed = 10 : 10;
w_Speed_Add = 8
_ex = Set1_Set2 & v_Speed < 10 : v_Speed + 1;
-> State: 1.5 <-
_ex = PlaySE_Set3 : 0;
TRUE : v_Speed;
NuSMV indicates that the property is not satisfied, which means esac;
that the bug could be detected. NuSMV also generates a counterex-
ample that shows why the property is violated. The counterexample Because of removing the Add node, the SMV variables w_Speed_Add
illustrates the execution flow that leads to Branch node via Set1 and and w_Add_Set2 (as well as d_Speed_Add and d_Add_Set2) are no
Set2, after which the execution is terminated by the triggering of longer needed, and are therefore removed from the model. The
the False execution pin. Thus, NuSMV can detect bugs and support conjunction with d_Add_Set2 is accordingly removed from the
the bug analysis with the generated counterexample. second clause of the transition of _ex.
Verifying Game Logic in Unreal Engine 5 Blueprint Visual Scripting System Using Model Checking
4.2 Variable Domain Abstraction
In game programs, many nodes perform complex calculations, such
as “calculate the area of a triangle from the coordinates of the three
vertices.” If the behavior of such nodes is modeled as is, there is a
significant possibility of a state explosion due to the large definition
range of each variable. In addition, a flag variable indicating whether
the value of each variable is already assigned is also required. Thus,
the number of states increases with the size of the game space, and
the state space grows exponentially with each increase in these
nodes.
However, if the property to be verified is highly dependent on
the execution flow rather than the data, it is possible to verify the
desired property without rigorously modeling the contents of the
data flow. Therefore, we seek to reduce the number of states by
abstracting the domain of variables in modeling, thereby reducing
the cost of verification. Specifically, the number of states is reduced
by avoiding direct modeling of the computation target, the value of
the computation result, and the computation process for the node
performing the numerical computation.
As an example, to model a node that calculates the area of a
triangle as described above, the following variables are required
even if the target area is limited to a rectangle with (0, 0) and
(100, 100) as diagonals:
VAR x1 : 0..100; x2 : 0..100; x3 : 0..100;
y1 : 0..100; y2 : 0..100; y3 : 0..100;
area : 0..10000;
d_x1 : boolean; d_x2 : boolean; d_x3 : boolean;
d_y1 : boolean; d_y2 : boolean; d_y3 : boolean;
d_area : boolean;
Even with only those SMV variables, the number of states of the
model would exceed 260 . By changing the target area to a rectangle
with (0, 0) and (10, 10) as diagonals and abstracting the domains
of those SMV variables, the number of states can be reduced to
about 235 . Furthermore, if the contents of the data are not strictly
modeled, but only the flow of the data is represented, the number
of states can be significantly reduced by eliminating all but the flag
variables and the property-affecting variables.
For the example in Fig. 1, we can abstract the model by eliminat-
ing the variables representing data pins and the variables excluding
IsSprint, which appears in the CTL formula expressing the property.
4.3 Preliminary Evaluation
In this section, we provide a preliminary evaluation of the effec-
tiveness of the state reduction approaches described above in the
example. The original model obtained by the proposed modeling
method and the models obtained using optimization and abstrac-
tion are shown in Fig 3. The results of verification by NuSMV are
shown in Table 1. The verification was completed within a short
time in all cases, and the target bug can be detected in the model
with optimization and abstraction as well. In addition, the number
of states (# st.) and reachable states (# reach. st.) of the model can be
significantly reduced through optimization and abstraction. Thus,
the proposed state reduction method is expected to decrease the
cost of verification, even for large-scale blueprints.
ASEW 2022, October 10–14, 2022, Ann Arbor, Michigan
Table 1: Verification results
model # reach. st. # st. time[sec.] detected?
original 772 596,288 < 0.01 yes
optimized 256 1,232 < 0.01 yes
abstracted 9 448 < 0.01 yes
5 CONCLUSION AND FUTURE REMARK
In this paper, we propose a method to verify game scripts created
with UE5 Blueprint using the NuSMV model-checker. To verify
game scripts with NuSMV, we presented a method for converting
blueprints to the input model for NuSMV. The proposed method
can also handle blueprints in which multiple control flows work
in parallel, and furthermore, the model size can be reduced by ab-
straction. As a preliminary evaluation, we performed modeling
based on the proposed method on an example game script and con-
firmed that typical flag management bugs are correctly detected.
Furthermore, we found that the proposed optimization and abstrac-
tion can significantly reduce the number of states and the cost of
verification.
Future work should include a quantitative analysis of the effects
of model size reduction through optimization and abstraction on
practical examples, as well as the frequency of bugs missed due to
abstraction. Besides, it is necessary to evaluate the verification cost
and bug detection rate for practical game scripts. In order to improve
the usability of the proposed framework, we will also develop an
automated modeling and visualization of counterexamples.
ACKNOWLEDGMENTS
This work was supported by JSPS KAKENHI #21K11831 and #21K11833.
REFERENCES
[1] Mordechai Ben-Ari, Amir Pnueli, and Zohar Manna. 1983. The Temporal Logic
of Branching Time. Acta Inform. 20, 3 (1983), 207–226.
[2] Armin Biere, Alessandro Cimatti, Edmund M. Clarke, and Yunshan Zhu. 1999.
Symbolic Model Checking without BDDs. In Proc. of the 5th Int’l Conf. on Tools
and Algorithms for Construction and Analysis of Syst. (TACAS ’99). 193–207.
[3] Blender. 2022. blender.org - Home of the Blender project - Free and Open 3D
Creation Software. https://www.blender.org/.
[4] A Cimatti, Edmund M Clarke, F Giunchiglia, and M Roveri. 1999. NuSMV: A New
Symbolic Model Verifier. In Proc. 11th Int’l Conf. on Computer Aided Verification
(CAV 1999) , LNCS1633. 495–499.
[5] E M Clarke, O Grumberg, and D Peled. 1999. Model checking. MIT press.
[6] Isamu Hasegawa and Tomoyuki Yokogawa. 2022. Formal Verification for Node-
Based Visual Scripts Using Symbolic Model Checking. IEICE Trans. Inf. Syst.
E105-D, 1 (2022), 78–91.
[7] Nao Igawa, Tomoyuki Yokogawa, Mami Takahashi, and Kazutami Arimoto. 2020.
Model Checking of Visual Scripts Created by UE4 Blueprints. In Proc. 8th Inter-
national Conference on Smart Computing and Artificial Intelligence (SCAI 2020).
516–519.
[8] M M Lester. 2020. Solving Interactive Fiction Games via Partial Evaluation and
Bounded Model Checking. arXiv preprint arXiv:2012.15365 (2020).
[9] Pablo Moreno-Ger, Rubén Fuentes-Fernández, José Luis Sierra-Rodríguez, and
Baltasar Fernández-Manjón. 2009. Model-Checking for Adventure Videogames.
Information and Software Technology 51, 3 (2009), 564–580.
[10] Amir Pnueli. 1981. A Temporal Logic of Concurrent Programs. Theor. Comput.
Sci. 13 (1981), 45–60.
[11] Stefan Radomski and Tim Neubacher. 2015. Formal Verification of Selected Game-
Logic Specifications. In Proc. the 2nd EICS Workshop on Engineering Interactive
Computer Systems with SCXML. 30–34.
[12] R Rezin, I Afanasyev, M Mazzara, and V Rivera. 2018. Model Checking in Multi-
player Games Development. In 2018 IEEE 32nd Int’l Conf. on Advanced Information
Networking and Applications (AINA). 826–833.
[13] SQUARE ENIX CO., LTD. 2016. FINAL FANTASY XV. http://www.jp.square-
enix.com/ff15/.
 ASE ’22, October 10–14, 2022, Rochester, MI, USA Wayama et al.
ASEW 2022, October 10–14, 2022, Ann Arbor, Michigan Wayama et al.

1 MODULE main 1 MODULE main 1 MODULE main

2 VAR 2 VAR 2 VAR
3 _ex : {_undef, Beginplay_Set1, Set1_Set2, 3 _ex : {_undef, Beginplay_Set1, Set1_Set2, 3 _ex : {_undef, Beginplay_Set1, Set1_Set2,
4 Set2_Branch, Branch_PlaySE, PlaySE_Set3, 4 Set2_Branch, Branch_PlaySE, PlaySE_Set3, 4 Set2_Branch, Branch_PlaySE, PlaySE_Set3,
5 Set3_Set4}; 5 Set3_Set4}; 5 Set3_Set4};
6 w_Speed_Add : 0..10; 6 6
7 w_Add_Set2 : 0..10; 7 7
8 w_IsMaxSpeed_Branch : boolean; 8 w_IsMaxSpeed_Branch : boolean; 8
9 d_Speed_Add : boolean; 9 9 d_Speed_Add : boolean;
10 d_Add_Set2 : boolean; 10 10 d_Add_Set2 : boolean;
11 d_IsMaxSpeed_Branch : boolean; 11 d_IsMaxSpeed_Branch : boolean; 11 d_IsMaxSpeed_Branch : boolean;
12 v_Speed : 0..10; 12 v_Speed : 0..10; 12 d_Speed : boolean;
13 v_IsSprint : boolean; 13 v_IsSprint : boolean; 13 v_IsSprint : boolean;
14 v_IsMaxSpeed : boolean; 14 v_IsMaxSpeed : boolean; 14 d_IsMaxSpeed : boolean;
15 15 15
16 ASSIGN 16 ASSIGN 16 ASSIGN
17 init(_ex) := Beginplay_Set1; 17 init(_ex) := Beginplay_Set1; 17 init(_ex) := Beginplay_Set1;
18 next(_ex) := case 18 next(_ex) := case 18 next(_ex) := case
19 _ex = Beginplay_Set1 : Set1_Set2; 19 _ex = Beginplay_Set1 : Set1_Set2; 19 _ex = Beginplay_Set1 : Set1_Set2;
20 _ex = Set1_Set2 & d_Add_Set2 : Set2_Branch; 20 _ex = Set1_Set2 : Set2_Branch; 20 _ex = Set1_Set2 & d_Add_Set2 : Set2_Branch;
21 _ex = Set2_Branch & d_IsMaxSpeed_Branch 21 _ex = Set2_Branch & d_IsMaxSpeed_Branch 21 _ex = Set2_Branch & d_IsMaxSpeed_Branch
22 & w_IsMaxSpeed_Branch : Branch_PlaySE; 22 & w_IsMaxSpeed_Branch : Branch_PlaySE; 22 : {Branch_PlaySE, _undef};
23 _ex = Set2_Branch & d_IsMaxSpeed_Branch 23 _ex = Set2_Branch & d_IsMaxSpeed_Branch 23
24 & (!w_IsMaxSpeed_Branch) : _undef; 24 & (!w_IsMaxSpeed_Branch) : _undef; 24
25 _ex = Branch_PlaySE : PlaySE_Set3; 25 _ex = Branch_PlaySE : PlaySE_Set3; 25 _ex = Branch_PlaySE : PlaySE_Set3;
26 _ex = PlaySE_Set3 : Set3_Set4; 26 _ex = PlaySE_Set3 : Set3_Set4; 26 _ex = PlaySE_Set3 : Set3_Set4;
27 _ex = Set3_Set4 : _undef; 27 _ex = Set3_Set4 : _undef; 27 _ex = Set3_Set4 : _undef;
28 TRUE : _ex; 28 TRUE : _ex; 28 TRUE : _ex;
29 esac; 29 esac; 29 esac;
30 30 30
31 init(w_Speed_Add) := v_Speed; 31 31
32 next(w_Speed_Add) := v_Speed; 32 32
33 init(d_Speed_Add) := TRUE; 33 33 init(d_Speed_Add) := TRUE;
34 next(d_Speed_Add) := TRUE; 34 34 next(d_Speed_Add) := TRUE;
35 35 35
36 init(w_Add_Set2) := 0..10; 36 36
37 next(w_Add_Set2) := case 37 37
38 d_Add_Set2 : w_Add_Set2; 38 38
39 !d_Speed_Add : w_Add_Set2; 39 39
40 w_Speed_Add < 10 : w_Speed_Add + 1; 40 40
41 !(w_Speed_Add < 10) : 10; 41 41
42 TRUE : w_Add_Set2; 42 42
43 esac; 43 43
44 init(d_Add_Set2) := FALSE; 44 44 init(d_Add_Set2) := FALSE;
45 next(d_Add_Set2) := case 45 45 next(d_Add_Set2) := case
46 d_Speed_Add : TRUE; 46 46 d_Speed_Add : TRUE;
47 TRUE : d_Add_Set2; 47 47 TRUE : d_Add_Set2;
48 esac; 48 48 esac;
49 49 49
50 init(w_IsMaxSpeed_Branch) := v_IsMaxSpeed; 50 init(w_IsMaxSpeed_Branch) := v_IsMaxSpeed; 50
51 next(w_IsMaxSpeed_Branch) := v_IsMaxSpeed; 51 next(w_IsMaxSpeed_Branch) := v_IsMaxSpeed; 51
52 init(d_IsMaxSpeed_Branch) := TRUE; 52 init(d_IsMaxSpeed_Branch) := TRUE; 52 init(d_IsMaxSpeed_Branch) := TRUE;
53 next(d_IsMaxSpeed_Branch) := TRUE; 53 next(d_IsMaxSpeed_Branch) := TRUE; 53 next(d_IsMaxSpeed_Branch) := TRUE;
54 54 54
55 init(v_IsSprint) := {TRUE, FALSE}; 55 init(v_IsSprint) := {TRUE, FALSE}; 55 init(v_IsSprint) := {TRUE, FALSE};
56 next(v_IsSprint) := case 56 next(v_IsSprint) := case 56 next(v_IsSprint) := case
57 _ex = Beginplay_Set1 : TRUE; 57 _ex = Beginplay_Set1 : TRUE; 57 _ex = Beginplay_Set1 : TRUE;
58 _ex = Set3_Set4 : FALSE; 58 _ex = Set3_Set4 : FALSE; 58 _ex = Set3_Set4 : FALSE;
59 TRUE : v_IsSprint; 59 TRUE : v_IsSprint; 59 TRUE : v_IsSprint;
60 esac; 60 esac; 60 esac;
61 61 61
62 init(v_Speed) := 0..10; 62 init(v_Speed) := 0..10; 62 init(d_Speed) := TRUE;
63 next(v_Speed) := case 63 next(v_Speed) := case 63 next(d_Speed) := TRUE;
64 _ex = Set1_Set2 & d_Add_Set2 : w_Add_Set2; 64 _ex = Set1_Set2 & v_Speed = 10 : 10; 64
65 65 _ex = Set1_Set2 & v_Speed < 10 : v_Speed + 1; 65
66 _ex = PlaySE_Set3 : 0; 66 _ex = PlaySE_Set3 : 0; 66
67 TRUE : v_Speed; 67 TRUE : v_Speed; 67
68 esac; 68 esac; 68
69 69 69
70 init(v_IsMaxSpeed) := {TRUE, FALSE}; 70 init(v_IsMaxSpeed) := {TRUE, FALSE}; 70 init(d_IsMaxSpeed) := TRUE;
71 next(v_IsMaxSpeed) := {TRUE, FALSE}; 71 next(v_IsMaxSpeed) := {TRUE, FALSE}; 71 next(d_IsMaxSpeed) := TRUE;
72 72 72
73 CTLSPEC AG(v_IsSprint -> AF !v_IsSprint) 73 CTLSPEC AG(v_IsSprint -> AF !v_IsSprint) 73 CTLSPEC AG(v_IsSprint -> AF !v_IsSprint)

(a) original model (b) optimized model (c) abstracted model

Figure3:3:Comparison
Figure Comparisonof
ofthe
theoriginal
originalmodel
modelwith
withthe
theoptimized
optimizedand
andabstracted
abstractedmodels
models

[14] Unity.
[14] Unity.2022.
2022. Unity
UnityReal-Time
Real-TimeDevelopment
DevelopmentPlatform
Platform| |3D,
3D,2D
2DVR
VR&&AR
AREngine.
Engine. [15] Unreal
[15] UnrealEngine
Engine5.5.2022.
2022.Blueprints
BlueprintsVisual
VisualScripting
ScriptingininUnreal
UnrealEngine
Engine| Unreal
| Unreal
https://unity.com/.
https://unity.com/. Engine5.0
Engine 5.0Documentation.
Documentation.https://docs.unrealengine.com/5.0/en-US/blueprints-
https://docs.unrealengine.com/5.0/en-US/blueprints-
visual-scripting-in-unreal-engine/.
visual-scripting-in-unreal-engine/.

View publication stats