On Apr 18, 2009, at 11:05 AM, Toni Alatalo wrote:
Yanom Mobis kirjoitti:
So writing a game in python and pygame usually doesn't involve
writing C/C++ code?
correct. i think most of the pygame written full games are just py. i
personally also have so far not encountered speed probs in our pygame
projects, they are all just py so far 'cause the libs have provided
what have needed.
Absolutely. I wrote a half-a-game that (so far) is basically a
cellular automata (a souped-up version of Conway's "Game of Life"). It
runs about 1100 cells, and is written in the most naive way possible,
on purpose. I load separate graphic files to display cell states, and
do some really not-performance-helping "talk to my neighbors" code on
each pass through the loop.
*It will run 15-20 fps on an OLPC XO. The XO has a AMD Geode
processor, which runs a very old x86 instruction set at 400 MHz. I
think it has 256 MB of RAM, and 1 GB of flash storage. The entire
machine consumes 2 watts of power, less than the backlight on my
MacBook Air. *
*
*
*PyGame is fast enough, even on really slow machines. That old
programmers proverb that languages like Lisp (and Python) are too slow
and add huge overhead -- WRONG. Has been wrong for years. People are
finally figuring it out.*
I firmly believe (although I haven't tried it) that PyGame is good
enough to make a "Super Mario" type game with purely "obvious" code
and NO C. Maybe even on an OLPC.
In contrast: Most game developer books I've ever seen have been
nothing BUT graphics trickery code in obscure C or C++. I think they
are *poison*, because they encourage what Kernighan and Plaugher (the
guys that originally wrote UNIX) call "Premature Optimization." (And
for the non-english speakers, there is a deliberate implication that
premature optimization is just as shameful as premature ejaculation.)
No less authority than Donald Knuth, the guy who is writing THE
standard encyclopedia of algorithms, said,
* Premature optimization is the root of all evil.*
If I had to get a geek tattoo, that would be it. And I know Knuth
would be way down with it.
It's way too easy to get mired in the "developer fun" of counting fps
and rewriting algorithms as obfuscated code that, when you go back a
week later, might as well have been written by a Martian. (And, it
will inevitably have subtle bugs.) Ultimately, all of that fiddling
about is just *masturbation*, because nobody but you derives any
pleasure from it.
Games should be about fun for the players, and that comes from
gameplay and looking good.
I am a firm believer in expressive code, code that says things like
"count how many of my neighbors have a state that is in this list of
states, and of the number is between 5 and 7, move to this next state."
I do that in 3 lines of Python. (I could do it in one, if I didn't
insist on pretty code.) Doing it in straight-C is a nightmare, and
even in C++ is fraught with peril.
*So Python makes writing expressive code easy. And PyGame makes
writing good-looking graphics code easy. (And sound, and keyboard, and
mouse, etc.)*
*
*
*
*Here is my goal:*
There are millions of kids out there with OLPC XOs, who will be able
to download my game, and then start messing with it, and change it
into THEIR game. Without a textbook.
When I was a kid, I snuck into a computer lab and learned how to write
BASIC, and how to issue the graphics control codes that caused the
display terminals to make little animated "games" where $TEACHER gets
run over by a tank. As a result, I became a programmer.
*
*
*My game, if it's any good, might grow 100 kids who are
programming-literate, and maybe 1 that is brilliant.*
*
And THAT'S what it's all about.