Battle Chips -- Updated

Examples
1

UPDATE

A new video to show the project at 0.50. As per several suggestions, I’m going to add some additional challenges (Laser Skeet – blast a set of fast moving targets, Maze Race – be the first bot to reach the goal, Chip Chase – track down and collect wandering prizes) in addition to the standard “zap the other bot” exercise. That will mean some fairly big changes in the structure.

So I thought I’d show “classic” BC before I rip it apart. Comments not just welcome, but really really needed.

http://www.youtube.com/watch?v=hIlgrPfpzZc&feature=youtube_gdata_player

Original Post

After finally trying out the wonderful Cargo Bot, I got inspired to knock around my own drag and drop programming toy. Battle Chips is a new take on battling robot games going back to Robot Wars. It’s incomplete, but after a long day trapped in waiting rooms, I think I made good progress.

Now I need some suggestions for additional programming chips, ways to implement varied bot hardware, and a system for exchanging bots with others.

http://www.youtube.com/watch?v=hjFkfjxAKgc

2

The blurry video makes them hard to read, but the current chip codes are:

FORWARD
REVERSE
TURN RIGHT
TURN LEFT
FIRE LASER

BUMP [socket]
RADAR [socket]
DAMAGE [socket]

GOTO [socket]

The first five chips are simple actions. They cause the robot to move or fire it’s weapon.

The next three are sensors. They check a value and change program flow. For example, suppose you put a BUMP sensor in socket 4 of the chip board. When the program reaches that line, it checks to see if there has been an impact (with a wall or another robot) since the last time the BUMP sensor was checked. If true, then the next socket to be executed is the number set on the sensor chip. If the answer is false, then control moves on to socket 5. The RADAR sensor checks to see if there are other robots ahead (a good time to employ that laser) while DAMAGE let’s you know if your bot has taken a hit.

The last chip is a simple GOTO [socket] statement that does… exactly that, routes control to the designated socket.

A very simple program (the first one in the video) would look like this:

1 FORWARD
2 GOTO 1

A bot running this would move straight ahead until it hit a wall, then stop.

A better sense of flow would be a program like this:

1 FORWARD
2 BUMP 4
3 GOTO 1
4 TURN RIGHT
5 GOTO 1

This bot would got straight until it hit a wall. At that point, the bump sensor would pass control to socket 4, the bot would turn right, and then it would start to move again (meaning it would end up moving around the perimeter).

Is this enough variety to yield rich, surprising behavior in only 30 lines? I have no idea.

I’m open to suggestions on what other chips are needed, but if possible I’d like to not get any more complex than the single command plus socket number layout.

3

BACKUP?

4

This looks so cool! How about a close-range weapon that does more damage than the laser?

5

That’s brilliant Mark, really good.

A sensor for checking if another robot is within range (or line of sight) would be useful. As well as a command to target (orient towards) another thing.

6

@jlslate, there’s a REVERSE chip, though I’m finding it hard to make good use in my sample programs.

@Frad, what if the laser caused more damage at short range, rewarding bots that could close on their enemies?

7

@Simeon, the RADAR sensor essentially does a dry run for the laser, returning true if a current shot would hit an opponent (unless that opponent steps away before you fire). Hopefully it let’s you search for opponents and fire on target rather than just shooting blindly.

As I test these things, I’m finding it would actually make for shorter programs if the sensors responded to negative values… But I think that would be confusing.

8

Closer laser more damaging would be an equally interesting game mechanic. In terms of your laser and radar, unless there is a cost to firing and missing, why not just keep shooting rather than test to see if they are there with the radar?

9

“BACKUP” == “REVERSE” – who would of thunk?

I’m such a dummy. :">

10

@Fred, using the radar lets you deliver shots where they are needed. For example, the Bozo drone in the initial video spins and shoots without using radar. If you stand in front of it, it would hit you, but only 1 cycle out of 12 (4 shots + 4 turns + 4 goto). On the other hand, a fire routine that used radar could ping back and forth between radar and fire laser, delivering a shot 1 out of 2 cycles. You can also stack up fire commands, to do something like fire three times in a row after a radar hit.

The most successful design I’ve come up with so far starts off by running forward till it hits a wall, then it turns around and starts shuffling to the side, checking the field row by row for enemies. When it finds one, it fires twice and checks again. It keeps firing until the enemy is destroyed or moves. After that, it goes back to the shuffle-radar-shuffle routine.

The only bot I have hat bests it is a specialist – it rushes the wall, then starts looking for other bots hugging the wall.

I’m hoping to have a version up soon. Though boy, the code is a mess.

11

Wow - this is really nicely done! :slight_smile:

Oddly, I started playing about with the same idea myself a few weeks ago. I didn’t get much further than some basic movement though. Here’s as far as I got:

http://www.youtube.com/watch?v=su6J6RAjJSc

12

@Mark, I get it now - if the robot knows there is someone in front, it jumps to a ‘blast them away subroutine’… :slight_smile: rather than keep spinning.

I guess you could export the bots as short text files. How about loading them with http get?

Can’t wait to try it out! :slight_smile:

@frosty, impressive number of bots you have there! Almost like bacteria…

13

A counter would be nice - it would increment each time thru a loop, letting you trigger a different behavior after some time, ie “seek a corner, then wall fire - but after 25 no-target scans, move to another corner”.

This looks fun - looking forward to playing it.

14

Very interesting idea Mark. Maybe “turn” needs more granularity so that you can turn in increments of less than 90%? (so that you can shoot at a robot that’s far away)

Would love to have a play with it if you don’t mind sharing the code.

15

This is just awsome. I love it. Maybe a PAUSE for a certain amount of time? An angle to turn would also be a good thing to add. I think this is awsome. Out if curiosity - The sweet graphics for the background and blue bar in the middle - Is that Codea rendered or an imported image?
Thanks!
P.S. This is an app that needs Xcode export.

16

Random numbers to either repeat a step a random amount of times or to jump to a random step. RANDOM 0 3 would select 0, 1, 2 or 3. Not sure how you would incorporate it in with your other statements, though.

17

@Bortels – I like the idea of a counter, but I’m having a hard time of thinking of how to implement it without at least two numbers to set (loops and routing) which kind of breaks the current set up. Still, it probably should be done.

I like the movement seen in @Frosty’s demo. Which suggests that being able to set the turn rate would be a good deal… even if it would make testing radar and laser calls more complex. Right now I can do just a rectangle-overlap check between bot bases and the laser/radar. With other than 90 degree turns it would change to a ray intersect. I’m also a bit concerned about how to deal with wall impacts if turns are not 90 degree. Would it be difficult to get away from the wall with just a bump sensor? Would you need some other way to square your movement to the area?

Hmmm. Maybe there could be a heading sensor.

When I first did it, the movement was actually vector-based, with acceleration and deceleration. That led to beautiful little spiraling movements, and allowed you to move one way and fire in another, but it made it impossible to control the bot accurately. I had nifty curves-- and robots that pinged all over the place without good control.

Anyway, I’ll put this up for everyone to kick around as soon as I get through a few major bugs. Right now, saving and loading the bots is causing problems, radar and laser intersects (even the simple version) is giving me fits, and the tourney section is nonexistent.

But I hope to put something up tonight.

18

I was going to suggest finer angles - decided against it. The 90-degree restrictions is an interesting limitation, and might help from the old robo-war issue of robots not being able to find each other all of the time.

19

And here it comes… Warning, the code is a mess and there are a heap of classes. Ready you cut and paste…

https://gist.github.com/2468451 (part 1)

https://gist.github.com/2468466 (part 2)

lots of bugs. Lots of incomplete functions.

20

Yay! Thanks @Mark.