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 5I'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
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. | [reply] |
|
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!
| [reply] |
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.
.
| [reply] [d/l] [select] |
|
- 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.
| [reply] [d/l] |
|
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] |
|
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 | [reply] |
|
| [reply] |
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 | [reply] |
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.
| [reply] |
|
|