Poll

What do you like doing most in RA2/RA3/robot combat games?

Building robots
Local single player battles with manually-controlled robots
Local multiplayer battles  with manually-controlled robots (PvP with controllers or a shared keyboard)
AI-only tournament battles
Other?  Please comment below.

Author Topic: Robot Rumble 2.0 - Robot Combat Simulator - Under Development  (Read 187681 times)

Offline cjbruce

  • Super Heavyweight
  • Posts: 963
  • Rep: 11
    • View Profile
    • Awards
Re: Robot Rumble 2.0 - Robot Combat Simulator - Under Development
« Reply #520 on: April 23, 2019, 06:19:25 AM »
What went well?
  • While the physics still need tweaking, you're off to a good start - already we're getting the kinds of big spinner hits that you don't normally see in RA2.
  • I find it amazing how, even with the limited parts we have currently, we're already seeing such a great diversity of bot types, and they're effective. Bull and Bocuma are great flippers, and RT 2.0 actually pulled off a perfect grab-and-lift on at least one occasion, something you just can't do in RA2.
  • While there were the occasional havoks, and at least one crash, the game seems a lot more stable than DSL. Even Obama Gaming's flails didn't cause any problems.

What was terrible?
I wouldn't say anything was terrible, but...

  • Component destructibility (or at least, loss of health when components are hit) needs to be a thing. It's trivial to surround your chassis with armour (or in Drone's case, weaponry) and make yourself invincible.
  • Tone down the damage taken from hitting the wall in the Test Arena. Right now it's more damaging than 99% of weapons.
  • Additionally, certain bots (Bocuma, Fait Accompli) seem to have an issue where they take damage from the wall even if they hit it with a component wedge instead of their chassis. Would be nice if that could get looked at.

There's probably more but it's 11pm and that's all my tired brain can think of.

1. I can't believe Obama Gaming actually (sort of) worked!  I have a strategy that I might try to rework the flail physics to prevent the flail from being so stretchy.  I have no idea if it will work.  Its also pretty low on the priority list.  Fixing spinners is a lot more important to me -- we need to get spinners right.

2. Component destructibility is a huge issue, and quite a challenge with the optimizations we made to make things performant.  If you guys are interested, I can post more details about how things were built and why this is a challenge, but for now know that we aren't going to release the game until we can figure out an acceptable solution.

3. There are multiple types of damage happening.  Any time a component accelerates above a certain threshold value it takes "acceleration" damage.  In this way, a chassis can take damage even when it is completely surrounded in armor. 

One problem is that the threshold is set too low (10 g's, I think currently).  I don't have any data on this, but I suspect most electronics IRL don't really have a problem until you get up around 50-100 g's, maybe more.  As a result, both wall collisions and spinners cause the chassis to shake itself too violently and cause self-damage. 

The problem is particularly bad when you have a rigidbody chain as follows: wall <-> spinner or wedge <-> chassis.  The resulting impulse gets to be huge as PhysX tries to resolve the collision.  We are using PhysX as the physics engine for the game, but the explosions we call "Havoks" result from these sorts of interactions between multiple physics rigidbodies all lined up.

Maybe the solution is to get rid of acceleration damage entirely.  I dunno.  I like the idea that impacts can shake an entire robot to pieces, but maybe it isn't worth it because there isn't a way to limit the forces involved when rigidbodies are aligned in such a way as to cause an "explosion".

Offline cjbruce

  • Super Heavyweight
  • Posts: 963
  • Rep: 11
    • View Profile
    • Awards
Re: Robot Rumble 2.0 - Robot Combat Simulator - Under Development
« Reply #521 on: April 23, 2019, 10:01:39 AM »
I cant really add what people have said, except one thing.
A timer, even a simple 180 second timer
This might require some sort of judging system to determine who wins if multiple robots are still running. "Who has the most health" isn't reliable, what with the walls causing damage - I could be the most aggressive and dominant robot and still lose because I took more damage from the walls. And of course, with indestructible components, it's possible for neither robot to sustain any damage at all. Then what?

The basic logic for a judging system is in place, though it isn't hooked up to arena yet.  Here's what I have so far:

1. Damage points: 1 point of damage = 1 point scored
2. Control points: points scored for every tick in which you are driving in a direction and your opponent's velocity matches your velocity
3. Aggression points: points scored for every tick in which you are driving toward your opponent
4. "King of the Hill" points: points for every tick you maintain control over a certain location in an arena

The 180-second game timer code is already in place, but again, no UI exists yet.

Offline cjbruce

  • Super Heavyweight
  • Posts: 963
  • Rep: 11
    • View Profile
    • Awards
Re: Robot Rumble 2.0 - Robot Combat Simulator - Under Development
« Reply #522 on: April 23, 2019, 10:51:30 AM »
I cant really add what people have said, except one thing.
A timer, even a simple 180 second timer
This might require some sort of judging system to determine who wins if multiple robots are still running. "Who has the most health" isn't reliable, what with the walls causing damage - I could be the most aggressive and dominant robot and still lose because I took more damage from the walls. And of course, with indestructible components, it's possible for neither robot to sustain any damage at all. Then what?
Atleast something simple for now, with cease instead of Player X wins, atleast for online events

Interesting.  I didn't think about doing "Cease!" instead of directly declaring a winner for an externally judged event.  Maybe an options menu that caters to either internally refereed (single player) or externally refereed (Parsec tournament) play?

Sorry for the newbie question, but should AI tournaments be determined by the AI, or an external referee?  Could the AI be good enough?  What if "damage", "control", and "aggression" were done in a reasonable way by the AI?

Offline WhamettNuht

  • *
  • Posts: 1302
  • Rep: 12
  • Robot Building Drag Queen
    • View Profile
    • Awards
  • Discord: WhamettNuht #1457
Re: Robot Rumble 2.0 - Robot Combat Simulator - Under Development
« Reply #523 on: April 23, 2019, 11:07:21 AM »
Sorry for the newbie question, but should AI tournaments be determined by the AI, or an external referee?  Could the AI be good enough?  What if "damage", "control", and "aggression" were done in a reasonable way by the AI?

It depends on how it can all be coded. I suppose if the AI was to 'judge' matches, 'Damage' could be determined by overall negative component HP caused on another robot, 'control' to be judged by stating areas in the arenas that would be ideally avoidable (such as hazards) and how often a robot drove over/near one of them, and 'aggression' to be judged by time/rate that a robot is near another or making contact. Since there are 3 criteria, the robot who scores most in 2 or all 3 criteria wins the fight. Just an idea though!
Damn I should probably put something fancy in this bit huh?

Offline Hoppin

  • I save GTM
  • *
  • Posts: 2017
  • Rep: 10
  • -rep TheRoboteer. "queermint"
  • Awards BOTM Winner
    • View Profile
    • Awards
  • Discord: Hoppin#0013
Re: Robot Rumble 2.0 - Robot Combat Simulator - Under Development
« Reply #524 on: April 23, 2019, 11:09:07 AM »
I cant really add what people have said, except one thing.
A timer, even a simple 180 second timer
This might require some sort of judging system to determine who wins if multiple robots are still running. "Who has the most health" isn't reliable, what with the walls causing damage - I could be the most aggressive and dominant robot and still lose because I took more damage from the walls. And of course, with indestructible components, it's possible for neither robot to sustain any damage at all. Then what?

Atleast something simple for now, with cease instead of Player X wins, atleast for online events

Interesting.  I didn't think about doing "Cease!" instead of directly declaring a winner for an externally judged event.  Maybe an options menu that caters to either internally refereed (single player) or externally refereed (Parsec tournament) play?

Sorry for the newbie question, but should AI tournaments be determined by the AI, or an external referee?  Could the AI be good enough?  What if "damage", "control", and "aggression" were done in a reasonable way by the AI?

Usually there's an external judge in the case of tournaments, but in a for fun muck around environment, the ai can determine it. It'll be about which direction you'll want to take imo. But worst case external judges can overrule the ai system
Things I did & done

Offline cjbruce

  • Super Heavyweight
  • Posts: 963
  • Rep: 11
    • View Profile
    • Awards
Re: Robot Rumble 2.0 - Robot Combat Simulator - Under Development
« Reply #525 on: April 23, 2019, 11:55:34 AM »
Hey! Absolutely loving the game as it is so far!

Just a few ideas and stuff I've had on how to make it absolute perfection (Apologies if I'm just spouting stuff that's already been advised/in progress!)
-In the bot builder, in addition to having the 'Snap' setting, I think it could also do with a user-variable for 'grid' size and rotation amount (To allow precise rotation of objects to be exactly 90degs, 45degs, 33.3degs, ect.)
-Some sort of 'Mirror' function... Maybe with the critical components (motors mainly) but especially with extras. Kind of like how in the old Bamzooki Creator you could place an object/limb onto the body and it would be automatically mirrored on the other side to make for easier, quicker building. Would also be especially helpful with the blueprint editor and future decal painter.
-With the blueprint editor, having the option to import vectors in the shape of a circle, triangle, and even the option to create curves would be very useful.
-The blueprint editor would also be a lot more effective with the ability to scale the vertices much like how you can scale them once they're rendered into 3d. I know it's possible to just move the vertices around but scaling would be beneficial with complex shapes and if the circles, triangles ect. got offered, would allow users to create shapes similar to that of, for example - Typhoon or Megabyte's shells. Also, smaller dots to represent the vertices for precision.

That's about all I can think of at the moment...
Hope this helps in some way! Please do keep up the amazing work as it is phenomenal!

1. Snapping already works in the Robot Workshop.  You can also type exact numbers by pulling out the menu arrow on the right side of the screen.  I usually pull out the numbers right away when I'm building.
2. Mirroring is an interesting idea.  I will let @tashic tackle that.  There is already a "duplicate" function, which when combined with manually setting an angle, will get you most of the way there, depending on symmetry.
3. Importing vectors is an interesting idea.  Making a shape in an .svg editor like Gravit Designer might be cool.  The ultimate solution is the RR2 Component Modding Tool, which will allow people to do whatever they want using whatever 3D tool they want.  My personal workflow will be Blender for modeling + Substance Painter for texturing -> RR2 Component Modding Tool -> RR2 Robot Workshop.

Offline cjbruce

  • Super Heavyweight
  • Posts: 963
  • Rep: 11
    • View Profile
    • Awards
Re: Robot Rumble 2.0 - Robot Combat Simulator - Under Development
« Reply #526 on: April 23, 2019, 12:44:49 PM »
This game is great and has some nice potential! but:


- I would  like to see a first person camera position. Nothing really major, but playing with the other camera positions just doesn't feel ideal to me, but then again, that's just me

-Flippers glitch a lot in the sumo arena

1. First person cameras are on the Trello board for us to look at again.  I tried it about a year ago, and it was totally unplayable due to how jerky the robot motion was.  Adding smoothing helped, but it was still nauseating.  I then spent some time with over the shoulder cameras, but it turns out these are extremely difficult to get right.  When it is done well (try the game called "Journey"), it looks completely effortless, but it might take a person months to get it to look right.  Depending on time, I might try to revisit it before launch.

2. What specifically was happening with the flippers in the Sumo arena?

Offline cjbruce

  • Super Heavyweight
  • Posts: 963
  • Rep: 11
    • View Profile
    • Awards
Re: Robot Rumble 2.0 - Robot Combat Simulator - Under Development
« Reply #527 on: April 23, 2019, 01:35:58 PM »
What went well?
Overall, the gameplay was fun and exciting. Mainly, the reason in my opinion is due to everyone's unfamiliarity with the state of the meta. This has allowed for people to experiment with designs, spinners like Gaullin, Grabbers like RT 2.0, flippers, like Bocuma. Even some of the wackier stuff like Obama Gaming and Mystic's new overhead disc spinner.

During the Gaullin and Bull fight if I recall correctly, Robo and I discussed about the wedge mechanics, in how they are more complex then they appear. This was lovely to find out, because it isn't just a simple "bolt wedglets onto it" like in Ra2.


I am so thrilled to hear this!  Getting rid of the tried and true "magic mobility" systems that most games use was a big gamble.  We had absolutely no idea whether just letting PhysX do its thing with spinning mesh colliders for wheels was a good idea, but it sounds like it has paid off, at least in terms of wedges.


Stability of the game engine was great despite some havocs and the odd crash, given the current status of the game, this was to be expected.
What was terrible?

Self damage is currently my big problem with the fights, on impacts, it appears you take too much damage to appear realistic. This is kind of an issue with vertical spinners. When they're consistently attacking an opponent, they'll be taking more damage to themselves than they deal out, this is usually because they're hitting the indestructible parts of the opponent, which I'll cover later. Another reason for this is if they're pushed into the wall. Robo was a victim of this a lot, just taking large amounts of damage by being bumped into the wall.

Definitely on the list!  I think the problem is that shaking (acceleration-based) damage occurs at too low of a threshold.  I will try raising it to 100 g's or so to see if that make things a little better.

Weight investments, personally I find that the chassis armour feels rather weak for it's weight investment, this could be due to the previously mentioned issue, my personal designs, the fact we have a weight limit of 110kgs which the game isnt designed for currently or all of the above.


Armor doesn't do anything yet, other than add weight. :)


The weapon motor power seems quite lacking, I'm aware that you're aware of this issue, so I don't plan to go into much detail. But it appears you need 50kg minimum to throw something currently, I'l like to see that minimum lowered, almost a fifth I'd say.

I put a speed limiter on motors to minimize crazy physics explosions.  In a few weeks we will be switching over to a new version of PhysX that supposedly improves performance for high-speed spinners.  Once we have switched over, I am hoping to put spinners up to more or less full speed.

Indestructible parts this right now is a large issue, and again, you're aware of this. Drone and Caliban were the main culprits of this in the tournament, along with RT 2.0. We've combated this temporarily with some rule changes for the new tournament which can be read here.


I think I can do a quick-and-dirty fix for component damage, where damage to everything gets transferred to the chassis.  Robots will go from indestructible to *very* destructible with this, so it might take a little tweaking.  It should solve the "Drone" indestructibility issue though.  In the released version of the game, exposing motors like that will be a terrible idea.  IRL motors tend to die immediately when they get nicked by a spinner.

Controlling of undercutters, Mystic's undercutter had some major issues with control, not sure if that's his design or because the game struggles with it. Just a heads up and something to look into.


Undercutters are really difficult to pull off.  By design, they skim the ground.  In a game physics engine, everything is a little more compliant than in real life, so it is highly likely that a wheel will be smushed enough to put the tip of the spinner on the ground, launching the whole robot.  I'm not sure how much fixing I can do for this without making things super derpy.


One of Robo's complaints was the pit that rose up after a certain period of time, I agree with this design flaw currently. It's a huge disadvantage for control bots. Continuing with some of the arena design issues I saw is that there should be some oota zones, it'd just be nice to have, maybe not Series 7 wall height arenas or all around the edge, I'd suggest how battlebots does it, in the corners. That'll stop  Ra2 Slapshot like stuff box rushing and oota'ing the opponent which is just boring and wont lead to interesting gameplay and fights. The rolling pin is odd, I think it needs to have it's orientation changed and given some more kick to it. You might have to re-position it to prevent it flinging robots into the pit if you do decide to take this route.


Maybe try the Warehouse arena?  It has a pretty low wall height.  It might be a good match for the current batch of flippers.


Stuck on arena objects, Bocuma and some other bots got stuck into the pit button, doesn't make for fun gameplay whilst it does reflect robot fights accurately. The wall is also easy to get stuck too, or atleast it's difficult to get away from, probably due to the wall's design.


Up until recently I had placed OOTA colliders along the wall.  My thought was that they weren't really necessary, because if someone got caught on a wall they would be counted out anyway.


Batteries and control boards, these currently don't effect the robots and aren't actually needed for them to function.


Not yet.  Batteries definitely need to be a thing though.  A robot should be able to run at varying voltages, corresponding to various torque/speed characteristics for each motor.  Smaller motors will have lower voltage limits.

I'm not sure about ESCs and receivers though.  It might be that adding them is too much detail.  Thoughts?


A question I have, is where would I be able to locate the folder for pre-made custom components on Windows? An idea I had was to import CAD files into that folder and add them in, is this a possibility?


I like the way you think!!!  :beer:

Unfortunately, the Unity game engine doesn't play nicely with importing 3D models and textures at runtime.  We are planning to sidestep this by creating a RR2 Component Modding Tool project in Unity and placing it on GitHub for people to download.  The tool will be its own Unity project and allow you to make whatever crazy thing you want as a fully textured 3D model, then pull it into the game to be used as a robot component.

It doesn't work yet.


Overall, this game is great so far. Like I've said before, I'm enjoying it more than Ra2 and whilst I've described more negatives than positives, the positives have a much bigger impact on the overall player experience.

Offline F1Krazy

  • Put me on a pedestal and I'll only disappoint you
  • Super Heavyweight
  • Posts: 920
  • Rep: 4
  • Tell me I'm exceptional, I promise to exploit you
    • View Profile
    • Awards
  • See profile for gamer tags: Yes
Re: Robot Rumble 2.0 - Robot Combat Simulator - Under Development
« Reply #528 on: April 23, 2019, 04:33:29 PM »
I put a speed limiter on motors to minimize crazy physics explosions.  In a few weeks we will be switching over to a new version of PhysX that supposedly improves performance for high-speed spinners.  Once we have switched over, I am hoping to put spinners up to more or less full speed.
My DSL Showcase


Offline Badger

  • Permanent Artifact
  • Giga Heavyweight
  • Posts: 6318
  • Rep: 3
  • I wish to be with my people
  • Awards BOTM Winner Donated money for site hosting 2019
    • View Profile
    • Awards
Re: Robot Rumble 2.0 - Robot Combat Simulator - Under Development
« Reply #529 on: April 23, 2019, 04:43:06 PM »
You mentioned that the max speed of spinners is limited by the refresh rate of the physics engine (or something to that effect), which in turn is limited by the minimum spec hardware that you want the game to run on. As a compromise, would it be possible to put a slider for physics refresh rate in the options, so those with more powerful hardware can put that hardware to use to improve the gameplay?
also lol at most toxic guy around calling others out on this sh**
Google Drive with my newer bots

Offline cjbruce

  • Super Heavyweight
  • Posts: 963
  • Rep: 11
    • View Profile
    • Awards
Re: Robot Rumble 2.0 - Robot Combat Simulator - Under Development
« Reply #530 on: April 23, 2019, 04:58:08 PM »
You mentioned that the max speed of spinners is limited by the refresh rate of the physics engine (or something to that effect), which in turn is limited by the minimum spec hardware that you want the game to run on. As a compromise, would it be possible to put a slider for physics refresh rate in the options, so those with more powerful hardware can put that hardware to use to improve the gameplay?

Possibly.  I haven’t tried adjusting physics tick rate at runtime.  I can look into it though.

PhysX 3.4 supposedly does some nifty interpolation for rapidly spinning objects that allows for much finer collision checking for rapidly spinning objects.  Hopefully it will make high speed spinners possible without having to significantly increase the tick rate for the entire physics engine.  Physics doesn’t multithread well, so high powered machines don’t tend to have significant advantages over lower powered ones.  I’m hoping that the new PhysX will solve the issue entirely.  Fingers crossed!

Offline Badger

  • Permanent Artifact
  • Giga Heavyweight
  • Posts: 6318
  • Rep: 3
  • I wish to be with my people
  • Awards BOTM Winner Donated money for site hosting 2019
    • View Profile
    • Awards
Re: Robot Rumble 2.0 - Robot Combat Simulator - Under Development
« Reply #531 on: April 23, 2019, 05:21:54 PM »
You mentioned that the max speed of spinners is limited by the refresh rate of the physics engine (or something to that effect), which in turn is limited by the minimum spec hardware that you want the game to run on. As a compromise, would it be possible to put a slider for physics refresh rate in the options, so those with more powerful hardware can put that hardware to use to improve the gameplay?

Possibly.  I haven’t tried adjusting physics tick rate at runtime.  I can look into it though.

PhysX 3.4 supposedly does some nifty interpolation for rapidly spinning objects that allows for much finer collision checking for rapidly spinning objects.  Hopefully it will make high speed spinners possible without having to significantly increase the tick rate for the entire physics engine.  Physics doesn’t multithread well, so high powered machines don’t tend to have significant advantages over lower powered ones.  I’m hoping that the new PhysX will solve the issue entirely.  Fingers crossed!
Actually, single thread performance is probably the biggest differentiator between laptops and gaming desktops. Most modern laptops have quad cores, as do most gaming PCs (over 55% of steam users are on a quad core system), however laptop CPUs are constrained by thermal/power limitations to low clock speeds, whereas desktop CPUs can boost to over 5GHz (depending on the exact chip).

It's good to hear that there's an inbuilt solution to high RPM collisions, the future is looking bright for this game
also lol at most toxic guy around calling others out on this sh**
Google Drive with my newer bots

Offline cjbruce

  • Super Heavyweight
  • Posts: 963
  • Rep: 11
    • View Profile
    • Awards
Re: Robot Rumble 2.0 - Robot Combat Simulator - Under Development
« Reply #532 on: April 23, 2019, 07:45:33 PM »
You mentioned that the max speed of spinners is limited by the refresh rate of the physics engine (or something to that effect), which in turn is limited by the minimum spec hardware that you want the game to run on. As a compromise, would it be possible to put a slider for physics refresh rate in the options, so those with more powerful hardware can put that hardware to use to improve the gameplay?

Possibly.  I haven’t tried adjusting physics tick rate at runtime.  I can look into it though.

PhysX 3.4 supposedly does some nifty interpolation for rapidly spinning objects that allows for much finer collision checking for rapidly spinning objects.  Hopefully it will make high speed spinners possible without having to significantly increase the tick rate for the entire physics engine.  Physics doesn’t multithread well, so high powered machines don’t tend to have significant advantages over lower powered ones.  I’m hoping that the new PhysX will solve the issue entirely.  Fingers crossed!
Actually, single thread performance is probably the biggest differentiator between laptops and gaming desktops. Most modern laptops have quad cores, as do most gaming PCs (over 55% of steam users are on a quad core system), however laptop CPUs are constrained by thermal/power limitations to low clock speeds, whereas desktop CPUs can boost to over 5GHz (depending on the exact chip).

It's good to hear that there's an inbuilt solution to high RPM collisions, the future is looking bright for this game

You might be right -- a faster CPU might allow us to double or triple the overall tick rate.  400 fps is fast, but 1000 fps is just a crazy psychological barrier. :) 

Check out the "Speculative continuous collision detection" blurb in the blog post below:

https://blogs.unity3d.com/2018/11/12/physics-changes-in-unity-2018-3-beta/

We haven't upgraded yet, but are planning to do so once Unity comes out with their 2018.4 LTS release.  I'm hoping this comes sometime in the next few weeks so that we can play with it before the Bugglebots Alpha Build (BAB???) on May 25th.

Offline UberPyro

  • Lightweight
  • Posts: 205
  • Rep: 6
  • Well, here goes.
  • Awards GTMCS Division Winner
    • View Profile
    • Awards
Re: Robot Rumble 2.0 - Robot Combat Simulator - Under Development
« Reply #533 on: April 25, 2019, 12:22:06 PM »
For the AI:
I need some more time to think about it, but off the top of my head here are some of the things I would like to see included:

Some way to know the approximate dimensions / reach of myself and my opponents
Time since my last collision with each other bot
Distance from and angle to each wall of the arena

I haven't looked at the new botbuilder recently but I think smartzones are important and so we need a way to check each of them
Normally distance to each robot is nice to have but that can be calculated from the x, y, z coordinates

There was another game called roboforge which had a well done AI system which I could probably refer to for more ideas, but its super old and I think has trouble running on newer computers.
I'll post more when I think of them.

Offline cjbruce

  • Super Heavyweight
  • Posts: 963
  • Rep: 11
    • View Profile
    • Awards
Re: Robot Rumble 2.0 - Robot Combat Simulator - Under Development
« Reply #534 on: April 25, 2019, 01:03:32 PM »
Great feedback here!  Thank you!

Some way to know the approximate dimensions / reach of myself and my opponents

I need to think about this a bit.  Right now I have the type of component and the health on each component of our own robot, but not the local position/reach.  I thought that since each robot would have its own custom AI code, it would be easy enough to adjust the values, but you are right in that it might be better to have AI code that adjusts itself to each new robot and doesn't require manual tweaking.

Time since my last collision with each other bot

This existed in RA2.  I wasn't quite sure how I would use it, so I left it off, but I can definitely include it if we need it.

Distance from and angle to each wall of the arena

In RR2, "walls" aren't explicitly defined.  Any object in the scene (wall, crate, spinner, fence, stairs, the side of a ramp, etc.) can be a navigation obstacle. 

Arenas have predefined navmeshes that are computed once all of the obstacles are placed in the scene.  I am relying on Unity's built-in NavMesh system to do this.

In addition to the arena's NavMesh, "hazards" can also be placed in the scene.  These are things that are not robots, but explicitly cause threats to robots, such as Out of the Arena colliders, arena spinners, lava pits, etc.

The AI system receives inputs from each of these differently:

NavMesh - A method exists that returns a list of (x,y,z) waypoints when given a destination from the robot's current position.

Arena Hazards - A method exists that returns the location (x,y,z) of the closest point and the center point of the nearest hazard.

I haven't looked at the new botbuilder recently but I think smartzones are important and so we need a way to check each of them
Normally distance to each robot is nice to have but that can be calculated from the x, y, z coordinates

Once smart zones are made available in the workshop, they should be fed into the AI.  We don't have them available in the workshop yet.  The AI code is already written to include basic smart zone information though.

Distance between robots can be computed because you can get a list of all of the robots in the scene.  By default, the gets a list of waypoints to the nearest robot, then drives toward getWaypoints[0].

There was another game called roboforge which had a well done AI system which I could probably refer to for more ideas, but its super old and I think has trouble running on newer computers.
I'll post more when I think of them.

Nice!  Apanx also mentioned robocode, which looked like a good place to mine for ideas.



Offline kix

  • RR2 dev
  • *
  • Posts: 3452
  • Rep: -3
  • H
    • View Profile
    • Awards
Re: Robot Rumble 2.0 - Robot Combat Simulator - Under Development
« Reply #535 on: April 25, 2019, 05:01:47 PM »
One of Robo's complaints was the pit that rose up after a certain period of time, I agree with this design flaw currently. It's a huge disadvantage for control bots. Continuing with some of the arena design issues I saw is that there should be some oota zones, it'd just be nice to have, maybe not Series 7 wall height arenas or all around the edge, I'd suggest how battlebots does it, in the corners. That'll stop  Ra2 Slapshot like stuff box rushing and oota'ing the opponent which is just boring and wont lead to interesting gameplay and fights. The rolling pin is odd, I think it needs to have it's orientation changed and given some more kick to it. You might have to re-position it to prevent it flinging robots into the pit if you do decide to take this route.

Maybe try the Warehouse arena?  It has a pretty low wall height.  It might be a good match for the current batch of flippers.


Yeah about that. I was thinking about using it for my next tournament, but problems are apparent as it can be witnessed in this video:

Sorry about poor quality. OBS was a pita so i had to lower bitrate

Offline cjbruce

  • Super Heavyweight
  • Posts: 963
  • Rep: 11
    • View Profile
    • Awards
Re: Robot Rumble 2.0 - Robot Combat Simulator - Under Development
« Reply #536 on: April 26, 2019, 09:17:57 AM »
One of Robo's complaints was the pit that rose up after a certain period of time, I agree with this design flaw currently. It's a huge disadvantage for control bots. Continuing with some of the arena design issues I saw is that there should be some oota zones, it'd just be nice to have, maybe not Series 7 wall height arenas or all around the edge, I'd suggest how battlebots does it, in the corners. That'll stop  Ra2 Slapshot like stuff box rushing and oota'ing the opponent which is just boring and wont lead to interesting gameplay and fights. The rolling pin is odd, I think it needs to have it's orientation changed and given some more kick to it. You might have to re-position it to prevent it flinging robots into the pit if you do decide to take this route.

Maybe try the Warehouse arena?  It has a pretty low wall height.  It might be a good match for the current batch of flippers.


Yeah about that. I was thinking about using it for my next tournament, but problems are apparent as it can be witnessed in this video:

Sorry about poor quality. OBS was a pita so i had to lower bitrate

Ahh.  The overwhelming power of the arena spinner.  We can work on that.

I think the issue is that the arena spinner is treated as a kinematic rigidbody, meaning we are directly setting the orientation of the spinner every frame, instead of letting the physics system handle it.  This means that the spinner effectively has an infinite mass, and everything that it collides with as it spins is going to go flying away uncontrollably -- there is no "give" when it hits.  This should be a relatively easy fix, just swapping it out with a regular old hinge motor attached to the ground.

While we are at it, we might just have to add the Motenergy ME0909 to the game. :)

Offline kix

  • RR2 dev
  • *
  • Posts: 3452
  • Rep: -3
  • H
    • View Profile
    • Awards
Re: Robot Rumble 2.0 - Robot Combat Simulator - Under Development
« Reply #537 on: April 26, 2019, 10:31:14 AM »
No not only that. There is also a problem where floor break and oota bots, like in the video

Offline cjbruce

  • Super Heavyweight
  • Posts: 963
  • Rep: 11
    • View Profile
    • Awards
Re: Robot Rumble 2.0 - Robot Combat Simulator - Under Development
« Reply #538 on: April 26, 2019, 01:05:18 PM »
No not only that. There is also a problem where floor break and oota bots, like in the video

By any chance was the game running slower than normal when you recorded this?  The Warehouse arena shouldn’t be any different than the Test Arena, but if the game was having trouble keeping up with physics, that would explain the rigidbodies penetrating too far, then exploding outward to resolve the collision.

Offline kix

  • RR2 dev
  • *
  • Posts: 3452
  • Rep: -3
  • H
    • View Profile
    • Awards
Re: Robot Rumble 2.0 - Robot Combat Simulator - Under Development
« Reply #539 on: April 26, 2019, 01:44:31 PM »
No not only that. There is also a problem where floor break and oota bots, like in the video

By any chance was the game running slower than normal when you recorded this?  The Warehouse arena shouldn’t be any different than the Test Arena, but if the game was having trouble keeping up with physics, that would explain the rigidbodies penetrating too far, then exploding outward to resolve the collision.
No game is running perfect, it happens off recording too