This past week we made good progress on the Unity 5 upgrade, dove into the details of building mod support, and err.. ran into some health & safety warnings.
Unity 5 Upgrade
Pilot’s flying reasonably well again, and with a bit more tuning will be ready for prime time. I still don’t really understand what fixed the joints last week, but they’ve been working consistently ever since.
For a moment I thought the damage model wouldn’t work anymore because it relied on a non-standard trick for setting Joint properties (overriding motor force settings each frame), but it’s working fine now.
Getting everything to look coherent with the new physically based lighting pipeline has been an interesting challenge, especially where third party plugins are concerned. One moment I’ll have the game look gorgeous (see top), only to see it break down and look absolutely pants moments later (see below).
Unity’s shading pipeline is hyper-complex, and with the Unity 5 changes everyone is scrambling to get their plugins compatible, while also maintaining backwards compatibility with Unity 4.
At the moment I’m debating rolling my own terrain shaders instead of using the everything-and-the-kitchen-sink third party shaders we’re using now. We only need a select subset of features from them, so they could be much simpler and compact. And I need to write my own shaders for the custom terrain system anyway so it’d be good practice.
I can’t tell you how nice it is to just drop a Pilot in an empty scene, press play, and just be able to tweak the flight dynamics.
I’ve been telling you about this for a while now, but the work we’ve put into decouple all the game systems from each other is really starting to pay off.
Frank has been using this new-found freedom to work on an attract screen. You know, like this one from Ocarina of Time:
Ours is still bare bones in that it doesn’t yet feature Pilot merrily flying about, but we do have silky-smooth camera tracking shots and nice fades.
(Yeah, I totally forgot to make a video of the work in progress of our version. Just trust me when I say that it instantly gives the game a really polished feel, and is very pleasant to look at.)
We’ve made it dead-simple to make a separate scene with just terrain in it, add some spawn points, place some camera paths, and load that in and out dynamically as the game runs. Unity 5 also fixed an important bug that broke background loading, so our loading screens won’t actually freeze the game anymore.
We’re doing a review of different ways we could make Volo Airsport (and Unity games in general) user-modifiable.
Ideally we would have as few restrictions as possible. Both small mods and total conversions would be very welcome. With Unity 5 being released and us working on a major framework overhaul it seemed like a good time to take stock of our options.
We encountered some great new opportunities, but also discovered some nasty snags. We’re looking for feedback from other developers and also (especially) from Asset Store content creators.
The Asset Bundles Approach
The great news is that the free license of Unity can now be used to create asset bundles! I did a quick test, and sure enough: you can create arbitrary asset bundles with free edition and load them into any other game at runtime. Linking to existing game code from your mod’s code can be done too, provided the original code is set up for this. An easy-to-link-to DLL with relevant original game code in it would be perfect, here.
You can distribute a Unity project with your game’s core assets in there, plus some editor tools for exporting a Mod Asset Bundle. The resulting bundle can then be distributed and loaded by the game client.
Pretty cool, right?
One small concern we have is that distributing such a Unity project would also enable a modder to create full builds of the game and distribute those. We’re not worried about piracy (hey, if you want the game for free, there are torrents out there). We’re worried about cloning, about our assets being used in similar commercially released games without our consent. Granted, existing builds of our game are decompiled easily enough to the same effect, but by distributing such a Unity project we would make the process easier.
I suppose this is mostly a marketing issue. You can’t stop clones of your game from being made, but you can try to establish a brand identity before clones start to market themselves.
Asset Store Plugins
Linking to Plugins
Compiling your game’s code as a DLL is easy, until you consider linking to code from plugins you’ve bought from the Asset Store. Some plugins will compile to libraries without significant effort, others might not.
The biggest issue we’re facing right now is that the Unity Asset Store EULA (section 3.8) does not allow us to redistribute any plugins we’ve bought. For example, we’d want modders to make new terrains from within the Unity editor, but they couldn’t use the Relief Terrain Pack plugin we’re using unless they bought their own single-seat license.
This makes perfect sense, as a redistributed Asset Store plugin (source and all) could be used by people in any other Unity project they wished, regardless of the legality of such use. From our perspective we certainly wouldn’t want to aid the pirating of any plugins our game uses, but at the same time it would be great if modders could use those plugins free of charge for non-commercial purposes.
We came up with several possible courses of action, but haven’t decided yet:
- Replace all used plugins with our own implementations (costs a lot of time, renders Asset Store useless)
- Contact plugin authors to work out custom modding license (probably not worth it for them. Potentially of effort, for which we can’t offer much in return yet. Plugin piracy is still an issue.)
- Create a stripped down, plugin-free Unity project for mod content creation, then load exported content into the game to see the final result. (Could work, but it makes mod development less efficient as you don’t see the end result in the editor.)
Unity 5 with Asset Bundles gives new opportunities for making extensively moddable games, but the current licensing structure for Asset Store plugins greatly limits this potential.
Our concept artists started their work this week. We’re meeting tomorrow, and I’m super curious to see their first sketches. Expect visual goodies in the next post! (I totally promised those for this week, I know, I know.)
Team Management & Stress
We end this week’s What’s Happening with some notes on non-technical, but still very important matters.
Frank and I have both been experiencing some physical side-effects due to stress lately, and it’s making us wonder if we’re pushing ourselves a bit too much sometimes.
It’s a very strange beast, stress. It presented itself to us by making us feel quite ill for no discernible reason, and we both didn’t for a second consider we were overworking ourselves.
We’re horrendous at relaxing. We don’t really take time for ourselves, and we rarely get any real peace of mind. There’s preciously little work/life separation right now; we work, and while we’re not working we think about work, so we’re actually still working.
Anyway, I took mental stock today, and I realized I have taken about 6 days worth of actual vacation time in the last 5 years. It’s not like I slave away 24/7 of course, but I rarely ever fully distance myself from work.
Why do we work so much, then? Well, at any point in time there is just too much to do. There’s always more, no matter how long or how fast we work. When we started work on Volo Airsport proper we realized it would an ambitious project, but we didn’t think about how to structure the work in a sustainable way. I usually wonder how I can manage to get more work done, instead of less.
Stress is no stranger in the games industry. Ever heard of crunch? It’s the phase some studios enter into near a significant point during development (tradeshow demonstrations, or the release date) where overtime becomes par for the course, sometimes even mandatory. Need sleep, or need to spend time with your family? Too bad, the game needs to be finished, so you’re working this weekend. Crunch can last anywhere from a couple of weeks to many months.
You can probably imagine that crunch is pretty bad for long term physical and mental health, and crunch has a bad reputation these days.
But we’re a small indie studio, right? We don’t have crunch, we’re in full control of our work schedule.
Here’s the real problem: We just love to work, and there’s always way more waiting for us than we could ever get done. We love to work so much that we just do it all the time if you let us. When we don’t work, nothing gets done and we feel guilty about it. These dynamics drive us to put in as many hours as we can.
In retrospect we crunched through last summer, through autumn, and into winter. Then we wound down to a normal tempo, but never took the time to recover energy lost in that lengthy crunch period.
Obviously, and as we’re finding out, this doesn’t work.
It’s counter productive. Work too hard and you initially get more done than you otherwise would, but it drains you, after which you can get significantly less done. The long-term benefits often don’t outweigh the costs.
Taking That Chill Pill
So how should we deal with this? Don’t worry, we’re not about to take extended sabbaticals or anything. Work on Volo Airsport will continue as normal.
We will however put more conscious effort in relaxation. Whether it be spending a Friday working on a hobby project instead of the todo-du-jour, taking an afternoon to go on a long run, or finally scheduling that two-week skydiving trip I’ve been putting off for years; we’re going to force ourselves to take that chill pill.
(Besides, I’m sure y’all want me to go skydiving for research purposes, right? I’ll make videos and everything!)
All right, kudos if you made it all the way down here. Take care, and take it easy folks. See you next week!