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.