Temporary Power-Up Items

[MCSnapTurtle]

Randomly generated items should be added to the game. When a bot collides with the item, they get the power-up. The location of the power-up should be random, and they should 'de-spawn"/ disappear after ~250 steps. There should be a max of 2 power ups per game.

Power-ups examples:
-invincibility (aka Can't take damage) for 100 steps (bot will not take any damage)
-immortality (aka Can't Die) for 100 steps (bot will take damage, until at 0.1% health, then it will stop taking damage)
-faster turn rate (aka turn like at 0% speed, regardless of speed) for 100 steps.

Bots can ask the server for the location (x, y) of the power-up.

Describe alternatives you've considered
Bots can shoot the power-ups to get them instead of having to collide with them.

[dbakewel]

Ok, I like it. We can also simply have them be worth 10 points each. Have you given some thought to the format of the getPowerUp message? we also want some of the game mechanics to be tunable, such as how long a power of last for on the in the arena. Just wondering what other tunable parameters would be needed. What would the server arguments be to turn this on and off? Will there be just on offer would there be other server arguments?

[MCSnapTurtle]

Maybe first just making them worth 10 points would be easiest. I will work on this instead, because team bot is very painful to do. I'll look into how to write it.

[dbakewel]

OK, this is a big one since it requires a new server message and code changes in lots of places. Please give me a description of how it will work and what parts of the code you will need to change before you start. What will the data look like that the server will store and manage? What will the message from bots look like? How will the server create and delete items? How will the server detect a robot getting item?

I think this is all doable but I want to keep you on the right track. FUN!

[dbakewel]

If you are smart, I bet you can do all this with only 50 lines of code!

[dbakewel]

@MCSnapTurtle I was thinking about the robot/server message format. Here is one idea. It assumes a lot so feel free to propose other ideas:

getPowerUps Message
Used to determine which power ups are currently in the arena.

Robot Sends:
Format: { 'type': 'getPowerUpsRequest' }
Example: { 'type': 'getPowerUpsRequest' }

Server Returns:
Format: { 'type': 'getPowerUpsReply', 'powerUpsEnabled': bool, 'powerUps': list of dicts} or Error
Example:

{ 'type': 'getPowerUpsReply', 'powerUpsEnabled': True, 'powerUps': [
    {'type': 'points', value: 1, x: 30, y: 403, untilStep: 493}, # Power up at (30,403) for 1 point that is removed when someone gets it or after step 493
    {'type': 'points', value: 1, x: 303, y: 43, untilStep: 300}, # Power up at (303,43) for 1 point that is removed when someone gets it or after step 300
    ]
}

The nice thing about this is the the 'powerUps' list could be stored in d.state['powerUps'] in the exact same format. 'powerUpsEnabled' would be stored in d.conf['powerUpsEnabled']. That would make things easy.

[MCSnapTurtle]

Sounds good! In the server code, would using a modified variant of the jam zones be suitable for creating and colliding with these power ups?

[dbakewel]

It depends on what you are thinking. I was assuming that power ups are just point objects, not circles. The viewer may have a fancy display but in the server they would just be points. As long as any part of a robot touches that point then they would pick it up. In this case the JamZone code has a way to pick random x,y points.

I assume there would be no power ups at step 1 of a game. So they would appear as time goes on. Therefore the code to add them would need to be triggered in step(). The actual code to add them could be it's own function called from step().

As far as choosing the position of power ups. I suggest they are at least bot radius away from any wall and at least bot radius away from any robot with health > 0. Besides that the layout can be random. Look at the jam Zone and obstacle code for ideas on how to check distance and overlaps. Ask more questions if you need help.

[dbakewel]

We should talk about server arguments as well. This is one option:

-powerUpOdds 0 # defaul value,, power Ups are not enabled
-powerUpOdds 0.01 # Each step there is a 1% chance of a power up being added to the arena.
-powerUpOdds 0.02 # Each step there is a 2% chance of a power up being added to the arena.

We could actually store 'powerUpOdds' in d.conf and not have 'powerUpsEnabled' as suggested above since powerUpOdds already does the same job as powerUpsEnabled and more.

[MCSnapTurtle]

Ok, nice suggestions, I'll see what I can do.

[MCSnapTurtle]

So far, here's a list of things that I must add to get the feature to work:

• add power-ups to server config
  -allow bots to ask server for location of power-ups
  -allow server to respond to these requests

-create a function that randomly places power-ups
-add in step(), that power-ups will be added as the game progresses.

I'm not sure whether I should use something like mkObstacles to place the power-ups or have the code inside step(). Are those mk functions supposed to be used only when initializing a game? or can they be called later at any time?

-function to check whether bot is overlapping with power-up

So, something like a modified findOverlapingBotsAndObstacles function, with lists changed accordingly and with the radius of the object removed?

-remove power-up after collison, or after a certain amount of steps has passed

Sorta like deleting a shell?

-draw/delete power-ups in the viewer

@dbakewel is there a "suggested" implementation order? (ie. easiest to work with, and easy to test as I go along)

[MCSnapTurtle]

Forgot to add:

-once a bot collides with a power-up, they should be given a set amount of points (and possibly in the future, have an actual power-up, but that may be a bit too difficult for me)

[dbakewel]

OK, I'll look at this tomorrow afternoon and give any feedback I can.

[dbakewel]

This is the order I susggest you do this in:

1. Start by getting a copy of the latest develop branch. It has other server update from @mcstoer and @lsh010815.

2. Add the data structures:

• add 'powerUpOdds' = 0 to SrvData class under conf.
• add 'powerUps' = [] to SrvData class under state.
  You also need to reset powerUps to [] at the start of each game in initGame().

3. Set up command line argument in server to allow -powerUpOdds to be set. The default should be 0, which means no power ups.

4. I would put all your step related code in a function called powerUps(d) and call it from step() after the robots have moved but before the collision code.

5. The powerUps(d) function needs to do three things:

• determine if it should randomly add a powerup this step. If so then add a power up that is at least botRadius from any wall and bot Radius from any robot. (new power ups are added to the d.state['powerUps'] list in the same format described above for messages.
• determine if any robot currently overlaps any powerup. If they do then remove the power up and assign the points to the robot.
• remove powerups that are due to be removed based on the game step.

I would log all actions of powerUps() for now until we get the viewer working.

This can all be in one function because you do all the mk, check overlap , and remove work every step. That is why it makes sense to all be one function. You could put it in three functions and then call each in step() one after the other. That may be more useful down the road. Either way is fine with me.

Do what's above first and then put in a pull request. I'll have a look before we move on.

6. Add support for new message type.

• Add new messages to netbots_ipc:MsgDef. If you can't figure this out then ask.
• Add getPowerUpsRequest function to netbots_srvmsghl.py. Look at getInfoRequest() as an example.

Do another pull request for this code.

7. Now we can set up the viewer. This may have some issues we need to address but we can talk about that later. The main issues is that there needs to be some sort of unique index. Something like explIndex
   but I'll need to think about it.

[dbakewel]

Regarding finding a spot for a powerUp. mkObstacles() is a good model but your code will be different. mkObstacles() is good because is does three things you need:

• mkObstacles tries to place obsticales and if it fails then it retires in a loop. You need to put a limit on the attempts so the server does not lock up and mkObstacles() does that (999 attempts)
• mkObstacles makes sure obstacles are not to close to the edges of the arena.
• mkObstacles makes sure obstacles are not to close to other obstacles (you will want to make sure you are not to close to other robots).

So yes, mkObstacles is a good model to use...but with some changes.

[MCSnapTurtle]

Due to time constraints, I will not be able to implement this.