These are various ideas for features to add to Xtank, contributed by many
different people.  It's not that well organized, I admit.

###############################################################################

The maze design area should have a key for quick-save, which should retain
current settings on Name/Type/Designer/Description.

Let relative shooting be a per-player option?

Safe turning should be toggleable by users.

How about catching signals, so if a robot program dies, we can just nuke it and
continue the game?

How about putting the message window near the map window so pointing to a box
and then sending a message is a little easier?

There should be keyboard equivalents for sending different message types.

Vehicle_info should have the turret positions in addition to the turret angles.

You should be able to steer by clicking in the map window, like in XTrek.

We really need multiple players/programs per vehicle.

The Prog_desc structure should have a field for suggested stack size, so
heavily recursive robots can be written.  This will not be compatible with
existing robots, I guess.  There should also be a function that robots can call
to see how much stack space they have left.

Scoring should be game dependent (i.e. #goals for race, etc.)

Have weapon on/off toggles be actuated by clicking on the weapon as
well as using the shifted keys.

It would be nice if, when in battle mode, you get to see the messages
sent to the vehicle you are tracking.  Right now, the only way to
see debugging messages is to send them to RECIPIENT_ALL, so it's
impossible to debug a specific vehicle when lots are playing  (I
need to have at least a 2 on 2 for the problem I'm having to show
up).  If that feature were in, vehicles could send debugging messages
to themselves, and I could switch back and forth and see what they
were saying.

How about leaving burnt-out hulks when a vehicle is killed?  They could be
implemented as special kinds of vehicles.  They would not move by themselves,
but could be pushed around (they would obey the normal collision rules for
vehicles).  They would absorb bullets too.  Each hulk would start with
something like half the mass of the killed vehicle.  When a hulk took damage
from bullets or collisions its mass would be reduced.  At some lower limit of
mass the hulk would simply vanish.  Presumably there would be a few different
bitmaps for different-sized hulks.  The damage rate for hulks could be tweaked
so that they would be an interesting presence without becoming so long-lived as
to be annoying.

How about a self-destruct command?  It is very annoying to run out of fuel and
have to just sit there until sombody comes by and kills you.  To prevent people
from robbing their opponents of a kill, a 10 second delay in which no other
action is possible would be needed.  Or the pay-to-play setting could be used
instead.

How about a TEWS (is that the right acronym?), a radar-detector special that
locates tanks that have their radar on?  There must be some reason for having
on OFF switch on the radar...

Optionally allow the player to select which tank to buy next. This would make
long games more interesting.

###############################################################################

Mines and mortars:

Set the fuse on mines on a per-game or per-tank basis.  Currently they're
not that big a deal, but if they lasted the lifetime of a tank (an extreme)
life could get strange.  Setting a limit on the number of active mines per
tank might be good, and a way to set all of them off remotely would be good.

A high-trajectory, unguided, area effect weapon.  The mouse would be used
to select the point of impact, and intervening tanks, etc., would be passed
over. [ mortar ]

Maybe the mortar and the mine-layer could be combined: you can lob your mines
over walls.  If they land on a tank, top armor is damaged.

Anyone see TRON?  Remember the grid bugs?  Wouldn't they make lovely,
pseudo-predictable, heat-seeking mines?  Wouldn't it be a bitch to
accidently deploy some of these in a constrained area?  >;->

###############################################################################

The slide boxes correlate nicely to the effect of gravity upon a tank
upon a ramp.  It might be possible to assign each square with an integer
level, and the same for bullets.  This would enable three-dimensional
layout (although without bridges and the like) with bullets passing over
lower tanks, or impacting upon ramps between levels.

The smaller tanks would have a better chance against the huge ones if
there were places in the maze the megaliths couldn't access due to their
size.  Perhaps increasing the resolution of the base game grid and using
more open mazes to compensate would provide this effect.

###############################################################################

Has anyone tried writing a tank program which opens a socket to a
seperately-run user interface?  (This approach would also let the
user swap out tank algorithms without having to dynaload, without
the risk of a bug crashing xtank, and without having to think about
data-hiding problems invalidated the simulation.)

Has anyone tried to use sockets to have two tanks communicate, or
arranged for them to be controlled by a single external program?

###############################################################################

make difficulty reflect difficulty
side mounted weapons firing in 90 degree arc
serparate keys for firing different types of weapons
fire_weapons(flags)
fire_mines
fire_slicks
both take x,y

###############################################################################

Here's an idea a friend of mine had for Yet Another way to handle relative
shooting.  He's convinced me that it is a Good Thing.

The idea is that each type of weapon would have its own (fixed) degree
of relative shooting.  There would be no user-settable switch.  For
instance bullet-type weapons (machine guns, autocannon, pulse rifles,
mine layers) would shoot relatively, rocket-type weapons (rocket
launchers, heat seekers) would shoot absolutely, and fluid-type
weapons (acid sprayers, flame throwers, oil slicks) would be a
combination of both.

The advantages are these:

        It's more physically realistic (for whatever that's worth).

        It's more fun, since it introduces new skills to be learned.
        You have to learn to aim different kinds of weapons.  You have
        to learn to design vehicles with appropriate combinations of
        weapon types.  During combat you have to learn to choose a
        line of fire that brings the right weapons to bear.

        It's more consistent.  I'm tired of having arguments with my
        co-players over the relative-shooting setting.  Those with
        religious convictions can just stick with those weapons that
        conform to thier bias.  They lose the use of the other
        weapons, but that's the cost of pig-headedness :-).  (Note
        that I myself have a religious preference for absolute
        shooting).

The disadvantages are these:

        It's harder to write robot code, since a single aiming
        algorithm no longer suffices for all weapons.  I don't think
        this is such a big deal, since robots currently have to
        contend with the relative-shooting setting anyhow.

        It'll piss off players with hardened habits.

###############################################################################

I believe some of this has already been fixed...

			   VEHICLE DESIGN

increase power of smaller engines to give the vehicle designers
more reasonable choices.

increase cost of small vehicles, since they're so hard to hit.

decrease speed penalty for having a larger vehicle.

make acid sprayers less optimal
	more expensive?
	lower damage?
	more weight?

make spiders roomier, space = 4000?

make rhinos faster and more maneuverable

make malices less gross
	less maneuverable/speedy
	more expensive

make armor heavier

###############################################################################

Specials and landmarks
----------------------
Jump		Allow passage over walls
Nitro boost	Double acc, 50% higher max speed, sets speed to max
Turret lock-on	Program that automatically tracks the nearest enemy with turret
Smoke screen	Makes smoke which can't be seen through
Radar detector	Detects when someone is using radar on you
Radar jammer	Makes enemy radar within a given range useless
Radar cloak	Makes you invisible to radar

Display Modes
-------------
LOS	Only display things that you can see by line of sight
3D	Perspective display of things.  tanks+bullets are polygons
night	Only display things that have light shed on them from light source

###############################################################################

				PHYSICS

1.  collisions based on actual shape of vehicle

2.  collisions that rotate vehicles

3.  skidding, losing control of vehicle during collision


###############################################################################


Thanks to Steve Jankowski, Christos S. Zoulas, Hal Peterson,
Christopher North-Keys, Robert Potter, Bill Bolosky, and Tor
Lillqvist for their improvements. 

Desired improvements:

1.  Get it running on other hardware.  (HP9000 series 300, Apollo, Dec 3100's)

This requires porting the multi-threading code, which is used to run
multiple robot programs concurrently to control the enemy vehicles in
the game.  For most machines, this requires a change to thread.c
around line 58, where the stack pointer register is initialized.
Or you can substitute a different threads package if one is available
on your machine.

This also requires porting the dynamic linking code, which is
used to load object code for robot programs into the running
executable.  The current implementation in unix.c should work on most
Unixes.  Never strip an xtank executable since that makes it
impossible to dynamically link.  If you can't get the dynamic linking
code working, just remove the #define DYNALOAD in config.h.
You will then not be able to add new robot programs without recompiling.

If you are not running X11R3, you may have to modify the graphics code. 
All the X specific code is in x11.c.  Scattered about the
code you will find #ifdef AMIGA and #ifdef 640x200.  They don't work.
Neither does the Amiga version.

2.  Make multi-player games easier to start.  This can be done by
having xtank listen to some port (or a zephyr message class for
those who have it) for messages from other machines that want to join
the game.  Also, when someone starts a game of xtank, xtank would
call out to the network (on the known port) to find out if there
are any other machines currently running xtank.  If so, the player
would be asked if he wants to join that game (perhaps with some
information about the number of people currently playing, what game,
etc.).  The player should also have the option of not allowing
other players join the game, if he just wants to play alone.

3.  More conformance to X application standards (support for more
XResources, a man page, correct command line option handling).
Perhaps use of a toolkit (although I don't like the thought of the
executable doubling in size...).  

4.  A better language for writing robot programs (along with a fast
interpreter/compiler for the language).  This seems like a big
project to me, but I know many programmers who are better at writing
compilers than me!

6.  More dynamic listings of vehicles and mazes that are available.
I'd really like to see a list of all the mazes in the Mazes directory
and browse through them quickly.

7.  Difficulty levels (currently the difficulty level does very
little).  This is pretty easy to do, since you just need to pick
a set of vehicles and robot programs from the set available.  To
facilitate this, it may be useful to write robot programs which
look at the difficulty level of the game to decide how well to play.

8. Implementing new games.  Let your imagination run wild.  Xtank was
designed to maximize player creativity.

I heartily recommend 2-on-2 Ultimate with commentator and no-wear set,
2-on-2, in moosemaze with everyone in Ultimate vehicles.  It has the
pace and feel of ice hockey.

				Terry Donahue

Note slightly       -->		tmdonahu@athena.mit.edu	(once a week)
different usernames -->		tdonahue@next.com	(every day)
