Tag Archives: mods

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: http://eej.dk/angryant/general/tipsandtricks/downloading-the-hydra/. 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!

Playtests, Networking and Logo Design

I’ve been a little too quiet lately! Here’s a collection of Volo-related tidbits that have been going on.


Over the last couple of weeks I’ve put the game in the hands of a bunch of friends. They played a slightly more updated version of this:

In short, they loved it! This is the first version that really engaged them in a just-one-more-go kind of way. This means that the game is intuitive enough to pick up, deep enough to provide a lot of choices and room for skill development, and contains enough feedback for people to identify things they are doing right or wrong.


Amongst all the feedback I’ve gathered several things were key:

  • While control feels smooth and fairly intuitive, precision is often either too coarse of too fine. This depends on what they wanted to do of course. When you are performance flying you want to use the full range of your input device for generating very small but very precise moves. Coarse input here means that your movements get exaggerated, which can throw you off course and make you lose altitude fast. I had added some tricks to dynamically alter your precision, but apparently I’ll need a more rigorous solution.
  • Gametypes, ranging from real-world (think proximity flight, formations) to very game-like mechanics (think James Bond action scenes). Many people would also like to see the game’s scope include normal skydiving and basejumping. I’m aiming for the game to be flexible enough to allow all kinds of game types, created either by me or by modders. By keeping my code well-organised and by paying special attention to possibilities for code reuse, hopefully you will even be able to do some hanggliding or skysurfing.
  • Multiplayer! This is by far the most requested feature. As well it should be; skydiving is hardly a solo activity, right? Since this feature is so important it has become a top priority to get some netcode fixed.
  • A replay/ghost racing system. This will get in right after the netcode is done, as it will use a great deal of its functionality.

Some of these features are also based on discussions on the community forum. Check out the Ask The Developers and Wishlist threads to see all the features that the forumites have come up with so far, they’re all very good food for thought. And while you’re there, why not drop in some of your own ideas; we can always use more!


In other news, a couple of graphic-design buddies have started brainstorming about Volo’s graphical style. The logo is their first point of interest and I’m very curious to see what they’ll come up with. Many thanks, and good luck to them!

That’s it for now. I’ve got some course-work related deadlines this week, so I’m not sure how much work I can get done, but we’ll see. 🙂

Open Development

I’ve been thinking about switching to open development for Volo. Open development, in short, means that you make the development process very transparent. There are several things you can do, including:

  • Maintain a publicly available, detailed log of all important developments.
  • Keep in close contact with the community, by all means available.
  • Make some or all of your game’s  assets (code, models, textures, etc.) available online. (Under GPL licence, and for preorderers. People still have to pay for the actual game.)

By doing this you sacrifice privacy for exposure, which is something any small-time developer can always use more of. By being so open you can maximise the chances of serendipitous events happening. You can make a lot of friends, grow a community before the game is out, and people can support the project in all kinds of ways. For example, people can create their own modifications, and fix bugs that you’ve missed.

Anyway, Wolfire (developers of Lugaru and the upcoming sequel Overgrowth) have a more detailed post about this, so I’ll let them explain it: Wolfire’s PR Tips.

The reasons I’ve started thinking about opening up Volo’s development process are numerous. Here’s some of the important ones:

  • The game needs to grow a lot if it is going to survive. And it will not do that as long as it stays within the confines of my bedroom.
  • Some prominent indie developers have succesfully used open development to make a name for themselves. Look at the Humble Bundle to see what I’m talking about.
  • I like sharing. If people can learn from my work then let them. If people can contribute to my work then let them.
  • Unity does not support an easy way to facility game modification, even though it should. This means you cannot, for example, use the Unity Basic edition to write a new multiplayer mode for the finished game using Unity script. This limits my options for allowing mods, unless I integrate my own scripting tools, or go open source.

So what do you think? I know that you like to know what’s going on in my work-shed, I know that you really want mods,, and I know that some of you would be delighted to contribute some content to the game. Also, would you consider paying for a game that’s not nearly finished for a chance to play with the source code, or just to support a smalltime developer?