Vector Theory #29: Object Oriented Design Methodology

Object Oriented design is a concept that has swept across computer programming over the past twenty years (probably longer), but it seems to be something that has been restricted to the computer world, and hasn't really spread much further to my knowledge.

That's not entirely true, but I'll explain a bit more later.

Traditional computer programming looks at developing an outcome, then works toward designing a solution to fulfill that outcome. In traditional methodologies, each program develops independently. They may achieve something similar in the end and they make take a number of similar steps along the way, but the development process is discreet for a particular project. For example, if you need to develop a program that will print out facts about a person, you create a series of specific routines that gather information about the person, consolidate the specific information into a specific format, then print the specific information.

Object oriented programming follows a different theory. Instead you build a bunch of chunks. The same program developed from an object oriented perspective might take a chunk that's designed to gather information of all different types and add it to a chunk that provides a data structure for the class referred to as "people". It would then take another pre-designed chunk for sorting any type of data, but since it's a generically functioning piece it can work just fine in this overall system...finally a general use printing chunk is attached to the end.

This is a very simplistic scenario, but you get the idea.

Traditional design builds everything from the ground up, object oriented design develops a series of generic pieces that can be built together like pre-built clusters of Lego blocks into a larger structure.

Computer programming might have received countless pages of theorising about object oriented design, but a simple look at Lego shows that the practice is more widespread.

What sort of computer do you have?

Do you simply say "I have a Mac" or "I have an HP"? Or do you look at the motherboard a singular object, the graphics card as another object that fulfills a specific range of functions, specific sticks of RAM, a specific sound card, a Central Processor Chip....

I remember being amazed the first time I had a friend open up a computer and fix things for me by simply taking out one of the boards and replacing it with another modular piece. The mystery was shattered. A computer isn't a monolith, and the little sticker that says "VOID WHEN REMOVED" is just a social barrier, it doesn't actually affect the workings of the computer if you open it up, and you can actually make it better if you are willing to get your hands dirty.

Cars are much the same once you get down to it; sure, it takes a different skill set to fix a car and each of the tasks becomes easier with a very different range of tools, but at the essence you can look at the car as a range of assemblies and systems, or it can be looked at as a collection of numerous tiny pieces.

In a similar way, all cars from a certain company might share the ability to use a certain range of parts...mufflers might be interchangeable across the range. They all share the same function on the car and a single company finds it cost effective to mass produce a single part to be used on various models in their range.

Let's pull this back to game design.

John Kim and John Kirk have written some great stuff about the patterns used in RPGs. I'd thoroughly recommend any prospective designer to have a look through their works. I've mentioned Kirk's work in the past.

Take a look at generic systems like GURPS. In most cases they aren't truly generic, instead they provide a toolkit of generic objects and then in the sourcebooks and genre books they'll offer a way to combine the components to provide an experience that reflects the genre, or maybe they'll add a few new subsystems to plug into the generic toolkit.

But you don't need to get deeply involved in game theory to appreciate the concepts of object oriented design. I've seen it applied in almost every game that I've run, and most other GMs seem to do it pretty frequently as well.

"I like this game, but I don't like the experience system, so I'll allocate experience the same way they do it in that other game."

"This game has a really great combat system, but that game handles magical stuff much better."

"I like the official game released for that licensed property, and I'll use some of the ideas, but if I combine these parts from this game, and those parts from that game it'll be much closer to that dramatic episode that we all like."

Home Brews. Hacks. Call them what you will, they're a staple part of the hobby. We take components from one game, add components from another and get something that we like. We might use a bit of trial and error to get things just right. Exposure to a wider variety of games gives a wider assortment of components to choose from. A bit of good knowledge and grounding in theory can help to make the process a bit easier. Visiting game design forums and looking at insightful blogs, might teach you some new ways to incorporate pieces, or discover how other people have failed when trying to combine certain game design objects.

I"m thinking of design objects as Game Chef looms closer. I've got a whole bunch of unfinished components that could be plugged together into a range of new game forms. It's just a case of which ones to use.