Category Archives: Programming

Still working on dull but important things

So yeah, I’m still slogging through the implementation of the Split Screen Audio system I detailed last post. It’s boring, it’s a total bitch to get right, and once done it will merely enable functionality that you would consider standard in any other context; but it’s important and like me many developers have use for it.

Unity has been a right pain all the way through, too. (What happened Unity, I thought we were friends?)

“Did you know I actually wasn’t serializing your Dictionary.”
“Err, no you can’t extend GameObject. Why would you want to?”
“I’ve secretly overridden the Equals operator so your null-checks are bogus.”
“No, you can’t control order of instantiation, and no, I will not tell you when it happens.”
“This field value only exists in unmanaged code, good luck if you want to manipulate it!”

It’s not so much extending Unity’s functionality, it’s fighting against its functionality.

I chose Unity so I wouldn’t have to develop my own game engine and could immediately start building my game. It turns out that for anything other than a mini-game or a tech-demo you still need to do lots of non-trivial ground work. This seems logical to me now, but I didn’t realize this when I started.

Anyway, I keep telling myself that Volo will need a strong foundation, and that these features need to be in place before I can start creating the game properly. Whether that’s correct I don’t know, but it’s a way to get there, I suppose. Actually, you could argue that I should work these big frameworks into the game gradually, and you would be right. But at the same time I want to finish up these frameworks, start selling them to other developers, and actually earn some money off the work I put in the game.

I know you are anxious to play new, better Volo. Heck, you might be someone who pre-ordered (thanks!), in which case you’re definitely expecting more bang for your buck. I’m committed to making Volo Airsport into all that it can be. To you I say: I’m not going anywhere! I’ve refused jobs in the triple-A industry and stuck to freelancing specifically so I can do this, and while I may dabble with other game concepts from time to time (game jams) I never intend to work on those for more than just study. That said, Volo Airsport is a multi-year project and there’s no way around that. 🙂

You’ll have noticed: I suffer from a character flaw: I hate to disappoint other people, so when I inevitable get myself in a situation where that can’t be avoided, I tend to stop communicating. When I asked you to demand frequent updates at the start of this year it was precisely with regards to that. Thank you for demanding!

Ok, any more of this and this website will be more LiveJournal than development blog. I’ll finish these damn input and audio frameworks and get to the real meat of the game. Then we can have fun times!

What’s Happening – End of January

Split Screen Audio Plugin

Work on the split screen audio solution for Unity has ended up taking most of January. It’s quite mindboggling to consider that I had the basic idea up and running in a couple of hours of coding, but to properly finish it up it required thousands upon thousands of extra lines of code. I’ve been up to my armpits in disassembled Unity editor code, and have been forced to change course drastically at several points. I might do another big technical blog post about the development when its done, to serve as a roadmap for anyone venturing into similar territories.

It started so simple:

* Move real sources to correct relative position around the real listener.
void UpdateRealSources()
    // pair.Value = real source, pair.Key = listener
    foreach (var pair in _listenedSources)
       pair.Value.transform.position = pair.Key.transform.InverseTransformPoint(transform.position);

Each Virtual Source has one Real Source for each Virtual Listener in the world. Each frame the position of each real source is adjusted according to position relative to its associated Virtual Listener.

And that’s all there is to it, really.

But then you have to actually integrate it in your game code and your editor, and by far the biggest problem becomes robustly modelling object and component relationships and comply to Unity’s editing workflow. I never, ever imagined there would be so many edge cases to keep in mind (especially all the different ways you can utilize prefabs). With every new use case there would be a new bug, another thing that would break. But that’s for another time.

Global Game Jam

Last weekend I participated in the Global Game Jam with six other friends. If you’ve not heard of it before, the premise is this: You go to one of the official jam venues near you, you get a theme to develop a game around, and you get 48 hours to do it. Go!

The theme this year was an audio clip of a beating heart. Here’s the, uh, thing we ended up with. (WordPress seems to be a bit broken so I can’t embed this right now. :/)

We associated the sound with a living machine, one with many individual parts that are all tightly intertwined and interdependent. From that interpretation came a concept for a multiplayer game in which each player controls a single element of a body or machine, is responsible for a singular task, but is entirely dependent on the other players to achieve success.

One player controls the heart and lungs. This player’s goals are twofold: Pump things through the system with the heart, and supply things with energy when they pass through the lungs.

Two other players control cells that live in the blood stream. They are responsible of transporting energy through the body, to be used by other organs, or by themselves to fight off infections. They have very limited means to move by themselves and rely on the heart to pump them through the system so they get where they need to be.

An infection starts to develop throughout your play session. The infected cells try to invade the body and remove energy from every part of it. Without energy none of the organs or cells will be able to do anything, and the body will die.

Live in harmony. Die in disconcert.

We were not able to finish what we set out to do (no gameplay yet), but we ended up with an interesting little toy and are very happy with how the Jam went.

The team consisted of:

Joost Pastoor (Game Design, Programming)
Frank Versnel (Game Design, Programming)
Ruben de Gooijer (Game Design, Programming)
Bram van der Hoeven (Game Design, Sound Design)
Robin Vink (Game Design, Graphic Design)
Snoo Chen (Game Design, Graphic Design)
Martijn Zandvliet (Game Design, Team Captain, Additional Programming)

My role was not so much to code the game, but to lead the team. Being the most experienced with game design and development I tried to make sure everyone felt invested in the concept, was able to do their work, and avoided common pitfalls. Not being the one doing the driving was a little scary at first but in the end it was a wonderful experience and I learned a lot.

Right, back to work!


P.S. Next post I’ll talk about the short term and possible long term features I have in mind for Volo. They’ve gotten to a point where they’re concrete enough to get feedback on. It has taken me a long time to figure out what the game is, can and should be.

Technical: Split Screen Audio

As I mentioned last time I’ve been creating a plugin for split-screen audio in Unity. I can demonstrate the basics now, so here’s a video:

The plugin will be sold on the Unity Asset Store once finished, so if you’re interested in testing it or using it for your own games let me know!


I uploaded simple a webplayer demonstration for you to check out:

The Beta package is now ready for testing. Again, if you want to participate, contact me through email, or post in the Unity forum thread:

7DFPS – Armed & Dangerous: Opposing Thumbs

(Crossposting here since seems to be down)

Over the last week my friend Robin and me created a first person shooter game in seven days, participating in the 7DFPS challenge. It was close, but we made it just in the nick of time! Our game is called Armed & Dangerous: Opposing Thumb, and we’re quite happy with it.

In Armed & Dangerous you play a robot defending his lovely Data Cube. Build a fort, kill the oncoming drones, and defend the Data Cube at all costs. The game is player cooperatively with a friend beside you. The trick is that you both control the same character, a robot, and you have to  really work together to win.

One player controls the left arm, the other controls the right arm. Both players can run, look and jetpack at will. All this means you have to coordinate, otherwise you’ll just stumble around and not get anything done.

You can grab things, you have guns, and bad guys want to kill your Data Cube. Stop them no matter what!

Here’s some of our influences:

Jeckyl & Hyde
Enviro Bear 2000

Tools used:

Unity, Visual Studio, Blender, Photoshop.

You can check our dev-blogs and download a playable version on the 7DFPS project page, although the website seems to be down right now. Direct link for windows version:

This first version is very rough, only available for Windows, and only playble with two Xbox 360 controllers. We will be updating with more builds and better support for platforms and input devices though.

Stay tuned, and let us know what you think!

Landscaping: Importing & Streaming Tiled Terrains

Completely out of the blue, here’s something I’ve been working on for the past month or so that might interest you:

Landmass Screenshot

A test landscape for the system

The above landscape might seem like a single, solid piece of geometry, but it isn’t. Instead it consists of many smaller peaces that are seamlessly stitched together as you move through the world.

How does it work? The import tools takes chunks of heightmaps, splatmaps and any other relevant maps, and loads them into Unity. The streaming system dynamically loads and unloads these chunks around the player.

The view from up really high

What’s so cool about this? It allows games that use it to have much larger areas of play! The system only loads the parts of the level it needs, while the rest just sits on your hard disk. Now, it won’t quite give you the whole surface of the earth to explore, but you can certainly spend ages walking towards a far stretching horizon of a level.

The test level I’m working with right now uses heightmaps with a 1 pixel-per-meter resolution to form an island of about 16 square kilometers. The individual chunks have either 1 or 2 splatmaps assigned to them, with 4 channels each. Compressed on disk this results in a package of around 200MB, so a full game could have a lot more of it. Plus, a game like Volo could easily manage with a 2 pixel-per-meter resolution, doubling the potential size. I have yet to explore the idea of having different map resolution for different tiles, but such a thing would make sense for chunks of terrain that you don’t expect the player to get close to.

Both the importing and streaming system are built to be highly configurable and extensible. More on this later, but right now I’m interested to hear what other developer would want from this tool, so I can make sure everybody’s happy. If you have any suggestions: Let me know!

An early snapshot of the editor, to be overhauled later.

Note: I was originally developing these systems for Creath Carter, a fellow indie developer. He has kindly let me develop this into a tool I can use for Volo and sell on the Unity Asset Store as middleware. The terrain meshes in the above screenshot were generated by him using World Machine. The textures and engineer character are some default Unity assets.

Volo Modding

Wooh! Exciting techno-mumbo-jumbo coming up! 🙂

Unity’s game object system has a base-class called MonoBehaviour, and every script you want to use in your game scene has to derive from it. Thus, you use it for everything, it is your hook into everything that is Unity.

Mod makers for a Unity game would need to write their own MonoBehaviours and plug them into an existing game, but earlier versions of Unity did not allow the use of MonoBehaviours loaded from external libraries (those .dll things). This meant that for modding you either had to provide a system to link MonoBehaviour stubs to externally loaded behaviours, or just let go of your big ideas altogether. With Unity 3 though, it now appears that you can spawn MonoBehaviours loaded from external libraries directly into a scene! Score!

Admittedly, I only did an absolute minimum of testing. I created a subclass of MonoBehaviour like so:

Then I built this into a library, imported it in Unity, and lo’ and behold: The editor even allows you to drag and drop classes from the library straight into the Inspector! Dragging it onto a game object and running the scene results in a printed message, as expected.
I believe this means several things:
  • I can let the Volo application load user-made scripts at run-time.
  • I can let users create their mods using the Unity editor.

I can even do this without having to give modders all of the source code. Instead, I just compile all Volo code into a library of its own, so people can link to it from their Visual Studio or MonoDevelop projects.

I’m really curious to see where this goes, and whether other Unity developers will do something  like this. As far as I know nobody is doing it yet. 🙂

Development Tidbits!

High time for an update, methinks!

Non-Technical stuff

I have been demoing the game to more and more people, and I’ve been streamlining the feel of the game according to the feedback I’ve received so far. The design principle I’m trying to use is something you can call ‘layered complexity’. I’m making sure that the basic flight manoeuvres are easy to use; you can now perform broad banking turns using a single analogue stick, for example. Fancier stuff (for harsh turns, flips, barrel rolls) will be accessible by using the other controls, turning off assists, and using the basic controls in new ways. The crucial things is that you will have all those things available from the start, and you can explore them at your own pace.

I presented the game in playable form at Joint Venture: Check de Technique, which was an event in Amsterdam about games, audio and technology. Many people liked the basic control scheme, and noted that while it felt really solid, they also liked the sense of growing instability at high-speed manoeuvring. Jarno proposed hosting a playtest session in the AirRebels office soon, and I’m really looking forward to it. If you’re in the neighbourhood of Rotterdam, let me know!

Also, wingman (which is what we call our courageous stick-figure) now has elbows, and he has gotten a tiny bit smarter. New video soon.

Technical Stuff

I’ve been working on the framework for the game, which consists (among other things) of:

  • Networking
  • Editing, saving/loading player settings
  • Game types
  • Event system
  • Runtime assembly loading (for mods!)

Networking is coming along slowly but surely. It’s requiring a lot more study than I thought beforehand, and I’m starting to understand why networking experts get paid so handsomely. I’ll get it done though, I’m sure of it.

The other major thing I’m trying now is loading .NET assemblies into the game live, as described here: Long story short: That trick allows you to build mods for the game using normal Unity scripts. If everything works out I think I can make the workflow such that you can build a mod using the unity editor, compile your custom code using Visual C#, and tell the game to load your compiled mod at startup. How cool would that be huh? Now, I don’t think there has been a Unity game that uses this trick so I’m unaware of any caveats, but since this is coming from one of Unity’s own developers I recon it has serious potential.

That’s it so far, cheers!

Rock Paper ShotgUnity – Rigid Body FPS Controller

(By request: This is a repost from my old blog)

Rock Paper Shotgun is an excellent PC gaming blog, maintained by some of the UK’s coolest gaming journalists. Recently I’ve done some programming for their community effort to create a game in Unity. It is an implementation of  a first person shooter movement system that utilises a rigidbody, so that it can be influenced by physics.

Some features:

  • Slope limiting
  • Movers (elevators, escalators, etc.)
  • Climbable surfaces (ladders, vines, etc.)
  • Air control (not finished)

Here’s the script: Clicketyclick

And here’s an in-game preview:

[WP_UnityObject src=”” width=”720″ height=”391″ altimage=””/]