In the last post you got a little bit of an insight into our daily routines, the fact business matters can distract from development, that coffee is drunk in copious amounts and that we can be lazy when we want to. In this post, though, I'll try to paint a picture of our actual development process.

Thanks to Google Wave we have an on-line repository of game ideas. Usually ideas come thick and fast and we note them down, sometimes with notes on why one of us thinks a particular idea is worth pursuing or not. Whenever we decide it's time to look at a new project we go through the list and discuss our best options and ideas. As I've mentioned before, getting ideas is the easy part, but deciding which project to go for next is quite difficult. Both Paul and I have our little "vanity projects" we'd like to do, but those are usually too big for a small team and would require significant time and money investments. So naturally we focus on the do-able, the most fun and interesting ideas. Once we have picked one we try to decide whose baby it is.

One thing I've learned working at Japanese development studios is that having a single person at the top in charge of final decisions is a pretty good way of working, if that person is rational, schedule-minded and knows what's going on. So this is one element we've tried to incorporate in the way we do things at Score Studios. Though the process is 99% collaborative, in the end it's best to have one of us in charge of a product, making final decisions on looks, design, implementation, etc. As Paul and I are usually well in tune with each other, these decisions usually come naturally without either of us having to put our foot down, but it's good to know that when necessary the buck stops at just one of us. Design by committee is something we really want to avoid.

The "auteur" usually is the person who pitched the original idea. Flock It! for example grew out of an original idea of Paul's, with plenty of input from myself. He focused mainly on the flocking and gameplay code, tuning it until he was happy with it, but giving me free reign over the graphic style and level design. Score Video Poker grew out of my personal desire to have a decent video poker game on the iPhone that had an auto-hold feature. Development of this title saw me basically telling Paul how I wanted it to work. As I said, everything we do is collaborative, and I would never try to credit one person's input over another, but during development it really helps us keep focus.

Once an idea is decided upon, we each go do our own thing. Paul will either take an existing prototype or create a new one that covers the basics of the gameplay. Usually he uses art from earlier games as placeholders and scripts the game in our tool to basically work as we intend it to. It is important we get this running very early on, as balancing and tweaking the gameplay is the hardest, most time-consuming task of development. It doesn't really matter if it looks like the end product, as long as we can play it, get feedback and come across early problems and issues we'll need to fix. Due to the nature of the tool and script, the way Paul built it up from scratch to his own specific architecture, it usually takes him no time at all to get something up and running.

Myself, I start making mockups of the art, graphical user interface and in-game graphics. I try to pick a "feel" for the graphics early on, a technique so that I am sure the rest of the art I create all fits in with the art style. I usually make these in Photoshop and send fake screenshots to Paul for feedback.

While I create these I am always careful to keep my work process as open as possible; if you're familiar with Photoshop you can, for example, "flatten" layers together to keep things organised, but at this stage I never do this, instead organising everything in folders. This way, once I pick a good style I can go back and apply the same effects to other required art or make an actionscript to do it automatically. As you might have seen in an earlier blog post about the art of Flock It!, for example, each rendered image underwent the same post-production steps, so I made a little script for that to speed up the process and to make sure everything looked the same, that nothing stuck out as being odd, or off kilter.

Once a prototype is running and an art style has been decided our processes start to overlap. As Paul continues scripting the game, optimising gameplay and adding features I start adding final art to the tool as much as possible. That way we will be running a prototype in a form much closer to the final product, which will often bring up new issues we hadn't foreseen. Where will we fit this integral part of the GUI, for example, or figuring out why certain in-game objects don't look right once the game is running. This part of the process can be a little frustrating, as the game will look more and more finished, yet it is still fairly incomplete. Plus developing while at the same time bug tracking can slow down the process. I will tell Paul that something isn't working right, and he'll say that he hasn't optimised that part yet, but that it's on his task list. Most of this down to exuberance and excitement; seeing your work in action is always exciting and it's hard to not to get too keen at this point.

What follows is the scourge of every game developer in the world; the final push. The design has been implemented, it works, you have had your creativity but now it's hard graft. Now I have to spend a lot of time simply making assets and Paul is optimising and fixing bugs. There is not much room for creativity anymore, it's simply a matter of getting it done. There is always a temptation to add more features at this point, to keep the brain sharp, but that usually just delays the process needlessly. You have to be disciplined and work hard, hunker down.

Nearing the end of this part of the process we start letting friends and family members play the game for that important feedback. Some close friends and family members might have had an opportunity to sneak a peek earlier in the process, but it is always important to show something that is pretty much complete or people get the wrong impression. The feedback we get is very important to us. We may think we know what is fun, we certainly know what we think is fun, but if our prospective customers are not enjoying it there is absolutely no point. Because of the nature of Paul's scripting framework it is fairly easy to make tweaks or add features that we now find out people are really hankering for. We found this after we released Score Video Poker, Bail-out and Flock It!, reading reviews and web forums, and we gladly went back to add features people felt were missing. Not all proposed features are worthwhile implementing, but often if enough people are saying the same thing we will have to swallow our pride and admit we messed up.

Once we finish our game, or at least version 1, we submit it and start working on PR materials and screenshots. But even before that, we go back to our list of ideas and start thinking of the next one. And the whole process repeats itself.

If this post was useful or interesting to you, or if you have questions or comments we'd love to hear from you at info@score-studios.jp.

Comment in our forums ...