A Brave New World
Anyone who reads my blog regularly will know that when it comes to development, I generally stick to Microsoft or web-based technology, and rarely step outside that comfortable little bubble. I made a promise to myself back in January that I'd get into mobile or games development this year, and finally I've found the time to start looking at one of them.
I'm no ideas man, but occasionally a spark ignites and the juices start flowing. Armed with an idea that's been rattling around in my head for a few years, I spoke to a friend who's been focusing on indie games development, and he suggested using Unity3D, a fully featured game engine that supports C# and JavaScript out of the box (making my learning curve a little bit easier). I told him my idea, and - as geeks do - we spent the next few hours hashing out concepts, and by the end of the night, we were fully bought into the idea. The next step was seeing how Unity would fit in.
I'm no ideas man, but occasionally a spark ignites and the juices start flowing. Armed with an idea that's been rattling around in my head for a few years, I spoke to a friend who's been focusing on indie games development, and he suggested using Unity3D, a fully featured game engine that supports C# and JavaScript out of the box (making my learning curve a little bit easier). I told him my idea, and - as geeks do - we spent the next few hours hashing out concepts, and by the end of the night, we were fully bought into the idea. The next step was seeing how Unity would fit in.
So, for the past few months, my good friend Lew and I have been prototyping various aspects of our game, and playing around with source control and collaboration tools for Unity3D. There's a stark difference between developing client / server applications in .Net and developing for 3D games, but Unity's use of Mono for scripting (with built in support for C#, Boo and a weird derivative of JavaScript) has made the transition a lot easier than it would have been if I was to learn C++.
Of course, 3D game design is - and always will be - a completely different animal to enterprise application development; even if you consider that you'll need to learn at least the basics of 3D vector maths (which I totally suck at), you still have to factor in that game development - by its very nature - relies on multiple pieces of code executing asynchronously, which is completely the opposite of how most .Net developers go about their day-to-day jobs. Most of us have touched on asynchronous operations using .Net's built in libraries, but it really doesn't help when programming in Unity.
Developers Unite
Unity is a pretty advanced (yet generic) 3D games engine that comes with a plethora of built in functionality including (but not limited to) skeletal rig animation, a nifty physics engine and dynamic lighting. A lot of this you can get for free, though you really need the Pro version if you're going to do anything serious.
By far the most appealing aspect of using Unity is the thriving open source community that's built up around it. Whilst their Answers pages don't quite match the awesome prowess that is Stack Overflow, and their documentation is a little out of date and lacking in some areas, the community is alive and their Asset Store provides many free scripts, textures, models and systems to help you develop your game. I've generally found myself discarding or re-writing the scripts I've downloaded as I've started to understand things more, but they definitely help to point you in the right direction, and some are pretty awesome.
Obviously I'm no game dev pro, but I think it's safe to say that Unity helps you make a simple game, quickly. However, as with all games, anything more advanced will require a lot of your time. It's not long before you realize the potential - and limitations - of the engine, and of course figure out exactly how much work you've let yourself in for - in our case, it's a fuckton. Without revealing too much at this point, we're putting together a 3D FPS game with a heavy focus on stealth, parkour and hacking. The best way to describe it is Deus Ex meets Mirror's Edge. The ideas we've had are probably a bit ambitious, but I suppose it's better to aim too high than too low!
Unity's IDE is a bit buggy, but is also very extensible (in fairness the bugs I've experienced seem to be related to 3rd party scripts and plugins rather than Unity itself, though there are still definitely problems with it). It's not quite Winforms programming, and the Unity crew have written the Editor scripting objects in a very weird way, but you can achieve almost anything you want within the IDE; drag and drop systems, simple property enhancements, graphs, flow diagrams etc. This neat little addition increases your productivity when working with game objects that share custom scripts - which is basically how you write games in Unity.
Scripted Away
Unity's modular approach to object scripting is both refreshingly easy, and infinitely frustrating. It's a very different way to work than I'm used to, and certainly feels more like scripting / hacking than proper development. Saying all that, it's perfectly acceptable to abstract code out of the C# scripts within Unity and put them into your own project and develop them separately (maybe with TDD etc), but for the simple reason that Unity is a bit fiddly anyway, I can't see it being an easy task to accomplish.
As it stands, I've written quite a lot of C# scripts in Unity that deal with everything from player movement to object interaction and message relaying, but it doesn't feel quite right. It very much feels like I'm back to basics with C#; I know the syntax, and a number of patterns, but Unity's way of working feels loose and fumbly. I never feel like I'm doing things the right way, and my code is definitely starting to look a little bit like spaghetti code, and is at risk of bug creep. This has a lot to do with the code being "Proof of Concept", and me being unfamiliar with all this new stuff to play with, but I do feel that some things could have been organised just a little bit nicer when they were designing the engine.
Each "script" is basically a C# class that inherits from the Unity base class, MonoBehaviour. Within this class, there's a well documented event pipeline that helps you get off the ground quickly, and is fairly intuitive - for example, you override Start() to execute code when the script starts, and Update() when you want to control things on a per-frame basis. MonoBehaviour also provides a number of protected / public properties that can be used to access common components directly - although Unity suggests using the built in GetComponent() method to get them instead. I do like the way it works, but I'd like to add further redundancy by putting my code into a separate assembly, and writing unit tests for it.
Not So Safe Source
If you're doing any kind of collaboration with Unity, you'll soon discover that its source control support is not very good. Mainly, complaints have arisen to do with the free version previously not supporting text serialization of assets (which Unity have rectified recently in version 4.2), but I can confirm that it doesn't make that much difference, especially when it comes to large or complex assets like scenes. We're using git for our project, and I spent a considerable amount of time setting it up to work as well as it does at the moment. I'll write a blog post about it at a later date.
Through many months of trial and error, it seems that two people can't work on a single scene at once - and if you do, you basically have to ignore any merge that takes place and manually apply the changes. Obviously this can get very complex and time consuming, but it's the only way to do it. Instead, Lew and I have been working on separate scenes or projects; I really can't imagine what it's going to be like when we end up putting some proper levels together.
Model and the World Models with You
I've worked directly with some very good designers over the years, and I've been very appreciative of the experiences. My creativity comes in the form of architecture of systems and structuring code... most things graphical are quite literally mind-bending to me. I've used Photoshop and Illustrator for years, and I know them quite well, but only to manipulate images that already exist; I've never been able to create anything from scratch, but I've gawped at plenty of designers as they've magically created something awesome from literally nothing. Obviously there's going to be a certain amount of graphical work involved in game development, though I'm not sure how I'm gonna get through it!
Modelling, on the other hand, is something I quite enjoy. I've created a few designs over the years for custom built stuff around the house; my console collection cabinet, the BBQ in the back yard, and sound diffusers for my studio, and enjoyed making all of them. The thing is, I've only really modelled complex cubes... when it comes to doing anything more sophisticated, I'm pretty much starting from scratch. It's been challenging, especially having to learn new tools like SketchUp, 3DS Max, and Blender, and all the new terminology and 3D modelling techniques like hierarchies and UV maps. It's a crazy, new experience, and there's a hell of a lot to learn.
Then there's how to actually design models and levels for our game. So far, it's a lot of trial and error - different export settings, playing with hierarchies and origins, figuring out what we need to model individually and what we can combine inside other models, and how to arrange our meshes. Unity allows you to import entire 3D models into your project, automatically generating things like colliders, and UV lightmaps, seriously reducing the amount of time it takes to get things up and running. The hard part is exporting the model from whatever 3D package you have in a way that makes sense in Unity.
The Sound of Silence
These days, good sound design can make or break a game. Even Pong had sound effects, but anyone who's played any modern triple A title will know we've come a hell of a long way since then. Unity features a very easy to use audio system that lets you play various formats of audio file directly from disk, and adjust properties like pitch, volume, and distance rolloff. Luckily, my past experience in the recording studio pays off here, as I've got an array of tools available to me for both recording and editing. At the moment I'm just finding royalty free samples online, though I'm having to do some minor editing to most of them so they fit in with our game.
A game is a pretty boring place if the items your character is interacting with don't make a sound. One thing I didn't think about much before taking this on was that I'd have to think about how every single object will make a number of different noises depending on what you're doing with it. A gun, for example, requires numerous bullet firing sounds, a reload clip, a dry fire noise, noises for shells hitting the ground and bouncing, then there are bullet impact sounds for different materials, glass shattering, crates breaking, and ricochet noises. It all depends on the level of realism you want to achieve, or the type of game you're making, but each new sound you add and calibrate properly really makes a difference when you're play testing.
Hello World
If the coming months are anything like the last few, I'll be spending most of my nights following beginners tutorials on youtube and writing hello world scripts for every new thing I need to accomplish. It makes a refreshing change from writing software for insurance and travel companies, and challenges me on every level. I'm not sure if I'd have managed to get into it if I wasn't for Unity's C# support; I think the challenge of learning something like C++, plus all the extras I've mentioned above would have been overwhelming. It's a good move from the guys at Unity.
So, expect my normal blog posts to be interjected with the occasional Unity 3D related ramble... I imagine I'll be developing this game for a while!
Of course, 3D game design is - and always will be - a completely different animal to enterprise application development; even if you consider that you'll need to learn at least the basics of 3D vector maths (which I totally suck at), you still have to factor in that game development - by its very nature - relies on multiple pieces of code executing asynchronously, which is completely the opposite of how most .Net developers go about their day-to-day jobs. Most of us have touched on asynchronous operations using .Net's built in libraries, but it really doesn't help when programming in Unity.
Developers Unite
Unity is a pretty advanced (yet generic) 3D games engine that comes with a plethora of built in functionality including (but not limited to) skeletal rig animation, a nifty physics engine and dynamic lighting. A lot of this you can get for free, though you really need the Pro version if you're going to do anything serious.
By far the most appealing aspect of using Unity is the thriving open source community that's built up around it. Whilst their Answers pages don't quite match the awesome prowess that is Stack Overflow, and their documentation is a little out of date and lacking in some areas, the community is alive and their Asset Store provides many free scripts, textures, models and systems to help you develop your game. I've generally found myself discarding or re-writing the scripts I've downloaded as I've started to understand things more, but they definitely help to point you in the right direction, and some are pretty awesome.
Obviously I'm no game dev pro, but I think it's safe to say that Unity helps you make a simple game, quickly. However, as with all games, anything more advanced will require a lot of your time. It's not long before you realize the potential - and limitations - of the engine, and of course figure out exactly how much work you've let yourself in for - in our case, it's a fuckton. Without revealing too much at this point, we're putting together a 3D FPS game with a heavy focus on stealth, parkour and hacking. The best way to describe it is Deus Ex meets Mirror's Edge. The ideas we've had are probably a bit ambitious, but I suppose it's better to aim too high than too low!
Unity's IDE is a bit buggy, but is also very extensible (in fairness the bugs I've experienced seem to be related to 3rd party scripts and plugins rather than Unity itself, though there are still definitely problems with it). It's not quite Winforms programming, and the Unity crew have written the Editor scripting objects in a very weird way, but you can achieve almost anything you want within the IDE; drag and drop systems, simple property enhancements, graphs, flow diagrams etc. This neat little addition increases your productivity when working with game objects that share custom scripts - which is basically how you write games in Unity.
Scripted Away
Unity's modular approach to object scripting is both refreshingly easy, and infinitely frustrating. It's a very different way to work than I'm used to, and certainly feels more like scripting / hacking than proper development. Saying all that, it's perfectly acceptable to abstract code out of the C# scripts within Unity and put them into your own project and develop them separately (maybe with TDD etc), but for the simple reason that Unity is a bit fiddly anyway, I can't see it being an easy task to accomplish.
As it stands, I've written quite a lot of C# scripts in Unity that deal with everything from player movement to object interaction and message relaying, but it doesn't feel quite right. It very much feels like I'm back to basics with C#; I know the syntax, and a number of patterns, but Unity's way of working feels loose and fumbly. I never feel like I'm doing things the right way, and my code is definitely starting to look a little bit like spaghetti code, and is at risk of bug creep. This has a lot to do with the code being "Proof of Concept", and me being unfamiliar with all this new stuff to play with, but I do feel that some things could have been organised just a little bit nicer when they were designing the engine.
Each "script" is basically a C# class that inherits from the Unity base class, MonoBehaviour. Within this class, there's a well documented event pipeline that helps you get off the ground quickly, and is fairly intuitive - for example, you override Start() to execute code when the script starts, and Update() when you want to control things on a per-frame basis. MonoBehaviour also provides a number of protected / public properties that can be used to access common components directly - although Unity suggests using the built in GetComponent() method to get them instead. I do like the way it works, but I'd like to add further redundancy by putting my code into a separate assembly, and writing unit tests for it.
Not So Safe Source
If you're doing any kind of collaboration with Unity, you'll soon discover that its source control support is not very good. Mainly, complaints have arisen to do with the free version previously not supporting text serialization of assets (which Unity have rectified recently in version 4.2), but I can confirm that it doesn't make that much difference, especially when it comes to large or complex assets like scenes. We're using git for our project, and I spent a considerable amount of time setting it up to work as well as it does at the moment. I'll write a blog post about it at a later date.
Through many months of trial and error, it seems that two people can't work on a single scene at once - and if you do, you basically have to ignore any merge that takes place and manually apply the changes. Obviously this can get very complex and time consuming, but it's the only way to do it. Instead, Lew and I have been working on separate scenes or projects; I really can't imagine what it's going to be like when we end up putting some proper levels together.
Model and the World Models with You
I've worked directly with some very good designers over the years, and I've been very appreciative of the experiences. My creativity comes in the form of architecture of systems and structuring code... most things graphical are quite literally mind-bending to me. I've used Photoshop and Illustrator for years, and I know them quite well, but only to manipulate images that already exist; I've never been able to create anything from scratch, but I've gawped at plenty of designers as they've magically created something awesome from literally nothing. Obviously there's going to be a certain amount of graphical work involved in game development, though I'm not sure how I'm gonna get through it!
Modelling, on the other hand, is something I quite enjoy. I've created a few designs over the years for custom built stuff around the house; my console collection cabinet, the BBQ in the back yard, and sound diffusers for my studio, and enjoyed making all of them. The thing is, I've only really modelled complex cubes... when it comes to doing anything more sophisticated, I'm pretty much starting from scratch. It's been challenging, especially having to learn new tools like SketchUp, 3DS Max, and Blender, and all the new terminology and 3D modelling techniques like hierarchies and UV maps. It's a crazy, new experience, and there's a hell of a lot to learn.
Then there's how to actually design models and levels for our game. So far, it's a lot of trial and error - different export settings, playing with hierarchies and origins, figuring out what we need to model individually and what we can combine inside other models, and how to arrange our meshes. Unity allows you to import entire 3D models into your project, automatically generating things like colliders, and UV lightmaps, seriously reducing the amount of time it takes to get things up and running. The hard part is exporting the model from whatever 3D package you have in a way that makes sense in Unity.
The Sound of Silence
These days, good sound design can make or break a game. Even Pong had sound effects, but anyone who's played any modern triple A title will know we've come a hell of a long way since then. Unity features a very easy to use audio system that lets you play various formats of audio file directly from disk, and adjust properties like pitch, volume, and distance rolloff. Luckily, my past experience in the recording studio pays off here, as I've got an array of tools available to me for both recording and editing. At the moment I'm just finding royalty free samples online, though I'm having to do some minor editing to most of them so they fit in with our game.
A game is a pretty boring place if the items your character is interacting with don't make a sound. One thing I didn't think about much before taking this on was that I'd have to think about how every single object will make a number of different noises depending on what you're doing with it. A gun, for example, requires numerous bullet firing sounds, a reload clip, a dry fire noise, noises for shells hitting the ground and bouncing, then there are bullet impact sounds for different materials, glass shattering, crates breaking, and ricochet noises. It all depends on the level of realism you want to achieve, or the type of game you're making, but each new sound you add and calibrate properly really makes a difference when you're play testing.
Hello World
If the coming months are anything like the last few, I'll be spending most of my nights following beginners tutorials on youtube and writing hello world scripts for every new thing I need to accomplish. It makes a refreshing change from writing software for insurance and travel companies, and challenges me on every level. I'm not sure if I'd have managed to get into it if I wasn't for Unity's C# support; I think the challenge of learning something like C++, plus all the extras I've mentioned above would have been overwhelming. It's a good move from the guys at Unity.
So, expect my normal blog posts to be interjected with the occasional Unity 3D related ramble... I imagine I'll be developing this game for a while!