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 →

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 →