Musical Matters

My life at the moment is all music, which doesn’t lead to much game development actually getting done. It hasn’t stopped me experimenting with ideas though.

The one I’m currently working on is solving the problem of music in a 4X game. It’s not something that many games actually get right as it’s impossible to write enough hours of music to keep it all sounding original for a playthrough that may last tens of hours. What if we could generate it dynamically?

This is actually an area that has had lots of research already so I dove in at the start with messing around with PI. There’s a pretty good example of others doing things here.

This is all well and good, and I knocked up something quickly that generated a MIDI file that I could drop into Logic and make sound OK. The next problem is that 20 hours of that is rather like dripping water on somebodies forehead for torture.That means that the actual style needs to change according to the seed as well, which is a content creation issue rather than a technical one at this stage. Once you’re using a never ending number as your source you just use it to make every decision from then on.

That leads to the next problem, which is I’m using Logic to create nice MP3 files that sound like they’ve had boatloads of sound libraries thrown at them. I’m currently working on generating the blocks that can be used in code in order to create it on the fly. I think I’ve just invented MOD files about 30 years too late. I miss MOD files, they were really important back in the early 90s and now next to nobody remembers them.

The music itself is background ambient stuff that’s meant to sit on the edge of perception, but it should be possible to come up with something a little more battle like for the exciting bits.

It’s an interesting diversion, and one that’s probably going to turn out to be good enough for use in the game. It’s by no means anywhere near as good as properly composed music, but ambient as a genre does hide a lot of sins…

The creative side

I’ve done precious little coding recently because I’ve been working on the other things that the game will need. Music goes a long way towards making a prototype seem more than just a few mechanics, and I’m in desperate need of some artwork to make it look more like a game rather than a collection of blobs.

The problem is that the learning curve for both is rather high. I’ve messed around with music before, but learning what I need to do all of the sounds is rather intimidating and I can’t draw for toffee. The last month has been spent trying to get around this and I have to say I’m rather pleased with the progress, at least as far as the music goes. I’ve almost got something I’m happy with for a style and it’s really not what I was expecting it to be.

The art is harder. Starting with some space backdrops in Photoshop was easy enough, but now I’m onto 3D models and what the UI looks like and I’m floundering. More practice needed I think!

Maybe I’ll go back to coding for this month, I can do that…

An update to unit testing with Unity

Last month Unity acquired the ability to run NUnit tests from inside of unity itself. While this is a good thing it does have the problem of moving your tests away from your code writing and meaning you have to switch back to unity in order to run them. This is really disruptive, and you also can’t get code coverage for your tests.

My original solution worked fine, but now with the new abilities I can run my tests in both visual studio and Unity so there is a bit more validation that they are actually behaving as expected. The problem with this is that all of my mocks can’t be used and so it actually tests against the real unity classes and so loses any diagnostics that I’ve added in along the way.

The final problem is that the tests exist in your main codebase and not in a separate assembly and so they are mixed in with your shipping code. I haven’t tested it yet, but I assume that they also get compiled into your final game and not optimised out, which may be a problem with unwanted bandwidth usage as you’ll have more lines of tests than you do actual game code if you’re doing it right.

In order to fix some of these things I’ve added in more #if statements. Tests that can only be run outside of unity because they require mock functions that don’t exist on the real classes are the main use, but I can also wrap all of my test classes if needs be in order to exclude them from the build in a notional release build if reflector tells me that my unit tests exist in my published game.

Unit Testing with Unity

For reasons of being a responsible developer I decided that because games are no different than other software they need unit tests as well. Unity does not make this easy.

Visual Studio supports unit tests inside the IDE, and they can run whenever you build, which is a mere Ctrl+Shift+B away. It can also use whatever framework I want, so I’m not restricted to just MSTest so can get nice things like Assert.Throws through NUnit. This seems to be the most useful way of having the tests run while you’re actually coding.

The first thing I had to do was switch the editor IDE within Unity and get it to generate some visual studio projects for the game. Double clicking on a CS file kicks it all off, but the first problem is that these projects are re-generated whenever it feels like it. You can’t add a unit test project to the solution and expect it to remain included, so I created a separate unit tests solution and added the Assemby-CSharp-Firstpass-vs and Assembly-CSharp-vs projects to it. While those will still be recreated, the solution and tests themselves will remain stable. Next I created the unit test project using the handy unit test generator extension (available through NuGet) and tried to test some code.

The next problem I faced was actually the biggest of the whole process: MonoBehaviour based classes cannot be instantiated. I took a peek inside of the code and it turns out that the way that they hook into the Unity engine itself is by a mechanism that is totally unsupported by code running under the normal .NET framework.

Several solutions suggested themselves. The first was to put all of the logic into “proper” classes and call them from the MonoBehaviour ones. This design pattern can work well, and does have some major advantages of extracting logic from platform specific implementation if I ever need to ditch Unity in the future, but also has the larger drawback of leaving any code that needs to actually interact with Unity itself, whether by spawning objects, showing the UI or whatever, untested. This was a big enough drawback for me to discard the idea.

The next thing that I tried was Microsoft Fakes, which is a rather nice feature of Visual Studio to mock objects. It can do some very impressive things behind the scenes with member replacement and I’ve used it a lot on other projects, but the linking tricks Unity use again defeated it and no matter how much tweaking I tried I couldn’t get it to work. After a day of getting to know a whole new level of the .NET framework and visual studio I rejected this as well.

This left me with the obvious low tech solution: doing the mocks myself. By replacing any Unity supplied class that I wanted with my own implementation I’m able to add any testing logic that I want, but at the risk of misunderstanding the actual logic of those calls and introducing false logic into the tests. For 90% of tests this won’t matter as it’s at the lowest possible level and each member function of the game only does one task at a time, like all good design should.

Mocking is easy enough to do. I created an empty MonoBehaviour class in the Assembly-CSharp-vs project under the Assets.UnityMocks namespace. Next I needed to find a compile time define that could be used to see if I was compiling from inside Unity or running the unit tests from within Visual Studio. Because Unity uses Mono for its C#/.NET implementation I first tried the __MonoCS__ define that is defined by Mono itself. Unity however doesn’t use this so I looked for a define that Unity does set.

Unity does actually create a series of defines while it compiles, and these are documented at http://docs.unity3d.com/Documentation/Manual/PlatformDependentCompilation.html. None of those quite do the job, but further down the page it explains that if you create a file called smcs.rsp in your Assets folder then you can add command lines for the compilers. In this case it just had to contain -define:_UNITY_RUNTIME for me, to be able to wrap my mocks and the using statements that reference them with some conditional compilation.

The last thing I needed to do was add the following to the top of all .cs files that use any Unity objects:

#if _UNITY_RUNTIME
using UnityEngine;
#else
using Assets.UnityMocks;
#endif

The resulting compilation errors then told me which Unity classes and members I needed to implement. As a bonus I only ever have to implement those once for every project as I can share code afterwards.

This does have the drawback of divorcing the actual implementation of, say, Resources.Load() with my new implementation, but I’m happy enough that I can catch that through other forms of testing. There will be all manner of graphical glitches that cannot be spotted through unit tests because of this, but those are always going to be hard to code tests for anyway.

Now I can happily go about with test driven development with my Unity projects.

Making a “proper” game

For months now I’ve been pottering around with various game ideas. I’ll code up a bit, get something working that is miles away from being a game before moving onto the next thing. The reason for this is I’m not treating it like any proper development that I would do, but rather as a learning exercise that leads to me jumping onto the next interesting thing.

If this was my day job I’d be doing the following:

  1. Try and get an idea as to what the basic requirements for the application are. What do people expect it to do?
  2. Make something that sort of works for the first bit of functionality as quickly as possible, and always keep it working as a full application. If management are inclined to confuse “working” with “finished, let’s ship it!” then don’t tell them about that bit.
  3. Add features along the way as needed. Unit test them while working and don’t be afraid to refactor.

I have an idea for a game. It’s a 4X space game, and I’m not exactly making it with the right intentions which is causing some problems. I have a folder full of half coded ideas as I flip between different cool bits and I’ve not really considered what I’ll do about releasing it. The goal would be to get rich and retire of course, but that isn’t going to be this game. This is a chance for me to learn the tools and have a poke under the hood of a genre.

At this point it doesn’t actually matter about anything in the game other than it is 4X. I have pages upon pages of ideas written down and I have the direction sitting comfortably in my head, but for the first goal I need to set a task that satisfies my three points. This means that I have a working game that is winnable and has as much unit test coverage as I can manage.

The first is actually easy enough as the general direction is eXplore, eXpand, eXploit and eXterminate, which are of course the four Xs of 4X. This means I can move onto step 2 without worrying. The genre itself gives enough direction at the start and I imagine that many genres are like that, and many a game has probably been condemned to mediocrity because of it.

Moving onto the design for a fully contained but incredibly basic game I’ve settled on the following:

  1. Title screen that contains New and Exit.
  2. Procedurally generated universe. Sounds more difficult than it is, just random numbers for now.
  3. Links between the systems.
  4. The systems all displayed on screen with shiny programmer art.
  5. Return to title screen through a quit button.
  6. Next turn button that moves the universe on (i.e. increments a turn counter)
  7. Ability to conquer systems to your own faction through arbitrary means and no resistance.
  8. When all systems are owned show a win message and return to title screen.

That’s the smallest 4X game I can come up with. Actually it’s just eXpand, but it’ll do for now as it ticks the box for a winnable game even though there is no challenge and you can’t lose. It does however satisfy step 2 though so I can move onto step 3, which is actually implementation.

My tool of choice is Unity but using Visual Studio instead of Monodevelop. This leads to a couple of easy choices such as unit testing can be NUnit or MSTest and fully outside of Unity. It brings up the problem of not being able to test MonoBehaviour derived classes due to the fact it doesn’t work outside of Unity, but that actually leads to better design as it forces me to extract game logic from Unity implementation and means that should I ever want or need to change engine that I’m all set as long as it supports .NET.

This leaves me with a small-ish chunk of code to write and a commitment to publish it here using the Unity web player when it’s done.

The lure of Unity

There was a brief moment this year when I was actually a full time indie game developer. It only lasted a couple of weeks, and like so many others it ended when I got offered a new job, but the though was there. After I started the job I dropped the project, but this weekend something happened and I picked it up again.

What happened was Unity getting another round of press, which reminded me that I’ve still not really delved very far into what it can do. I’m of the opinion that Unity is one of the most useful things to happen to game development since, well, since the Spectrum and typing in games from listings in magazines.

This blog probably isn’t going to interest many people, but it will contain what I’ve learnt when it comes to solving problems in Unity. This is mainly for my benefit, but if it helps anybody else along the way then all the better.