Game journalists like to think they know a lot about video games. For the most part, they do! Some writers have encyclopedic knowledge of the most obscure games: games are their love, the stirrer of their loins, the honey to their bunny. But how much do they know about making games? If this game journalist is anything to go by, the answer rhymes with “schmuck schmall”.
Last week I wrote about how I had started making a mobile game with a group of talented and experienced indie developers. This week, I will write about how badly I am getting my arse kicked by the loveliest people in the gentlest of ways.
When we started the project, the idea of a four-week development cycle appeared perfectly reasonable. I’ve been to 48-hour game jams where small teams have been able to create fascinating games in just two days – we have four weeks! What a luxury! Well, that’s what I’d thought.
“Most iOS games actually take six to nine months to make,” said Craig Duturbure, the game designer in the team.
“Those 48-hour game jams are a bit unrealistic when it comes to an actual development cycle. Trying to get approval from the Apple store alone can take weeks!”
I had not known this. I pretended I did. I stared out into the distance with my sunglasses face.
Getting My Ar(t)se Kicked
I came onto the project assuming my role would be simple. I thought of myself as the dumb kid in the class who was made to wear a helmet by teachers because I kept walking into various objects: walls, doors, rolling pins and occasionally tea cups. Surely no one would entrust that kid with any important tasks, right? Surely I could just do what I’ve always done and, like magic, it will all just work out, right guys? Guys?
The tumbleweed of the game industry rolled its way out of a dusty old hard drive and through my office, stopping in front of me just long enough to say I was wrong and that I should probably remove my sunglasses while indoors.
I had whipped up some concept background art for Craig. I took a photo of the painting and sent it off to him, and this is where the first of my lessons began.
Lesson #1: A good painting does not necessarily make for a good background
The first piece of feedback from Craig was that he liked what I’d painted, but I would need to dramatically reduce the contrast. I was meant to be painting a background that would hang behind the character – if my paintings were too busy, the player would be distracted – they wouldn’t focus on their character, they wouldn’t know where to look, it would be too chaotic.
A terrible first draft of a background painted by yours truly.
I went and studied all my previous paintings and found that they all have a few things in common: they have bright and intense colours, they’re high in contrast, and they’re all very busy. As a painter, I never had to accommodate anyone or anything. My paintings were standalone pieces that didn’t need to complement their surroundings, the frame, or the works of others – all of that would come after the painting was completed. It can be quite a selfish activity, now that I think about it.
As a background artist, my work is meant to be in the background. It is not the centrepiece, and the background does not make the game. Hardly anyone ever plays a game and thinks: “The game design was superb, the graphics were fully sick, and MAN THOSE BACKGROUNDS WOOOOOO! HOT DAMN THEY WERE SIZZLIN’!!!” In fact, I would hazard a guess that no one ever thinks that.
So rather than wave my colourful brush wildly, causing distractions and creating unusable backgrounds, I’ll be spending this week studying the backgrounds in other games to see how they do it.
Lesson #2: We need a unified style
Damian Pin is an incredible artist. He is far more talented and diverse than I will ever be as a painter. He created all the illustrations on this page. Having said that, if the character artist draws something amazing and my background style is on the opposite end of the spectrum, the game is going to look pretty crummy. I am going to have to press pause on the giant machine that is my ego and think about everyone involved in the project and what the game needs.
Lesson #3: Four weeks is going to be a very tight development cycle
Before I caught up with the team about what would be involved in making the game, I had been convinced that game coders are also magicians: they can make a little sponge ball disappear behind my ear before making it reappear behind my other ear. In the process of making the ball reappear, a fully-coded video game would also spontaneously burst forth from my face. I would never look the same again, but the programmer would have an award-winning game on their hands. They would then ride off into the distance, donning sunglasses made of rolled-up million-dollar bills.
I did not know what it meant that our coder, Stuart McVicar, had to decide on a game engine. I did not know how he would create a prototype. I did not know the difference between one game engine and the other and how any of our art and music would be incorporated into the game. As discussion about game engines went on I broke out the panic sweats – I was sweaty like a dolphin is fuzzy. Stuart seemed unperturbed. It’s going to be a tight development cycle, so thank my sponge balls we have a coder who knows what he’s doing.
Lesson #4: Not all saxophone music sounds like an erotic track
The man behind our audio is Matt Christensen. He’ll be composing the music for Tasty Tasty Grandpa from scratch, and he intends on doing it with his saxophone. When I first heard this news, I thought our track would sound like this:
As it turns out, I know nothing.
We’re all set to work through Easter. Craig has set up a task list for all of us in a program that allows us to keep track of who is doing what and when. I haven’t broken anything or set the game on fire yet, so I am going to grip my sponge balls and hope that this is a positive sign of the things to come. WHOOOSH!
This is the second developer diary in a series where Tracey joins a team of experienced game developers to make an iOS game in four weeks.
Leave a Reply