Gallant Games Blog

InControl: State Of The Asset

Thu, 19 Mar 2015 20:31:00 -0500

InControl is just a little over a year old on the Unity Asset Store now. It started as an open source project to scratch my own itch but it clearly resonates with the Unity community. Following the encouragement of friends and fellow developers to turn it into a sustainable paid asset, I've been really happy with how it has done.

There's always been an essence of good will to this project. Much of its success is due to the generousity of others and spreading it by word of mouth. I've tried really hard to provide good support and help folks with what they need. I've kept the slightly-less-featured open source version going with near parity, which has been put to great use in countless game jams. For the past year, I've shelved working on anything else in order to focus all my free time on it — well, what little free time one has with an 18-month-old son.

So, I want to take a moment to give a huge thank you everyone who has been so supportive of this little project. It has enabled me (in a teensy tiny way) to vicariously be a part of developing several wonderful games out there and that gives me plenty of warm fuzzies. Meeting and catching up with several of you at GDC 2015, was inspiring and motivating.

I'd also like to give a few of my thoughts on the future.

I've just published version 1.5, which contains the long-awaited support for runtime rebindable controls. This update has required several significant changes to the internals in order to support this feature and prepare for some future additions.

But it has been difficult maintaining two separate forks. As I've added more features to the Asset Store version, porting those additions over to the open source version has become more and more time consuming. With the latest update, the internals are so different that it is prohibitive.

And so, after some deliberation, I'm announcing that the open source version (which roughly corresponds to version 1.4.4) will now be put into a frozen, basic maintenance-only mode. The repository will stay where it is, and I'll continue to try keeping it compatible with Unity 4 and 5, but it will get no new features or significant changes. I hope that it can continue to be helpful in game jams and prototyping, and so I intend to keep it alive as long as is reasonably possible, but it will inevitably begin to age.

As for the Asset Store version, untethering it completely from the open source version will allow it more freedom to grow. I'll be keeping it backwards compatible right down to Unity 4.3 for several months to come to help ease the upgrade cycle as everyone begins to either move to Unity 5 or finish up their games with Unity 4.

I have a few great features planned for the months ahead. There are certainly plenty of challenges to overcome and problems to solve in the controller space. I'll briefly mention one planned addition that I'm particularly excited about.

With the recent announcement of Unity 5 Personal Edition absorbing many of the features previously only available in Unity Professional, the most exciting prospect to me was that native plugins are now supported in the free version of Unity. Even before the announcement, I had begun to work on developing a native component for InControl that will bypass Unity (and many if its more troubling bugs) and provide a host of additional capabilities, specifically on desktop platforms.

This will allow features such as high-frequency polling, robust hot-plugging and controller specific functions such as haptic-feedback and light control. In some cases it could also allow using certain controllers (for example, on Mac) without the need for installing weird third-party drivers.

It is certainly a challenging thing to do right and it's still super early in development, but my plan is to initially bring it to Mac and then grow it to Windows and Linux. I believe it has the potential to really take InControl to the next level.

I'm excited to see what the next year brings!

Speculation: Unity And Xbox Controllers

Fri, 08 Aug 2014 13:00:00 -0500

This is a follow up to my last post on the current Xbox 360 controller bug in Unity. In this post, I speculate on the possible cause of the bug.

In my last post, I wrote the following:

“An brief note on the Xbox 360 controller: Microsoft originally designed the triggers to work on a combined axis, with the left trigger adding 0..-1 to the axis and the right trigger 0..1. The value of the axis is the sum of the two trigger values. In Unity on Windows, this axis happens to be axis 2. Recently, support has (somehow) been added to Unity for splitting the triggers properly on axes 8 and 9.”

It's the word “somehow” that got me thinking. Please grab your tinfoil hats and accompany me on this train of thought.

I was surprised when I found out that separated triggers had become possible with this controller in Unity. As far as I know, there isn't a way to get access to those through DirectInput. But, I thought, maybe Microsoft had done something about it in a Windows update, or maybe Unity was doing some low level HID shenanigans to query the necessary trigger data.

In the light of what I observed while experimenting with the recent bug, I have a new theory.

I think Unity is using XInput.

But XInput is a very targeted API for querying up to four Xbox 360 controllers. Unity supports up to ten controllers, all of which could conceivably be of Xbox variety.

Furthermore, Unity would logically need to use DirectInput to query for other types of controllers, but Xbox controllers would also show up through DirectInput. The same goes for XInput compatible clones. Which creates the challenge of ignoring the first four XInput compatible controllers from the DirectInput list.

And this is where I feel Unity may have gone wrong. I do not believe matching up controllers between XInput and DirectInput is reliably possible. And yet, they may have tried, most likely by trying to identify XInput compatible controllers in the DirectInput list by name and then matching them up in order.¹

The problem is Microsoft never intended for XInput and DirectInput to be used in conjunction. They explicitly state DirectInput is essentially deprecated, and is, in fact, not supported for Windows Store apps. Which is interesting, considering Unity 5 will add support for joysticks in Windows Store apps. Hmm.

So now, assuming that it is the case that Unity is trying to use XInput together with DirectInput, or perhaps their own native HID input library, suddenly the observations made about the bug begin to make sense.

This would explain why the problems usually start with a controller being in the wrong XInput position, for example, slot 3 instead of 1, with slot 1 being empty. There is no guarantee that the DirectInput/HID device order would match up with the XInput order. This could throw off the logic for matching up controllers, which would in turn cause the wrong devices to be ignored or “deactivated” by Unity leading to a dead controller.

This would explain why it's always the separated triggers that malfunction on one or both devices.

This would explain why, in rare circumstances, there is a third phantom controller which matches one of the others on all input except the separate trigger axes. In this case, Unity has not disabled the DirectInput/HID version while still enabling the XInput version.

This would explain why it takes more than one Xbox controller to cause the problem reliably, as quickly plugging and unplugging them could create a small window of time where Windows hasn't quite realized one is disconnected before assigning a new slot.

This would explain why, at times, even with a single controller, the separated triggers don't work for some users. This is either because DirectX (and therefore XInput) isn't installed correctly or some internal logic in Unity didn't match up the controllers and is ignoring the XInput side.

Of course, this could all just be me connecting unrelated dots like John Forbes Nash, Jr.

^1. It's worth noting, that InControl takes a similar approach when enabling XInput support, except that it never tries to match up controllers. It simply ignores and hides any known XInput compatible devices with the result that a limit of four Xbox 360 controllers can be used in that mode. If Unity wants to tread this path, it should impose the same limit as the price to pay for separated triggers, or accept the limitation of the single combined trigger axis.

Details On The Xbox 360 Controller Bug In Unity

Fri, 08 Aug 2014 12:00:00 -0500

tl;dr: Unity (as of at least 4.5.2) has significant problems dealing with two or more Xbox 360 controllers on Windows, where they randomly may not work at all, or have non-functioning triggers, and/or have phantom clones. This is significant because it is the most common controller on the most common platform for many desktop gamers. There is no known workaround or reliable method for returning all connected controllers to a working state, except by trial and error.

Update

The bugginess turns out to be due to a conflagration of several issues. As of Unity 4.6.3 and the 4.6.2p2 patch, two critical fixes have been made by Unity to address part of the problem:

Windows Standalone: Adding/removing game controllers should be detected more reliably now.
Windows Standalone: Fallback to XInput 1.0 when XInput 1.3 is not installed on the system.

Another critical fix was added in Unity 4.6.3p1 and 5.0.0p1:

Input: Changed Input.GetJoystickNames() on Windows to always match names to joystick numbers, similar to most other platforms.

I believe there may be a few more issues to deal with, but it should be somewhat more reliable now.

Context

My project, InControl, has been an increasingly popular solution for cross-platform controller support in Unity.

Recently, I started receiving scattered bug reports about strange controller behavior on Windows. It's been surprisingly difficult to get details, with some users never responding to requests for more information, or replying that the problem has inexplicably solved itself.

Reports covered a range of controllers, with the general flavor being controls not working, or working incorrectly, particularly triggers. Over time, the Xbox 360 controller has been the common denominator. Finally, one user responded with some specifics: two wired Xbox 360 controllers, on Windows, occasionally not working at all or the triggers not working properly.

An brief note on the Xbox 360 controller: Microsoft originally designed the triggers to work on a combined axis, with the left trigger adding 0..-1 to the axis and the right trigger 0..1. The value of the axis is the sum of the two trigger values. In Unity on Windows, this axis happens to be axis 2. Recently, support has (somehow) been added to Unity for splitting the triggers properly on axes 8 and 9.

As I experimented, it's been relatively easy to reproduce, although it takes some persistence.

Results

With at least two Xbox 360 controllers connected, and launching Unity or a pre-built player on a freshly booted system, things usually work fine. If any of the controllers are attached and detached a few times, either while the app is running or before launch, things get a bit crazy. I found at least four states you can end up in randomly:

Everything works perfectly.
The controllers are recognized by Unity, and all controls work with the exception of the independent trigger axes (8 and 9). These are not to be confused with the combined trigger axis 2, which does continue work in this state.
Both devices are recognized by Unity, but one or both devices do not report input.
A "phantom" third device appears, which also receives input (so two joysticks in Unity are receiving the input from the same physical device, although one of them has the independent trigger axes working, while the other does not). This state is very rare.

The problem state will usually persist indefinitely through restarting Unity (or relaunching a built player), although, at least once I observed a controller going from state 3 to state 2 after relaunching Unity.

Once one or more devices are unplugged and replugged, it goes to a random state in the list again.

Often a broken state may be accompanied by one of the Xbox 360 controller player lights being “incorrect”. For instance, two controllers connected and they have lights 2 and 3 respectively. I'm not certain if Microsoft guarantees that two attached controllers will always occupy positions 1 and 2.

I should point out that even while in a broken state in Unity, input still works correctly for both controllers with other applications. For example, using the XInput API with something like XInput.NET, or opening the controller properties in Windows Devices and Printers and testing the inputs there. The devices are still fully functional as far as Windows is concerned.

Thoughts

There seems to be no reliable course of action to get the devices back into a proper state, even plugging them all out, closing Unity, plugging them all back in one at a time slowly, and relaunching Unity, does not always seem to work. Rebooting may be the most reliable option, but I have not tested this extensively (yet).

It is possible this bug manifests with other controllers too, as other controllers have been mentioned in bug reports I have received, but since at least one Xbox 360 controller has always been involved in every case, that issue needs to be resolved before any further assumptions can be made.

The Xbox 360 controller is the “go-to” device for most desktop gamers, and Windows is their platform of choice, so this is a fairly serious issue. I have submitted a bug report to Unity and Unity QA has been quick to respond. Hopefully, it can be resolved soon in a patch update.

A possible workaround in the short term, is turning on InControl's XInput support, however, since the Xbox 360 controllers are still picked up and processed by Unity they may very well affect, and break other kinds of attached controllers.

I will update the status message at the top of this post as things progress.

(For some wild speculation on why the bug may be happening, read this follow up post.)

Irons In The Fire

Sun, 02 Feb 2014 21:01:00 -0600

It's been a long time—too long—since I last posted. Work and life got busy, as they tend to do. Our first child was born three months ago. And I've been all over the place with side projects and prototypes. But now it's time to dust off the site with a fresh redesign and begin talking about some of the things I'm chipping away at this year.

I've been getting into Unity3D over the last year or so, learning C# and generally getting the hang of things. I've worked on a little JSON library and a controller library (more on this later). After working on and discarding a bunch of game prototypes, it became time to work on a something more seriously and feel… well… productive.

I've started work on a shmup, partly because I enjoy the genre and partly because it is simple enough that I won't get overwhelmed—though it certainly has its challenges.

I'm hoping to have something playable to show at GDC this year. Maybe a level or so. I've put some money into graphics assets and have commissioned an illustrator to work on some of the characters for the little plot it has. I think it is safe to say I am committed to finishing it. Anyhow, here's a little clip of the work in progress:

The controller library is called InControl and I created it to scratch a big itch. It certainly isn't the first cross-platform controller solution for Unity, so it is surprising just how enthusiastically other developers have received it. The project gets plenty of e-mail, bug reports and patches. A more recent trend is a flood of feedback during large game jams. Clearly, it is needed. Unfortunately, it does take time and, ultimately, hardware, to test, add to and maintain.

InControl has reached a tipping point. I am still weighing the options, but it is almost certainly going to go into the Unity Asset Store soon, possibly with a few “pro” features to come. Still, I hope it can continue to be viable as an open source project.

Playing board games is one of my passions. As a designer/developer, I love being exposed to new mechanics. There is something special about the raw, tactile nature of board games and they have a great social aspect too.

As a child, long before I was able to program digital games, I would draw on bits of cardboard and make up games and activities. So perhaps they also hold sentimental value for me. They certainly inspire me. I've left dozens of discarded ideas and a few prototypes in my wake. I've been working on a prototype lately that I think has real potential, but it is early days yet.

So, it looks like I have a few irons in the fire this year. They all seem viable and I'm excited to see how they pan out.

Xcode Version Icons

Wed, 05 Oct 2011 19:00:00 -0500

Typically, I have at least two versions of Xcode installed. Occasionally more. Keeping track of which one is running can be difficult, so I grabbed this lovely icon by Artua and put a ribbon on it with a label.

It helps keep me sane.

In the package available below, I've included the Illustrator CS3 file (so you can make your own), ICNS and PNG versions.

Download Xcode Versions Icon Pack

360iDev Comments, Video and Slides

Wed, 21 Sep 2011 19:00:00 -0500

360iDev was a blast. Several other iDevBlogADay authors have already commented on this. In trying to explain what the conference is like, I came up with the phrase “liberal arts developer conference.” There are plenty of developer talks, but also some great design, business and just-plain-makes-you-think talks.

And multiplayer Pac-Man. Let's not forget that. Oh, and donut burgers.

I had a fantastic time meeting folks. While the talks were fantastic on their own, talking to other devs, sharing perspectives and experiences on various subjects took it to a whole new level. Below is a photo of Mike Berg, Matt Rix and myself.

Mike and I teamed up for the Game Jam which was a lot of fun. We came up with a little game called Darkolite. You can check it out here.

And finally, I promised to post my Git talk slides after the conference, but I also managed to get a pretty good screencast video of the talk and the audio pickup from the laptop was surprisingly good — so if you missed it, or couldn't make it to the conference, check it out below.

View/Download Slides

360iDev Git Talk

Wed, 07 Sep 2011 19:00:00 -0500

As I've mentioned before, I will be speaking at 360iDev. I do have a few announcements about that. With just a few days to go and many attendees also reading iDevBlogADay, I hope you will forgive this post not being all that developerish.

My talk has taken a slightly different angle than the original proposal, and for those wondering whether to come to my talk or not, here is some more information.

In preparing my talk, it became obvious that a different presentation on Git was needed. I really wanted to focus on things that you cannot get by just hitting Google — or at least not easily.

This talk will be technical, though not hard to understand.

There are nearly 200 slides. I will take you on a deep dive inside Git, how it works, how it thinks about your project. I will show you why it is fast and powerful on the operational level. Then with that foundation I'll take you into workflow and organization. I believe this is the right approach to demystifying and really “getting” Git.

I'm not going to spend much time on using Git or getting it set up. There will be no boring command line demos. I'll touch on a few things, but that stuff is all available online. If you DO need help with using Git, I will be happy to talk to you at any time during the conference to help you get set up or answer questions. If I don't know something off the cuff, I'll find an answer and get back to you.

I recently had an opportunity to give a beta version of this talk at my local CocoaHeads. One developer commented that although he had been using Git for a while, this talk revolutionized how he thought about it and prompted lots of discussion with his team. Based on further feedback, I tried to strip out or trim down any less interesting part to get it streamlined.

I'm really excited to give this talk at 360iDev and I hope you'll join me for it. If you do miss it, you can always get the session video after the fact. The slides will be available on this blog.

Here are a few more reasons to attend:

The awesome guys at Fournova have generously allowed me to give away a free copy of Tower to an attendee. They've also provided some stickers, Git cheat sheets, and a coupon code for 10% off during the conference.

As if that isn't enough, GitHub have provided a pile of stickers and a free month of their Micro hosting plan.

Regardless of your interest in Git, please come up and introduce yourself — I'd love to meet you.

See you there!

Scaffolding Code From Shaders

Wed, 24 Aug 2011 19:00:00 -0500

I don't like writing boilerplate code.

A while back, I started dragging my game engine kicking and screaming into the world of OpenGL ES 2. The good news is this lets me write shaders. The bad news is I need to write boilerplate code every time I write a shader — you know the kind — scaffolding code to load the shader, code to bind the attributes and uniforms and provide some sort of constant, enum or handle to refer to them, etc.

Meh.

So of course this is a terrific opportunity to write some code to write my code for me.

I've blogged on Ragel and its usefulness for parsing things like shaders before. I don't know what happened to that post, though. It seems to have disappeared in the transition from Tumblr to my new site. Oh well. It was a bad post anyway.

I won't bore you with all the details, but I wrote a little tool called shaderize which takes a folder full of vertex and fragment shaders (hereafter referred to as the shader directory) along with an output folder containing templates (hereafter referred to as the output directory), parses the shaders and applies the data to the templates producing… code I did not have to write! Hooray!

Installation

I used Ruby to write shaderize, so I packaged it up as a gem. All you need to do is:

gem install shaderize

You'll probably need to prefix that with sudo unless you're using Ruby Version Manager. Note: OS X comes with Ruby installed out-of-the-box.

Templates

The templates are written in mustache, a wonderfully simple little templating language. Seriously, it will take you about 2 minutes to learn. Your code templates can have anything in them, but mine look something like:

// Shaders.h.tpl

#pragma once
#ifndef _Shaders_H_
#define _Shaders_H_

#include "ShaderProgram.h"
#include "ShaderUniform.h"
#include "ShaderAttribute.h"

namespace Shader
{


{{#shaders}}
class {{name}}_Shader : public ShaderProgram
{
public:
    {{#attributes}}
    ShaderAttribute {{name}};
    {{/attributes}}
    {{#uniforms}}
    ShaderUniform {{name}};
    {{/uniforms}}

public:
    void Load( void )
    {
        ShaderProgram::Load( "{{name}}" );
        {{#attributes}}
        {{name}} = GetAttribute( "{{name}}" );
        {{/attributes}}
        {{#uniforms}}
        {{name}} = GetUniform( "{{name}}" );
        {{/uniforms}}
    }
};

extern {{name}}_Shader {{name}};


{{/shaders}}

void LoadShaders( void );


}; // namespace

#endif // _Shaders_H_

And:

// Shaders.cpp.tpl

#include "Shaders.h"

namespace Shader
{


{{#shaders}}
{{name}}_Shader {{name}};
{{/shaders}}


void LoadAll( void )
{
  {{#shaders}}
  {{name}}.Load();
  {{/shaders}}
}


}; // namespace

You can see the files have a double extension. Shaderize expects the templates to end in .tpl and will produce files in the same directory with the same name sans the .tpl extension.

Invoking

You can run shaderize from the command line like so:

shaderize Resources/Shaders Source/Application

I have a shell build phase that does this for me. Shaderize is smart enough to only update the scaffolded files if something has changed that requires it to do so.

shaderize $PROJECT_DIR/Resources/Shaders $PROJECT_DIR/Source/Application

And that's it. Now when I hit build, shaderize will take all my shaders and produce wrapper classes for me, including members for the attributes and uniforms, along with a method that loads them all. This means I can write a shader, and use it without writing a single line of boilerplate code to manage it.

Nifty.

Of course there is a lot more code hiding behind ShaderProgram, ShaderAttribute and ShaderUniform, but that's just vanilla C++ code and left as an exercise to the reader.

Tangent

I do actually have a C version of my shader parser that I use to extract the uniforms and attributes at load time so I can set those up with the appropriate OpenGL handles and so on. As a result I have no enums, constants or #define statements littering my code. That's really a more complicated subject and could be done with shaderize too — I just haven't got around to it yet.

I'm really happy with my shader workflow now. Code for using them is very clean. There's a lot more that could be done, including smart shader generation, but I've done enough yak shaving for now.

Turn TODOs Into Warnings With Xcode

Thu, 18 Aug 2011 19:00:00 -0500

In the process of going through my game engine and refactoring a few things, I noticed a bunch of TODO: reminders that I had apparently dropped in months ago and promptly forgot about. Out of sight, out of mind.

After a quick search, I found this very helpful post by Jake Marsh for turning them (and other markers) into Xcode warnings at build time.

I refactored his snippet slightly and ended up with the following. Just drop it in as a script build phase.

TYPES="m|mm|c|cc|cpp|cxx|h|hpp"
MATCH="TODO:|FIXME:|\?\?\?:|\!\!\!:"
find "${SRCROOT}" -type f | egrep "^.*\.($TYPES)$" | xargs egrep --with-filename --line-number --only-matching "($MATCH).*\$" | perl -p -e "s/($MATCH)/ warning: \$1/"

The advantage of all this is that I absolutely abhor warnings. Having them show up every time I build will quickly grate on my nerves until I go in and address them.

Speaking At 360idev

Tue, 19 Apr 2011 19:00:00 -0500

I am super excited to announce that I will be speaking at 360iDev this September. You can see the schedule here. This is going to be an awesome conference, and I'm stoked to be a part of it. Everyone who attends 360iDev raves about it so, if you can attend, don't miss it!

My talk is entitled, “Power Your Workflow With Git.” Here is an excerpt from the description:

Xcode 4 finally includes much requested support for Git. Git is a free, distributed version control system designed to handle everything from small to very large projects with speed and efficiency. This makes it perfect for indie developers.

While Git has been around for a while, the tools and workflows are only now maturing. Now is the time to examine how you can benefit from using it.

This talk will be practical. We will start by briefly introducing Git, the core concepts of a distributed version control system and why it might be preferable over Subversion.

After peeking under the hood, we will focus on how to use it effectively in iOS development. Git does not enforce any given workflow, so we'll discuss best practices, the pedantically “perfect” workflow and then scale it back for the indie developer and small teams. We'll run through the common use cases, tasks and configurations, survey several of the tools and services available and, of course, get down and dirty on the command line.

You can expect this talk to be packed with content. Even if you've kicked the tires with Git already, you will most likely learn a few tips along the way.