Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Perl Tanks

by SilverB1rd (Scribe)
on May 23, 2001 at 02:03 UTC ( #82411=perlmeditation: print w/replies, xml ) Need Help??

Ok let set the stage for the game. You control a tank, with your script, on a battle field of variable size, and fight up to 9 other tanks in the field during one match.
The match will last for a set amount of time.(not infinite)
Your tank my perform tasks as moving, shooting, scaning, etc.
The object is to kill all the other tanks on the field.

Contributing programmers: mr.nick, OeufMayo

Please give your suggestions and comments.



UPDATE 5
I'm thinking of implementing everything in a true 3D space.

UPDATE 1
Thanks to Larsen for pointing out those other game

UPDATE 2
Mr.nick had the idea to include different types of moving or firing methods such as Moving::hover or Moving::treads. This made me think of stuff like Radar::passive, Radar::active, Body::normal, Body::stealth. The Body::stealth would suggest that radar is not 100% accurate.

UPDATE 3
Looks like it is going to be a time based not turn base game. Oh all the possibilities! =)

UPDATE 4
What do you think of 4 teams of 3 tanks fighting it out as a extra play type?

Game specs

M = meters; S = seconds; Body::Normal { Hull = 1000 Radarsig = 90 Maxpower = 100 } Body::Stealth { Hull = 700 Radarsig = 45 Maxpower = 60 } Weapon::Cannon { Damage = 500 Accuracy = 5 // Within n M of location shot at DamageArea = 5 // M Reload = 10 // S Rrange = 500 // M Speed = 20 // M per S Power = 10 // Power needed from body } Weapon::Rocket { Damage = 700 Accuracy = 30 // Within n M of location shot at DamageArea = 20 // M Reload = 10 // S Rrange = 500 // M Speed = 20 // M per S Power = 20 // Power needed from body }

------
PT - Perl Tanks %100 Perl programming game
The Price of Freedom is Eternal Vigilance

Replies are listed 'Best First'.
Re: Perl Game, suggestions.
by larsen (Parson) on May 23, 2001 at 02:42 UTC
    Interesting. It seems similar to Crobots (and others programming-based games).

    What would you like to see in a game like this? Different types of weapons, armor etc?
    Well I think that in a game of this kind the scenario should be as simple as possible (but not simpler :)), so that one could concentrate on the intelligence of his bot rather than coping with weird weapons, armors and so on.
      Agreed. I've developed a game like this before ... years ago using C... which had it's own design issues (such as linking multiple peoples code together). Using perl, however, this might be relatively easy. You could have each person package their robot into, well, a package. Then have the main driving script load each one and execute them each turn.

      I would suggest writing some modules for the basic functions: Moving, Scanning, Firing, Status. Each bot may ONLY include these modules, nothing else (if you want a feature that another package has, you must write it yourself and include it directly into your bot).

      This sounds quite neat. I played Crobots for quite a long time and would LOVE to see something similiar in Perl.

      But like with all games, you are going to have to allow enough variations that people stay interested. You might have the choice to include one type of "Firing" module over another. Or perhaps a "Moving::Hover" instead of "Moving::Treads". They both would have their advantages and disadvantages.

      The different types of armor, weapons and movements should probably be categorized by a point value. Then each bot may include upto X number of points in accessories (kinda like weight restrictions in Mechwarrior).

      Something to think about!

Re: Perl Game, suggestions.
by Vynce (Friar) on May 23, 2001 at 18:35 UTC

    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.

    .
      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); }; } }
      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.

      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
        how would you distinguish between active & passive radar in this game?

        multiple tanks is an amusing idea.
Re: Perl Tanks
by MZSanford (Curate) on Jul 13, 2001 at 20:21 UTC
    One thing i would like to see is having the display code in a seperate module, so someone with a bit of speage time could use the OpenGL module to give a 3D frontend, while someone could (and, indeed, will) make an ascii art frontend ... just a thought
    OH, a sarcasm detector, thatís really useful
      Yes indead that was one of the reason I was going to make it all in 3d space in the first place. I hope everything is modular like that.

      ------
      PT - Perl Tanks %100 Perl programming game
      The Price of Freedom is Eternal Vigilance

Re: Perl Tanks
by suaveant (Parson) on Jul 12, 2001 at 23:42 UTC
    Heehee... golf it... the more code it has, the longer it takes per action... might be a good variant

                    - Ant

Re: Perl Tanks
by dga (Hermit) on Sep 19, 2001 at 03:15 UTC

    Some thoughts.

    Radar could be sensitive to energy output of the target. ie if tank 1 is expending 100 units last second its more easy to spot on radar.

    Storage space for carrying ordinance so a Rocket takes more space (less shots per tank) then a cannon shot.

    Also rockets tend to be more guided and slower than bullets.

    The game concept is a Cool Idea.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://82411]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (3)
As of 2022-08-18 03:44 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?