Beautiful(?) Darkstar (BA Ch 3)

The intent behind Project Darkstar has great merits--anywhere you can bring code reuse to make building software easier, cheaper, faster, and more stable is a worthwhile endeavor.  The architecture laid forth provides a good framework for developers to build from, but I believe that it falls short of its intention.  Wheras it was designed to be a "black box" type platform, where developers wouldn't have to understand its inner workings, it really only succeeds as a starting codebase.  It's well known that you can't (in the general case) take a standard algorithm and run it in a distributed or concurrent fashion (as the team found out), and as such, it misses the mark for its overall intention.  In the example where a team had build a data model on Darkstar with a "coordinator" object, it's clear that there was some other useful paradigm in play.  Perhaps the Darkstar team, instead of coaching the game team on how to make their game work better on Darkstar, should have looked at the reason for using such an object, and performed some analysis to see if they could build a Darkstar-compatible base class or method library, such that the poorly performant piece could be reworked to function in the general case, and provide some additional utility to game developers.

If I were on this team from the beginning, my biggest concern would be with potential performance.  I would advocate establishing benchmarks from other games in the industry--even if I couldn't know the workings of what other game engines were doing--but at least to quantify what response times are expected for what types of operations.  From there, I would have made incremental performance tests under various load conditions as part of the standard automated testing suite, such that performance bottlenecks could be identified as early as possible after implementation.