Re: Software Architecture/Design

>> Profile then optimize.
>
> Then it seems to me that you were so busy arguing against a straw-man that you missed the point of the initial comment.  The point was that programmer productivity is a higher priority than raw performance, and that the historic trend favors more productive tools over the long-term.
>
> That performance-sensitive tools don't *completely* go away is entirely beside the point.
>
> I've shipped two(-ish*) games, have two more ready to ship, and have one more in the works, none of which ever involved ME touching -- or even CONSIDERING touching -- assembly.  Only one even has any C++ in it written by my hand, and that's purely because TorqueScript is just horrifically bad performance-wise.  Even then, most of the game is in TorqueScript and only a handful of performance-sensitive bits are in C++.  Something which happened AFTER I got the game mechanics where I wanted them.
>
> The folks at GarageGames and at Unity Technologies have put an enormous amount of time and energy into their C++-based engines, and the latter have even put in some hand-crafted ASM in a couple places (notably mesh skinning on iPhone).  While you can argue that the use of performant tools under the hood is relevant to me because I'm relying on the tools I'm using to have adequate performance, the reality is that I just don't care HOW the tools I'm using got to be of adequate performance.  The folks at Unity Technologies could write their rendering loop in Forth for all I care.  At the end of the day, all 15k loc in Hordes of Orcs were written in C# (well, that and a touch of Cg of course).
>
> * - One game shipped three times, under three names, with incremental refinements at each step.  "When Orcs Attack", "Epic Tower Defense", "Hordes of Orcs".  The other game has shipped only once.

While I respect your opinion, if I could offer a slight counter-point:

I have been on large AAA projects in the past where no mind was given
to performance until the very end, and engineering decisions were
experimental / incremental / to-feature instead of taking the long
view, as they tried to meet each successive shifted milestone rather
than aiming for a realistic, stable goal (or kept trying to expand
systems to fit other uses without consideration of the engineering
impact).  This results in a mad scramble at the end to try desperately
for shippability on your min-spec, and without having gotten very
lucky, we might have missed that goal entirely.

So while I agree that people who duck toward ASM immediately are quite
scary, I don't agree that we should simply design without performance
in mind either.  You need to be making the smart choices early on, and
constantly, to avoid  a tremendous risky crunchy at the end.  You
don't need to whip out ASM, you don't need to unroll loops (usually),
but cache coherency?  Memory usage?  Merits of functional programming
on data streams vs theoretical OO design?  Limitations of your target,
and realistic design toward those limitations, and constant
(real-life, not barely applicable half-assed) performance testing with
as close to actual data as possible?  These are absolutely critical to
your long-term success.

Now, at the end, yes, that's the proper time to pull out the really
gnarly optimizations that tend to be brittle.  You want to avoid those
early on.  But smart design is far, far more important than brittle
tricks, and is 90% of the optimization of a game if you're doing it
right (which includes making sure that you're not relying on script in
the wrong places, etc - it'll depend on how efficient your script is,
and how you've architected the script logic)

-- 
Megan Fox
http://www.shalinor.com/
_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com