A few basic questions

I like zeroing out thrust every turn. My feeling is this is both the simplest model and the one that any moderately advanced bot will use anyway (most Robocode bots recalculate movement every tick), so why not keep your API simple and make it the only model.

My first thought is that drag sounds not fun and not that interesting a problem either, but there are good reasons you might want it - e.g., to keep max speeds in check, if you think that would be good for gameplay.

Your thoughts on missile behavior sound interesting and like a big change from Robocode, which is cool. Will there be any limit to what you can see on radar - e.g., walls obstructing it, distance, etc? That would play interestingly into the invisible mine thing, like being able to move your stuff around when you think the enemy can't see it. Incomplete information is a pretty powerful gameplay dynamic, and without it you risk creating a "solvable" game, especially with computer players.

I think my biggest advice is to be vigilant about only adding complexity that really multiplies the gameplay depth. I posted a bunch of thoughts about this in BerryBots vs Robocode game rules.

Chess is a good example of a game that probably gets it just right. Each type of piece multiplies the complexity, and the result is a game where the greatest human minds, with tons of practice, can almost play it perfectly. Any more pieces and it would become too complex and even less approachable, and any fewer pieces and it probably would have become uninteresting ages ago.

I was only referring to only one kind of movement, I was asking an opinion on which one in particular.

You have an interesting point. The 3D by itself already makes the game fairly complex. However compared to the original version it has been greatly simplified.

Currently the radar is an 'all seeing eye'. It can't see bullets, but I could see it being blocked by a robot, since missiles are 1/3 the size of the robots that fire them. So an enemy could fire a missile opposite of the enemy, cover it till it stops and then lure the enemy towards it, or wait for them to approach it, and reactivate it, or possibly several to flank an enemy with mines.

That actually sounds awesome, and as long as missiles/mines are not one hit wonders, it should work wonderfully. I think 8-16 damage (4-8 to fire), with a limited fuel supply is best. I don't want it to overlap with bullets, which at the moment cost 0.5, and do 2 damage.

Though I think limiting the number of active missile a robot can have might also be an good idea. But that requires a way to disable them, or rather remove them from your control so you can fire another. But perhaps they could still work as passive mines.

On the note of missiles, since they can navigate. I think you should be able to hit yourself with them (after a few ticks to activate).

After much consideration I decided to go with depleting thrust, so that you can do things like this.

//Lay a mine
Missile m = setFireMissile(new Vector(1,0,0));
if(m != null)
	m.setThrust(m.getVelocity().scale(-1));

or this

//thrust towards center for 4 turns
setThrust(getPosition().normalize().scale(-4));

This will allow smaller robots by making the thrust system easier for robot creators to use, while not impacting those who want to change it every turn. If you set a thrust, it replaces the current thrust, just like calling setAhead(-100) replaces the previous setAhead(100) call.