Thread history

I figured I should try and get some input from other robocoder on this game.

I was wondering about thrust. Should be constant: If you set it to [1,0,0] it will remain that until you change it. Should it zero out: If you set it to [1,0,0] it will apply that thrust and then zero out the next turn. Should it deplete: If you set it to [1,0,0] it will apply that thrust and be reduced by however much was used (based on maximum thrust).

Currently it zero's out, and depleting thrust would be more similar to robocode, and would also allow you to set it to the inverse of your velocity to have your robot come to a stop without having to set it again.

That is assuming of course I do not add some kind of drag. I kind of like the frictionless feel of the current simulation, but that doesn't mean everyout has to agree with me on that front.

The missiles are the most difficult. I want to make them versatile but not too versatile/dangerous.

I figure there are two things, Yield and (possibly) Fuel. Unlike bullets, I would want them to be detectable by radar. But I also want the robot to be able to control them (this is simple enough). But I want them to possibly be able to stop and act as mines (and disappear from radar). But they would be easy enough to avoid in theory if the enemy just memorizes the position they were last at. But I also want them to possibly just disappear at some random point in the field (to the robots) without that area being considered dangerous. I think bullet missile collision might be the best way to achieve this. But that would only work if there were more then 2 opponents (since if you didn't shoot it, and your enemy definitely didn't then it must still be there). Etc ad nauseam

So any thoughts?

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.