Wednesday, November 17, 2010

Atlas Textures

When we first started with Call Connect we used the method for textures that I had been using for my OpenGL framework since I created it which was to have each visual item in it's own texture. And whilst this was working fine for the most part we discovered that there were a few visual abnormalities cropping up such as sprites not appearing to draw at exactly the right size as well as there being artifacts around the edges of some of the textures.

As OpenGL requires that all textures put loaded by it need to be at a power of two this meant that the majority of our images needed to be stretched or squashed into a power of two texture which OpenGL would then resize to the correct size when drawing.

  • An example of the stretched plug animation
 Greg noticed that when he resized the sprites to be saved out into power of two textures and then resized them back the textures would sometimes gain artifacts around the edges. As we could always notice these visual quirks when playing the game we decided something needed to be done.

That was when we came to Atlas Textures. I'd known about using atlas textures for a while but it was always the same thing of choosing between spending time going back and rewriting a bunch of code that worked already (for the most part) or writing new code for features of the game. The latter choice always won out but now that there were some real issues to be resolved we decided to spend the time to make it work properly.

If you don't know about atlas texturing the basic concept is to have one big texture that you put all of your various sprites and animations in, fitting them like a puzzle, and whenever you need to draw a specific sprite you only draw that section of the atlas texture.
The benefits of using this technique are twofold.
Firstly, you don't need to resize any of your sprites into textures of power of two as you can fit them into the atlas texture in their original form.
Secondly, the way OpenGL works is that it loads in each texture to the memory when it needs to draw it so therefore the more textures you have the more time OpenGL will spend swapping and loading in new textures each time the game draws. But if you use one atlas texture OpenGL just needs to load that one big texture at the start of the draw call and each sprite in the game will just draw it's own subsection from that texture. This can be a big performance boost in a sprite heavy game.

  • Here is the (unfinished) atlas texture we are using for Call Connect
 Once we had the atlas texture set up all that was needed was to reprogram the sprite and animation classes to handle drawing from the big atlas texture and to calculate the pixel positions for the top left and bottom right of each sprite.
Whilst the static sprites made the change quite easily the animations required a bit more mathematical rejiggering and after a few "WTF why isn't this working!" moments I managed to get it working as smoothly as it was before. The visual improvement on the static sprites was noticable straight away and the animations looked better too. This blog post is being written after when the atlas texture was implemented and before all the textures have been swapped over to their atlas texture version (I was keen to write this down!) so we shall the overall improvement when that process is complete.

And even though we probably won't see a performance boost in Call Connect due to it's relatively simple nature - in terms of processing and sprite drawing - we have set ourselves up to be able to create much more system intensive games in the future.

So I guess what I'm saying is: Use atlas textures, they'll be worth it in the long run.
Oh and there's some handy tools out there like this flash Atlas Texture creation thingy which you can also download:


Sunday, November 7, 2010

Mein Craft

Few people on the gaming globe (it's like the regular globe, just a tad smaller) have yet to hear about Minecraft.  Speaking of globes, the potential maximum size of a Minecraft map would allegedly take around 6 years to traverse on foot.  I am willing to take on this Craft Walk challenge and am currently taking donations on behalf of ClockFund, a non-profit organization dedicated to... well, obviously that is a lie.

Lying aside, Minecraft is fast becoming the definitive PC game of this year and possibly the decade to follow.  While much is made of the adventuring aspects, the griefing, the ingenuity and dedication of certain players (see the functioning 16bit ALU for a frightening example), the vast, complex projects constructed using the myriad tools and editors that have sprung up since MC first appeared, my time with MC has revealed perhaps it's most appealing aspect; teamwork.

I dabbled briefly with the singleplayer to become acquainted with the rules and control scheme, but multiplayer was clearly the budding minecrafter's natural habitat.  Having joined a server of like-minded types, we set about creating an environment that lacked any kind of architectural consistency.  Castles here, sunspheres there, an impossibly high diving board and a tree that touched the world's invisible ceiling.  None of it really fit; these would not be 'council approved' constructions.  I had built my own little castle and continue to work on it but the most interesting and discussion-worthy experience I have so far is interaction with fellow crafters.  Myself and one other local decided to collaborate on a rail line, one that would run a complete circuit of the inconsistent township, sort of a sightseeing venture.

He began to dig a trench on an island beach, close to where his own personal project was located, then began excavating in earnest.  In the meantime I set up a smelter and workbench to facilitate the construction process.  We communicated via the in-game chat function and pretty soon had created a length of track that, encased in glass, dipped below the water line and continued on under water until it reached the land mass opposite.  Visible from the surface, it was quite pretty.  The sense of achievement derived from completing that particular project easily equaled and probably surpassed that which I'd felt when creating my own personal project.  My interest in collaboration and the nature of collaborative spaces probably was cause for deeper analysis than "well, that was fun", but collaborating on and completing a project in this kind of space was not something I had experienced before, at least not virtually.

This, to me, is Minecraft's real hook.  Investment of time and effort to create something impressive in single player mode is doubtless satisfying, but that shared experience ensures a more emotionally resonant experience for the players that contributed.  Minecraft's gameplay can quite rightly be labeled as emergent, but this emergence is creative and collaborative, surely worth far more to the player.

Few games (if any) are like Minecraft and many games are not designed to be used in such a way, but give players a tool-set, a space in which to use those tools and the capacity to collaborate with other players and voila, remarkable things happen.  A quick glance at youtube shows any number of Minecraft videos, many of them concerning group projects (notably this one).  People, generally, enjoy working with other people and further to that, people enjoy creating with other people.  This is not exactly a new concept for game developers, but never has it been so starkly highlighted as it is in Minecraft.

The creative act is highly addictive.  Minecraft gives you a relatively simple building system (one consistent unit of measurement) and the capacity to do virtually anything with with it.  Throw in other people who can build with you in real time and hours, days, weeks are lost creating something that has little relevance (beyond youtube) outside of the space in which it was created, yet is maddeningly addictive and very rewarding.

Whether Markus Persson thought so deeply about the multiplayer experience or not, his game allows free expression of creativity through a shared experience and the importance of that to those that play Minecraft is utterly evident.

- Greg

Wednesday, October 27, 2010

Reusability and You

Greg sent me this link a little while ago: The Basics of Design Patterns

It's about how useful it can be to use design patterns in your code. Not only for the sake of reusability but also because they can, if used in the right place, make your code cleaner and more efficient.

It got me thinking on how much I have been implementing not only design patterns but also reusable code in Call Connect. I've been long time friends with Singletons and have a solid Singleton class that follows me around from project to project but when it comes to some other elements I feel like I could (and should) create code that is much easier to transfer over to new projects. The menu system I have created is reusable but could be improved to reduce the size of the eventual screen changing switch statement as one example.

The tricky decision is always whether to spend the time creating something reusable or to just hack something together so that it is working sooner. Sometimes the temptation to hack and see results quicker is too great and the promises to 'come back and redesign later' are made. You just have to make sure to actually keep those promises otherwise you'll get to the next project and find you have to rewrite something that would have been easy to bring over from the previous project. I know I've found myself in this situation too many times over my academic career and so I am aiming to rectify this in my professional one.

This is also something that can be extended to Tools Development, something which I have not put enough effort into and will have to fix in the very near future. Tools can be especially helpful in smaller teams as they can - depending on the type of tools - share the development load across more people. With the right tools Greg could be tweaking game design elements and testing game assets instead of all the this load being placed on me, the programmer. Luckily with the close work environment and quick change and build times this is not as large a burden as it could be but it still is one of the more important lessons that has been learned in the development of Call Connect and will see improvement in the future.

Call Connect, as the first project from Walk Through The Clock, has always been thought of as a learning tool (As well as our stepping stone to fortune and fame!) and hopefully using good design patterns and tools will allow each subsequent project to not only have reduced development times but to also be an improvement on the previous project.


P.S. Matt has also started documenting the various possible design patterns starting with The Singleton. Check it out.

Wednesday, October 20, 2010

GCAP '10

Fascinating trip to GCAP this year (that is to say GCAP itself was fascinating, not the trip there.  That was mundane and, dare I say it, rather painful).

If I could sum up this year's conference in one word it would be this one: marketing.

This word and subsequently theme was common to 80% of presentations, particularly the plenaries.  David Edery's take on the lifecycle of a console is a useful guide for those wishing to maximize their chances of success when launching a new title on a particular platform.

The chaps at Endgame offered one of the few solely gameplay focused presentations as they outlined the difficulties they encountered when balancing, er, difficulty.  Fractured Soul for the DS is a gamers game, if there is such a thing any more; if there is, this it is one, or something.  A significant portion of their presentation was centred around the user testing process and the feedback generated by it.  Heartbreaking might be one way to describe it.  However, for the sake of a little pain, a well balanced gameplay experience is its own reward.

The Doublefine keynote was entertaining though not particularly relevant to those not running a large studio.  Despite that, it did offer one particular lesson applicable to any developer; take risks. 

Between sessions we were treated to a middling selection of pastries, none of which tempted me (though they were quickly snapped up by other more ravenous developers.  Devs are a fine judges of pastryflesh).  Lunch was distinctly DIY which seemed in keeping with the rise of local indie developers and the room in which we were provisioned could have housed a giraffe.

The EEDAR keynote illustrated the value of statistical data to developers as stat after stat was hurled at us from the podium by Greg Short.  I was left in no doubt of the comparative scale of the industry and it's continuing growth through a particularly rough economic period.  This previously 'recession proof' industry had been downgraded to defcon 2 or 'recession resistant', though this is still a pearly state of being.

Halfbrick's session had arguably the heaviest marketing focus and highlighted the need for a dedicated marketing person or unit depending on the scale of the assault.  Of note were the fact that reviews were synchronised to launch alongside the game itself, thus creating a sort of tidal wave of attention.  Of further note was the focus on maximizing marketing opportunities for each update, effectively relaunching the game in the process.

Special mention must go to Jupiter's Casino for having the gaudiest neon lighting system imaginable, the most appalling taste in music and the snottiest waiter this side of Noosa.  "Got the money mate?  Can't pay with hopes and dreams!"  No, no you can't, though when you've already set up a bar tab it's not really relevant is it?

Afternoon all,


Wednesday, October 6, 2010

New Beginnings, or How I Learned to Stop Worrying And Love The Blog

Hello everyone!  We are Walk Through The Clock, a youthful pairing of game development muscle and finesse about to make an imprint on the gaming landscape, or something.  We are Greg (art and design) and Shaun (programming) and plan to use this blog as a means of detailing our game dev failures, victories and experiences in general.  That, and perhaps the odd rant about tram inspectors and the ever increasing cost of a latte in Melbourne.  Posts will feature a mix of the technical and the creative, plus general musings on the world of game development, a world we love so much we'd marry it if we could.

We are currently working on our first title, an iPhone game called Call Connect.  We can't reveal too much about it just now (mainly because it isn't done yet!) but we'll put up some screenshots and perhaps a video of the little guy in action.  We'll throw in a few words about our development experience to date and go through the mechanics of this fairly atypical game.  In the meantime, check our website link on the sidebar over there; you can follow our rants and raves via the ubiquitous Twitter and the dreaded Facebook.

Until then, this is hello, and our motto:

"Through glass and wood and cogs and springs, step inside; we'll show you things..."

P.S. By things, we mean games :)