Python suitable for a game engine?

[Christian Tismer]

Nick Trout wrote:

[I wrote, thinking of coroutines but not talking of it loud]

> >I had a quick look, but not the time to check it completely.
> >Does it have coroutines or small threads to do very
> >quick context switches? This is something which
> >Python will be able to do very fast, soon. You can have
> >thousands of current contexts and switch them in no time.
> >This can simplify the implementation of games in a scale,
> >that the speed penalty might be compensated by that.
> >Well, we have to try...
> 
> You don't need a proper threaded system to do game AI. Every object just get
> s X ticks each frame. This is maybe getting a bit off topic. A context switc
> h can be as quick as changing a global pointer to the new current context. I
> think Unreal works as you explain, running lots of objects in parallel. When
> you create a new "live" object it spawns a new "thread". Essentially this is
> just a list of objects that have a member function tick() which gets called
> every frame. Please correct me if I'm wrong.

Yes. I thought of coroutines without spelling them. These are no
threads. In a simple world, you coud have one main coroutine
and thousands of "thing" coroutines which would switch forth and back.
This is extremely fast and convenient, since all the routines are
already running and don't need to do any setup each time they
resume. They also share a global namespace, so they can communicate.
This was kind cooperative multitasking.

Alternatively, preemptive multitasking can also be done, with the
same low cost of switching time, since we always stay in the language
and never need to take care of system stacks, real threads
and so on.

I'm about to publish the building blocks for all flavors of
these, and one can build the most suitable system in Python
itself.

Why I said this can really a saving: In time critical situations
like games and simulations, the Python fuction call overhead,
setup up temp variables, even loading of often used functions
into local variables, costs time.
But if you have simple handlers which are initialized once
and then only transfer control to colleagues when it's time,
you save almost all of it.

> The way I'd look at is: which languages are suitable ie. can do what you wan
> t, can be embedded conveniently. And for games, which is fastest and most co
> mpact?!! Lua and Python can do what you want and can be embedded but Pythons
> byte code execution is slower than Lua's by about 50% or more and its a lot
> smaller. Python is streets ahead for writing tools/parsers/simple utils with
> a GUI. Although you can do all that in Lua as well!

I agree that Python is not too small, although it isn't relly big.
But for games, you could go without many of its types, so much
of Python's code is just hanging around. But development
goes towards much more modularity and pluggability, so I guess
it will not take so much time until you can select if you want
Python with head or without tail.

> I'm interested in your ideas. I have thought about doing similar things. I c
> ame to the conclusion that Lua was more suitable for embedding in a game. Pe
> rhaps you could elaborate on your ideas.

I cannot compare what I don't know. I'm just so pleased
with Python that I put all my energy into it, to help
it suit all the areas where it is still suboptimum.
You may expect something to happen with the speed issue
by end of this year.

later - chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home