top of page

- Character Data -


    Welcome! This section contains information and few examples about what certain functions and variables are that are inside our Characters. We also assume that you previously checked the Tutorials regarding the Fighter Basic Information and Creation.

    There will be certain System-Only variables, functions and many types of other things and in most cases they can be left alone and editing them can be dangerous. Therefore they won't be explained in detail.


    We will be using "Omen_Char" for this section which you should already be familiar in case you checked the tutorials mentioned above.

 1- Components

  • Scene is a "Scene Component" which holds all the other components that you see. You will also a lot of "... Container" named components which do basically the same thing; holding what is coming after them. Scene's icon is same with others regardless of their names and they serve the same purpose.

  • Ground is the red box you see around the Fighter's feet. It is a static box to let you easily position the Fighter.

    You can disable the visuals by the variable shown in the video with name
    "Ground Visual" to position your Fighter's Flipbook better.

  • Character Collision Box is the component that handles the collision between Characters, preventing each other from getting too close than they supposed to.

    Only Characters that are enemies of each other gets the treatment mentioned above. Same Team Characters do not get pushed away from each other.

It is suggested to not move the Box in X axis but it is safe to do so in Z. It must NOT have its scale properties changed as well. Instead "Box Extent" values should be changed to adjust its size as shown in the video. After the extent adjustments, the Box should be repositioned so that its bottom touches the ground. Of course Character Flipbook will need adjustments as well and you can do so as shown in the video above.

Feel free to also use the
"Character Collision Visual" variable to view it much easier.

  • Arrow Container holds Arrows that are System-Only but you can make them visible as shown in the video.

    It can be useful to see where your Character is looking at or which Enemy it is focusing to. Lean Back Direction Arrow (purple one) only gets updated when it touches a Stage Object with collision on (such as Stage Walls).

  • World Collision Box his used for interaction when it comes to Stage Objects that got collision on. It prevents Characters going out of Stage Bounds unless specified.

    As shown in video, we can toggle its visuals to edit its Box Extent values via "World Collision Visual" variable.

    This Component is completely locked to Character Collision Box and only its X axis Box Extent value can be changed.

This Component's all sub-components are System-Only and should not be touched by any means.

  • Character FB Main is the only one that is not a System-Only component that is connected to the Flipbook Container and can have its Transform values changed without issues.

    It is called "Main" as we will eventually add multiple Flipbook support to Characters.

  • Audio Container contains the channels that trigger sounds and it is System-Only.

 2- Graphs, Functions, Interfaces

  • Event Graphs can hold as much as Graphs you like. There is no code that needs to be in specific one to work.

  • For example "Input System" can be deleted and use the functions such as "Input State Definition" in another Graph.

  • The reason those Graphs exists is to keep things tidy and more understandable. There is no harm on spreading code around if we are not overdoing it.

  • In "Input System" Graph, you will see two Events which every Fighter can use.

  • Check Player Action Input - Delayed :
    This one triggers every time Player presses an ACTION Button. It got an internal delay of 2 frames to check dual and triple presses.

  • Check Player Movement Input - Instant :
    This one triggers every time Player presses a MOVEMENT Button. It triggers instantly and there is no internal delay.

  • We will talk about "Input State Definition" node in detail in a later section but feel free to jump to it by clicking here:

  • "Act System" is a single event called "Reset Act System".

      This event is called in various places and can also be called in anywhere if a developer wants. It        is used mainly in "Fighter_MainSM" which is the main state module for all Fighters that hold              States such as Standing, Jumping etc.

      Every time a Fighter gets his control back by any means, this event is triggered and a bool                  variable called "Act System Bool List" is reset to its default values.

  • "Unique Events" is a Graph that I made as an example and other Fighters don't need to have such a Graph. It currently contains 2 Events that are related to Stage Interactions which are triggered by our Stage that got interactable zones. However for now it is best to ignore them.

  • "Function and Interfaces" are full of System-Only properties. You can of course have your own function calls in them but that's not in scope of UF2D documentation/tutorials yet.

 3- Variables

  • Character Blueprints has tons of variables of their own. Fighters also inherit all of it. There are 3 sub categories that we will be talking shortly about and rest is Unreal Engine's own "Pawn" blueprint variables that we don't deal with much.

  • System Variables - DO NOT EDIT is the category that contains all the variables that should not be touched and is internally updated in game via UF2D itself. It is strongly advised to leave them alone unless you know what you are doing, as deleting / changing the values might break the Fighter you are working on.

  • Preload Asset System contains Folder Targets to load everything within said Folders and Subfolders. When a Fighter is selected to play, all these folders load with it. We will get to use it when we are making our first Fighter!

  • Gameplay Components contain extra functionality that a Fighter needs. Most of them can be left alone but not "Animation System" as it contains the animation data a Fighter needs.

  • Character Variables are safe to change and important to separate the Fighter from others. So let's check what they are about right below!

  • Character Name is the name that is shown on Fighting Zone UI.

  • Author Name is an optional variable of the developer.

  • Win Quote is the sentence that shows up in Win Quote Screen after a match ends. And the Flipbook is the one that shows up in the
    same menu.

  • Max Health is the total Health Points your Fighter will have and once it is zero it will be knocked out.

  • Health Segments is used if you want your Character to have its health represented by multiple health bars such as a boss character.

  • Max Power List is an Array that can contain all sort of powers a Fighter. Make it the regular Hyper Move bar to a Guard Meter, it is all up to you. We will get into these systems later on when UI is updated!

  • Attack / Defense Power Multipliers are there to increase / decrease how much a Fighter does/receives damage globally. 1.0 means no change, 2.0 means double amount and so forth.

  • Damage Reduction List is an Array that lowers the damage of all incoming attacks. For example, having 25 Defense would reduce the attack damage by 25%. Note that UF2D supports more than one Attack Type without a limit (for ex an Attack is physical while another one can be Fire).

  • Attack / Defense Type Multiplier List is unlike "Power Multipliers" above, are for specific attack types. If you are making a simple Fighting Game, there is mostly only one Attack Type so the list can be left with 1 item only (stating attack is a Physical for ex).

  • Default Laydown Time is how long a Fighter should lay down on the ground after receiving an attack that would make him fall.

  • KO Sound is for which sound to play when the Fighter is knocked out.

  • Buffer Online List is an advanced variable. Normally UF2D can support up to 5 input buffers but most of the time 1 is enough and so is the default value.

    Feel free to toggle the others and use a different channel in Input State Definitions!

  • Base Forward / Backward Speed is related to the speed a Fighter that walks around when in control and on ground as Player uses movement keys.

  • Jump Curves are there to change the way your Fighter Jump and Fall. Mostly related to the movement keys like above.

  • Can Crouch / Jump toggles whether your
    Character can do those actions are not.

  • Main State Module is the State Module BP that contains all the State data that a Fighter must have in order to function properly such as Idle, Moving, Guarding, Receiving Hit etc. All Fighters have "Fighter_MainSM" as default and If you want to have a different Idle State for ex, it is strongly suggested to make a Child BP out of it.

  • Intro and Outro State Modules are also baseline and must not be empty as they are triggered when a Round starts and ends. No need to make child BPs out of them. You can have your own State Modules for them. Please refer to the default SMs for more information about what's unique about them compared to regular SMs.

  • Guard / Dizzy Sys State Modules are there to make the Character be able to get guard broken once the meter is empty and get dizzied when it gets enough hits. Generally default values are enough but there will be more work done about them later on!

  • FZ Self UI State Module is there to let a Fighter have its own unique interface while in Fighting Zone (aka its own power bars etc).

  • Health Recovery State Module is used for getting health back in time when a certain Attack causes some damage to be recoverable. This is an additional internal support for making Marvel vs Capcom like games easier!

  • Collision Visual Toggles are for easier and better visualization of important Collision Boxes and Ground Display.

  • Collision Boxes will also visible in game if toggled on for a specific Fighter.


 4- Input State Definition

  • "Input State Definitions" allows us to have connection between the buttons you press and the States you want to trigger. They exist in Fighter Blueprints and demand certain Conditions to be met in order to trigger the said State.

  • Once a button or combination of them is done to trigger a State, the Input is stored and Input State Definitions check each whether the input belongs to them or not.

  • If the input is not related or conditions are not met, another Input State Definition is checked if it is linked to "Input Failure" output.

  • The more complex input an Input State Definition has, the further it must be in the beginning. For example a "Down + Forward + Punch" should be checked earlier than an Input State Definition with "Punch".

  • There can be many Input State Definitions sharing the same Input Combination.

  • Success Condition is a Boolean that you can link whatever you prefer as variable with multiple properties to check.

    Variables named "Character Stance", "State ID" and "Act System Array" are commonly used. Omen_Char has many examples so feel free to check it out.

  • Ability and Movement Input Checks are Enumeration values that are defined by "State Addon / Component Control Adjustment" nodes used in Character State Modules.

    They are not a must to use but can make things easier.

- General Settings -


- State Properties -

  • Trigger State toggles the State Trigger System off, allowing you to use the "Input Success" Output without worry of triggering a State if it is not needed.

  • Target State Module is used to determine which State Module to use when all Input conditions are met. You can not leave this empty.

  • State to Trigger is used to trigger which State to trigger in the Target State Module.

  • Post State Var List can be used to send data to the State Module while triggering it at the same time.

    Below image contains an example that where you can set a variable's value after triggering the State inside that State Module.

  • Input Name / Command Ref values are used for mostly debugging. They can be left empty. They are also entered in "Command Name List" and "Command Input List" when triggered once in game.

  • Force Exact Input prevents false positives from Input Buffering. For example, let's say you have a Move that has Input of "Forward + Forward". This Move would trigger even if you entered "Forward + Down + Forward" in game. This Boolean prevents that.

  • Input Channel is used to choose a Buffer that you would like to have for this Input Definition to use and count down before it resets.

- Input Settings / Required Input List / Miscellaneous -

  • Input Combination needs an Array Input which can be filled by using the Input Nodes shown below.

  • Movement Inputs can have up to 3 possibilities for confirmation on "Correct Input". For example this is useful in case you want the Player's "Down Forward" Input to be accepted as "Forward" as well.

  • Action Inputs can be singular or accept multiple presses at the same time. Useful if you want to make a "Heavy Punch + Heavy Kick" Input for your move.

  • Debug opens up a debug scene runtime which provides a wide information about the status of the Input State Definition once triggered.

    It attempts to provide useful data, allowing you to test and see why it succeeded or failed.

 5- Assist and Swap Calls

  • Assist Call is a system that UF2D supports internally. You need Team Mode 2 or 3 in Test Mode to be able to use it.

  • The idea is simple: Main Character of the Team calls for any other present for an assist. The said Fighter pops up, does its move and leaves.

  • Assist Calls are done by the Inputs specially assigned to them. For Player 1 they are Keyboard "1 2 3" and for Player 2 it is "5 6 7" for each Sidekick available in Teams.

  • All Fighters inherit the ability to call for Assists. The functions to trigger them are in "Fighter_Base", which is the Parent Blueprint of All Fighters that you make.

  • That being said, you can still change the Controls by disabling the Test Mode and going into Options.

  • Menus are still heavy work in progress so it won't let you unbind an input completely. For now feel free to leave it as it is.

  • If you don't want accidental Assist Calls via those inputs, feel free to unplug the Assist Call nodes from those Input Events.

  • It is of course possible to Trigger Assist Calls via Input State Definitions as well.

  • Optionally you can use Input State Definition solely for that purpose by disabling its State Trigger System as shown in the video.

  • Node for it is pretty simple. "Sidekick ID to Call" is used to select the Fighter to assist you.

  • It is suggested to keep the State variables Default for now, or at least check "State 5610" State that resides in "Fighter_MainSM" and see how we handle it all.

  • "State 5610" is when the Fighter arrives to Assist.

  • "State 5615" is reserved for Main Assist Action such as doing a move.

  • "State 5640" is for taking Fighter out of the Stage.

  • "State 5600" is the State where the Fighter is sent to the Void completely disabled. 

  • Swap Call is a system that UF2D supports internally too. You need Team Mode 3 in Test Mode to be able to use it.

  • Main Character calls for a Swap with a Sidekick and they switch roles. The switched Character loses control and leaves the Stage completely and the new Main Character gains control.

  • "State 5685" is when the Main Character calls for a Swap and departs afterwards.

  • "State 5650" is reserved for Sidekick that comes into the Stage.

  • "State 5660" is for Sidekick to do an post-arrival animation.

  • "State 5700" is for Sidekick arrive into the Stage if the Main Character gets KOed.

  • "State 5600" is the State where the Fighter is sent to the Void completely disabled. 

  • Node for it is also pretty simple. "Sidekick ID to Swap" is used to swap the current active Fighter.

  • It is suggested to keep the State variables Default for now, or at least check "State 5650" State that resides in "Fighter_MainSM" and see how we handle it all.

  • We will eventually get a Tutorial on how to handle both Assist and Swaps, just know that they are not any much different than regular States aside from editing Stage Presence and Player Control toggling!

  • That is it for Character Data. I will be adding further stuff as things progress so stay tuned!

Char Components
Char GFI
Char Var
Char ISD
Char A&S
bottom of page