The Input Manager

past tense: shipped; past participle: shipped
1. transport (goods or people) on a ship.
“the wounded soldiers were shipped home”
2. (of a boat) take in (water) over the side.
3. zip up a build and save it on a server without sharing the link with anyone.

I just shipped version 0.1.8-alpha of Altair as per the 3rd definition above. I think it’s important to clearly define for myself what it means to actually ship a version of Altair. At some point I’ll start sharing this with people. IPromise toShare = new Promise();

What’s new?

  • Input manager to control which input contexts get a chance to process input in any given frame
  • Attack order which allows targeting a ship and a basic laser animation followed by an explosion!
  • Attacks are limited in range and will also account for obstructions. Example: the right-most ship targets the left-most ship and fires but hits the middle ship because.. wrong place wrong time.

The most interesting challenge with this release has been the implementation of the input manager to enable more control over user input.

The original input handling was trivial as it relied solely on the built-in OnMouseUpAsButton method baked in to every GameObject. This worked great as long as I was only concerned with a single input action which was Select Ship. The Move Ship action was baked in to the movement arc view which worked great because the select ship code only kicked in to effect if you were clicking on a ship, not empty space.

Of course to implement combat, I needed to be able to select a ship and then select its target without losing the current ship selection. I had a pretty good idea as to how to pull this off but went looking for examples anyway.

It is my hope that one day a post on this blog will prove to be as useful to someone as this post was useful to me.

My input manager is quite a bit simpler than the above linked implementation but it certainly confirmed that I was on the right track.

The input manager in Altair is implemented with a couple of pretty trivial interfaces:

public interface IInputManager {
    void Update();
    void Push(IInputContext context);
    IList<IInputContext> Peek();
    void Remove(IInputContext context);

public interface IInputContext {
    Handled Update();
    ContextPriority Priority { get; set; }

It’s basically a wrapper for a list masquerading as a stack. On each frame, InputManager.Update() is called which simply iterates over the highest priority input contexts that it knows about and lets them do what they need to do.

There are a couple of neat things in this implementation that I want to call out such as the ContextPriority. I decided that I needed to be able to have more explicit control over where an input context would live in the stack rather than just pushing it on to the top. The ContextPriority is an enum that I’m casting to an integer value which is used to order priorities any time one is added to the queue. If no priority is provided, then it is given the current highest priority value +1 which is basically intended to allow me to make overlays or something similar later.

A case that I had to account for with the ContextPriority bit in play was the potential for duplicate priorities. I solved this by allowing a list of input contexts to exist at any priority. The actual declaration for that data storage looks like this:

SortedList<int, List<IInputContext>>

The int is the priority which then keys in to a list of input context objects. All input context objects within a given priority are treated as equal and are given the opportunity to handle input regardless of whether a sibling input context has returned a true value for Handled.

That’s another neat thing that I don’t see enough of when people are writing code in C#. C# allows us to create rich data types that make things easier and safer to use. Take a look at the return value of IInputContext.Update() for example. It is of type Handled. It could just as easily be a boolean as that’s basically how it’s used, but check out this implementation:

public struct Handled {
    public bool IsHandled { get; private set; }
    public Handled(bool isHandled) {
        IsHandled = isHandled;
    public static implicit operator Handled(bool isHandled) {
        return new Handled(isHandled);
    public static implicit operator bool (Handled handled) {
        return handled.IsHandled;

That little bit of code lets me have a nice type-safe object that happily converts itself to a bool as required to support my common use case. I use this technique in several places throughout the codebase so far. A demonstrably more useful place for this technique is the ShipId type which is similair but implicitly converts to a string. It makes it super easy to find any location that requires the id of a ship and to ensure that those methods get what they need.

So, what’s next?

I think the next push is going to be to implement a game lobby where players will actually be able to join a game and begin with ship placement and follow that up with being able to play through a simple game of cat and mouse (movement and shooting at one another until somebody explodes). I might even go so far as to suggest that if I can pull that off, I might actually have a game on my hands!

Alright that’s it for now. Let’s wrap this up with a quick clip of Altair 0.1.8-alpha in action!

4 thoughts on “The Input Manager

    1. Reply
      Chris Stavropoulos - November 12, 2015

      Thanks. Updated the post accordingly. :)

  1. Reply
    Derek Steinmoeller - November 12, 2015

    Cool. What advantages does your pseudostack (IListManger) over a traditional stack that you’re leveraging here? I noticed that your peek function returns the full IList pointer, do you need ad-hoc access to all the InputContexts that live in the list, or would a pointer to the bottom of the stack (i.e., the root ship selection) be enough?

    1. Reply
      Chris Stavropoulos - November 12, 2015

      Advantages include the ability to add arbitrary items such as a low priority context. Additionally it’s now possible to remove arbitrary items from the manager without requiring to pop everything else off the stack first.

      As for Peek() it’s returning the full list in order to allow me to iterate over all elements of equal context priority. I should probably rename it but this structure started out as a stack before I added the concept of context priority.

Leave a Reply