Forem: Omar

Patterns in gameplay programming, Command

Omar — Wed, 18 Jul 2018 03:43:43 +0000

I'll be starting a series on design patterns applied to real-life gameplay programming using Unity3D along with sample scene explaining one mechanic, by following Matt, our imaginary gameplay programmer who just joined the studio.

CTRL+Z:

Matt came to his office this morning, motivated, he is working on Paladins Tactics, a turn based RPG for mobiles. When opening Slack, he discovers his product manager just assigned him this story

As a player, i should be able to undo my actions and change them
before ending the turn.

With an explanation image that shows the wanted result:

Our developer scratches his head, all of the gameplay mechanics like movements and attacks were deeply hardcoded in the Player related components that decoupling them would be insanely hard.
Well, not that much, enters the Command pattern, quoting wikipedia:

In object-oriented programming, the command pattern is a "Behavioral pattern" pattern in which an object is used to encapsulate all information needed to perform an action or trigger an event at a later time.

'at a later time' may make it sound like a callback, a simple slugline for it would be "an object-oriented replacement for callbacks"

In every video game there is some functionnality that reads raw user input from the player and translate it into something of value inside the game world, and Matt's implementation was dead simple but working during conception:

     void HandleInput()
    {
        //....other inputs tied here
        if (Input.GetButton("BUTTON_X"))
        {
            Move();
        }
        //....other inputs tied here
    }

While this was working just fine during the early stages, it poses the problem of not letting the user configure his/her own input scheme, it forces us to write duplicate code for other moving units not controlled by the player and finally, makes implementing our undo feature a pain in the arse, enter our pattern.

Command:

we start by defining a base class that represents any triggerable game action:

/// <summary>
/// The 'Command' abstract class that we will inherit from
/// </summary>
abstract class Command
{
    public abstract void Execute();
    public abstract void UnExecute();
}

We could then create a set of subclasses for each of our actions in game, in our case here, just movement:

class MoveCommand : Command
{
    private MoveDirection _direction;
    private float _distance;
    private GameObject _gameObject;
    //Constructor
    public MoveCommand(MoveDirection direction, float distance, GameObject gameObjectToMove)
    {
        this._direction = direction;
        this._distance = distance;
        this._gameObject = gameObjectToMove;
    }
    //Execute new command
    public override void Execute()
    {
        MoveOperation(_gameObject, _direction, _distance);
    }
    //Undo last command
    public override void UnExecute()
    {
        MoveOperation(_gameObject, InverseDirection(_direction), _distance);
    }

    // Rest of code, MoveOperation can just be a method that translates a Transform with a given distance
}

By passing it an actor we want move, we loosen restrictions and make that command also callable by an AI agent rather than only the player input controller. Then we can just implement the rest of our Player Movement Handler, it would be a Monobehaviour existing somewhere in our scene.
Note to mention, this implementation varies slightly from a standard one due to the Undo mechanic, commands here represent something that can be done at a specific point in time and thus we should keep track of them.

public class PlayerMovementHandler : MonoBehaviour
{
    public float moveDistance = 10f;
    public GameObject objectToMove;

    private List<Command> commands = new List<Command>();
    private int currentCommandNum = 0;

    void Start()
    {
        // some null checks
    }

    private void Move(MoveDirection direction)
    {
        MoveCommand moveCommand = new MoveCommand(direction, moveDistance, objectToMove);
        moveCommand.Execute();
        commands.Add(moveCommand);
        currentCommandNum++;
    }

    public void Undo()
    {
        if (currentCommandNum > 0)
        {
            currentCommandNum--;
            MoveCommand moveCommand = (MoveCommand)commands[currentCommandNum];
            moveCommand.UnExecute();
            commands.Remove(moveCommand);
        }
    }
    // Simple public move methods below
    // to attach to UI buttons, Gamepad buttons
    // EventSystem or whatever
    //....
}

a fully downloadable sample can be foud here.

reference:

Robert Nystrom's Game Programming Patterns book, language and framework agnostic.

Credits to Free visual assets used in this post:
RPG Hero HP, Medieval Town Exteriors, Simple UI

VR Locomotion tips, 2017 Edition

Omar — Tue, 23 Jan 2018 05:14:49 +0000

originaly posted in my blog here

For a medium that is only 2 years old in the hand of the mainstream customer, we can say that virtual reality's user interaction and experience is evolving very fast. And more with the introduction of AAA studios in the game like Bethesda.

Let's pick some of 2017 UX ideas and add them to more classic locomotion methods.

Design ideas inspired by Windows MR's Cliffhouse (the VR menu) as well as Bethesda's Doom/Fallout VR.

Pre-Requisites:

Repo is available here
Foremost, we will be using Oculus GearVR for these, it should work without hassle for the Rift since it is using the Oculus Utilitie's CameraRig, and could easily be rewritten for Daydream and/or SteamVR as most of the interaction is in ArcTeleporter.cs.

What is in there ?:

Our main orientation method will be the Arc (also known as Bezier) teleporter that let us point to where we are going using hand tracked controllers. and the two classical locomotions would obviously be the Blink Teleport, and the Dash. Then we'll see what could we add to make them better. But first, let's tackle a boring part about curves.

Bezier Curves

A Quadratic Bézier curve would be the easiest way to implement an arc teleporter, the other being a parabolic curve.
It consists of three points: start/end points and a control point. And two line segments: a first one 'S0' between the start and control point, and a second 'S1' between the control and the end points.

Two additional points, Q0 and Q1 will be obtained by interpolating along S0 and S1 by some value t with a range between 0 and 1. And another segment S2 will be created by connecting Q0 and Q1, then by interpolating along this segment, a point 'Q2' would be the result that creates our curve.

This can be expressed with this snippet:

Vector3 SampleCurve(Vector3 start, Vector3 end, Vector3 control, float t) {
      // Interpolate along line S0: control - start;
      Vector3 Q0 = Lerp(start, control, t);
      // Interpolate along line S1: S1 = end - control;
      Vector3 Q1 = Lerp(control, end, t);
      // Interpolate along line S2: Q1 - Q0
      Vector3 Q2 = Lerp(Q0, Q1, t)
      return Q2; // Q2 is a point on the curve at time t
  }

Blink Teleport

This method was the first to be adopted as a motion sickness-free viable method of locomotion in most early VR experiences, either with a fading in/out or immediate. by either pointing to static teleport points or -what we are using- the Arc teleporter.

Sidenote/History: In VR, the developer gives full control of the camera to the player's...neck, that is part of the deal. But for the sake of accessibility, some way to support seated vr play was necessary. Oculus started to ask for a "snap rotation" using the joysticks as a best practice for their games and thus it became common nowadays. That bring us to our issue: mobile VR controllers only have a trigger and a touchpad.

Microsoft's implemented this just right in their cliffhouse menu by letting the user calibrate it's facing rotation while teleporting. A modest implementation looks like:

Bezier Teleport

//......SOME CODE.......

// Unity Methods
void Update () {
        if (!HasController) {
            return; 
        }
        bool currentTriggerState = OVRInput.Get (OVRInput.Button.PrimaryIndexTrigger);

        // If the trigger was released this frame
        if (lastTriggerState && !currentTriggerState) {
            Vector3 forward = objectToMove.forward;
            Vector3 up = Vector3.up;

            // If there is a valid raycast
            if (arcRaycaster!= null && arcRaycaster.MakingContact) {
                if (objectToMove != null) {
                    if (teleportedUpAxis == UpDirection.TargetNormal) {
                        up = arcRaycaster.Normal;
                    }
          objectToMove.position = arcRaycaster.HitPoint + up * height;
                }
            }

            if (OVRInput.Get (OVRInput.Touch.PrimaryTouchpad)) {
                forward = TouchpadDirection;
            }
      objectToMove.rotation = Quaternion.LookRotation(forward, up);
        }
        lastTriggerState = currentTriggerState;
}

// Helper Methods
Matrix4x4 ControllerToWorldMatrix {
        get {
            if (!HasController) {
                return Matrix4x4.identity;
            }

            Matrix4x4 localToWorld = arcRaycaster.trackingSpace.localToWorldMatrix;

            Quaternion orientation = OVRInput.GetLocalControllerRotation(Controller);
            Vector3 position = OVRInput.GetLocalControllerPosition (Controller);

            Matrix4x4 local = Matrix4x4.TRS (position, orientation, Vector3.one);

            Matrix4x4 world = local * localToWorld;

            return world;
        }
    }

Vector3 TouchpadDirection {
        get {
            Vector2 touch = OVRInput.Get(OVRInput.Axis2D.PrimaryTouchpad);
            Vector3 forward = new Vector3 (touch.x, 0.0f, touch.y).normalized;
            forward = ControllerToWorldMatrix.MultiplyVector (forward);
            forward = Vector3.ProjectOnPlane (forward, Vector3.up);
            return forward.normalized;
        }
    }

  //...........MORE CODE...............

Dash Teleport:

Very cool for action fast paced games/experiences, the dash gives the user a sense of power and was well designed in DOOM VR (as well as the flat screen Doom game btw), but if improperly implemented can induce sickness.
The culprit here is the Field of View, while it can be pretty wide if you're in your couch watching TV, it get reduced if you're walking, running or focusing on a task in front of you. That bring us to the tunneling effect.

View post on imgur.com

Implementation makes use of a mask attached to a Quad/Plane/UIPanel child of our main camera. then by tweaking the alpha or the scale it creates a cool vignette effect that reduces the FOV while moving. a sample of a mask can be created in 3 clicks in photoshop and looks like:

Conclusion:

VR is still a great terrain for R&D and experimentation, and what is accepted today as good practice will surely become tomorrow's mistake. so don't take these for granted and feel free to experiment, tweak and playtest(A LOt) as you want.

Automating Unity3D Assets Import

Omar — Sat, 11 Nov 2017 16:53:52 +0000

Games aren't always made by a one-man-team but involve several developers, who are people akin to making mistakes,that in turn increase dev cost time.
Importing assets is no joke, with the default settings and different rules for different parts of your project, let's start with this premise and ask ourselves: "can we write tools to prevent common, costly mistakes ?"

the answer is yes and let's discover one cool Unity3D Class.

AssetPostprocessor:

the AssetPostProcessor class receive callbacks on importing something. it implements OnPreProcess* and OnPostProcess* methods and apply your rules to the assetImporter instance.
therefore we can write rules that prevent some common mistakes, let's take textures for instance, we can ensure:

setting the texture type (deault, sprite, etc..)
making sure Read/Write is disabled.
disabling mipmaps for anything that is 2D or UI (it is enabled by default).
forcing a max texture size

public class AssetImportSample : AssetPostprocessor {

    void OnPreprocessTexture()
    {
        if (assetPath.Contains("_UI") || assetPath.Contains("_Sprite"))
        {
            TextureImporter textureImporter = (TextureImporter)assetImporter;
            textureImporter.textureType = TextureImporterType.Sprite;
            textureImporter.spriteImportMode = SpriteImportMode.Multiple;
            textureImporter.mipmapEnabled = false; // we don't need mipmaps for 2D/UI Atlases

            if (textureImporter.isReadable)
            {
                textureImporter.isReadable = false; // make sure Read/Write is disabled
            }
            textureImporter.maxTextureSize = 1024; // force a max texture size
            Debug.Log("UI/Sprite Audit Complete");
        }
    }
}

Now with the above script, is it easier for the team to comply to naming conventions rather than cherrypick settings for different parts of a project.

we can also implement the same OnPreprocessModel() method for meshes to audit some common errors:

• Make sure Read/Write is disabled
• Disabling rig on non-character models (it fixes the auto added Animator component)
• Copy avatars for characters with shared rigs
• Enable mesh compression

and of course, also applies for Audio.