You can play Volo Airsport right now! Get it through our own website, the Humble Store, or Steam.

What’s Happening

We’re in Early Access now, and part of doing early access well is clearly communicating the state of development. If we don’t show you what we’re working on (and why), it might very well seem like nothing is happening!

To date we have been pretty bad at this; it doesn’t come naturally to us. Well, not yet anyway. As developers it is ever so tempting for us to just work on the game and release a new build when it’s ready, leaving you none the wiser.

Let’s fix that! We should at least be able to do a weekly post summarizing our activities, right? Even if it’s just a single sentence reading “nope, still didn’t get to do parachutes this week“, that’s more information than nothing at all.

With that said, welcome to the first edition of What’s Happening. Lots has been happening after the release of v3.3, most of which was entirely parallel to work on v3.4.

Welcome Aboard!

We’ve brought freelancers on board who can help us with the things Frank and I are woeful at. We both can’t draw to save our lives, and while I have experience producing music and sound there’s way too much programming to do!

Concept Art

We are getting concept art contributions from our friends Diana and Janis, two artists at Moldybyrd. They’re both highly talented painters and animators, and we can’t wait to see what they’ll come up with.

Here’s some concepts they made a while ago. (Please note nothing is final! This is just trying out some ideas, colors, textures, and shapes.)

You can already see we’re not going for anything photo-realistic, as that would be too hard to make and very dull. Volo is about the dream of flight, not nitty gritty sand-in-your-teeth detail. Sure, we’ll have fairly true to life proportions for everything, and locations might reference some real-world locations, but we can take many artistic liberties along the way.

Sound & Music

Michael (who worked with us on The Aurora Wager) just went freelance, and we’ll be working with him to expand the currently paltry aural palette of the game.

First we’ll need to figure out a workflow. It’d be best if Michael can work directly in the editor software, import his own sounds, hook them up to specific systems, and iterate on this process, all without requiring our help.

We’ve made a list of the most important sound to work on. In no specific order:

• User interface
• Collision
• Wingsuit cloth
• Environment prop wooshes
• Ambiance

Funding

Last year we applied for a modest bit of funding from the Dutch Gamefund, and as luck would have it, they granted it to us! The amount of funding we received helps us pay freelancers. It also takes a part of the stress out of doing work that doesn’t immediately result in new features (and thus sales), but is work we really need to do. More on this below!

Code Architecture Changes

Frank and I are making some sweeping changes to the game code. Not the physics mind you — they’re fine for now — but the structure of the code that loads assets, levels, handles transitions between game states and menus, lets you respawn; everything outside of the simulation, basically.

Why on earth would we do that? Don’t we have features to get on with? Good question! Beware though, this stuff gets geeky very fast.

As we tinker away on new features we often encounter friction from the existing architecture. You see, you never quite know what you need to build a house until after you’ve built it once. Then the next one you build will be much more stable, prettier, better isolated, and might actually stand up to a storm. Volo is the first Big^TM game we’ve ever worked on, and so we could only guess at the structure the game code needs to do what we want it to.

Building and rebuilding is an integral part of the development process. Heck, even veteran developers don’t really know what they’ll need beforehand.

Now that we’re further along and actually worked on some new features we’ve got a much better feel for what works and what doesn’t. Here’s some examples of the problems we ran into:

“Why is the pause menu awkwardly showing underneath the course editor window?”

“Hey, I need to put the course editor in as a new game state, but the current state machine logic is all over the place, so where do I even start?”

“It’d be really nice if you could configure separate keys for menu navigation, course editor controls and wingsuit flying; but right now we can’t!”

“I can’t even make a simple test scene with just a wingman in it. The code requires me to also put in these 30 mostly unrelated systems because they’re all linked, and before you know it my test scene is just the whole game again.”

“If we use this third party plugin for networking, will mod makers be legally allowed to use it too? If not, how do we let mods use networking code?”

System Dependencies

One type of problem we have (well, had) all over was systems requiring other systems. A needs B, which needs C, so in order to use A you also need to have B and C in place.

We used to set references to other systems in the Unity Inspector directly, but this caused all the game systems to become a huge mess of interconnected spaghetti. We could either load everything at once, or nothing at all. This means we couldn’t load, say, just wingman and a test terrain for tweaking just the aerodynamics; we’d also need to load the wind system, the audio system, the menu screens, and everything else.

It also makes it really hard to add new systems that re-purpose existing ones. Say you create a new game type, D, that wants to use just system A (say, the wind system). You can’t, not unless your new game type also plans to use systems B and C.

It takes a while to learn how to write clean components that just do one thing, have as few dependencies to other components as possible, and yet work well with other components to create complex behavior.

Dependency injection gives us a more flexible ways to resolve dependencies to other systems when we load any system. Frank wrote a fairly simple framework for this, and early tests are making us really happy.

The implementation of a new event system means that most systems don’t talk to each other directly anymore, and don’t necessarily need other systems to exist. They just fire an event when something happens, and don’t care who hears it. Right now we’re playing with multiple forms of event processing, and it looks like they will all be useful: traditional DotNet events, Bubbling events that travel up and down through hierarchies, and sending events through a global event bus.

Game State Flow

Games and states go hand in hand. Sometimes you’re flying, sometimes you’re browsing menus, sometimes you’re selecting an exit point, or doing a time trial, and many more states will follow as we add new features.

All these states are unique. They have specific behavior, and manage specific processes and assets. When you go from one state to the other (say from the course editor back to flying) you often need to perform a transition. You might need to save or load some configuration data, destroy or spawn some objects, play a sound, or do a smooth camera animation.

Our original code featured a state machine to handle this, and while it worked, it was hardly perfect. Logic for a single state could be all over the place, and it was really hard to see the structure of the machine at a glance. On top of that, it didn’t have any support for running logic over time (e.g. when you want to move something from A to B over 2 seconds). This made it a nightmare to work with after a while.

We’ve made a new state machine now, one that is specifically made for games, but can also be used by non-unity-component code. It deals explicitly with behavior over time, and lets you easily defer specific callbacks or events to a state-specific implementation (not just your standard unity OnCollision callbacks, I mean).

Prefabs & Scenegraphs

Objects in Volo (in the Unity engine, really) often consist of hierarchies of smaller objects. Here’s a random bunch of objects so you get the idea:

Prefabs are whole hierarchies of nested objects that you can easily reuse. Take wingman for example: he consists of a lot of little objects, but we have a convenient prefab for him lets us save him to disk, and create him when the game loads.

Scenes are even larger hierarchies, often used as levels. Loading  a scene loads all the object hierarchies in it, and all the assets (models, textures, etc.) that go with them.

Unity’s prefab and scene systems are mostly really good, except — drum roll — when you want to support modding. When you build your Unity game the editor packs and compresses your prefab and scene files to an unreadable and unusable blob. You can’t open or change those files yourself, and neither can you really use the free version of the Unity editor and export something to the Volo folder and load it.

There are ways of working around this, but it would almost surely involve creating our own prefab and scene serialization systems. Frank tried his hand at this recently, and while it works beautifully for our own code, it hit some snags when it comes to Unity’s built-in components. That’s not to say we can’t make this work, but it requires further research.

Right, this leads into another big reason we’re doing all these revisions…

Mod Support

Modding is great, right? You get to take the game in the direction you’d like to see, which might be very different from what we have in mind for it. Since the intended design for Volo is very open-ended anyway (the ‘playground’ bit I’m usually on about), it makes sense to let you add your own toys to the sandbox.

With this in mind we’re taking a big look at how we can make different aspects of the game modifiable, and while we have many options it won’t be as trivial as we naively assumed (like every creative effort ever, really).

The ideal case would be that you can create anything we can create, and the best way to achieve this goal is for us to build all our Volo content as if it’s a mod itself. There are a couple of games that do this (e.g. Star Craft II, the Unreal series), and their mod support is rock solid.

Whether we can make the Unity engine flexible enough is an open question. Let’s take a look at the usual types of assets that the game uses to do things; the assets that you’d be creating and we’d be loading into the game at startup:

• Code
• Models
• Textures
• Animations
• Sounds
• Shaders
• Prefabs
• Scenes

Loading code is very easy. We just need to make sure mod code can integrate well with our existing code, but loading a library with custom code is a cinch. Models, textures, animations and sounds can’t be loaded by a Unity game out of the box, but we can use custom importer code to do this without issues. It seems shaders can’t be loaded and compiled at runtime, which is unfortunate but not a game changer. Finally, I explained above how prefabs and scenes are problematic.

Like the rest of the architectural changes, work on mod support is ongoing. We don’t know exactly how it will end up, but we at least wanted to let you know we’re doing extensive work on it.

Open Source

The building blocks we’re designing now are generic enough that we feel comfortable sharing them with the world, and we do think they might be of some help to others. Therefore, we’ll be open sourcing some of them soon!

Our StateMachine and CoroutineScheduler are pretty much ready to go, but our event system and dependency injection code need some more time to germinate before public consumption.

Phew!

This was a big post. The next weeklies will likely be shorter, but I had a bit of catching up to do, and I hope you enjoyed reading it. I’m off to celebrate my birthday now, have a good one!

As always, let me know what you think, and feel free to leave comments and questions below or on the forums.