Real Time Battle and Python

[hg]

Hi,

I have started to work on a python-based robot, and am interested in your
feedback:

http://realtimebattle.sourceforge.net/
www.snakecard.com/rtb
hg

[Matimus]

On May 3, 5:20 am, hg <[e-mail] gwrote:

Hi,

I have started to work on a python-based robot, and am interested in your
feedback:

http://realtimebattle.sourceforge.ne...kecard.com/rtb

hg

This is not necessarily a response to your effort, but just a note
(rant) about realtimebattle. It reminds me more of homework in 300 and
400 level college engineering classes than a game. Based upon my
previous effort and realizations, I found realtimebattle coding to be,
from a programming perspective, an exercise in protocol implementation
first. Once the protocol work is done you need to implement control
algorithms for movement and enemy tracking. Think PID algorithms
(Proportional, Integral and Differential). Only when the protocol and
control portions are done can you focus on strategy and play the game.
You should also note, however, that the first two tasks are quite
daunting. And the second is difficult to get right. I found the whole
process to be very tiring and not very rewarding. I don't mean to
discourage you, I just think it would be more fun to write my own game
than to 'play' that one.

A better game, from a programming perspective, would be
"discretetimeba ttle". Where each player controls their robot with
second order parameters (velocity not force), the world has no third
order effects (friction) and the time is discrete. Discrete time
meaneing that the protocol updates every player at regular intervals
with the same information and, in terms of the simulation, each update
represents a set time delta.

I would be interested to know if anybody else has played, or tried to
play, realtimebattle and has similar sentiments.

I do wish you luck though. If you get a robot working you are a far
more dedicated and patient individual than me.

-Matt

[hg]

Matimus wrote:

On May 3, 5:20 am, hg <[e-mail] gwrote:

>Hi,

I have started to work on a python-based robot, and am interested in your
feedback:

http://realtimebattle.sourceforge.ne...kecard.com/rtb

hg

This is not necessarily a response to your effort, but just a note
(rant) about realtimebattle. It reminds me more of homework in 300 and
400 level college engineering classes than a game. Based upon my
previous effort and realizations, I found realtimebattle coding to be,
from a programming perspective, an exercise in protocol implementation
first. Once the protocol work is done you need to implement control
algorithms for movement and enemy tracking. Think PID algorithms
(Proportional, Integral and Differential). Only when the protocol and
control portions are done can you focus on strategy and play the game.
You should also note, however, that the first two tasks are quite
daunting. And the second is difficult to get right. I found the whole
process to be very tiring and not very rewarding. I don't mean to
discourage you, I just think it would be more fun to write my own game
than to 'play' that one.

A better game, from a programming perspective, would be
"discretetimeba ttle". Where each player controls their robot with
second order parameters (velocity not force), the world has no third
order effects (friction) and the time is discrete. Discrete time
meaneing that the protocol updates every player at regular intervals
with the same information and, in terms of the simulation, each update
represents a set time delta.

I would be interested to know if anybody else has played, or tried to
play, realtimebattle and has similar sentiments.

I do wish you luck though. If you get a robot working you are a far
more dedicated and patient individual than me.

-Matt

I do try to separate the "engine" from the "driver". Yes the engine is a
pain to code and the documentation quite skimpy (have to got through C
headers to understand the command set) ... still I'll try to finish it.

hg