That last reason describes this post. It’s been over a month since my last post, and so much has and is happening.

Graduation is almost here – a week and a day away – and I think it could go without saying that reminiscing has been more frequent lately. Where to start…

The senior show was last Friday, and it could not have been a more resounding success. The recruiters has an absolute blast playing Office Mayhem, and there’s even a picture of Don Laackman, president of Champlain College, enjoying the game. The team finished the win screen, including balloon popping. It’s quite a lot of fun:

The build is in a great place, and we actually have interest from multiple publishers to release the game. It has only put an even better end-cap to my experience at Champlain. I don’t think I’m ready to write that blog post yet.

Working with the Office Mayhem team has been the best team experience I’ve had at Champlain, and I hope I’ve made that clear across the plethora of blog posts I’ve written about them and the game. I am excited to see what we make of Office Mayhem, and I wish them nothing but the best. They’re an extremely talented lot, and I know they will succeed in whatever they strive for.

In other news, David and I finished our physics demonstration, which was to implement volume and point based fields. I’m hoping to get a write-up of that on my portfolio in the coming weeks. I also have been slowly working on DASHockey in my free time, though the more progress I make the more I am unsure of its viability. I’m also working on a sample project showcasing Action – currently it is in its infancy, but I’m excited to explore what I can do with it.

With all of that said, I could not be happier, or more excited, to announce that I was offered and accepted a position at Vicarious Visions as a junior software engineer. I am so humbled to join their team and am itching to start working.

Part 2 will be in a week or so, after graduation, and will be much more emotionally fueled. Until then, I’m off to enjoy this last week to its utmost.

The biggest addition is the introduction of timer tasks: a group-wide task where all of the players fight over doing the most of whatever the task dictates (like throw everything out, or answer the most phone calls). When the timer runs out, points are awarded to first, second, and third place. They have been received really well at QA, and experienced players love the new strategy elements they bring to the game.

The UI for timer tasks fell on my shoulders, and it was a nice change of pace for me. With that said, it came with its fair share of difficulties: we wanted to introduce all of this new functionality to our pre-existing TaskCard framework, while still letting the players get the information they needed at a glance. The finished product is above, obviously, but there was a fair amount of iteration to get there.

Another feature added this week was a plug-in ‘attract mode’ – basically a kiosk mode if the game sits idle for too long. We also knocked out a lot of the bugs and polish items we’ve been meaning to get to. Andy added random character creation on the start screen which is a nice bit of polish, and Tony finished the stamp system in the break room, which finally finishes our inner game loop.

This coming week, we hope to spruce up our tutorial systems so new players experience even less friction when playing the game, and to implement the accolade system and Employee of the Week room to finally be feature complete. After that it would be small ticket items like implementing new sounds, tasks, and characters. The finish line is really close, and I can’t wait to cross it.

While Richard and Will were at PAX, Tony was hard at work optimizing Office Mayhem. He managed to double our frame rate, and almost triple it on low-end Macs like mine. On higher end machines it isn’t too noticeable, but it is great to be able to lower our low-end target even more, especially if we decide to release. I took spring break as just that, a break, but towards the end I spent time on a lot of the smaller polish-level items we have been meaning to get done: getting random markers from the copier, level randomization, a better item spawning system in the tutorial, etc.

Once we were all back in the Green Mountain state, production was right back in full swing. Norman started working on the fifth character head, and Andrew was working on new animations for our ‘win’ room at the end of the work week, while Tim has been working on a third set of levels, which I can’t wait to implement. Richard has been working on lobby music for the start and break rooms, which are eerily quiet right now. The biggest change we brought to QA testing was character customization: Andy worked diligently to add in swappable bodies and heads, which has been a really great addition judging by the feedback from QA.

I spent this week helping Andy with the rough edges of character customization, as well as implementing new particles I received from Jeremy. We finally made the elevator a breakable object, which leads to some interesting strategies. I also implemented, and removed, group tasks. These tasks worked similar to normal tasks, but they would replace all current tasks, and there would only be one of them – creating a four player rumble of sorts to complete this task. After bringing them to QA, we soon realized that they acted as a pinch point in the game flow, and could very easily let first place keep their lead in certain instances, basically creating a standstill. While fun to work around, we ultimately decided that this wasn’t the type of pace we wanted, and decided to scrap it. We took the time to look deeper at timer tasks – a specific type of group tasks that want players to do the most of something in a given amount of time. These don’t seem to have the same pinch points as normal group tasks, so we plan on implementing these this coming week, and hoping they fare better at QA.

We also took the time this week to record some gameplay for an alpha video. Take a watch!

We learned so much at PAX – we had over a thousand people play a round or two! Our tutorial can be smoother, and that’s something we’ve noted for a while now – the game has just been evolving at such a rapid pace that we’ve neglected it. We are planning to add button prompts above the relative items for each stage of the tutorial to help engrain what buttons perform which actions. This also shows the pitfalls of Playstation vs Xbox controllers, with PS’ X button being Xbox’s A button, and on the Xbox controllers, we use both X and A a lot, so to people who play more on Playstation, their controllers are different, and muscle memory took over. Otherwise, the booth was really well presented; Will did a great job creating marketing materials for it. I really hope Champlain believes we represented them well. We seemed to have a constant flux of people playing, and we even had lines at the busier moments, which is a huge boost of pride to the team.

We also received a lot of praise, which was a little unexpected. Richard and Will said that there were complete strangers laughing with each other, and if Office Mayhem can do that, maybe it’s not half bad. There were a good handful of people asking where to buy it. Buy it. Those words seem alien to me. People are willing to pay money for Office Mayhem – that’s insane. We also had people from 3 to 63 learn, play, and have fun playing it, which finally solidifies our target market of a couch party game – you never know who’s going to be sitting on the couch next to you.

We also might have some very, very, very exciting news about Office Mayhem in the near future, but I can’t play that hand quite yet. I hope to be able to talk more about it soon.

In my last post about Action, I mentioned that Action did not have support for bezier/custom curves. I have since added that functionality with Action::GetCurveFromPoints(T x1, T y1, T x2, T y2) for cubic bezier curves, and Action::GetCurveFromPoint(T x1, T y1) for quadratic curves. The functions clamp the x coordinates to [0, 1] to prevent the time axis from going in reverse, which could cause some ill-intended effects.

I also have encapsulated the framework entirely in the Action namespace – before the timing functions were not under it. Hopefully this will fix any potential namespace clashes.

Simply update your local repository, or pull it.

Since Flip, almost three years ago now, I’ve used interpolation in every game that I’ve created – starting with Starling, and then moving to iTween in Unity, and SKActions in SpriteKit. Interpolation is used everywhere in games, from UI animations, to AI actions, animations, and even world building. It truly could be looked at as a universal tool in a game developer’s toolbox.

What is interpolation?

Interpolation is a method of constructing new data within the range of a discrete set of known data. Put simply, it’s the translating of one piece of data into another piece of data.

Casey Muratori, who worked on The Witness, has a great video on the basics of interpolation, which I highly, highly suggest watching. He explains bezier curves in 40 seconds better than other’s have done in half an hour.

Introducing Action.

I’ve been wanting to roll my own solution for a while now. Not necessarily because I think I can do it better, or include more features, but so I can say I’ve created my own, gain experience in creating the backend of such a system, and have another tool at my disposal.

Thus, Action was created.

What it is.

It is a time-based, self-contained interpolation framework. It contains the common list of easing functions, and the ideology of a Single action. Single contains a value to interpolate, start/end values of that interpolation, a duration of how long the interpolation will take, a start-delay, a loop type (currently None, Normal, or Yoyo), an easing type, and an optional callback to be called upon completion of the interpolation.

There are also Group and Sequence actions: the former is a list of Singles that are run in concurrency, with an optional callback when the entire group is finished, and the latter is similar, except the Singles run sequentially.

The value to be interpolated is a reference to memory, and thus can be applied to any data of any object: volume of a sound clip, scale of a transform, rotation of a quaternion, etc.

What it isn’t.

The easing functions (called TimingFunctions in the code base) are exposed, so more can be added, but currently there is no support for bezier/custom curves. Because they’re stored as function pointers, there’s no way to include more parameters in the call without casting another typedef. I’m experimenting to find the best way to implement this.

There currently is also no option to pause actions, but that is due to the fact of me focusing on the interpolation framework more than the timer it runs on.

How to use it.

First, include Action.h.

Let’s create a value:

// imagine t is some object,
// with testInt being some int in that class.

//                 variable to change, 'start' value, 'end' value
Value<int> value { &t->testInt,         0,             100 };

There are common interpolations generally referred to as To, From, and FromTo. The above is an example of FromTo. To and From could be modeled by doing:

// To:
Value<int> value { &t->testInt, t->testInt, 100 };

// From:
Value<int> value { &t->testInt, 0, t->testInt };

Singles

Now let’s take that value to interpolate, and create a Single from it:

Action::addSingle(&value,
                  3.0f,   // duration  
                  0.5f,   // delay
                  TimingFunctions::ExponentialEaseIn);

There’s a lot of customization in addSingle:

>(Value<T>* value)
>(Value<T>* value, float duration)
>(Value<T>* value, float duration, Callback cb)
>(Value<T>* value, float duration, TimingFunction tf)
>(Value<T>* value, float duration, TimingFunction tf, Callback cb)
>(Value<T>* value, float duration, TimingFunction tf, Callback cb, LoopTypes::Type loop)
>(Value<T>* value, float duration, float delay, TimingFunction tf)
>(Value<T>* value, float duration, float delay, TimingFunction tf, Callback cb)
>(Value<T>* value, float duration, float delay, TimingFunction tf, Callback cb, LoopTypes::Type loop)

Note: For any variable that is not set in the method call, the default is constructed: 0 seconds for delay, 1 second for duration, no looping, no callback, and Linear for the timing function.

Rather than calling one of the predefined methods, you can create a Single on your own:

Single<T>* s = new Single<T>(&value);

s->setDuration(3.0f);
s->setTimingFunction(TimingFunctions::BounceEaseOut);
s->setDelay(1.5f);
s->setLooptype(LoopTypes::Yoyo);
s->setCallback(cb); // more on callbacks at the end of this post

Action::addSingle(s);

Action::addSingle automatically starts the interpolation (including its delay).

Groups and Sequences

Now what about groups and sequences?

Let’s first create a list of Singles:

std::vector<SingleBase*> singleList = std::vector<SingleBase*>
{
    Action::createSingle(&value1,
                         3.0f,
                         2.5f,
                         TimingFunctions::ExponentialEaseIn),

    Action::createSingle(&value2,
                         3.0f,        // no delay on this one.
                         TimingFunctions::ExponentialEaseOut)
};

You’ll notice here that we call Action::createSingle as opposed to Action::addSingle. The former simply returns a Single object without adding it to the pool of actions, whereas the latter creates the Single, adds it to the pool, but doesn’t return anything.

You can also create Singles like above on your own and create a list of them that way.

After the list of singles is constructed, creating a Group or Sequence is very straightforward:

Callback groupCB    = std::bind([&](){ std::cout <<"GROUP COMPLETE\n";    }),
         sequenceCB = std::bind([&](){ std::cout <<"SEQUENCE COMPLETE\n"; }),

Action::addGroupFrom   (singleList, // list of singles     
                        1.0f,       // additional delay on top of singles' delays     
                        groupCB);   // callback for when the entire group is done

Action::addSequenceFrom(singleList,      
                        1.0f,             
                        sequenceCB);

Like Singles, Action::addGroupFrom and addSequenceFrom automatically starts the interpolations.

  All that’s left is to call Action::update(); in your main game loop (otherwise none of the actions will run).

A word on callbacks.

Callbacks are typedefs of std::function<void()>. Thus, we can use std::bind and lambda function notation to create callbacks:

Callback exampleCB = std::bind([&](){ std::cout <<"SINGLE COMPLETE\n"; });

The beauty of them being lambdas means any code can be executed as a callback. Going back to our example t class from the start of this post:

Callback cb = std::bind([&]()
{
    int temp = 0;

    while(temp < 100)
    {
        t->someRandomFunction(temp);
        example += 5;
    }
});

Creating a Single with a callback is as simple as:

Action::addSingle(&value,
                  3.0f,   // duration  
                  0.5f,   // delay
                  TimingFunctions::ExponentialEaseIn,
                  std::bind([&](){ std::cout << "SINGLE COMPLETE"; }));

Or, using the above callback:

Callback cb = std::bind([&]()
{
    int temp = 0;

    while(temp < 100)
    {
        t->someRandomFunction(temp);
        example += 5;
    }
});


Action::addSingle(&value,
                  3.0f,   // duration  
                  0.5f,   // delay
                  TimingFunctions::ExponentialEaseIn,
                  cb);

This coming week, our main focus is to add the final touches for PAX. Things like adding the other characters, adding an attract mode of sorts, and the big bucket item: reimplementing the break rooms. Rather than being traditional break rooms, we’re making the entire floor a whiteboard that players can draw on. Tony’s been hard at work over the past week, and he’s making really great progress on that front. I’ll be focusing on smaller issues like adding more particle effects where needed, and iterating on the (now outdated) tutorial.

Today during class, we were talking about adding a ball pit cheat to the start screen. I said why not?

There wasn’t a lot of visual progress this week, but that’s ok. The game as a whole is stronger, and we have a lot planned for these coming weeks. We’ve come to a new solution to the break rooms (but for now is under wraps), and that will be a large (and probably difficult) project over the next week. We’re hoping to get Norman’s characters with Andrew’s animations into the actual build this week, and we’re excited to see just how much life they add to the office. The accolade system is also very close to being implemented; we just need to decide on the final representation of them and how they’ll affect the players/break room environment. We also cleaned up Interruptables this past week, so we’re hoping and excited to start adding group task types to the mix (and with that comes the concept of point stages and difficulty curves).

We have a lot on our plate this coming week (obviously), and that’s not even including the smaller things like replacing outdated models, cleaning up some of our data-holding architecture, and implementing the alphabet rain in the start menu when the Konami code is input. (I really hope if Office Mayhem reaches the public, someone stumbles upon this post and realizes the immense power they have just unlocked). It’s going to be a long, but very exciting week.

In other news, David and I finally finished our particle system project for Game Physics, and I could not be happier with the result. Expect a write-up on that sometime this week.

This post assumes the reader has a decent understanding of Swift. Thankfully, it’s a very verbose language, so it shouldn’t be too hard to get the high-level architecture from it. See Apple’s Swift handbook for a great resource on Swift.

The Entity

In this protocol-oriented, event-driven example, the base entity isn’t too different from the classic pattern.:

class Entity
{
    var components:[Component]

    // name and tag attached to this entity
    private var name:String
    private var tag: String?



    init()
    {
        components = []
        name = "NONE"
    }

    init(name:String)
    {
        components = []

        self.name = name
    }

    init(name:String, tag:String)
    {
        components = []

        self.name = name
        self.tag  = tag
    }


    func set(tag:String)  { self.tag  = tag  }
    func set(name:String) { self.name = name }


    func getTag()  -> String { return self.tag ?? "NONE" }
    func getName() -> String { return self.name          }
}

Here, we have a simple array of Component objects (which we’ll get to), a name and tag to reference this entity by, and methods for getting/setting these values. But what about finding components in our bucket?

extension Entity
{
    // get first component of type T
    func find<T>(component: T.Type) -> T?
    {
        for item in components
        {
            if item is T
            {
                return (item as! T)
            }
        }

        return nil
    }

    // get all components of type T
    func findAllOf<T>(component: T.Type) -> [T]
    {
        var returnArray:[T] = []

        for item in components
        {
            if item is T
            {
                returnArray.append(item as! T)
            }
        }

        return returnArray
    }
}

// sample use:
let rink = self.find(component: Rink.self)!

Here, we use generics to be able to return any type of component (This is very similar to how Unity handles its ECS). In the singular search, we use the power of optionals to elegantly return nil if there’s no such component attached to this entity. For the multi-search, we return an empty array. In the sample use, notice that we use ComponentType.self. The .self is necessary to reference the class type, and not just the member type. It’s a small syntactical hiccup, but I think it is worth the power and flexibility it provides. If you’re savvy, you’ll notice this is in an extension of Entity. I did this simply for organization purposes: we don’t declare any new member variables, so we can place these function in an extension. I name my extensions in comments for easy finding; this one is the ‘search extension’.

For adding and updating components, we use a similar extension:

extension Entity
{
    func add(component:Component)
    {
        components.append(component)
    }

    // update all components that conform to UpdateableComponent
    func update(dt: Double)
    {
        for item in components where item is Updateable
        {
            (item as! Updateable).update(dt)
        }
    }
}

Adding is simple enough, but what exactly is happening with update? Swift 2 added the where clause – basically a filter on an array. Thus, in update, we are iterating over all of our components, and if the current one is an Updateable component, we call its update method. It’ll make more sense in a little bit.

That, at its core, is the entity in this system. It’s not very complicated, but can be easily expanded, which is always a great goal to have.

The Component

At its root, the Component class has similar initializers, name and tag functions as the Entity class. The interesting functionality comes from the use of protocols:

// in Component.swift:

protocol Updateable
{
    func update(_ dt: Double)
}

protocol Renderable
{
    func addToScene()
    func get() -> SKNode
    func destroy()
}

This is designating that any component that conforms to the Updateable component will have to contain a definition for the function update that takes a double as a parameter (and similarly for the Renderable protocol). What this does, at least in my setup, is that it takes items like the players, puck, and nets, and turns them from entities that would have to be handled by the scene to components that are held by a single entity. Basically, it’ just a reduction of one more layer, and it can be argued that it’s just renaming the architecture, shifting it up a level, but more importantly, it allows the puck object to contain all of its own logic, broken up into extensions and protocol implementations. Yes, in games with hundreds of thousands of objects this would not be ideal, but in DASHockey where there are never more than ten objects in a scene, it works very well. For instance:

extension Puck: Renderable
{
    func addToScene()
    {
        scene.addChild(node)
    }

    func get() -> SKNode
    {
        return node
    }

    func destroy()
    {
        node.removeFromParent()
    }
}

Here’s the puck’s implementation of the Renderable protocol. Granted, it is extremely simple, but it allows for complete customization on a puck-level basis. In a sense, its similar to prefabs in Unity.

Another high-level advantage of this system is that it allows for event-like components, like a GoalScored component:

protocol GoalScoredComponent
{
    func goalScored(team: String)
}

.....

extension Rink: GoalScoredComponent
{
    func goalScored(team: String)
    {
        if team == "red"
        {
            scene.backgroundColor = .red
        }
        else if team == "blue"
        {
            scene.backgroundColor = .blue
        }
    }
}

This, in turn, allows the code called for when a goal is scored be this:

func goalScored(net: Net)
{
    goalScored = true

    // find all of the GoalScored components and let them do their thing
    let score = SKAction.run({
        for c in self.entity.findAllOf(component: GoalScoredComponent.self)
        {
            c.goalScored(team: net.getTag())
        }
    })

    // find all of the GoalReset components and let them do their thing
    let reset = SKAction.run({
        for c in self.entity.findAllOf(component: GoalResetComponent.self)
        {
            c.reset()
        }
    })

    // let there be a pause between for the celebration
    let wait = SKAction.wait(forDuration: 5) //global goal celebration length

    // create a sequence from it
    let sequence = SKAction.sequence([score, wait, reset])

    // and run it! upon completion, start a new faceoff
    scene.run(sequence, completion: {
        self.goalScored = false
        self.entity.add(component: Faceoff(entity: self.entity, name: "faceoff", tag: "UI"))
    })
}

This code is incredibly concise, verbose, and clean. It pushes all of the logic of the objects into the objects themselves. It’s not without its flaws: it won’t work well for larger systems, it is hard to customize objects on a per-instance basis, and objects are authoritative over their own implementation. For DASHockey though, this is a great system that allows the game to run in a concise matter.

Bringing interruptables to testing has seemed to be positive so far, but it is still in its early stages. There is a bug where the timer doesn’t always start, rendering the interruptable uncomplete-able, but I hope to have that fixed for this coming week. We are happy to report that interruptables are doing their assigned job of making sure players are looking at the task cards and not just completing tasks that they think will be active. Up until this point, we only had four tasks, so the chances of completing a random task and being awarded points for it was a high probability, but as we add more tasks, players will have to look at what tasks are active. Interruptables are making players do this, and the player don’t seem to think it’s unfair, which is great for the roadmap of new tasks we want to implement.

In other news, Andy has completed our long-overdue intro sequence. Before each round starts, the camera is zoomed out, showcasing the entire level (and giving players an opportunity to locate all of the items in the level) before displaying what ‘day of the week’ it is and zooming in. It’s a small change, but it adds so much to the flow between levels, and players have really been appreciative of being able to glance at the entire level before being put into the action. Andy also has updated our ScoreCard UI so that it is easier to see which player is in the lead without having to read all of the scores – it’s like a reverse cell service icon.

Tony fleshed out the framework for our accolade system. Right now, all it keeps track of is number of tasks completed and number of items sabotaged, but the framework is complete, which was a pretty large undertaking. The next task obviously is to create the actual accolades on the end screen and to award them to players. The team is still trying to figure out the best way to do this. On one hand, we really want to have in-office trophies the color of the player that won it, but we don’t know an easy way to distinguish the different accolades that way. Tony is also working on a transition framework to better hide the switching of Unity scenes.

For instance, on the start menu when all of the players crowd around the door to go to the first level, everything freezes as Unity’s SceneManager class loads the level_1 scene. We hope to mask this by putting some sort of fade/screen-wipe, etc. on either end of loading a scene. It’s a polish mechanic, but I think it would add a lot to the professionalism of Office Mayhem.

The art team has been hard at work this past week. Norman has finished our first character, Charles, and Andrew has finished animating him. I’m excited to get these into the build. Will has been hard at work cleaning up some of the pre-existing assets (like the computer and outbox) to make sure they read the better in the office, and creating new assets like the coffee pot, bathroom door, and server rack (Wait, a server rack? Yes, stay tuned).

This coming week we plan on cleaning up a lot of smaller polish-level issues we have been neglecting over the past couple of weeks. While doing that, the programming team also hopes to clean up some of the rough edges of the codebase, specifically relating to the way Interruptables are handled on the back end, and smaller changes to the elevator, accolade, and message systems. The artists are cranking away at new environment assets, characters and animations, and the design team is going to be hard at work creating and balancing new tasks and laying out new levels. The end of the semester is fast approaching, and we’re super excited to see how much (and what) we can add to Office Mayhem before then.

Also, I mentioned a couple of weeks ago that I was working on transferring my website from Wordpress to my own self-hosted solution. Hopefully you noticed the site is a little different? I’m super excited because I finally have full control over things like the CSS, asset management, etc. In my opinion, this new site is a lot cleaner. Have a look around!

Andy spent this week finishing up crunch time to make it more pressure-inducing for the players (and more obvious what’s going on!), and reworking the score card UI so players can more easily figure out who’s winning (and thus whose computer to break).

I spent this week squashing the few bugs that have been popping up in QA, as well as lending a helping hand to Tony and Andy when they’ve needed it. I created a DataHolder class that helps keep track of game data between rounds, which will be the start of our outer game loop framework, and I started the Interruptable framework. For now, I’m going the fast and easy, if not sloppy, route to get it working and tested first before spending the time to refactor it into the current task system. I would rather not waste the time to implement it cleanly and have QA rip it out of the game.

This coming week, I’m hoping to finish up interruptables, and I’m hoping Tony and Andy can clean up transitions between scenes, and start the accolade system. I feel like morale fell slightly this week (whether because of lack of visual progress, the plague that’s going around, or simply unenthused to tackle the problems at hand), so I’m hoping to give them (and the rest of the team) more freedom to decide what they want to work on.

Expect gifs and code next week :)

In other news, David and I are creating a particle system container in Game Physics, and it’s shaping up quite nicely. Expect to see a blog post on it soon.