A few basic questions

Jump to navigation Jump to search
Revision as of 30 April 2013 at 15:14.
The highlighted comment was edited in this revision. [diff]

A few basic questions

Edited by author.
Last edit: 17:14, 30 April 2013

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?

    Chase16:16, 30 April 2013

    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.

      Voidious17:00, 30 April 2013