Saturday 17 May 2014

Small Details

Writing this feels like I’m coming up for air.

I read an article somewhere the other day which suggested that it takes six months to develop even the simplest game. I’m not entirely sure that can be correct, but, perhaps taken as an average, it’s probably much closer to the truth than the fabled ‘couple of days’ it took the Flappy Bird genius to weave his magic.

At the other end of the genius scale where things don’t come easily and everything is a struggle, it only feels like I get closer to the end as I tick off the increasingly mundane tasks that dominate my ‘To Do ‘list. Beyond that, I spend most of my time fixing bugs and populating my levels with graphics. My problem goes back to the beginning when I didn’t so much design the game as start to play with Unity and a game gradually began to emerge. My game levels are potentially huge, though there are limitations which means not every square inch needs to be populated with landscape. I’m naturally reusing assets all the time but I need to break that up with unique graphics, which is where most of my efforts are not deployed.

The bug fixing takes the longest. A bug earlier in the week took two days to figure out but taught me an important lesson about the difference between Unity’s Awake() and Start() methods. Compared to that, coding new features is an absolute pleasure that rarely takes a very long.

The exception to that rule was the problem I faced creating explosions in my game. Having explosions came pretty late in the process and I thought it would be an easy thing to add. Unity has an AddExplosiveForce method  which you can add to game objects so they act as a bomb, pushing other objects away. However, Unity separates its 3D functionality from the 2D in an obvious way. If a method is designed for 2D games, it will have ‘2D’ appended to the end of the name. So, for example, there’s a RigidBody component, which makes a 3D game object respond to gravity and forces. There’s also a RigidBody2D component with does the same for 2D objects. AddExplosiveForce adds an explosive force to a 3D object and, as you’d guess, AddExplosiveForce2D would do the same for 2D objects.

Except Unity doesn’t currently have AddExplosiveForce2D which meant I had to write my own. It took a day but I solved the problem and my explosions are now working well, with sticks of dynamite even destroying other objects with a nice blast that radiates out. However, it’s an example of how I’m spending my days implementing features which are only a very small fraction of the finished game.

Not everything takes so long. I’d been putting off adding more online leaderboards to the game but I finished that just now, perhaps half an hour’s work to add 30 leaderboards, one for each level I’m currently planning to include in the finished game. I also finished adding the majority of my ‘achievements’ and they now stand around the fifty mark which means I’ll have to spend extra time checking that every one of them works, which means yet another game reset so I can play through it and unlock the achievements myself.

Even at this relatively late stage in the process, I’m learning new things. The surprising thing I’ve recently discovering is that it can be really small things that make a difference. Attention to detail is important. Just as a whim, I added a very small detail to the game about three days ago and it has completely changed the game’s dynamic for the better. It was an addition I made simply to add a little variety to the gameplay but it completely changed the way the game feels. The same is true of sound effects. I still have a few sound effects that don’t fit but those that do really make a difference.

In a way, I suppose all of this is my way of saying that ‘things are coming together’. As it stands, the game is pretty much finished in terms of the gameplay (though I constantly worry that there are times when the player doesn’t have enough to do). I have quite a bit of level design to complete, but that simply comes down to my finding the time to draw custom graphics for the different challenges. On top of that, there are things to write and I have to create some tutorial mode or, at the very least, provide instructions on how to play the game.

Then my final step will be to add some advertising, which I’ll do simply in the vague hope that it might earn me a few bob when others try this game. I don’t expect it to hang around on people’s smartphones and tablets for very long but I’d like to maximise whatever revenue I can generate. All this work should have a point and, I admit, at the moment, I fail to see what that point could be beyond my own amusement.

 

2 comments:

  1. Blimey.

    I once wrote a program to print semi-logarithmic graph paper (it was MSDOS so is bugger all use now) because I couldn't find any. That was the pinnacle of my programming years.

    Now I wait for people like you to sort it out ;)

    ReplyDelete
  2. Ah, I sometimes miss DOS and a world where you had to do everything by hand yet now I wouldn't even know how to write a half-decent .bat file without having to search on the web... I started out in that kind of environment and gradually stopped programming when everything moved to graphic editors and was Object Orientated. I thought everything was getting too automated. Wish I'd stuck with it. Unity is a wonderful play to program. I could never have written a game as good as the one I have here in just two months. Not even two years and, certainly, not by myself.

    ReplyDelete