Why Software Design Isn't Like Architecture
There's an article at GameProducer.net entitled, "New Level Graphics For Eidoki - And A Lesson Learned About Tiny Things" which hit on a subject that was all too familiar.

Their game was intended to take place entirely in 2D (but with 3D graphics). All the action was intended to take place in a flat environment. The modeler created some really cool building graphics that didn't respect the design constraint, and had small steps leading up to a slightly increased height. The graphics looked so good they didn't want to sacrifice their quality (or the steps), so they've decided to accept the increased complexity.

The modeler just didn't get why it was such a big deal. He said, "it is funny how I cant understand how hard it is to get it up the y axis."

I see that a lot from non-programmers. Not only in game development, but in all software applications. You get jokes about what would happen if computer programmers designed cars (it would quit running or crash randomly, and the solution would be to shut the car off and start it again... and the airbags would ask "Are You Sure?" before going off). In fact, many academics and consultants spend a great deal of time trying to improve software design methodology to make it more like architecture, or other forms of engineering, so that it might be far more predictable and controllable.

Except few other "controllable, predictable" disciplines are as subject to inadequate specifications and changing requirements as software engineering. I mean, can you imagine a civil engineer trying to build a bridge for an unknown location and environmental conditions, only being told that it should be made of steel, cross a body of water that is "less than 2000 feet" in width, and be capable of expanding to any kind of load they want to put on it (and in any distribution)?

I hear "game designs" that consist of no more than a paragraph or two, with the proud wannabe game designer waiting to see why nobody will suddenly take their idea and turn it into a best-selling console game (giving them half the royalties, of course). Yet the same individual would understand perfectly why they couldn't draw a pencil sketch of a cool car, send it to General Motors, and expect them to manufacture the car and give them half the profits.

Even though most people are not well versed in the engineering skills necessary to build a bridge or design a car, they have enough inherant understanding of the behaviors of physical objects to realize why you couldn't just swap the designs for the Golden Gate Bridge for the London Tower Bridge, or why you can't just stick a jet engine inside of their Malibu and expect it to work.

As with software, every little design issue may cause ripples throughout the system that have to be accounted and adjusted for. But non-programmers can't see it. You may not be able to just "drop in" an entirely new tax system for a different country. Not unless the system was designed with that kind of modularity in mind... which would have made for a much more expensive system. Keeping things so modular and flexible costs a lot more --- just like building a single model of bridge that is designed to expand to cover any body of water, anywhere, with any kind of load.

I'm not saying that programmers shouldn't write more flexible, modular code that is easier to maintain and change. That's certainly my goal, even when I'm coding up a project that I am SURE will never change beyond minor bug-fixes. Because that's only invoking Murphy's Law - the less flexible the code, the more likely it will be subject to change and expansion... and vice versa! How many times have I spend weeks making sure things were flexible and adaptable, only to find the code never gets used again?

But there is a huge gap in expectation and understanding between software engineers and those whom we serve (and if someone is paying you for your labor, you are serving them). One of our biggest problems is a lack of tools to help explain the impacts of certain design decisions or changes. Instead, we simply get blamed for the bugs that often result from the failure to take into consideration those changes.

Going back to the 3D artist mentioned in the above article... the game could end up with problems with the player being unable to "pick up" objects because they are on a different Y level. Pathing problems because now the Y axis must be taken into consideration. Monsters and players that can't hit each other because they are standing on different heights of terrain, even though the difference isn't that great (and how great of a difference in Y levels *should* be considered "too great?" What's the magic threshold where an inch below that is fine, but at that point there's no fighitng?). Are there bugs where the player ends up "wading into" a floor because the game failed to block movement into a higher Y-level?

Software engineers understand this. Experienced ones understand it and are halfway through coming up with an architecture in their head to robustly solve most of these problems. But it always comes with a cost. And that cost is really something that even software engineers have a tough time estimating sometimes.

Labels: Game Design, programming

- posted by The Rampant Coyote @ 8:44 AM (Permalink)