Another week has trampled by us here at Slick! This week we’ll get a little artistic and we’ll be showing you how the art is hacked together for Shellrazer. We’ll also throw in a cool time-lapse video of me drawing up a Shellrazer Scoundrel! What fun!
The first thing we wanted to make sure of in Shellrazer is that it needed to look consistent from screen to screen. This turned out to be a lot easier than we initially thought. All we ended up doing is creating all the art at double iPad resolution and then shrinking it all down 50% before getting them into the game. As long as we remembered to keep track of what brushes and colours we were using it would be a snap. With a few settings and actions this all became second nature and the art began coming together super quickly for our game.
We never really ended up “fixing” any artwork that we didn’t like, we just re-drew it all. This process of constantly creating new assets was very refreshing and helped us make huge artistic strides in the game. Below is a quick image of how everything is drawn, coloured, and shaded in Shellrazer’s world. By keeping up these habits it makes everything in the game work together.
Here’s a quick video we put together showing some timelapse footage of me drawing some artwork for Shellrazer. This art isn’t used in the final game, but it’s a fun way too keep up to speed on the universe of the game. With the Scoundrel series I’ve been trying to get back to the old instruction manual artwork that helped out some of the low-fidelity enemies. The baddies in Shellrazer are also pretty simple and small, but I’m crazy about them and wanted to represent them a little more properly.
And just so your ears don’t feel left out, there’s some music by the super skilled Riley Koenig!
Another week has past!
We are nearing the end of our development journey. It’s an exciting place to be for sure and we look forward to shipping this soon! Thanks so much for stopping by and remember to keep those turtle cannons blazing!
This week we get another tech post from our very own Nick! He’ll be covering how he’s managed to get our game running super smooth and displaying tons of stuff! Take it away Nick.
This week I’ll talk about an optimization that increased the framerate significantly on older iPad and iPod touch models.
One of the main performance bottlenecks of the iPad 1 is alpha blended triangles (or pixels, really). This is mentioned in the apple documentation, and they recommend drawing opaque triangles as much as possible. We tested this, and the difference between rendering opaque and alpha blended pixels is HUGE. The PowerVR chip handles opaque triangles very nicely, effectively eliminating any overdraw. Alpha blended triangles, not so much.
In our game we draw a ton of sprites, which use large textures with alpha. On the iPad 1 we had a bit of a performance problem when we drew a lot of them, so something had to be done. The solution is simple: draw less alpha blended pixels! The way I implemented this in the engine is to attach a ‘texture polygon’ to each texture. (Texture Polygon is actually a wrong name for it, it’s more of a texture mesh). Whenever we want to draw the texture on screen, instead of drawing a quad, we draw the mesh instead.
Here’s a screenshot of our game with our alpha blended debugging shader enabled. This screenshot is the ‘before Texture Polygons’ picture. The red parts are pixels that were drawn using alphablending.
The texture polygon has opaque and transparent triangles. This allows us to batch up all opaque triangles, and all alpha triangles. We draw the opaque ones in one big batch first, and then the alpha blended ones. The cool thing is that the alpha blended triangles have a zbuffer that allows quick pixel rejection.
Here is the same location, this time with texture polygons. As you can see there’s a lot more green areas, which is good! There’s still that big red block at the bottom, but we want that part to be transparent, so there really isn’t any other way to do this but alpha blending.
To edit the texture polygons, I created a little tool that allows us to place points and add opaque and alpha blended triangles. The goal is to create a large a surface as possible using opaque triangles (so for areas where the alpha value of the texture is 1), and put skirts of alpha blended triangles around the edges to keep the nice alpha blended edges.
All in all, this technique is VERY effective. We’ve more than doubled our framerate in general, and on some screens we’ve seen a speed increase of over 400%!
Alright, that’s all for this week. The game is really coming together now! It won’t be long before you can play it for yourself!
It’s week 17! This time we get technical with our very own Nick Waanders who’s here to tell us a bit of development wisdom and show all you nice people how we get this game made! Thanks for taking some time out of your coding schedule to fill us all in!
Hey all. It’s been a while since I’ve written a technical blog post. The last time was all about our 3D stuff, but ShellRazer is obviously a 2D game with a lot of things moving on screen. On iOS it can be challenging to make this run smoothly, so today I’ll describe one trick we’ve been using to speed things up: Texture Atlas Generation.
So, the problem is that drawing a ton of different sprites on an iPhone can be really slow, depending on how you do it. If you have separate textures for each sprite, it means that for each sprite you need to set up your vertices, set the active texture, do a draw call. This gets really slow if you have hundreds of things moving on screen. So it would be better if you could combine all these calls into ONE call, wouldn’t it? Well, this is where Texture Atlases come in. The idea of texture atlases is not new, it’s even recommended by Apple. There are many links on the internetz about how to efficiently pack textures into a larger texture, and I pack the textures using this method.
Now, obviously Jesse wouldn’t like to work with large texture atlases and manually picking the correct UV’s for each sprite part, so I had to come up with a way to do all this stuff behind the scenes. For that purpose I created a texture tool that enables me to put textures into a specific texture atlas, resize them, change the compression, etc. The tool spits out an XML file that knows the settings for each texture file in the data directory, and when I build the game, the texture atlases get generated based on these settings.
In this screenshot you can see the texture atlas for the world map (hi-lighted), and the settings. It uses a n RGBA8888 format, and it’s 512×512 in size. As you can see we have many different texture atlases, and they get loaded into memory at different stages in the game. One 2048×2048 texture atlas with an RGBA8888 format is quite big actually (16Mb), but loading on iOS devices is crazy fast, so it’s no problem. I’ll talk more about how to load data quickly in a separate blog post, but if you can’t wait, just look up one of Carmack’s posts about mmap.
Now, one thing I (as a programmer) like is that even in the code the texture atlases are ‘behind the scenes’. The engine only handles texture atlases in the very low-level rendering routines, and everywhere else in the code, I just work with a Texture Resource. All the art assets that refer to the texture atlas already have their UV’s adjusted during the build process, so there is no difficult stuff going on in the engine. Everything complicated happens in the build process and in the editors. I love optimizations like this, all the complexity is moved out of the game into the tools, everything becomes faster, yet all the inputs to the system remain the same.
Ok, so that’s a little bit about the things we had to do in the code to get Jesse’s art running at a decent pace. I could talk about a lot more topics, such as how we sped up our alpha blended sprites by over 400%, how all our loading times are below a second, and how we can change the tuning of the game while playing it, but those are for another time!
This week we have a special guest! It’s our Audio Director Jennifer Lewis! Jenn has been blasting out epic audio for 30 years (18 of them in games) and has tackled titles from Company of Heroes to Need for Speed! A true champion of the medium, Jenn’s love for sound revolves around story telling and and how it motivates people. Thanks so much for taking some time to talk with us Jenn!
Hi everyone! It’s great to come out from behind the sonic Shellstorm to be the guest blogger this week! Week Sixteeeeeeeeeen!
In case you didn’t know, we’re sprinting now. Speakers are pumping, neighbours are thumping. So later in the day, headphones get a-rattling. The end flag is in sight and audio bits are flying around in all directions! They’re shooting at Petrodactyls… they’re shooting down Petrodactyls! They pump up balloons and some sound like buffoons. Some break open chests. Some magnify loot. Some make you feel great, while some give you a boot. There are even a few, which beltch, bleet and shoot. Buzt… zap … kerpow!
Then there are the music bits. We scored musical treasure with a first time collaboration between Stefan Seslija and Gordon McGladdery (click on their names to go to their online portfolios). They’re 2 students, currently enrolled in the sound program at Vancouver Film School. Gordon and Stefan have mashed up their unique styles to contribute a modern and nostalgic vibe. I wish I could post it all here for you to hear but that’d be all spoilerly. So, for now, here’s a teaser: a carrot for you to seek out in game.
It’s a stellar time here, making this game. So with that I don headphones, and head off to sling sonic bits so that our turtle is well accompanied on his journey. As will you be!
Welcome back followers of the fearsome! This week it’s time for another tech-post. However, it won’t be about a shiny new rendering technique. Instead it’s about an equally important part of the process of creating a game: the build machine. In my IGS/GDC talks about developing N+ and Scrap Metal I’ve stressed how good it […]