I’m no stranger to game development, having dabbled in it when I was at University. It was by far my favourite course as whilst I had a decent amount of programming knowledge translating that into creating something playable seemed like a monumental step that required a whole lot of knowledge I simply did not have. This was long before the time when tools like Unity or GameMaker were considered viable and our lecturer made everything easy for us by providing a simple framework on top of DirectX, allowing us to create simple 2D games without having to learn the notoriously complicated API. Since then I’ve tried my hand at Unity several times over and whilst it seems like a programmer’s dream there’s always one place I come unstuck on: the art.
This isn’t exactly an unknown issue to me, all my university projects used sprites that were pilfered from various free game resource sites and anything extra was little more than primitive 3D objects whipped up in 3D Studio Max. For my current project however I had the bright idea to try and generate some terrain using one of those fancy bits of software that seem to make good looking landscapes without too much hassle. After wandering through a sea of options I found Bryce seemed to be the one to go for and, better yet, it had the ability to export all the mesh so I could import it directly into Unity without too many hassles. For the $20 asking price I figured it’d be worth it to get me going and hey, should I want to go full procedural down the line it’d be a good introduction into the things I’d need to consider.
Oh how naive I was back then…
Whilst Bryce is everything it claims to be (and the tutorials on using it are really quite good) I just couldn’t seem to get it to create the type of scenery I had in my head. This is entirely a user based problem, one that I’ve suffered with for a long time where the interconnects between my brain and the tools I’m using to create just don’t seem to be able to gel well enough to produce the results I’m looking for. Whilst I was able to generate a decent looking mesh and import it into Unity it was nothing like I wanted it to be and, after sinking a couple hours into it, I decided that it was best left to one side lest I uninstall everything in frustration.
Realistically though the problem was one of expectations where the disjoint between my abilities with a program I had never used before and my expectations of what I’d produce were completely out of alignment. After mulling it over for the past couple days I’ve come to realise that I had set the bar way too high for what I wanted to create and indeed creating such things at this stage of development is actually a distraction from the larger goals I’m trying to achieve. I’ve since settled on just making do with a flat plane for now (as that’s all I’ll really need for the foreseeable future) or, should I really want to put something pretty in there, I’ll just lift a 3D model from a game that’s close enough so I’ve got something to work with.
You’d think after churning through project after project I would’ve become adept at recognising when I was pursuing something that was antithetical to making actual progress but it seems even after so many years I still find myself making things far more difficult than they need to be. What I really need to do is focus on the parts where I can make good progress and, should I make enough in those areas, then look towards doing the parts that are outside my area of expertise. Of course the best solution would be to partner with a 3D artist, but I’d rather wait until I’ve got something substantial working before I try and sell someone else on my idea.
That is unless you’re one and you’ve got nothing better to do with your time
Cross platform development is one of those things that I’ve seen done dozens of times before but rarely do I see anyone get it right. I understand the allure of doing so, heck my most creative forms of procrastination came from experimenting with these ideas, but the fact remains that more often than not they’re going to be a total waste of your time. I do have one exception to this rule however and that comes in the form of the cross-platform game engine Unity. Where other libraries promise compatibility and a wide range of functions Unity actually delivers on these with little compromise. Couple that with their ridiculously good pricing model and awesome dev environment and it’s hard to fault the product. Indeed all the shortcomings I found were, as far as I could tell, limitations of my programming expertise.
For games developers Unity offers the chance to have one code base for all platforms with only minor tweaking required once you want to deploy the project to your chosen platform. This is great because initially you can focus on one platform and then once you’ve verified your product there it doesn’t take much to port it to the new platform. It’s no surprise then that you’ll find many Unity based games in both the Apple and Android app stores. Figuring that Unity was going for all round platform domination I thought it was only a matter of time before I saw that the library would support Windows Phone 7, even though it’s still in its nascent stages.
As it turns out however that won’t be happening:
The Unity engine does not support Windows Phone 7 because of restrictions placed on Microsoft’s mobile, the CEO of Unity Technologies has said.
“But we’re looking at Windows Phone 8 and hopefully it will be easier to work on that system,” he said.
In an interview with Develop, to be published soon, Helgason explained Windows Phone 7 “is a relatively closed system so you can’t run native content, which means we can’t really support it”.
The “closed” nature that David Helgason (CEO of Unity) is referring to is the fact that if you want to put a game on the Windows Phone 7 platform you need to have coded it in either Silverlight or Microsoft’s XNA framework. Unity then approached Microsoft to see if they could get an exemption from this rule (as well as access to some private APIs which would be required for their libraries to work) however Microsoft turned them down. This means that Unity and all the games built on top of it are banned from being released on this platform, save for a full rewrite of the code. In response Unity has turned their sites towards Windows 8 which will be a lot more friendly for them thanks to the WinRT framework.
This feels like a pretty big misstep from Microsoft. Windows Phone 7 hasn’t been gaining any momentum and it’s overall smart phone market share (that includes Windows Mobile devices) has been taking quite the battering dropping to a low of 1.6%. Whilst I won’t go as far to say that Unity would be its saving grace it definitely wouldn’t hurt to have that available as an option for games developers looking to develop for the Windows Phone 7 platform. Indeed since Unity supports coding in C# I’d hazard a guess that there would be quite a few who’d be willing to give it a shot just because it would be easy for them to learn. Heck I know I did.
In reality Windows Phone 7 has a lot of other hurdle to overcome before it can be considered a serious competitor in the market but Microsoft can’t afford to throw away any potential advantage it can get. Not working with Unity only serves to damage the Windows Phone 7 platform as it has demonstrated success on every platform it’s available on. Unity developers then may have to wait for Windows 8 and the corresponding Windows Phone release before they can think about coming across onto Microsoft’s platform but I feel that may be too far off, and the damage has already been done.
I can remember sitting in one of my university lectures a long time ago being taught about development philosophies. It was all pretty standard stuff, we were walked through the “traditional” methods of development (basically the once through, waterfall technique) and then brought up to speed on the more modern iterative approaches. However one little soundbite always stuck out in my head and that was when the lecturer asked us who pays for rework when a product doesn’t fit a customer’s expectations? The simple answer was you, the one who developed it and it’s something that always plays over in my head when I’m working on a project, especially those ones I do at home.
I’ve been paying extensively for rework with my latest forays into the world of game development. My regular readers and Twitter followers would’ve noticed that I cheerfully announced my success in cracking the stable orbit problem. Indeed in a round about way I had, basically my Unity scripts would push the planet around until it hit a stable orbit and afterwards would calculate the required velocity before turning off completely, letting the heavenly body orbit in a near perfect circle around its star. This worked for the 2 planets I had in there but unfortunately the equations I had developed didn’t generalize very well and adding in planets at random locations with random weights led to all sorts of wobbly orbits with planets meeting both fiery deaths and cold extinctions at the cruel hand of my orbit stabilizer. I was back to square one and I spent most of the weekend trying to figure out a fix.
Eventually I came back around to the idea that my smart-ass subconscious came up with a while ago. I had tried to implement it before but I gave up in frustration when the results I got were no different than from my far more complicated “find the angle between the sun and body, increment it a bit, find the new position, create a vector to it then apply force in that direction” when in reality the fault lied in the orbit stabilization code. All that pushing and pulling that made the orbit look stable was in fact imparting all sorts of wild forces on the poor little planet, when in fact the best way is just to simply let gravity do the work for you. With this in mind I re-implemented my perpendicular force calculations and then devised a rudimentary equation that combined the mass, radius and a fudge factor that let me hand stabilize the orbit. In the past attempting to do this stuff manually took me an hour or so per planet, with this revised code I was able to do one in minutes and have developed a new equation that is able to accurately send a planet into a stable orbit no matter where I place it in the game.
This solution was far more simple and elegant than what I had been trying to do previously but the cost in terms of rework was tremendously high. I’m lucky in this respect in that the client for this is just myself and my friend at the moment but had this been for someone else with whom I had a contractual relationship with that kind of rework would’ve been extremely costly. Of course I could try to make the client pay for it but ask anyone who’s gone back to a client asking for more money after saying they could do it for a certain price and you’ll usually be laughed out of the office, if not walked out of there by security.
Working around this isn’t easy as clients will usually want to have a strict set of deliverables and time frames which seems to rule out any iterative or agile development methodology. It also pushes a team dangerously towards suffering from analysis paralysis as you agonize over every requirement to make sure it’s covered off in the final product. A healthy amount of analysis is good for any project, especially if it makes the product easy to maintain or modify, but it’s also incredibly easy to fall into a never ending spiral of pointlessness. Thankfully however I’ve noticed that clients are far more receptive to the idea of milestones these days which lines up well with any iterative process, skirting around these problems easily.
Going after the most simple and elegant solution might seem like the best idea at the time but in my experience it’s those kinds of solutions that take the longest to achieve. It’s almost always worth it, especially if all you’re spending is your own time, but when you’re working for someone else they might not be so keen for you to spend inordinate amounts of time chasing your white whale solution. This probably explains why a lot of software contains incomprehensible code riddled with bugs, but that’s a whole ‘nother ball game and a blog post for another day.
So I’ve decided to try my hand at being a game developer after spending way too many hours thinking about it and wanting to do something more exciting than developing yet another web application. This isn’t the first time I’ve tried my hand at developing games either, I did a semester long course in games development back when I was in university. That course still rates as one of the most fun and interesting semesters I ever spent there, especially when your games were put up against the harshest critics I’ve ever met: the lecturer’s two kids. After finishing that course however I never really continued to try and make games until a mate of mine introduced me to Unity.
For a straight up programmer like myself Unity is a bit of an odd beast. The Unity editor reminded me of the brief foray I had with 3D Studio Max back in college, as it sported many of the same features like the split screen viewport and right hand column with all object’s properties in it. It’s very easy to navigate around and it didn’t take me long to whip up a simple littlesolar system simulator, albeit one that lacks any form of gameplay or semblance of realism. Still being able to go from never having used the product before to making something that would’ve taken me weeks in the space of a single weekend was pretty exciting, so I started about working on my game idea.
So of course the first game I want to make is based in space and the demo I’ve linked to before was the first steps to realizing the idea. It was however very unrealistic as the motion of the planet is governed by simply tracing out a circle, with no hint of gravity to influence things. Additionally the relative sizes and distances were completely ludicrous so I first set about making things a little more realistic to satisfy the scientist in me. Doing some rough calculations and devising my own in game scale (1 unit = 1,000KM) I made everything realistic and the result was pretty tragic.
The sun took up the vast majority of the screen until you zoomed out to crazy levels, at which point I couldn’t find where the hell my little planet had gotten off to. After panning around for a bit I saw it hiding about 4 meters above the top of my monitor, indistinguishable from the grey background it sat on. Considering this game will hopefully be played on mobile phones and tablets the thought of having to scroll like a madman constantly didn’t seem like a fantastic idea, and I relegated myself to ditching realism in favor of better gameplay. My artistic friend said we should go for something like “stylized physics”, which seems quite apt for the idea we’re going after.
It might seem obvious but the idea of suspending parts of reality for the sake of game play is what makes so many games we play today fun. The Call of Duty series of games would be no where near as fun if you got shot once in the arm and then proceeded to spend the next hour screaming for a medic, only to not be able to go back into the mission for another couple weeks while your avatar recuperated. The onus is on the developer however to find that right balance of realism and fantasy so that the unrealistic parts flow naturally into the realistic, creating a game experience that’s both fun and doesn’t make the player think that it’s an unrealistic (or unfathomable) mess.
I’m sure my walk down the game developer road will be littered with many obvious-yet-unrealized revelations like these and even my last two weeks with Unity have been a bit of an eye opener for me. Like with any of my endeavors I’ll be posting up our progress for everyone to have a fiddle with over in The Lab and I’ll routinely be pestering everyone for feedback. Since I’m not going at this solo anymore hopefully progress will be a little bit more speedy than with my previous projects and I’ll spend a lot less time talking about it