Starting your development

Developing your own custom digital twin solutions with c#

This page gives you some hints on how you should organize your own developments. For more information about development, in general, please check the Unity documentation or tutorials.

Selecting a Unity Version

We strongly recommend using, as we do, the latest Unity LTS (Long Term Stable Release - https://unity3d.com/unity/qa/lts-releases). This gives you a stable base Version of Unity for your own developments. For sure you can use also newer Unity Versions but this is riskier and we can’t guarantee full compatibility of all realvirtual.io features and functions.

Create your own solution folder

To separate your own development from the realvirtual.io standard Asset it is recommended to organize your own developments in your own folder under the Unity Asset folder. For example, create a Folder MyDevelopment:

As soon as updates for realvirtual.io are available you can import the Asset without risking to override anything of your developments.

Set the assembly definition

You don't need to use assembly definition but we recommend it for larger projects, because it reduces compile time and increases the separation of your classes.

The realvirtual.io framework is organized in different assemblies which are defined by Assembly Definitions. You must create your own Assembly and reference the game4automation assembly definition. For doing this you must create your assembly definition on the top level of your folder. In your assembly definition you must reference game4automation.base to be able to use the realvirtual.io scripts and classes.

Use a new namespace

It is recommended to use your own namespace for example MyNamespace to separate your classes from the standard classes. To use the realvirtual.io classes you need to include game4automation in your using statement. A base MonoBehavior of your solution could look like this:

using UnityEngine;
using realvirtual;

namespace MyNamespace
{
    public class myownbehaviour : MonoBehaviour
    {
        // Start is called before the first frame update
        void Start()
        {

        }

        // Update is called once per frame
        void Update()
        {

        }
    }
}c

realvirtual.io base component

Most realvirtual.io scripts are based on the Game4AutomatiohBehaviour Class and most of them are using settings that are stored in the Game4AutomationController inside the realvirtual.io prefab. Your scene should include at least the Game4AutomationController . After dragging the Game4AutomationController Asset into your scene you could parts of it if you don’t want to use the UI functions, the lights, the camera or the Scene Navigation. If you delete all this you will need to define your own camera script with mouse navigation and your own lights.

Build your own behavior models

One important part of realvirtual.io are Behavior Models. They link the inputs and outputs to generic Drives and Sensors. In the Behavior Models you can define your own behavior (e.g. your very special motor) and link this to the base Drive. For doing so your own class must inherit from BehaviorInterface.

Here is a very simple example of a Drive behavior which is controlling the Drive with one single Signal (a boolean):

using game4automation;
using UnityEngine;

namespace MyNamespace
{    
    [RequireComponent(typeof(Drive))]
    public class myownbehaviour : BehaviorInterface
    {
        public PLCOutputBool StartMotor;
        private Drive drive;
        
        // Start is called before the first frame update
        void Start()
        {
            drive = GetComponent<Drive>();
        }

        // Update is called once per frame
        void Update()
        {
            if (StartMotor.Value == true)
                drive.JogForward = true;
            else
                drive.JogForward = false;
        }
    }

With the RequireComponent tag, you are defining that your script needs a Drive attached to the same Gameobject. If not a Drive will automatically be added.

GetComponent is a time-consuming method, this is why it is better to get a reference at startup (here the private variable drive)

If you attach your Behavior to a component you will automatically see the Icon in the Hierarchy window:

Please note, that in the example the PLCOutputBool must be assigned. If not a NULL error will happen. To do a null check like PLCOutputBool!=null is possible, but Null checks are also expensive. It is better to check at the Start or Awake function if it is Null and set a local variable. Rider as and advanced development framework is even automatically able to do this. This is how the final and runtime optimized code is looking like:

Derive your classes from base classes

In more advanced use cases you might want to develop your own Drive. You could derive your class from the standard Drive or if you want to start from scratch you could derive from the class BaseDrive. If you derive from the BaseDrive you will need to develop the full kinematic and positioning functions yourself.

Improve the inspector appearance of your scripts

realvirtual.io is using in more and more components NaughtyAttributes for better user experience with the public script attributes. You will need to include the naughtyattributes namespace in your using statement for being able to use NaughtyAttributes. You can get the documentation of NaughtyAttributes here:

PreviousAssembly DefinitionsNextClass documentation

Last updated