I realize the discussion has started to move in a different direction,
but I would just like to briefly state... something. I wouldn't really
call it an opinion. This might be a bit long winded (and I should warn
you a cuil-like, nearly nonsensical metaphor is approaching), but bear
with with me :)
I view Valve as one of the three, when it comes to first person
shooter technology. Id, Epic, and Valve. Each studio seems to focus on
a particular aspect when it comes to development. Id focuses on the
technology, Epic focuses on the art, and Valve really doesn't care
about their tools, but rather the end product (as long as the player
wants more). And this is, I think, apparent when viewing the ad-hoc
way in which features are added (or should that be bolted? :P) on to
the Source engine, as opposed to say Id Tech, or the Unreal Engine,
where large portions of the engine are written with each iteration.
Now to get to the metaphor of engine technology I call The Burger.
Let's assume for a moment, that Id software has created a burger. It's
the first of its kind (to be released), and the cook, John Carmack, is
quite pleased with this creation. Everyone loves it, and some say it
will be the future of cuisine. John tells those who wish to listen
about what is in the burger, how he had to change the ingredients to
ensure that everyone in the world would be able to eat it, and enjoy
it, as well as some of the challenges to make it look and taste so
amazing. But, as a problem, nearly everyone in the world has begun to
hack together their own kind of burger, but only by looking at John's
Burger (because not everyone has the money to pay for the recipe).
Regardless, the Cheesequaker was a huge success.
Meanwhile, a man named Tim Sweeney began cooking his own burger as
well. He was aware of John's Burger, and had started to create his own
before John's would be released to the public. A few screenshots of
what Tim's burger *could* be were enough to entice burger fan's
everywhere. But instead, a young man was brought into Tim's Kitchen.
The burger's ingredients were delicious, but the burger could
definitely look better, so this young man named Cliff added some
pizazz to the burger. Once released, Tim allowed people to purchase
the ingredients, as long as they promised not to tell anyone what was
in them, they could create a brand new burger, independent of their
own (indeed, one such restaurant was 3D Realms, which promised The
Duke, a burger that would satisfy you, *forever*). Even fans of the
burger were told how they could add zest, and spice to this Bunreal.
Around the time of the Bunreal release, a startup approached John
Carmack, and told him of an idea they had for a burger, built on his
recipes. John, rather than be an megalomaniac, gave them the recipes,
parting with the words Make something great. This startup did. Using
some as of yet unreleased at the time additions to the Cheesequaker,
they were able to create a wonderful masterpiece. Half Fry-fe.
Let's skip forward several years, and ditch this metaphor because the
punchline has been told, and the horse has been beaten to death
(horse? don't you mean cow? hahaha). And I don't want to iterate all
of FPS gaming in the past 15 years for everyone with burger jokes,
because I'm fairly certain a majority of us were all there for it. :)
Part of why I think the Source SDK is starting to feel old and
decrepit is because of design decisions with the tools early on. I
emailed Valve back in and Mike was kind enough to respond. I asked
what toolkits Valve used, with nearly everything, and was told that
Hammer (and friends) used the old MFC framework, with a few tools
relying on Mete Cirrigan (of Milkshape 3D fame's) mxToolkit (though
this is mentioned in the copyright statements for the Source SDK). I
don't believe this is Mike's fault, nor do I think anyone wishes it
was, and if anything I think he is slowly trying to phase it out, or
at the very least, quickly phase it out in favor of OS X support. And
yes, the code for Source itself is most definitely not the cleanest
code. From clear cases of code that is ingrained with some instances
of code that hark back to the QuakeWorld version of the engine (I have
no way to prove it, but the ZPool/Memory Pool is most likely somewhere
within the confines of Source in some way shape or form. You can't
*not* have a memory pool. Otherwise I would question how Team Fortress
2 is able to allocate so much memory), to routines that return
allocated memory, to C With Objects code, to preprocessor macros
that have a blatent disregard for sanity (http://i.imgur.com/maP8P.png
-- seriously guys, you couldn't use a va_list? I mean I'm all for
type safety, but at some point you've just got to step back and say
It's ok to have a little overhead when calling a script from C++.
I'm pretty sure that list gets bigger too. I'm *not* diving back into
that code), to a small amount of template usage, and function
overloading, to even
