Hi,
I would like to program a small game in Python, kind of like robocode
().
Problem is that I would have to share the CPU between all the robots,
and thus allocate a time period to each robot. However I couldn't find
any way to start a thread (robot), and interrupt it after a given time
period.
Any suggestions on how to proceed?
Is Python just not adapted to this kind of things?
Thanks,
Yannick

2006-08-09, Yannick <yannick.leteigner (AT) gmail (DOT) comwrote:
Hi,

I would like to program a small game in Python, kind of like robocode
().
Problem is that I would have to share the CPU between all the robots,
and thus allocate a time period to each robot. However I couldn't find
any way to start a thread (robot), and interrupt it after a given time
period.

The robot code thread needs to block when it runs out of things
to do.

Any suggestions on how to proceed?

Just start a thread for each robot, and put a call to
time.sleep(0.010) in the main loop for the robot code. Adjust
the 0.010 value to taste.

As an alternative to sleeping, you could wait for some sort of
event each time through the loop.

Is Python just not adapted to this kind of things?

It's quite well adapted to this sort of thing.

There's several ways of doing concurrency in Python. than the
threading module, have you tried FibraNet? It's designed with simple
games in mind.
You can download it at
Specifically the nanothreads module from FibraNet uses generators to
simulate light-weight cooperative threads.

Generator-based approaches are fast and *deterministic*, unlike true
threads where you have to account for race conditions, etc. You can
pause, resume, kill, or end a "thread". In Python 2.5 (soon to be
released), generators will be consumers rather than just producers, so
you can pass things into generators (without needing global variables
as a workaround) rather than only being able to spit out data
on-the-fly. They'll also have a more graceful way to handle exceptions.

For a good overview of the concept, especially if you want to implement
this yourself instead of using Fibranet (although re-use is often the
better choice), take a look at this link from the Charming Python
column:

If this all seems too exotic, then you can also just go with the
traditional threading approach with the threading module. Normally
you'll want to use the "threading" module rather than the lower-level
"thread" module. But be warned, threads are a big can of worms.

I hope you find this useful.

Yannick wrote:
Hi,

I would like to program a small game in Python, kind of like robocode
().
Problem is that I would have to share the CPU between all the robots,
and thus allocate a time period to each robot. However I couldn't find
any way to start a thread (robot), and interrupt it after a given time
period.
Any suggestions on how to proceed?
Is Python just not adapted to this kind of things?

Thanks,
Yannick

Problem is that I would have to share the CPU between all the robots,
and thus allocate a time period to each robot. However I couldn't find
any way to start a thread (robot), and interrupt it after a given time
period.
Any suggestions on how to proceed?

import thread, time
def robot(name):
for i in xrange(5):
print "%s on pass %i" % (name, i)
time.sleep(0.01)

ids = [thread.start_new(robot, ("Robot%i" % i,)) for i in
xrange(4)]
Robot1 on pass 0
Robot2 on pass 0
Robot0 on pass 0
Robot3 on pass 0
Robot1 on pass 1
Robot0 on pass 1
Robot2 on pass 1
Robot3 on pass 1
Robot1 on pass 2
Robot0 on pass 2
Robot2 on pass 2
Robot3 on pass 2
Robot1 on pass 3
Robot0 on pass 3
Robot2 on pass 3
Robot3 on pass 3
Robot1 on pass 4
Robot0 on pass 4
Robot2 on pass 4
Robot3 on pass 4

Maintaining a Queue of things to do for each robot allows the
robot to process a single thing before sleeping a bit.

The thread scheduler does seem to provide interruptions, as I've
run the above code with no sleep() call and larger iterations,
and you'll find it bouncing from robot to robot.

, you can take advantage of python's yield statement:

class Robot(object):
def __init__(self, name):
self.name = name
self.thought = 0
self.done = False
def think(self):
while not self.done:
yield self.thought
self.thought += 1
def finish(self):
self.done = True

robots = [Robot(str(i)) for i in xrange(5)]
generators = [robot.think() for robot in robots]
[g.next() for g in generators]
[0, 0, 0, 0, 0]
[g.next() for g in generators]
[1, 1, 1, 1, 1]
[g.next() for g in generators]
[2, 2, 2, 2, 2]
[g.next() for g in generators]
[3, 3, 3, 3, 3]
[g.next() for g in generators]
[4, 4, 4, 4, 4]
generators[2].next()
5
[g.next() for g in generators]
[5, 5, 6, 5, 5]
robots[2].thought
6
robots[3].thought
5

Just do more complex stuff in the think() method (to most folks,
counting isn't very exciting thinking) and yield your current state.

Is Python just not adapted to this kind of things?

Python is quite adaptable to these sorts of thingsit requires
an adaptable programmer to make the best use of it though ;)
-tkc

2006-08-09, Tim Chase <python.list (AT) tim (DOT) thechases.comwrote:

>Problem is that I would have to share the CPU between all the robots,
>and thus allocate a time period to each robot. However I couldn't find
>any way to start a thread (robot), and interrupt it after a given time
>period.
>Any suggestions on how to proceed?

import thread, time
def robot(name):
for i in xrange(5):
print "%s on pass %i" % (name, i)
time.sleep(0.01)

>[]

I originally suggested the thread/sleep() scheme, but after
thinking about it more, I really like the generator approach in
the case where you want to explicity end each robot's "turn"
using the CPU (which is what the sleep() call does).

TH, if you want the robots to wait for events of some sort
(e.g. from a queue) or data from an I/ device, then threading
is probably the way to go.

I guess it all depends on whether the robots' behavior is to be
time-driven or event-driven.

Yannick wrote:
Hi,

I would like to program a small game in Python, kind of like robocode
().
Problem is that I would have to share the CPU between all the robots,
and thus allocate a time period to each robot. However I couldn't find
any way to start a thread (robot), and interrupt it after a given time
period.
Any suggestions on how to proceed?
Is Python just not adapted to this kind of things?

Thanks,
Yannick

You should take a look at stackless Python. It should do very nicely
for what you want. There is a good tutorial on it here:

9 Aug 2006 11:01:40 -0700, "Yannick" <yannick.leteigner (AT) gmail (DOT) com>
declaimed the following in comp.lang.python:

Hi,

I would like to program a small game in Python, kind of like robocode
().
Problem is that I would have to share the CPU between all the robots,
and thus allocate a time period to each robot. However I couldn't find
any way to start a thread (robot), and interrupt it after a given time
period.
Any suggestions on how to proceed?
Is Python just not adapted to this kind of things?

There are two ways to approach this

Discrete event simulation -- in which you run a master cycle and
call each "robot" passing in the "current" time value, the robot updates
its status to that time, and /returns/ so you can then invoke the next
"robot". After all robots have been processes, you increment the time,
and repeat the whole process again. Note that no threads are required
for this model.

Threading: each robot runs independently. Form 1: rely upon the S
scheduler (or, for Python, the scheduler that runs every /n/-byte codes
-- what is that set to these days, 100 byte codes?); Form 2: robots are
designed to sleep() at regular points (at the end of an update
computation say -- a sleep() lets the S swap to another thread); or the
robots are designed to block until some event is triggered, with maybe
the main program setting that event at regular intervals.

Thanks,
Yannick

Yannick wrote:
Hi,

I would like to program a small game in Python, kind of like robocode
().
Problem is that I would have to share the CPU between all the robots,
and thus allocate a time period to each robot. However I couldn't find
any way to start a thread (robot), and interrupt it after a given time
period.
Any suggestions on how to proceed?
Is Python just not adapted to this kind of things?

If your intent is to allow the user to program a robot using python
then no it's NT suitable. There's no builtin way to restrict what
code can do (but Zope might have a way), nor can you force it to pause
after a predetermined amount of time, nevermind making that amount of
time deterministic enough to be fair in a game.

However, if your intent was to have only trusted code then Python would
work fine. My preference would be for generators (especially once
Python 2.5 is released), but YMMV.

Thank you all for the detailled answers.

What I would like to achieve is something like:

# main loop
while True:
for robot in robots:
robot.start()
robot.join(0.2) # wait 200ms
if robot.is_active():
robot.stop()
# run all the game physics, pause, frame/rate, etc

Unfortunately the stop() call doesn't exist in Python.

By using a generator I would make the assumption that every robot is
playing fair, and would yield often. But I cannot control this as
eventually robots would be coded by third parties.

Using Python scheduler would allow me to share time equally between
each robot, but then I would loose the ability to have a main thread
organizing everything.

Yannick wrote:
Thank you all for the detailled answers.

What I would like to achieve is something like:

# main loop
while True:
for robot in robots:
robot.start()
robot.join(0.2) # wait 200ms
if robot.is_active():
robot.stop()
# run all the game physics, pause, frame/rate, etc

Unfortunately the stop() call doesn't exist in Python.

By using a generator I would make the assumption that every robot is
playing fair, and would yield often. But I cannot control this as
eventually robots would be coded by third parties.

Using Python scheduler would allow me to share time equally between
each robot, but then I would loose the ability to have a main thread
organizing everything.

This is just a dim memory, but something called lambdaM was (is?) a
Multi-User Dungeon that had (has?) a model of processing that allowed
you to create programmed objects that received a "budget" of processor
time. The objects would not work if they "ran out" of processor
time

Perhaps something like this could help you? (Sorry to be so vague.)

HTH,
~Simon

Simon Forman wrote:
This is just a dim memory, but something called lambdaM was (is?) a
Multi-User Dungeon that had (has?) a model of processing that allowed
you to create programmed objects that received a "budget" of processor
time. The objects would not work if they "ran out" of processor
time

It basically employs its own threading model to do just this.
SecondLife does much the same: any system that allows for the apparent
parallel running of code will.

LambdaM still exists, incidentally! You might also be interested in a
python-implemented version of the main M core, the unfortunately
named P:
-alex23

linnorm (AT) gmail (DOT) com wrote:

You should take a look at stackless Python. It should do very nicely
for what you want. There is a good tutorial on it here:

Not being intimately familiar with Stackless myself, I wonder, how
would it deal with a script that executed the line:

x = 10 ** 10 ** 10

My guess is that would cause a Stackless interpreter to block for a
long, long time, until it ran out of memory, but I'd like someone who
*knows* and doesn't have to guess to comment. :-)

Yannick wrote:

I would like to program a small game in Python, kind of like robocode
().
Problem is that I would have to share the CPU between all the robots,
and thus allocate a time period to each robot. However I couldn't find
any way to start a thread (robot), and interrupt it after a given time
period.
Any suggestions on how to proceed?

You've gotten a number of other suggestions from other posters. Let me
suggest, though, as someone else has already beat me to, that
programming the robots in Python might not be ideal. Without some
significant work, you won't be able to prevent one of your "robots"
from tying up your Python interpreter for arbitrary lengths of time.
Consider, for example, a robot that executes the following line:

x = 10 ** 10 ** 10

Now, if you're careful, you *can* prevent this sort of thing. My guess
is, however, for a "small game," this effort is not going to be worth
it.

Is Python just not adapted to this kind of things?

That depends. I think Python would be a good choice of language to
implement a custom VM for such a game, where you could have the level
of control you need. Now, implementing a simple and limited-purpose VM
really isn't as hard as it sounds. The hard part comes if you want to
program your VM in anything other than its equivalent of Assembler.
Then, you basically need to write a Language X -VM compiler for
whatever Language X you'd really like to program in, and that's
generally not a trivial task.

alex23 wrote:
Simon Forman wrote:
This is just a dim memory, but something called lambdaM was (is?) a
Multi-User Dungeon that had (has?) a model of processing that allowed
you to create programmed objects that received a "budget" of processor
time. The objects would not work if they "ran out" of processor
time

It basically employs its own threading model to do just this.
SecondLife does much the same: any system that allows for the apparent
parallel running of code will.

IIRC, LambdaM's threading model is based on cooperative multitasking,
possibly with the ability to limit how many VM-level instructions a
piece of code executes per timeslice (I'm not intimately familiar with
it). However, such an ability to limit how many instructions are
executed per timeslice really requires VM-level support.

In LPMUDs, which I am much more familiar with, and which also implement
a similar cooperative multitasking "thread model" (I put this in quotes
because it's not really threading -- it's actually a near equivalent of
generator-based microthreads), it's still possible to lag the game for
long periods of time with any reasonable limit on the number of
instructions per "tick." That might not matter much for a hypothetical
Python-based robot game, if it weren't designed to be interactive.

LambdaM still exists, incidentally! You might also be interested in a
python-implemented version of the main M core, the unfortunately
named P:

I believe P's "thread model" is much the same as I've described
above: inherently it's cooperative multitasking.

Incidentally, if you don't like the name P, there's also MP at
moop.sourceforge.net. I don't know if MP is derived from P, but
they have similar descriptions and aims, so I wouldn't be *too*
surprised.

10 Aug 2006 16:46:34 -0700, "Yannick" <yannick.leteigner (AT) gmail (DOT) com>
declaimed the following in comp.lang.python:

Thank you all for the detailled answers.

What I would like to achieve is something like:

# main loop
while True:
for robot in robots:
robot.start()
robot.join(0.2) # wait 200ms
if robot.is_active():
robot.stop()
# run all the game physics, pause, frame/rate, etc

Unfortunately the stop() call doesn't exist in Python.

There is also the problem that you can only "start" any given thread
once.

By using a generator I would make the assumption that every robot is
playing fair, and would yield often. But I cannot control this as
eventually robots would be coded by third parties.

Danger, Will Robinson, Danger!

Yannick wrote:
Thank you all for the detailled answers.

What I would like to achieve is something like:

# main loop
while True:
for robot in robots:
robot.start()
robot.join(0.2) # wait 200ms
if robot.is_active():
robot.stop()
# run all the game physics, pause, frame/rate, etc

Unfortunately the stop() call doesn't exist in Python.

By using a generator I would make the assumption that every robot is
playing fair, and would yield often. But I cannot control this as
eventually robots would be coded by third parties.

Using Python scheduler would allow me to share time equally between
each robot, but then I would loose the ability to have a main thread
organizing everything.

I think the best way is to give each robot its own thread. That way the
interpreter will share time between each of the robots (whether or not
they sleep or yield) on a reasonably fair basis.

regards
Steve