Category Archives: devblog

Demo Reel: Patch Prototype

I got the art for the first prototype from Clay recently, and so I reached out to my music guy, Georgie, to get some sound to back the demo up. Georgie mentioned he’d like to get a demo video to help during composition, so I put something together last night.

I’m tempted to call this the Soul Patch, but that’s probably not a good idea, given Georgie borrowed a banjo recently.

I’m prototyping with this level because it requires most of the elements I expect to need for every level in the full game, without requiring many single-use graphics or effects.

So far it’s been interesting. This level marks my first exposure to the Animation system in Unity, and it’s been interesting. I found myself struggling at first to understand how to put things together, because I really wanted to administrate state changes centrally, but once you’ve given up on that notion, things become fairly simple – import a sprite, create a GameObject, drag a set of animation frames over the object, and the Animation editor takes it from there.

I’m using a couple of control variables to manage transitions to new states, and I think I’ll probably end up allowing the Animation to drive the rest of my gameplay.

I’m not sure that’s the most efficient solution here, but it’s certainly the most straightforward, and to be honest, Beat Farmer isn’t likely to be a technically demanding game. My primary concern is keeping it relatively manageable in terms of development effort.

It’s nice, though. My little beets are growing up so fast!

Solo dev: Bizdev edition

I’ve been working on getting the non-gameplay aspects of  Beat Farmer figured out of late, and that has meant getting some of the basics figured out for Perfect Minute as a functioning business.

Before I did anything, I needed to commit to the business more heavily than I have been. I have an aversion to not paying people for their work, so I started putting away $100 per paycheque from my day job. There are a variety of opinions on funding game development, some of which encourage you to self-fund, others focused more on external investment, but as a rule I find that paying out of pocket helps me remember to look for the best possible value for my money, so that’s my preferred bootstrapping method.

With that tiny pot of money, my first order of business was finding an artist. I’m trying to hire locally where possible, so I sent out a call on this blog and on my friendly local game development Facebook community. I got a few portfolios right away, including an artist I was very interested in working with, Clay Burton.

Finding someone so quickly meant I had to scramble a bit to get the contract drawn up. I initially considered using Law Depot, but I didn’t feel confident that I would get something I could trust to legally enforce the rights I needed.

I looked around town to find a lawyer specializing in IP and media and settled on Lindsay Wareham at Cox and Palmer, whose focus areas include Intellectual Property and Startups, which seemed like a good fit. I’ve since discovered that Cox and Palmer have several folks working together in this area, as well as a helper program for startups in general, which gives me hope that I have, for once, made a pretty good call.

The drafting of the contract took a couple of weeks and wasn’t too expensive, as legal matters go. A lot of good questions came up during my conversation with Lindsay, though, stuff like:

  • Are you incorporating? (not yet)
  • What share structure do you intend to use for your corporation? (not sure, and I have conflicting information about the best structure to use)
  • Where will the copyright and moral rights reside? (with me until incorporation)
  • Do you foresee selling products other than games? (yes)
  • Do you need trademarks registered? (yes, when I have a bit more money)

Two weeks later I had a shiny new contract ready to fill out. I sent it over to my artist, who sent it back with his name on it…but not a witness! This is my first time doing this, and I didn’t want to bug the guy more than necessary, but after chatting with Lindsay, I had to go back and beg him to get it witnessed as well. So that’s ready to go.

I also sent out a call a while ago for a music person for the game, and I use the word “person” on purpose there, because I don’t know much about doing music in a game.

One of the musicians I know in town recommended his buddy, Georgie Newman. Georgie and I had spoken briefly after that initial request, but never got around to talking further. I reached out and we decided to meet up and chat.  That turned out to be really great for me, as Georgie knows what he is at to a much higher degree than I do when it comes to game audio.

That conversation has now left me with a number of things I need to do (“action items”, as the cool fogies say):

  • Flesh out the design for Beat Farmer enough to do cost and marketing plans
  • Figure out how much Beat Farmer is going to cost to make and market
  • Figure out the best sales model for this game and its follow-ons
  • Figure out how I’m going to fund the first few Perfect Minute Games ($50/week ain’t gonna cut it forever, after all)

As error-prone dark-groping goes, this has actually been ok. I’m hopeful that I can get all the way to the publishing phase without destroying myself and/or the company financially or otherwise in the process.

I’ll keep you posted!

Small art contract

As I mentioned on Twitter,

I’m looking for a freelance artist to do a small job for Beat Farmer.

I’m looking for someone who can do clean 2d/3d work in a cute/cartoon style. If you happen to know anyone who might suit,  please have them send a portfolio to mgb@perfectminutegames.com.

Super Simple Unity Surface Shader

As part of a project I’m involved with, I’ve been back at the shader business a little bit lately. In particular, I’ve been interested in how to provide input to a shader to allow dynamic displays of various kinds.

This post will be super-basic for those of you who already know how to write shaders, but if you’re just starting out with them and using Unity, it may provide a little extra help where you need it.

The shader explained below is a surface shader, which means that it controls the visual characteristics of particular pixels on a defined surface, and more particularly that it can interact with scene lighting. It also means that Unity does a lot of heavy lifting, generating lower-level shaders out of the high level shader code.

Doing this the way I am below is probably overkill, but since I’m learning here, I’m gonna give myself a pass (Shader Humour +1!).

Creating and Using a Surface Shader in Unity

In Unity, a Shader is applied to a rendered object via the object’s Material.  As an example, in the screenshot below, a shader named “PointShader” is applied to a Material named Upstage, which is applied to a Quad named Wall.

You can see in the UI that the Upstage material exposes two properties (actually 3, but we can ignore one of them), Color and Position. These are actually custom properties. Here’s a simplified version of the shader code for PointShader.


Shader "Custom/PointShader"{
  Properties {
    _MainTex("Dummy", 2D) = "white" {}
    _MyColor ("Color", Color) = (1,1,1,1)
    _Point ("Position", Vector) = (0, 0, 0, 0)
  }
  SubShader {
    // Setup stuff up here
    CGPROGRAM
    // More setup stuff

    sampler2D _MainTex;
    fixed4 _MyColor;
    float4 _Point;

    // Implementation of the shader
    ENDCG
  }
}

That “Properties” block defines inputs to the shader that you can set via the material, either in the Unity editor or in script.

In this case, we’ve defined 3 inputs:

  1. We will ignore _MainTex below because we’re not really using it except to ensure that our generated shaders properly pass UV coordinates, but basically it is a 2D graphic (that is, a texture). It’s called “Dummy” in the editor, and by default it will just be a texture that is flat white
  2. _MyColor (which has that My in front of it to avoid any possible conflict with the _Color variable that exists by default in a Unity Surface Shader)  is a 4-component Color (RGBA). This type is basically the same as the Color type used everywhere  else in Unity. This variable has the name “Color” in the editor, and defaults to opaque white.
  3. _Point is a 4-component Vector, which is slightly different from a Color in that it uses full floating point components, as you can see in the SubShader block. It’s referred to as Position in the Unity UI. The naming is up to you; I’m just showing you that you can use one name in code and a different one in the editor if you need to. It defaults to the origin.

As you can see in the screenshot above, you can set these values directly in the editor, which is pretty handy. The real power of this input method, however, comes when you start to integrate dynamic inputs via scripting.

PointShader was created as a sort of “selective mirror”. It allows me to apply an effect on a surface based on the location of an object in my scene. In order to do this, I have to update the _Point property of my material.  The code below shows how I’m doing that in this case.


public class PointUpdate : MonoBehaviour {
  public Vector2 texPos;
  internal override void Apply(Vector3 position) {
    var transformedPoint = this.transform.InverseTransformPoint(position);
    var tempX = .5f - transformedPoint.x / 10;
    var tempY = .5f - transformedPoint.z / 10;
    texPos = new Vector2(tempX, tempY);
    var material = this.GetComponent<MeshRenderer>().material;
    material.SetVector("_Point", texPos);
  }
}

Whenever my tracked object moves, it calls this Apply method, supplying its own position as a parameter. I then map that position to the local space of the object on which my shader is acting:

transformedPoint = this.transform.InverseTransformPoint(position);

Then I turn that mapped position into coordinates on my texture.

Three things you should know to understand this calculation:

  1. Texture coordinates are constrained to the range of 0 to 1
  2. A Unity quad has sides of length 10
  3. In this case my texture coordinates are inverted to the object orientation

var tempX = .5f - transformedPoint.x / 10;
var tempY = .5f - transformedPoint.z / 10;
texPos = new Vector2(tempX, tempY);

Finally, I set the value of _Point on my material. Note that I use the variable name and NOT the editor name here:

material.SetVector("_Point", texPos);

With this value set, I know where I should paint my dot with my shader. I use the surf() function within the shader to do this. I’ve added the full SubShader code block below.


SubShader {
  Tags { "RenderType"="Opaque" }
  LOD 200
        
  CGPROGRAM
  // Physically based Standard lighting model, and enable shadows on all light types
    #pragma surface surf Standard fullforwardshadows

  // Use shader model 3.0 target, to get nicer looking lighting
  #pragma target 3.0

  sampler2D _MainTex;
  fixed4 _Color;
  float4 _Point;

  struct Input {
    float2 uv_MainTex;
  };

  void surf (Input IN, inout SurfaceOutputStandard o) {
    if(IN.uv_MainTex.x > _Point.x - 0.05
        && IN.uv_MainTex.x < _Point.x + 0.05
        && IN.uv_MainTex.y > _Point.y - 0.05
        && IN.uv_MainTex.y < _Point.y + 0.05 ) {
      o.Albedo = _Color;
      o.Alpha = 1;
    } else {
      o.Albedo = 0;
      o.Alpha = 0;
    }
  }
  ENDCG
} 

The Input structure defines the values that Unity will pass to your shader. There are a bunch of possible element settings, which are described in detail at the bottom of the Writing Surface Shaders manpage.

The surf function receives that Input structure, which in this case I’m using only to get UV coordinates (which, in case you’re just starting out, are coordinates within a texture), and the SurfaceOutputStandard structure, which is also described in that manpage we talked about.

The key thing to know here is that the main point of the surf() function is to set the values of the SurfaceOutputStandard structure. In my case, I want to turn pixels “near” my object on, and turn all the rest of them off. I do this with a simple if statement:

  if(IN.uv_MainTex.x > _Point.x - 0.05
    && IN.uv_MainTex.x < _Point.x + 0.05     && IN.uv_MainTex.y > _Point.y - 0.05
    && IN.uv_MainTex.y < _Point.y + 0.05 ) {
  o.Albedo = _Color;
  o.Alpha = 1;
} else {
  o.Albedo = 0;
  o.Alpha = 0;
}

Albedo is the color of the pixel in question, and Alpha its opacity. By checking whether the current pixel’s UV coordinates (which are constrained to be between 0 and 1) are within a certain distance from my _Point property, I can determine whether to paint it or not.

At runtime, this is how that looks:

It’s a simple effect, and not necessarily useful on its own, but as a starting point it’s not so bad.

Adventure Time: Shaders

I’ve made a commitment to myself this year to learn more about low level programming. There are two parts to that effort.

The first is C++, a language with which I’ve had a love-hate relationship for years. I’ll talk in detail about this someday soon, but suffice it to say for now that I am trying to get more comfortable with all of the different quirks and responsibilities that come with that shambling mound of a language.

The second, which is, in its own hyper-specific way, both more interesting and less frustrating, is shaders. In case you don’t do this sort of thing much, shaders come in two basic flavours, vertex and pixel.

I don’t know where this goes, not yet. I’ve decided to write a talk for Gamedev NL, which will be a good way to crystallize whatever knowledge I gain in the process. Might not be the best possible presentation for the purpose, but we’re a small community, and I think people will appreciate it for whatever it is.

Shaders have long since hit criticality; they’re practically boring. You have only to look at sites like Shadertoy and ShaderFrog  to see that. But there’s something very spectacular about seeing the results of a tiny bit of code output the most realistic ocean you’ll never see, or the very foundations of life.

I mean, that’s cool, at least in my world. If you know how to build something like that, you got my vote for prom queen or whatever.

So that’s a thing I want a little more of in my life. I’ll talk about it as I go. I don’t have much specific purpose for this right now; Contension‘s not going to need this stuff for a good long time, but I’ll find something interesting to do with it.

Talk to you soon
mgb

Unity: Always a Work in Progress

While working on a couple of non-PMG projects, I was reminded that while Unity have had a banner year (couple of years, even) for major built-in feature upgrades – shaders, networking, UI, and services, to name a few – there are still some hard gaps.

The first problem I hit showed up while I was working on an enterprise-ey integration for the editor. The preferred data format in the enterprise these days tends to be JSON, so you need a JSON parser of some kind to be able to push data in and pull it out of systems. There are lots of third-party libraries that do this, but there are also framework-native options for most languages.

In Unity, the options for JSON are System.Web – which actually recommends a third-party library(!) and, as of the 5.5 beta experimental lane, System.Json, which is meant for use with Silverlight, but has the most desirable semantics and a fluent interface for dealing with JSON objects.

Having said all that, the best option right now for immediate use is still Json.NET, which has very similar semantics to System.Json but has the advantages of being compatible with the 2.0/3.5 .NET runtime and being mature enough to be fluent and fast.

This was my first time pulling a third-party .NET DLL into Unity, so it took a little while to understand how to get the system to see it. It turns out the process is actually super-simple – you just drop it into the Assets folder and use the regular Edit References functionality to reference it in your code IDE. Which is nice! I like easy problems.

The other problem I had was related to game development, though, sadly, not Contension, which remains on hold for now.

I was trying to get a click-object setup to work in a 2d game. Unity has a lot of different ways to do this, but the granddaddy of ’em all is the Input-Raycast, which works very well, but is kind of old and busted and not very Unity-ey anymore.

The new hotness for input is Input Modules, which natively support command mapping and event-driven operation. It turns out there are a bunch of ways to work with an IM, including the EventTrigger, which is basically zero-programming event handling, which, holy shit guys. That’s a fever of a hundred and three right there.

The thing about the Input Module for my scenario, however, was that if you’re working with non-UI elements and you don’t want to roll your own solution, you have to add a Physics Raycaster somewhere, which will allow you to click on objects that have a collider, and you have to have a collider on any object you want to click on. Which is fine! I’m 100% on board with having a simple, composable way to specify which things actually can be clicked. BUT.

See, there are actually 2 Physics Raycasters available. One is the ubiquitous Physics Raycaster, which does 3d interaction. The other is the Physics 2D Raycaster, which theoretically does interaction when you’re using the Unity 2D primitives. It may surprise you – I know it surprised the heck out of me – to learn that the Physics 2D Raycaster is actually a pile of bull puckey that does not in any way work at present.

It’s  one of those things that you often find out in gamedev that makes the whole exercise feel very frontier-ish, except there’s this enterprise dev in me. And he knows very well that a framework that puts that kind of dead-end red herring in and doesn’t even acknowledge the issue is a framework that I have to avoid trusting at every opportunity.

It all worked out ok; you can use the 3D raycaster and a 3d bounding box just fine for the purposes of interaction, and this particular project doesn’t need the 2D physics right now. It’s just annoying and worrying, which is, at the very least, not a super fun way to feel about the basic tool I’m using.

As an aside, I’m doing another talk soon, this time for the fun folks at NDev. It’ll be mostly a rehash of the 2016 NGX talk, but I’m hoping to tweak it at least a little to provide some depth in a few areas.  Should be interesting to see what comes of it!

Creating a single player version of a multiplayer game in Unity

I struggled to find any information about this online, so I’ll write a quick post about how I’m solving this with the prototype for Contension in hopes that it will help someone out there at some point.

The prototype has a ContensionGame object which derives from NetworkManager, which, if you’re not familiar with UNET, is basically the thing that coordinates the network traffic of the application, kind of a very abstract client/server class.

using UnityEngine;
using UnityEngine.Networking;
using System.Collections;
using System.Collections.Generic;

public class MultiplayerGame : ContensionGame // ContensionGame is a NetworkManager 
{
    public List<uint> _readySignals;
	
    public void Launch() 
    {
        StartHost();
    }
	
    public void Connect(string ipAddress) 
    {
        networkAddress = ipAddress; 
        StartClient();
        Debug.Log("connected");
    }

    public void AddReady(uint id) 
    {
        if(!_readySignals.Contains(id)) 
        {
            _readySignals.Add(id);
            if(_readySignals.Count > 1) 
            {
                ServerChangeScene(this.onlineScene); 
            }
        }
    }

    void Awake() 
    {
        DontDestroyOnLoad(this);
        _readySignals = new List<uint>();
    }
}

Simple enough – in a normal multiplayer game, we wait for all the players to connect (tracked with _readySignals), and once we have two or more we go to the “main” scene. This isn’t exactly how you’d do things with a full game; for one thing, you’d have more complex scene loading, and for another you’d probably have more robust reconnection logic, but it gets the job done for prototyping.

The real work of starting a multiplayer level, however, is done in the Player GameObject, primarily by the TeamSpawner script component. This object actually spawns our units in the appropriate areas on the map.

Network code can be hard to think about, but in Contension I’m using an authoritative server, which just means that the client won’t actually be doing a whole lot in terms of judging when and how units move or come into conflict. The premise of the game doesn’t work super well if you allow clients to make those judgements, though I’ll probably have to revisit that down the road.

The basic things you need to know to understand this are:

  1. SyncVars are automagically managed data that get replicated across the network.
  2. OnXYZ functions are called “Message” functions, and they’re usually only called by Unity based on events internal to the game engine, such as when a server starts or a client connects to the server.
  3. Command functions are called from the client to the server.
  4. ClientRpc functions are called from the server to the client.
  5. NetworkServer.Spawn creates an object in the game world for all players.
using UnityEngine;
using UnityEngine.Networking;
using System.Collections;
using System.Collections.Generic;

[RequireComponent(typeof(NetworkIdentity))]
public class TeamSpawner : NetworkBehaviour 
{
    public GameObject ContenderPrefab;
    
    [SyncVar]string _teamTag;

    List<Contender.Description> _contenderDescriptions;
    bool _spawned;

    void Start() 
    {
        DontDestroyOnLoad(this);
    }

    public override void OnStartServer ()
    {
        if(MoreThanOnePlayerWithMyTag()) 
        {
            _teamTag = "Team2";
        }
        if(isServer) { _tagged = true; }
    }

    public override void OnStartClient() 
    {
        _teamTag = tag;
    }

    public override void OnStartLocalPlayer ()
    {
        if(!isServer) 
        {
            CmdSendTag();
        }
        base.OnStartLocalPlayer ();
    }

    [Command] 
    public void CmdSendTag() 
    {
        RpcSetTag(this.tag);
    }

    [ClientRpc]
    public void RpcSetTag(string newTag) 
    {
        tag = newTag;
        _tagged = true;
    }

    internal void SubmitTeam (IEnumerable<TeamSetup.DescriptionWrapper> team)
    {
        ClearTeam();
        foreach(TeamSetup.DescriptionWrapper description in team) 
        {
            AddDescription(description.Role, description.Commitment, description.Speed);
        }
        CmdSignalReady();
    }

    [Command]
    void CmdSignalReady() 
    {
        GetComponent<ReadySignal>().Send();
    }

    private void AddDescription(Contender.Roles role, Contender.Commitments commitment, Contender.Speeds speed) 
    { 
        CmdAddDescription(role, commitment, speed);
    }

    [Command]
    void CmdAddDescription(Contender.Roles role, Contender.Commitments commitment, Contender.Speeds speed) 
    {
        ContenderDescriptions.Add(new Contender.Description(role, commitment, speed));
    }

    void OnLevelWasLoaded()
    {
        _spawned = false;
    }

    void Update () 
    {
        if(isLocalPlayer && _tagged && !_spawned && _contenderDescriptions != null) 
        {
            TeamSpawnArea[] spawnAreas = FindObjectsOfType<TeamSpawnArea>();
            foreach(TeamSpawnArea area in spawnAreas) 
            {
                if(area.tag == this.tag) 
                {
                    // Simple local perspective hack - the camera is rotated 180 if the player spawns in the
                    // top of the map instead of the bottom
                    transform.position = area.Center;
                    if(transform.position.y > 0 && GetComponent<AiPlayer>() == null) 
                    {
                        Camera.main.transform.Rotate (new Vector3(0,0,180));
                    }

                    if(isServer) 
                    {
                        SpawnTeam (tag);
                    }
                    else 
                    {
                        CmdSpawnTeam(tag);
                    }
                    _spawned = true;
                }
            }
        }
    }

    [Command]
    public void CmdSpawnTeam (string tag) 
    {
        SpawnTeam(tag);
    }

    private void SpawnTeam(string tag) 
    {
        TeamSpawnArea[] spawnAreas = FindObjectsOfType<TeamSpawnArea>();
        TeamSpawnArea teamArea = spawnAreas[0];
        foreach(TeamSpawnArea area in spawnAreas) 
        {
            if(area.tag == tag) 
            {
                teamArea = area;
                break;
            }
        }
        foreach(Contender.Description description in _contenderDescriptions) 
        {
            Vector2 SpawnLocation = PickSpawnPoint(teamArea);
            GameObject obj = (GameObject)Instantiate(ContenderPrefab, SpawnLocation, Quaternion.identity);
            
            Contender contender = obj.GetComponent<Contender>();
            contender.Initialize(tag, netId.Value, description);
            NetworkServer.Spawn(obj);
        }
    }
}

One of the basic problems with UNET, however, is it doesn’t natively support different player prefabs (read: types) for different players. This means that you can’t just set the player type and forget about it if you want to reuse the multiplayer code for your single player game. In a larger studio that might not be a concern, but I’m doing this on my own right now and that means I need to try to restrict how many things I have to worry about.

My solution to this (again, this is prototype code!) is pretty quick and dirty. Basically I’ve set the “main” playerPrefab to be my AI player class, and then added the human player as a spawnable prefab. As soon as the game starts, the AI player connects, which causes the game to spawn a second client with a hardcoded team.

Soo dirty. But it works!
Soo dirty. But it works!
using UnityEngine;
using UnityEngine.Networking;
using System.Collections;
using System.Collections.Generic;

public class SinglePlayerGame : ContensionGame
{
    bool _playerAdded;

    // Use this for initialization
    void Start () 
    {
        StartHost();
    }

    public override void OnServerAddPlayer(NetworkConnection conn, short playerControllerId)
    {
        GameObject Player;
        if(playerControllerId == 0)
        {
            Player = (GameObject)GameObject.Instantiate(playerPrefab, Vector2.zero, Quaternion.identity);;
        }
        else
        {
            Player = (GameObject)GameObject.Instantiate(spawnPrefabs[0], Vector2.zero, Quaternion.identity);
        }
         
        NetworkServer.AddPlayerForConnection(conn, Player, playerControllerId);
        if(playerControllerId != 0)
        {
            TeamSpawner PlayerTeam = Player.GetComponent<TeamSpawner>();
            List<TeamSetup.DescriptionWrapper> Units = new List<TeamSetup.DescriptionWrapper>();
            Units.Add(
                new TeamSetup.DescriptionWrapper(
                    new Contender.Description(Contender.Roles.ManyOnOne, Contender.Commitments.Balanced, Contender.Speeds.Average)));
            Units.Add(
                new TeamSetup.DescriptionWrapper(
                    new Contender.Description(Contender.Roles.ManyOnOne, Contender.Commitments.Balanced, Contender.Speeds.Average)));
            Units.Add(
                new TeamSetup.DescriptionWrapper(
                    new Contender.Description(Contender.Roles.OneOnMany, Contender.Commitments.Balanced, Contender.Speeds.Average)));
            Units.Add(
                new TeamSetup.DescriptionWrapper(
                    new Contender.Description(Contender.Roles.OneOnMany, Contender.Commitments.Balanced, Contender.Speeds.Average)));
            Units.Add(
                new TeamSetup.DescriptionWrapper(
                    new Contender.Description(Contender.Roles.OneOnOne, Contender.Commitments.Balanced, Contender.Speeds.Average)));
            Units.Add(
                new TeamSetup.DescriptionWrapper(
                    new Contender.Description(Contender.Roles.OneOnOne, Contender.Commitments.Balanced, Contender.Speeds.Average)));
            
            PlayerTeam.SubmitTeam(Units);
        }
    }

    // Update is called once per frame
    void Update () 
    {
        if(!_playerAdded && ClientScene.ready)
        {
            _playerAdded = true;
            ClientScene.AddPlayer(2);
        }
    }
}

For two AI players (for example, when building an AI demo or training simulator), you can do a similar thing but simply spawn a second AI player prefab instead of the human player.

I’ve also realized while writing this article that I can do a better team tagging solution based on the map’s available spawn areas. Which is neat!