There’s this old parable about several blind men and an elephant. There story goes something like this: Asked to describe an elephant each blind man grabs a part of the elephant then proceeds to describe what they felt. One feels the elephant’s tusk and describes an elephant as a hard, bony creature. Another feels it’s leg and describes the elephant as being stout like a tree trunk. Yet another grabs the elephants tail and promptly describes the elephant as being like a snake. Naturally, once they start sharing their findings, an argument ensues about what an elephant really is.
Each of these poor men is being totally honest in their description, but the end result ends up being divorced from reality by the limits of their own perception. The moral of the story is for one to be aware of where their limited perception (or preconceptions) may hide information from them. In more colloquial terms, it’s about learning to see the whole picture. Continue reading
Ah, New Year’s. The annual turn of the calendar marked by resolutions and gym membership renewals. This year, my big resolution (or, rather, personal challenge) can be summed up with a single hashtag:
Late last week, I finally managed to pass an update for Robot Legions out onto the Xbox Live Marketplace. I wasn’t originally planning to release an update this early (I have some other features in-the-works for the “real” next update), but… I had a bug. A nasty save data killing bug.
So, in the interest of helping other XNA devs out there, let me tell you about what I screwed up and how I fixed it. Continue reading
Comments in code, you can’t live with ‘em, you can’t live without ‘em. Depending on who you ask, comments are a crucial form of documentation without which most source code would be unusable. Others might say that code comments are, at best, an administrative nuisance or, at worst, dangerously misleading as they inevitably lose sync with the source code they purport to clarify. Reality, of course, lies across a spectrum between these extremes. Code comments, in-and-of-themselves, are neither helpful, nor hurtful. It’s the content of the comments themselves and how they relate to the reality of the source code itself that makes them valuable (or potentially harmful.)
If you’ve attended elementary school in the States, you should be familiar with 5WH, the building blocks of questions: Who, What, When, Where, Why and How. These six words cover the gamut of questions you can ask and provide structure to information sharing. So, what happens when you apply these questions to comments in source code and use them to direct the information you need to share?
A while ago, I posted about pre-rendering text to improve runtime performance when using XNA SpriteFonts. Since then, I’ve managed to complete a game (Robot Legions, currently up for peer review) using my XNA codebase and got to try out my text pre-rendering solution in a real project. It worked out pretty well, but there were a few features that I wished I had implemented ahead of time. Well, while Robot Legions was being play-tested, I went ahead and implemented some of those features. Now I’ll describe those features and share a bit of (hopefully) helpful code that will let you use them in your own games. Continue reading
In last week’s post, I described how I used CLRProfiler to identify a couple parts of my code that were producing garbage every frame. One related to equality comparisons with my ActorState struct and another involving System.Objects being produced when I called RuntimePropertyInfo.SetValue(). This time, I’ll talk about what I did to fix those two problems. Continue reading
As cutesy as it may be, I’m growing rather fond of my garbage collection count display. I’m especially fond of it because it helped me find garbage collections occuring in places I never expected them to happen. Such as my title screen for example:
Ack! Look at all those garbage cans, I mean recycling bins (reduce, reuse, recycle, folks!)
That’s a lot of garbage collections for a “static” title screen. Now, how to find out what’s causing all that garbage to be created… That’s where Microsoft’s CLRProfiler comes into play. Continue reading
I’ve lamented before about how unfortunate it was that my frametime display allocated memory and would cause garbage collections to occur. Well, I found a simple solution for my memory allocation problem and, if I say so myself, it’s kind of… cute. Continue reading
In a previous post, I talked about how I added basic memory usage output to my frametime debug display. I also mentioned the major problem with that system being that the debug output I used allocated memory, causing garbage collections to occur. This constant change in memory usage naturally made the output hard to read. As I was writing that post, I had an idea for how I could easily solve that problem which I will share with you now. Continue reading
Don’t get me wrong, I’m not against object-oriented programming (OOP). More often than not, it’s a valuable method for modeling data and logic in games. However, because of its near-total dominance of thinking regarding programming in games, I often find myself playing the anti-OOP advocate in conversations at work.
You see, there are times when designs that look “right” when viewed through an OOP lens turn out to be ill-suited to solving certain problems in game programming. One of the major causes of this is the tendency of OOP to encourage thinking of problems in terms of single data objects. Often this works because handling multiple instances of an object is a natural extension once you know how to handle a single instance. This isn’t always the case however and it’s common for OOP-oriented programmers (OOPOP?) to overlook cases in which it would be better to think of processing data as a gestalt as opposed to as lists of stand-alone objects.
To clarify this idea, I’ll share a recent experience with some code at work. Continue reading