Acorn Heroes

Let’s say you’re writing a piece of code to manage textures in your game, and you’re deciding on the feature set to support. You’ll no doubt be using this in future projects, so you could build in support for cube maps. Being able to dynamically update textures could be really useful. A texture manager is just a special case of a resource manager, so you should abstract out the non-texture specific stuff, right?

Stop right there, back the truck up.

How much of this effort will be directly useful on the task at hand? How much time would you be spending on code that may never be used? “Always in motion is the future” as a wise being once said. The needs you design for today may no longer be relevant when you come to reuse the code. Hind sight is 20/20, so make use of it to decide when to abstract or generalise your code.

A useful rule of thumb is that the first time you tackle a particular problem, write specifically for the problem at hand – do it well, but avoid the temptation to build in ‘what if’ code for possible future requirements. YAGNI.

The second time you face the same problem, adapt your original solution, refactoring as needed to meet the requirements of the new challenge. But still focus on the task at hand. When you come to back to this problem yet again, look at your first two solutions and see what you can pull out and use again. By this stage you’ll have some rock solid code to form the basis of a reusable component, and a strong feel for the areas that will vary from project to project.

A similar argument can be applied to writing a game engine. Don’t. Write a game. Write a second one. By the time you come to write your third, the engine will practically write itself. Great code isn’t built on crystal ball gazing, it’s built on experience.

*Update* Brandon Mantzey very kindly pointed out a glaring bug in the code accompanying this post… Never fear, I’ve tracked down the idiot responsible (me), and it’s all good now. The bug was actually two bugs – first I was confusing the width in pixels of a character’s texture and the space it takes on screen. Secondly I was working from the bottom left corner of a string, where as I should have been working from the top left. Thanks Brandon for encouraging me to fix this! The link in the paragraph below now has the updated code.

A bit of a change of pace this week as we dive into something more technical.  Code that accompanies this post can be found here, and is free for you to use as you see fit.

While OpenGL provides a lot of graphical power, it’s typically at a fairly low level, giving the programmer a set of tools with which they can build higher level, more useful code.  Rendering text is one example of this.  Pretty much every OpenGL application needs to put text on screen at some stage.  But with no built in font rendering support, we’re left to our own devices.  In this blog I’ll show you one easy way to get text on screen. We’ll end up with something like the screen shot on the right.
(continue reading…)