Battle Chips -- Updated

edited May 2012 in Examples Posts: 1,223

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.


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.

«13

Comments

  • Posts: 1,223

    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.

  • Posts: 176

    BACKUP?

  • Posts: 384

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

  • SimeonSimeon Admin Mod
    Posts: 4,837

    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.

  • Posts: 1,223

    @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?

  • Posts: 1,223

    @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.

  • Posts: 384

    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?

  • Posts: 176

    "BACKUP" == "REVERSE" -- who would of thunk?

    I'm such a dummy. :">

  • edited April 2012 Posts: 1,223

    @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.

  • Posts: 159

    Wow - this is really nicely done! :)

    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:

  • Posts: 384

    @Mark, I get it now - if the robot knows there is someone in front, it jumps to a 'blast them away subroutine'... :) 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! :)

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

  • BortelsBortels Mod
    Posts: 1,557

    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.

  • Posts: 447

    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.

  • Posts: 2,820

    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.

  • Posts: 176

    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.

  • Posts: 1,223

    @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.

  • BortelsBortels Mod
    Posts: 1,557

    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.

  • edited April 2012 Posts: 1,223

    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.

  • Posts: 2,820

    Yay! Thanks @Mark.

  • BortelsBortels Mod
    Posts: 1,557

    Wow, that's good.

    Collisions. If a bot runs into another, they should both take damage, and the moving bot should stop (or maybe push?).

    There's also part of me wants a dead bot to explode. :-)

  • Posts: 384

    Having fun playing this! Reminds me of the board game RoboRally!

  • Posts: 2,161

    Just downloaded it and am liking it very much. I'd been half thinking of something similar myself after playing Cargo-Bot, then decided it would be easier to install Scratch on the computer, and now this looks firstly better than anything I would have done and secondly on the iPad so more likely to get the kids interested.

    But I wonder how easy it would be to make a non-violent fork. It would need to replace the "destroy all other bots" by some other challenge. Anyone any ideas?

  • Posts: 159

    @Andrew_Stacey How about... The robots could find and collect resources, or traverse a garden to optimally plant seeds and water plants without trampling them, or clean a room?

  • Posts: 1,223

    @Andrew_Stacey I'd love that. In fact, some other focus... Collecting tokens, moving items from one place to another, would be welcome.

    I'll have another version up in a couple of hours. Scads of bug fixes. Some interface clean up. Tourney system still not implemented, but you can see now how it will work.

  • Posts: 2,161

    I like the idea of cleaning a room!

    Then once someone successfully programs a bot to do it, I just need to figure out some way to get that program into one of my kids.

  • Posts: 9

    For exchanging bots, how about generating a bar code and email to other user for import - bar code can easily be complex enough for your instructions.

    A bit fiddly though perhaps, but could fly.

  • edited April 2012 Posts: 1,223

    Version 0.20

    https://gist.github.com/2484258

    https://gist.github.com/2484269

    Roughly one scad zillion bug fixes, leaving only one blue jillion to go. Among other things, radar and laser fire now works when aimed down.

    As @Bortels suggested, robots now bump on collision (and their bump sensors are activated). There is also "heat" from exchanged laser fire and visible damage.

    The tourney screen is semi-functional, but doesn't actually launch matches. That's next.

    @blissap -- I love the idea of exchanging bots as images. I think I can code up something (not a standard bar code) that fits a bot on a postage stamp sized image. Could be a cute way to trade them.

  • Posts: 384

    @Andrew_Stacey, how about robots building something, like a car factory or something? Or bacteria battles... Violence on a very small scale... :)

    @Mark, thanks for keeping us updated!

  • Posts: 384

    The heat effect is great, @Mark. My bot survived your Killbot by reversing off the arena on to the UI... :)

  • Posts: 1,223

    @Fred, Ha! There's another bug to search out. I've fixed the order of execution problem with the radar so that it should now work correctly. Unfortunately, this also has the effect of making that %!&#! Smart Spinner into a real nuisance.

    Oh, and the damage sensor is working, so you can trigger a run for the hills routine.

    I'm thinking I need to reduce laser damage to give bots with more complex code time to react. Otherwise, the premium is on tiny shoot-first, think later programs, and unlike with Cargo-Bot, I don't think brevity should necessarily be the goal.

  • edited April 2012 Posts: 1,223

    Version 0.30

    Lots of bug fixes. New Random chip. Melee tourney now working.

    https://gist.github.com/2504980

    https://gist.github.com/2505005

    This is the first version where you can really put your ace bot through its paces.

  • Posts: 2,820

    Wow. Awsome. This is coming out on the App Store soon, right? This is starting to remind me of Scratch.

  • BortelsBortels Mod
    edited April 2012 Posts: 1,557

    It would be nice if forward took an argument for how far - I want my bot to seek a wall, then turn and drive away from it to avoid wallhuggers. I'm not sure how to do that without a variable forward, a counter, or a ton of forward commands.

    I'm also thinking interrupts - onDamage for example. You say "onDamage 10", and when you're hit, it jumps to 10 (which is presumably either evasion or return fire).

  • Posts: 1,223

    @Bortels, I've created a "Repeat" chip that repeats the preceding chip X number of times. So you can do something like go forward 10 times, or put a repeat behind a goto and execute a section of code a fixed number of times.

    It does seem to make for some more interesting behavior. It'll be in the next update.

    Thanks.

  • Posts: 384

    @Mark, like @Bortels I think measuring the distance to the wall would be fun, but also to other robots. That kinda gets us to registers or variables... Repeat sounds great.

  • Posts: 2,820

    Hi mark - I just really got down to playing with Battle Chips and designed a bot that can usually beat all the other bots. But I have suggestions:
    1. Better editor - Infinate scrolling, meaning Infinate chips. Also, you can drag chips between others.
    2. Custom angle rotation - So we can have more complicated bots. So say something like "turn left 63°".
    3. Check for bots within a radius - Basically checking for heat.
    4. Better number chooser - A number pad entry.
    5. Missle - Shoot a bullet that takes time to get to the destination.
    6. More bots - So I can have crazy battles.
    7. Automatically end round when one robot left - Self explanatory.
    8. Copy robot code to clipboard - Through the print window. Then when 1.4 comes out, the app can fetch a bot from a URL.
    9. Recording button - So you can record the battle.
    10. Full screen battles - So we can get the full effect of the battle.
    11. Little explosions - When someone is damaged or hit, a little explosion occurs.
    12. Drag a bot on another space to duplicate it - I really need duplicating bots.
    13. Add bump with wall or bump with player.
    14. Add a wait function - I don't know when we could use it, but it might be nice.
    15. Mines - So players can run into them.
    16. Get it on the app store.
    That's a lot of suggestions, but I have many ideas and I think these could be awesome. As you can tell, I think you should add a few more features and submit it to the app store possibly for .99¢. For the art, Simeon may be a trillion times better than me, but I'd be happy to do it if you need any.
    Thanks!

  • edited April 2012 Posts: 1,223

    @Zoyt. Wow, lots of good suggestions.

    I'm definitely intending to implement #7 & #12.

    To address #1, at some point I'd like to make it so you could take a whole board and reduce it to a chip, then let you drag that chip onto other boards.

    I really like the full screen battle idea. I hadn't even thought of that, but I think I will change the tourney mode so that it automatically goes to full screen. Which might make your "more bots" idea feasible.

    Suggestion 4 makes me sad. I was pretty taken with my little number slider.

    Oh, and I'm planning to extend the design screen so your bot can have different weapons, along with tougher armor, shields, and improved mobility.

    Finally, yes, I hop the app store is in the future for this app, but there's a lot of work to make that happen.

  • Posts: 41

    Mark, I would like your number slider better if it started at the current number. For example, I had a Goto 16 and now need to change it to 17, but when I long-tap it goes to 1, and I need to drag down again. If it went to 16 it would make it easier to slide a little bit down (or up) to change by one.

    (I'm still on .20, in case that matters.)

  • Posts: 2,820

    Thanks. About the number slider, how about just a drag to the chip you want like in Xcode when linking things. Then you can move that chip and it would stay linked. The number sliders were just a problem for me because of my lack of precision. Mabey just make bigger number targets for now. And I would love to help with this project in any way I can. I'm looking forward to every thing in the next updates!
    Thanks a lot!

  • BortelsBortels Mod
    Posts: 1,557

    What I'd like to do is tap the number, and then tap the step where it should go, at least for the goto.

    I love the program-in-a-chip. Subroutines!

  • Posts: 384

    In terms of the number sliders, like @Goatherd I think the slider should start at its current setting. But if you want to develop it, the ultimate would be tap for the reference like @Bortels suggested, a bit like Excel. I noticed the slots seem to remember the setting rather than the chip. If I move a chip, chances are it still needs to point at the same place, so remembering that would be good.

    Giving the player program on a chip effectively extends the scope to create complex behaviour by a lot, which will be great.

  • Posts: 1,223

    Version 0.40

    Uses Zoyt's suggestion for full screen tourneys. Also ends matches quickly when down to final bot. Bug fixes, graphic updates, adds the repeat chip, has a rough draft of the trading station for sharing robots as images.

    https://gist.github.com/2523657

    https://gist.github.com/2523992

  • Posts: 2,820

    Yes Mark! Your awesome!

  • Posts: 2,820

    Quoting Simeon:

    Battle Chips Beta
    You could use http.get to fetch them from a tweet, perhaps?
    Comment by Simeon 9:03PM permalink
    

    that would be great Mark!

  • Posts: 1,223

    New video in the first message showing "state of the project.". I'll link it here again just for expediency's sake.

  • edited May 2012 Posts: 688

    Ok please forgive my jumping into "ignorance corner" with both feet here.
    I'm trying to download this from the github links above, I get the fact that I have to create a new project and individually copy and paste the contents of the files (damm your downloading restrictions Apple), but I'm having a hellva job actually being able to perform a basic copy operation, if I do a long press on the text I get a copy box appear but if I try and resize it to cover all the code it just seems to snap to some random width, can anyone suggest an easy way for a noob to get in on the Battle Chips action??? :)

    Edit : nevermind got it sorted (dont know why i didn't think of opening a couple of windows in safari - doh ) :)

  • Posts: 179

    Hello, Mark. Very neat project, I have wasted some serious time on it already.

    While playing I had an idea that felt like an epiphany at the time, but which I have not, admittedly, fully hashed out in my brain: Turn-based mode.

    In turn-based mode, you would build a shorter program that runs, then your opponent's program runs, then yours again. Each chip would have a point value, like a turn or move would cost 1 point, while firing lasers might cost 3 points, etc. You could also make a "HEAL" chip costing even more points.

    As your program runs, each time a chip is executed, the points are subtracted from your "turn points," and when you run out of turn points, your turn is over and the opponent's program executes.

    For this mode, I might like a few additional sensors, such as one that checks my health or remaining turn points and executes chips as needed.

    Just an idea, but maybe it could add a whole different dimension to the strategy without too much extra coding effort.

  • Posts: 1,223

    Fiddling around with a new look. What do you think?

    http://db.tt/DNUKowr2

  • Posts: 384

    I like it @Mark, seems more modern.

  • Posts: 384

    Unlike my mobile Internet connection... Sorry!

Sign In or Register to comment.