Difference between revisions of "User:Pedersen/Hubris"
(new work-in-progress tank description) |
(adding link to workshop) |
||
Line 4: | Line 4: | ||
I have christened this tank thus to remind me to test exhaustively, that I may in time truly pound the snot out of the weak and give what for to the rest. | I have christened this tank thus to remind me to test exhaustively, that I may in time truly pound the snot out of the weak and give what for to the rest. | ||
+ | |||
+ | <b>Subsections:</b> [[/Workshop]] | ||
<h4>Highlights</h4> | <h4>Highlights</h4> |
Revision as of 18:49, 13 February 2008
Hubris
Hubris is the wanton humiliation of an opponent. In modern times, it is used to mean arrogance and exaggerated pride. In the context of Robocode, it has several applications. A high rating in the Roborumble is achieved not simply by defeating your opponents, but by utterly annihilating them. It is also not uncommon for bot authors to send a bot to the competition without basic testing for errors. And finally I don’t think any of us have devoted so much time to Robocode without telling ourselves that the top spot is rightfully ours, and we but need to reach forth to grasp it from the charlatans who have usurped the throne.
I have christened this tank thus to remind me to test exhaustively, that I may in time truly pound the snot out of the weak and give what for to the rest.
Subsections: /Workshop
Highlights
- Redesigned physics model. The storage of points, directions, magnitudes, and their various combinations has been revamped. The main purpose of this was to ensure that entities that are presumed to not change over time were not being changed over time. For example, if you associate an opponent data snapshot with a wave and then update the opponent data with a later scan, you don’t want the wave’s data updated. My previous implementation allowed for such mistakes to occur, which are very difficult to detect.
- Emphasis on graphical debugging. New features and old are being tested with graphical representations of the data involved before the logic is implemented. By knowing that I am collecting and manipulating the data correctly, the writing and testing of the logic is easy.
- Redesign of movement engine. Movement has always been a bit sketchy for my tanks. My first implementation was simply to bounce off walls at 45 degrees without hitting them, which worked marvelously in melee for some reason. Then I created a vector-based movement system, which allowed multiple movement methodologies to coexist. Eventually I modified it to attempt to reach a position in the least amount of time, but it never really worked satisfactorily, especially with wall avoidance. The new version finds the best transition between two snapshots: the present position, heading, and velocity, and a final position, heading, and velocity.
- Reintroduction of team support. Hat Tourney style communication support is to be implemented. Team strategy will be implemented in order to have something to communicate other than just opponent and bullet data. The ability to act upon communications, and determining when to act upon them, will also be added.