A story about Python... sort of

[Dave Brueck]

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