Starting your own project

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 Game4Automation features and functions.

Create your own solution folder

To separate your own development from the Game4Automation 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 Game4Automation are available you can import the Asset without risking to override anything of your developments.

Set the assembly definition

The Game4Automation 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 Game4Automation 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 Game4Automation classes you need to include game4automation in your use statement. A base MonoBehavior of your solution could look like this:

Base Monobehaviour
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
using UnityEngine;
using game4automation;

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

}

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

}
}
}

Game4Automation base component

Most Game4automation scripts are based on the Game4AutomationBehaviour Class and most of them are using settings that are stored in the Game4AutomationController inside the Game4automation prefab.
Your scene should include at least the Game4AutomationController. After dragging the Game4Automation 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.

In this example all UI components, the second lights, and the base plate have been deleted:

Build your own behavior models

One important part of Game4automation 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):

Base Monobehaviour
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
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:

Nullchecks
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

using game4automation;
using UnityEngine;
namespace MyNamespace
{
[RequireComponent(typeof(Drive))]
public class myownbehaviour : BehaviorInterface
{
public PLCOutputBool StartMotor;
private Drive drive;
private bool _isStartMotorNotNull;

// Start is called before the first frame update
void Start()
{
_isStartMotorNotNull = StartMotor != null;
drive = GetComponent<Drive>();
}

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

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 usability of your scripts

Game4Automation is using in more and more components NaughtyAttributes for better user experience with the public script attributes. You will need to include the game4automationtools namespace in your using statement for being able to use NaughtyAttributes. You can get the documentation of NaughtyAttributes here: https://github.com/dbrizov/NaughtyAttributes


© 2019 in2Sight GmbH https://game4automation.com - All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including printing, saving, photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher.