A brief overview on scripting with ORK Framework.

You can find an overview of all available classes in the API documentation.

See the Makinom scripting documentation for all Makinom-related scripting information. E.g. things like schematics or input keys are Makinom functionality and there are a lot of things that can be extended that are also used by ORK features.

When scripting with ORK Framework, either add the GamingIsLove.ORKFramework namespace (using) or implement your class in the GamingIsLove.ORKFramework namespace. In most cases you’ll also need to add Makinom’s namespace GamingIsLove.Makinom to be able to access Makinom functionality (e.g. input keys).

// add ORK Framework namespace
using GamingIsLove.ORKFramework;

// or use ORK Framework namespace
namespace GamingIsLove.ORKFramework
{
	
}

// add Makinom namespace
using GamingIsLove.Makinom;

Please note that some of ORK Framework’s classes are in separate namespaces, e.g. GamingIsLove.ORKFramework.Components is used for all component classes of ORK Framework.

The ORK class #

Most of what you need is accessible through the ORK class (similar to the Maki class for Makinom functionality). It holds references to all ORK data directly referenced by the project (e.g. combatants) and handlers for an easy and centralized access point.

Accessing settings and data #

All individual data list entries are stored as separate assets, only some of them can be accessed through the ORK class due to being directly referenced by the project asset:

• ORK.ControlMaps
• ORK.ActionCombos
• ORK.Classes
• ORK.Combatants
• ORK.Factions
• ORK.Formations
• ORK.ResearchTrees
• ORK.ResearchTypes
• ORK.Areas
• ORK.AreaTypes
• ORK.Difficulties
• ORK.Logs
• ORK.LogTexts
• ORK.LogTypes
• ORK.Quests
• ORK.QuestTasks
• ORK.QuestTypes
• ORK.Teleports
• ORK.AIBehaviours
• ORK.AIRulesets
• ORK.AITypes
• ORK.CraftingRecipes
• ORK.CraftingTypes
• ORK.Currencies
• ORK.ItemTypes
• ORK.Items
• ORK.EquipmentSlots
• ORK.Equipment
• ORK.InventoryContainers
• ORK.Abilities
• ORK.AbilityTypes
• ORK.AttackModifiers
• ORK.DefenceModifiers
• ORK.StatusEffects
• ORK.StatusValues
• ORK.StatusTypes
• ORK.ConsoleTypes
• ORK.MenuScreens

E.g. if you want to get a combatant, you can access it like this:

CombatantSetting combatant = ORK.Combatants.Get(index);

index is an int value representing the index of the combatant in the Makinom editor’s list. You can also access them via their GUID (string):

CombatantSetting combatant = ORK.Combatants.Get(guid);

guid is a string value representing the GUID of the data.

Beside data list entries, you can also access the general settings, e.g.:

• ORK.GameControls
• ORK.GameSettings

Handlers #

There are multiple handler classes that manage parts of a running game.

Instances of those handlers can be accessed via the ORK class during a running game – some examples:

• ORK Game Handler: ORK.Game
  The Game Handler manages all in-game related data, e.g. the player, global variables, factions, game time, language, etc.
  
• ORK Player Handler: ORK.Game.PlayerHandler
  The ORK Player Handler holds the reference to the player groups.
  
• Access Handler: ORK.Access
  The Access Handler is a feature that allows you to inject functionality in many ORK functionality calls.
  Learn more about the access handler feature in this documentation.

Data Assets #

Data of things like combatants, items or input keys are all stored in individual assets.

They are like any regular Unity asset and can be referenced in your custom scripts and components, e.g. an item:

public ItemAsset item;

You can access the settings of an asset via the Settings property, e.g. checking if an item is dropable:

if(item.Settings.dropable)

As mentioned above, only some of the data assets are directly referenced by the project asset and accessible via the central ORK class (or Maki class for Makinom data assets, e.g. input keys). This is due to initializint the project via a game starter also needs to load all references assets, leading to long load times if everything is directly referenced by the project.

Save Games #

You can add custom save data to your save games – see the Makinom custom save data documentation for details.

Additionally, ORK supports saving component data on a combatant’s game object, see the custom component save data documentation for details.

Custom Nodes #

Adding custom nodes to schematics or formulas doesn’t require implementing them in a plugin or ORK/Makinom’s source code – you can just add them in a script file in your Unity project.

You can find more details about custom battle AI node implementations in this documentation.

You can find more details about custom node implementations for schematics and formulas in the Makinom custom nodes documentation.

Schematic Nodes #

Schematic nodes must descend from BaseSchematicNode or any other schematic node class (e.g. BaseSchematicCheckNode for the default Success/Failed slot implementation).

Formula Nodes #

Formula nodes must descend from BaseFormulaNode or any other formula node class (e.g. BaseFormulaCheckNode for the default Success/Failed slot implementation).

Battle AI Nodes #

Battle AI nodes must descend from BaseAINode or any other battle AI node class (e.g. BaseAICheckNode for the default Success/Failed slot implementation).

Code Extensions #

You can extend many of ORK Framework’s type selections and settings with custom implementations by simply adding new scripts descending from a base type class.

Learn more in the code extension documentation.

For extending Makinom functionality, see the Makinom code extension documentation.

Source Code Project #

The full source code included in ORK Framework’s full/paid version is a Visual Studio 2017 project and should be ready to use out of the box.

The required references to Unity DLLs and functionality are already set up (the DLLs are included in the project’s bin/References folders). If you want to use different Unity versions than provided, just replace the references with the libraries you want to use.