chrisdembia / battlecode2014 Goto Github PK

http://java-source.net/open-source/profilers

http://stackoverflow.com/questions/11345034/how-many-bytes-of-bytecode-has-a-particular-method-in-java

javap -c mypackage.MyClass

When are y'all available?

Is it worthwhile for the robots to all learn the map? Yes. We send out some robots early on to do some exploration. They detect the terrain everywhere, and broadcast it. This broadcasting doesn't need to be done on every turn. This should greatly improve the path planning throughout the game.

Here's a paper on something called the D* algorithm. http://web.mit.edu/16.412j/www/html/papers/original_dstar_icra94.pdf

D* lite, less lines of code and as fast or faster than D*: http://pub1.willowgarage.com/~konolige/cs225b/dlite_tro05.pdf

Ok, been thinking about pathfinding. Here's an idea I had that i just wanted to write down somewhere before I forget:

Wall-hugging around obstacles

• Move in target direction
  • if an obstacle (group of void tiles) is encountered, record the distance away from your target that you currently are as initialObstacleDist and enter hug-obstacle mode
  • in hug-obstacle mode: keep moving with the void tiles on your right or left, staying along the wall, until you are closer to your target than initialObstacleDist. At that point, resume travelling directly toward target

I just pushed some sample MVC code that implements the example player's logic for the HQ robot. I am pretty much copying what we did 2 years ago (see https://github.com/chrisdembia/battlecode2012). Let's discuss if this is what we we're thinking.

Please feel free to dig in and change things, or to try and implement the example player's Soldier logic.

I just put this note in the code:

            // TODO note that we may want a turn to end naturally somewhere
            // else. For example, we may have a method. "Go to destination"
            // that calls yield() inside of it, and the loop continues
            // until the robot reaches its destination.

That is, we may not want to keep going back to the main loop. We may want multiple "loops" that run through multiple turns/rounds until completion, such as for going to a destination. Then, we'd want a system of interrupts to knock us out of that loop, in case there is a more urgent/pressing thing to take care of. This gets at the system of "priorities" we were trying to figure out before.

Hey:

So we should:

1. Get Scott's friend and Shipper's friend as part of this repository.
2. Figure out who should be registered as part of our team on the battlecode website.

Perhaps what makes the most sense is that the 4 people who register are the 4 who will be able to contribute the most time?

See discussion (potentially, solution) here http://www.battlecode.org/contestants/forum/2/22/

In the example funcs player, rc.isActive() is checked first before anything else. That's because you should only try taking an action if you CAN take an action. So there are two ways that I see we can be efficient in this way:

1. Replace takeOneTurn() with a think() and an act() method. think() can do anything that does NOT call functions that can throw a GameActionException. act() CAN throw GameActionException() except that we'll wrap it like so: if (rc.isActive()) { act() }
2. Create some sort of action queue...or, sleep until rc.isActive()...I'm not really sure what I'm saying here.

In the former case, Controller.run() would now be:

beginTurn();
think();
if (rc.isActive()) { act() };
myYield();

Here's how to do it in Python or C++ http://www.codeproject.com/Articles/484598/Keyword-mutable-and-data-caching-in-Cplusplus

Any ideas?

Bulldogs

idk

BTW it looks like the 2013 competition was easier than the 2012 competition.

Instead of having takeOneTurn(); endTurn(); yield() in the run() method, maybe we actually want:

takeOneTurn(); myYield()

where myYield() does a few things just before we actually yield(). For example, it could update an indicator string to the amount of bytecode used in that turn. The reason is that we might want to use myYield() in many more places than just in run().