in reply to Perl Tanks

caution, brainstorming ahead. beforewarned that there is an 80% probability of the overuse of phrases like "i think" and "could potentially"

i personally don't think it should be turn-based; i think some things should have to take a certain amount of time (like maybe moving) but leave as much as possible up to the robot itself; that way there is a good reason to optimize your algorithms for speed.

for instance, make them move the bullet themselves, and just provide a few arena methods for them to call. for instance, $arena->collide($bullet, $enemy) might return true if $bullet and $enemy occupy any of the same space, and automatically damage $enemy.

actually, further thought reveals that they'd maybe gain more by optimization if each one forked off and communicated back to a parent with requests. which starts to stray from the ultra-simple goal. do others think that gaining something by optimizing your code is worthwhile?

and really, you may only need to create a small handful of arena "commands" --

Create
creates a new object, likely a bullet. this perhaps has size ("mass") limits, both on individual items, and on total mass of all objects in existance for a particular owner.
Move ($obj, direction) or ($obj, location)
moves an object. automagically checks for collisions, deals damage, etc. probably has a maximum distance to move an object that is inversely related to the item's "mass" (number of pixels). probably automatically destroys objects that leave the arena or take too much damage -- a 2x2 bullet takes a lot of damage from a 20x20 tank, presumably.
Destroy $obj
maybe not necessary, since most objects should be destroyed by Move at an appropriate time, but if you want to auto-destroy bullets that stray too far from you without waiting for them to hit something, maybe you should be able to.
Look $direction or $location
get data about a part of the playing field. presumably in some pre-determined, easily digested form. possibly not.
for extra panible possibly make these more restrictive. for instance, make objects only able to move themselves (which means each object (read: bullet) needs to do its own looking, but still comes through your pipe, and make Move and Look rely on an object's curent Direction property, which can only be set via a call to Turn:
Turn
turns an object, changing its direction. making this only work up to 1 degree per call would potentially severely limit the movement algorithms for bullets.
both of these could potentially reduce the threat of heat-seeking missles and make the algorithms have to be more robust, i.e., more interesting.

then again, i might be playing a totally different game.

.

Replies are listed 'Best First'.
Re: Re: Perl Game, suggestions.
by mr.nick (Chaplain) on May 23, 2001 at 19:13 UTC
    i personally don't think it should be turn-based ...

    I agree. It should be time based. Something on the order of 

    while (TwoOrMoreAlive()) {
   for my $robot (@ArrayOfRobots) {
       eval {
           local $SIG{ALRM}=sub{ die };
           alarm(1);
           $robot->Process();
           alarm(0);
       };
   }
}

    [download]
    This would give each robot a fixed amount of time to do something. Somehow, we would want to parallelize the process (using a smaller time increment than 1 sec....). But by doing it time-based gives advantages to people who write very fast, efficient code: which should be a bonus.

    I have gobs of ideas, just not enough time to write them all down ... more later.

[reply]
[d/l]
Re: Perl Game Interface and Weapons
by SilverB1rd (Scribe) on May 24, 2001 at 01:13 UTC
    I like alot of your ideas vynce, mr.nick. I thinking most of the world actions will be 'hard' code into the game to avoid cheating. when I say hard coded I mean its not controled by the end users script.
    I thinking a few weapon types might be better then just one. I was think along the lines of a cannon (1 shot, small area of damage, accurate) and a rocket (1 shot, large are of damage, inaccurate) and possibly a few others. This would also make team matchs interesting, you control 3 tanks and they can talk with each other, one tank with active radar one with pasive could make for some fun combos.

    ------
    The Price of Freedom is Eternal Vigilance
[reply]
      how would you distinguish between active & passive radar in this game?

      multiple tanks is an amusing idea.
[reply]

        With active radar you emit a radar beam and wait for the return signal but with passive you are looking for the radar beam emited by the active radar.

        So with active radar you go looking for your enemy but with passive you let the enemy come to you.

        just think if you put a passive radar on a steath body. ;-)

        ------
        The Price of Freedom is Eternal Vigilance

[reply]

In Section Meditations