Archives by Month - February 2012

OddBall Graphics Update

7:05 PM February 29, 2012
My goal with Oddball development this month was to start adding more eye candy and presentable graphics to the game. Up until last month, pretty much everything in Oddball was placeholder art. I've always had a strong vision of what I wanted the art to look like in the game, but I have been putting off making it because I am never satisfied with my own art and I know how tedious it can be to make. Alas, as my game gets closer to completion I can no longer continue to put it off. So for February I strapped in for a month of tedious graphical tweaks (and as a result further performance tweaks in order to keep the game playing smooth on the iPhone).

Having had a fair bit of experience making 3D levels for games in a semi-realistic style (for Quake, Half-life, Half-life 2, and Unreal Tournament) I knew that I could get some decent semi-realistic graphics working in Oddball. I am not an artist in the same way that a proper computer artist is. I can not paint beautifully stylized cartoon art for a game, and if I tried I know I would be constantly frustrated and unsatisfied with my results. I know what my talents are with game development art and I know that I can achieve decent graphics with certain styles, but awesomely stylized art is not my strong point. Oddball has always been a personal project, starting first as a way for me to learn the Unity3D engine and culminating in an opportunity for me to release an iPhone game on my own. So I knew that I would not be collaborating with a proper artist on this game (but I do have plans for that in my next project) and that left me envisioning a semi-realistic and slightly cartoony style for Oddball because I know I could achieve that.

Knowing how to approach this style artistically does not mean it has been easy. Making a game for the iPhone (or any mobile device) is a constant battle of balancing performance with your design. Even the simplest games have become progressively more complicated and advanced these days, and mobile devices probably have the lowest specifications of any platform you can develop for today. So developing games on mobile devices often requires you to cut features and graphical fanciness in exchange for a smoother playing experience. It can be interesting coming up with trickery and hacks to get things working and looking how you want on a phone, but the trade-offs never end. Since Oddball is already a physics-heavy game, it requires a lot of CPU processing power from a device like the iPhone. Balancing the performance has been a constant struggle with that alone. However, adding in the prospect of somewhat realistic graphics has made it even more difficult.

I am now almost at a stage where I am ready to lock-in my graphics. It's a constant process of updating and tweaking things, but they have definitely progressed to a point where I'm becoming satisfied. So let's start with what OddBall looked like up until last month. Everything was placeholder art at this point as I got the gameplay working. Objects in Oddball are real 3D, but they looked flat and lifeless because they were simply blobs of colour on the screen:

My first task was to go out and take a bunch of photos for textures to use throughout the game. Oddball takes place mostly in a factory setting, and so that theme requires various concrete, brick, wood and metal textures. I'm still working on many of the textures, but I've completed enough to show a few partially completed scenes now. My first iteration of textured walls looked like this:

As you can see the textures definitely help the overall look, but everything still looks pretty flat. This is because shadows and lighting were not processed in the screenshot. Lighting a 3D environment on a mobile device in realtime is expensive on resources. At most I could have 1 directional light in the scene to give a bit of shading, but it would not generate real shadows and certainly wouldn't show dynamic shadows on moving objects. So my next step involved using Unity3D's built in Beast Lightmapping technology. This essentially lets you setup a few lights in your scene and "bake" the generated shadows onto your static textures. The result is that objects that don't move (walls) can have shadows pre-processed and rendered for a more 3D and realistic look. I am still tweaking the settings for this, but here is a snapshot after this step (with a new background too):

The next step was to add dynamic shadows to the balls as they move infront of the wall. Having real dynamic shadows is not really possible on the iPhone, so it's all about faking it. Unity provides resources for shadow blobs (which basically project a shadow texture from an angle away from your object and onto other objects behind it). This works well, but again is a bit too resource intensive for a phone. It adds 1 draw call per object it projects the shadow onto. So depending on the angle, the shadow blob could often be projecting onto 2, 3 or 4 other objects at once. As I've mentioned before, performance is the name of the game with mobile game development, and keeping your draw calls low is important. So instead, I ended up scripting a simple system of my own that draws 1 single fake shadow texture behind each ball that moves with those balls. The result works well because my game has a single unmoving camera perspective and I can tweak it to look pretty good from that one angle.

As I continued to tweak those settings and those of the lightmapping (it's always a continuous process) I began concentrating on the look of the Oddballs themselves. These are the main "actors" of the game and it is important they look good. Using shaders designed for mobile graphics processors, I tested a few different looks. This part was especially hard because shaders can be very resource heavy if you want fancy effects like dynamic specular shininess, bump mapping, reflectiveness and other details. In the end I needed to find something that was fast (draws the balls in only 1 draw pass which means nothing too fancy) but that also made the balls look more 3D. After testing many mobile shaders, I ended up learning to write my own and created a simple spheremap shader that blends a base texture with an overlayed spheremap. The result (when viewed in motion) is that the balls have "fake" specular shininess and shading that moves as they move and it only costs 1 draw call:

Surprisingly, the simple sponge ball was the hardest to get looking good. The other 2 balls are shiny and that was easy to fake, but the sponge ball is just a dull material. It's also too small on the screen to show much detail for sponge holes so adding that detail was pointless. After many iterations I settled on the current look you see above.

I am still working on the rest of the game's graphics. As mentioned, this is a continuous process, but at least things have now progressed to a point where I have an art style and direction. Next on my list is to model a proper cannon, texture the firing button and scoring target, and to create more textures and level pieces. I will continue to post updates as the look and feel of Oddball progreses. For now, enjoy the leap day as it will be another 4 years until the next :).

This entry posted by Graham in OddBalls  |  Comments (0)
Tags: Game Development, OddBalls, Unity3D