The game-object component architecture seems to be a design technique that’s gaining (or has already gained?) traction in the gaming industry. We’ve implemented a similar design at my daytime workplace with a slant toward simulation training, but until it gets further along I can’t talk about it publicly. Maybe one day I’ll write an article.

Lately I’ve noticed a lot of blogs and threads around the Internet that talk about this architectural approach, so I thought I’d log some of the best links I’ve seen that discuss the design concepts for game-object component designs. I haven’t seen a lot of good implementation discussion online, probably because it can be implemented in a variety of ways, but perhaps anyone looking for more information on this topic will find these links useful:

• Cowboy Programming Blog, “Evolve Your Hierarchy”, by Mick West
• Game Architect Blog, “Game Object Structure”, by Kyle Wilson 
• GDC 2002 Powerpoint, “A Data-Driven Game Object System”, by Scott Bilas 

While I can’t personally confirm more than a few of the engines out there, it’s my understanding that just about every major game engine commercially available is using this architecture. This makes sense because those engines are trying to focus on gameplay programming and content creation, which this architecture is meant to accomplish.

Some food for thought from WALL-E director Andrew Stanton:

Life is nothing but imperfection and the computer likes perfection, so we spent probably 90% of our time putting in all of the imperfections, whether it’s in the design of something or just the unconscious stuff. How the camera lens works in [a real] housing is never perfect, and we tried to put those imperfections [into the virtual camera] so that everything looks like you’re in familiar [live-action] territory.

Tip: kottke.org

In the world of languages, low-level assembly was developed to abstract out of bits and bytes, while C and FORTRAN were developed to abstract out of assembly. These days languages like C# and Java abstract so much from the machine level that they even have their own virtual machine.

In design we build layers and hierarchies to ease our ability to consider the higher-level concepts inherent in the software. Engines, API's, SDK's, libraries, components. They're all abstractions.

Take that one step further and you have the most important abstraction of all: the user interface.

It would be a mistake to design a user interface around the software design objects. Chances are the user isn't going to be a software engineer that can quickly grab the concepts of software design, so it's pretty worthless to create a user interface that reflects the design. Sadly, I see this on a regular basis, whether it's through my own coworkers, a tool I'm trying to use, or someone else's project on the Internet.

A better approach would be to abstract away from the design by simplifying operations and organization at the user interface level. This puts the user interface in the role of the lens into the functionality of the software design, without even exposing those design objects to the user.

And that's what we are trying to achieve in our tool development work: simple interfaces abstracting from a complex system. It's not easy, but striking the right balance with the user interface abstraction will help with our tools' success.

Anyway, the code looked a little something like this and resided in a pretty large function (names have been changed and some code simplified to protect the innocent):

Obj *myObj;
objListIter = GetObjListIterator();

for (int idx = 0; idx <= objIdx; idx++)
     myObj = objListIter.getNext();

myObj->DoStuff();

It’s clever. Simple. Probably not the way I’d do it. In fact, it made me do a double-take to where I had to make sure I understood what the for loop was trying to do.

But that’s kind of the problem.

The loop is performing a common task (get an index in a list), but it’s doing it in a unique manner. Such a unique manner that even the author had to verify himself that the code worked properly. When I first saw the code it did not, but it wasn’t an immediately obvious bug because the algorithm was too unique in the first place.

And that’s a problem. It wastes time.

I know programmers who like to be clever. They like to show that they can solve problems in unique ways. They forget that there is a human aspect to software, that other programmers have to read their code and possibly modify it one day.

I also know programmers who like to be practical. They like to show that they can create working, lasting code by being straightforward in their code and working hard to ensure design integrity throughout the software. They remember that there is a human aspect to software, that other programmers have to read their code and possibly modify it one day.

Which type of programmer would you rather work with?

I suppose that’s what you get for reading a book about software development targetted at anybody but a software developer.

Anyway, recently I came across a passage about Mitch Kapor’s thoughts on software design, which was interesting because it gave me some ideas on how to better frame software design when communicating with both engineers and management. It also led me to reassess my own views on software design.

It turns out that Kapor wrote about his thoughts on software design in a manifesto in 1990, including this idea of applying to software the architecture theorist Vitruvius’s principles of good design (Vitruvius is from Ancient Rome):

• Firmness, meaning "A program should not have any bugs that inhibit its function." aka, no bugs
• Commodity, meaning "A program should be suitable for the purposes of which it was intended."
• Delight, meaning "The experience of using the program should be a pleasurable one."

These three principles have been a backbone, so to speak, of building architecture for many, many years, and I think Kapor is (or was) onto something here in that these core architectural principles can and should be applied to software design. I don’t know if Kapor believed they applied to implementation or not.

Of course, I believe software design and implementation are the same activity at different levels of abstraction. A software architect designs algorithms at the system-level while your entry-level software engineer designs algorithms at the function level. An architect may use UML or a whiteboard as the design tool of choice, while the entry-level engineer uses code, but in the end the thought processes required are fundamentally the same.

When I think of these principles and view them in the context of the development I or my peers engage in I see that the best engineers are the ones who consider firmness, commodity, and delight at all levels of abstraction in design – from architecture to high-level design to subsystem implementation to function implementation.

So, I wonder, are truly great software designers the ones who know how to maintain that architectural integrity of design principles in the software? This isn’t an easy thing to do. It requires discipline. It requires the ability to see the big picture while diving into the weeds. It requires conceptual integrity in the design from start to end.

Yet, it makes sense. The best engineers are the ones who can see the big picture and work in the weeds. They are the ones who have the discipline to follow design principles from start to end and from architecture to code. They follow Vitruvius’s design principles not just from an architecture view, but even for each line of code.

It’s pure design integrity at every level of the software. It’s hard to do, but doing those things that are hard to do is what makes people great and it should be what everyone strives for.