In "Troubles with Tribbles" we discussed the problem with computing parallelism confronting game developers. Assuming Tim Sweeney's point of a driving growth in the numbers of game simulation objects (to implement larger worlds with more content) then how *does* one begin to manage the complexity of those objects.
Why should you care? Hang on...
In "Troubles with Tribbles" we suggested the object-based culture of the building-blocks of our virtual worlds in this way:
...If Code is the Law in our realm, then the modern conceptualization of code (see Footnote ) often aspires to be object-based. The craft of software objects is then Object Oriented Programming... Software object-oriented design has been (by-and-large) a cultural touchstone for nearly a generation of software developers and designers - objects provide a convenient and intuitive means of partitioning/ decomposing problems and mapping them onto code building blocks.
Grady's 2005 presentation on the nature of software complexity (excellent set of slides from his keynote at 2005 Aspect-Oriented Software Development) presents a compelling claim: software is expensive and getting more expensive, and a great deal of its cost is driven by its increasing complexity. Games, virtual worlds, or not, that is the bullet.
To manage complexity do developers need to be able to better decompose software into components in a way that trades-off successfully one type of complexity for another? Is it, in the words of aspectprogrammer.org about the illusion of simplicity:
...(T)he task of the development team is to engineer the illusion of simplicity. In (programming) languages we see the tradeoffs in history. Control structures are a tradeoff between primitiveness and convenience. Garbage collection is a tradeoff between expliciteness and abstraction. VB and Smalltalk are tradeoffs between performance of development and performance of execution. Beans, aspects, services are a tradeoff between packaging for design versus packaging for development versus packaging for deployment...
While Grady in his 2005 slides goes on to discuss the nature of software componentization (vertical vs. horizontal, "layers of abstraction" vs. "interdependence") he fundamentally hopes that software abstaction is simplifying. What are the right abstractions for game simulation objects and software?
Jonathan Blow in "Game Development: Harder Than You Think" (ACM Queue, February
2004) suggests a problem lies with the "glue layers" - the mortar to components fitted against ill-matched abstractions (emphasis added):
...Often the API (application program interface) is difficult to deal with because it embodies some conceptual model that is a poor fit for the way your game needs to work. Thick glue layers are usually necessary between the main game code and the third-party API. Application program interfaces for rendering or physics often want data organized in very specific ways, a situation that propagates through the rest of the program and imposes difficult constraints (because a lot of data needs to be passed back and forth...)...
Not to forget all the game simulation objects crowding to complete content and the rush to get product out the door, is there time to even think about the right abstractions?
In 2002 Joel Spolsky forwarded a widely cited article on "The Law of Leaky Abstractions," there he provides several simple but colorful examples (such as TCP vs. IP) - read it. His high-level claim can be summarized as:
All non-trivial abstractions, to some degree, are leaky.
By leaky he means that they fail us, to varying degrees. By failure he means that they don't accomplish what they were set out to do - insulate us as from the detail. Consider this example of his, albeit in geek:
...When I'm training someone to be a C++ programmer, it would be nice if I never had to teach them about char*'s and pointer arithmetic. It would be nice if I could go straight to STL strings. But one day they'll write the code "foo" + "bar", and truly bizarre things will happen, and then I'll have to stop and teach them all about char*'s anyway...
If you are scratching your head on this technical bent, pause for a second and consider Tim Sweeney's crude measure of complexity for Gears of War (ref "Troubles with Tribbles" above):
~20 different middleware, ~250k x2 = 500K lines of code
Then consider then Grady's ball-park estimate of 100$/SLOC (single line of code) and recall Johnathan Blow's account of the messy glue that is now used to bind the layers of game software. Even if game programmers work for less, perhaps the implied constant moving between the disparate levels of abstraction impedes progress.
When do abstractions become too complex and when do virtual worlds suffer for it? Perhaps driving down software costs is the first step along the road to having more choice in worlds.