On Monday 07 July 2003 02:02 am, Russell Reagan wrote:
> > There came a time when it was no longer economically viable to develop an
> > entire game in assembly, and IMO we've *already* passed the point where
> > no longer economically viable to develop most games entirely in C++ - the
> > time to market is too long, it's too expensive to add new features,
> > recovering from early incorrect decisions is too costly, etc. Games are
> > moving to higher-level languages as much as they can because it's a
> > competitive advantage to do so.
>> After thinking about it I tend to agree. I'm a little partial to C/C++
> because I develop (as a hobby) a chess playing program, and I like
> tinkering with it to see how fast it can go, and finding clever ways of
> doing things. A chess program is different from a 3D game in that with a 3D
> game, you can stop at some point and say, "ok, this is fast enough." There
> is little point in making the game run at 1000 frames per second if no
> human eye can see more than 60 (or whatever the number is).
True, although rather than let the frame rate continue up the game designers
will simply add more polygons, more actors, more textures, greater viewable
distance, etc. so they won't ever reach the "fast enough" point either.
Instead you always reach the "fast enough for now" limit.
There will remain *some* cases where you need a lower-level language in order
to get more speed, but those cases are becoming less frequent - for each one
there comes a time when the cost of that extra speed becomes too much. Also,
some projects (like Pysco) open the possibility of on-par (or even greater,
in theory) speed by using a higher-level language.
But my main point was that, at least for the stuff I do, there's never any
point in writing all or even most of an application in C++ anymore (and the
few parts that do need more speed would be in a dumbed-down, simplified C++
at that). If I were writing the chess game I'd probably write the entire
thing in Python to begin with anyway, just to get it working. Having a slow,
but working app would either help maintain my interest in the project or let
me know early on that it's not something I really want to do.
If I kept at it then I could, at some point, move some speed-critical code to
C or C++, but I'd try to avoid it for as long as possible. For example, you
mentioned that your interest was at least in in part about finding ways to do
things faster or to make the game smarter. In a higher-level language like
Python that sort of expermimentation is relatively cheap - in C++ you might
avoid radical experiments because the cost of change is too high. Your
biggest speed and smartness improvements after picking the low-hanging fruit
are likely to be algorithmic in nature (e.g. using a more ingenious heuristic
to reduce the search space of next moves) as opposed to low-level tuning of
loops or data storage, so it would be advantageous to do that work at as high
a level as possible (and you can always translate those algorithmic
optimizations to a lower-level language someday if you want).
Just my two cents of course,
-Dave