Robot Rumble 2.0 - Robot Combat Simulator - Under Development

[cjbruce]

THE ALPHA BUILD IS FINALLY HERE!

https://robot-rumble.itch.io/builds

Check out our Discord!

https://discord.gg/tXwYay9

Robot Rumble 2 is a 3D robot combat simulation game currently under development by Nerd Island Studios, LLC.  The game is a labor of love by several members of the GameTechMods community, and we are excited to announce our public Alpha release during the live filming of BuggleBots 2018.  We are shooting for a release date of fall, 2019.  Join the conversation here on GameTechMods, follow us on Twitter at @robot_rumble, and most importantly, sign up to join the closed beta at www.robot-rumble.com.

Build in the BotLab: Create custom parts from scratch with our built-in 3D modeling tool, combine those parts with prebuilt components to build a robot, then use sensors and logic to design your robot's AI for battle!
Fight in the Arenas:  AI vs AI, AI vs Player, or Player vs Player in local multiplayer matches

[kix]

But... Will it run on Vulkan API?
JK
Actually, Awesome work. Hope to see this become next big robot figgting game.
Keep up the good work!

[Badger]

Very cool to see another person have a crack at this. Keep us posted, this is the kind of stuff that the majority of the forum would be super interested in!

[Tashic]

Nice work there! Very impressed.

It's cool that you are trying to make it a simulator, rather than just a game.

I see that the wheels are very smooth, how did you achieved that? Did you use one of the standard colliders or something else?

[cjbruce]

Since we don't have gaming rigs at school, I am attempting to achieve as much detail as possible while maintaining 60 fps gameplay.  Here are some screenshots showing some models I am working on.

AmpFlow A28-400 gearmotor (modeled in Blender, textured in Substance Painter):


Welded 3/4" square tubular steel frame showing 5/16" hex bolts and 1/8" steel plate (modeled in Blender):

[Tashic]

Oooo! Nuts and bolts too!

Nice ampflow model as well.

Loving the details :)

[cjbruce]

Nice work there! Very impressed.

It's cool that you are trying to make it a simulator, rather than just a game.

I see that the wheels are very smooth, how did you achieved that? Did you use one of the standard colliders or something else?

Thank you!

For the original version of the game (Robot Rumble 1.0), I used Oimo.js physics, which uses cylinder colliders and is very smooth.  I just started with Unity, and it looks like PhysX is the only option, so I am experimenting with different drive mechanisms.  So far I have tried the following:

1. Forces applied directly to the model when keys are pressed (not at all realistic).
2. The standard Unity wheel colliders + white frictionless "casters" in the corners.  This is the model that you see in the link.
3. Cylindrical mesh colliders with hinge joints.  I made 16-sided, 32-sided, and 64-sided meshes in Blender and pulled them into Unity to see how they behave.  32- and 64-sided meshes work fine, but aren't quite as smooth as the wheel collider.

I am also considering an improved wheel collider that ray-casts in multiple directions for each wheel, but for now I am pretty happy with solution #2.  It has really low overhead and works wheel for protected wheels.  For flippable robots I will need to take a different approach, but right now I am just worried about getting everything running.

My target platform will be desktop with game controllers (Xbox and PS).  I would like to get it running with the Spectrum DX6i controllers we use for our real robots.  Assuming I can get them working, I will post a "how to" for this so people can use the real controllers.  For now, the simulator is intended to be 2-player multiplayer and 1-player vs AI.  Since I'm working in Unity this time, I would like to export to as many platforms as possible, potentially even to mobile and AirConsole, though I would need to think a lot about control scheme for those.

[cjbruce]

Oooo! Nuts and bolts too!

Nice ampflow model as well.

Loving the details :)

Re: Nuts and bolts - Of course! :)  It might be a little crazy to try to include every little screw that we use in a real robot, but right now I am exploring the limits.

I just received permission from AmpFlow to use models and the AmpFlow logo in-game.  I'm hoping to get permission from the other component manufacturers as well.  Hopefully everything ends up looking and feeling like the real thing.

The big problem we have is that we don't have our own arena, so students have to learn how to drive on the day of the competition.  Inevitably, this doesn't turn out well.  The goal is to give students driving experience beforehand so that they aren't completely befuddled by the controls when their robot is turned around in an odd orientation.

[Tashic]

Thanks for the info!

I have tried as well to make a robot combat game, didn't go very far, but I did encounter the problem of the wheels, I used a method where I have the collision model of the wheel not completely fixed to the wheel itself, but I used a configurable joint to make it like a shock absorber radially, so it doesn't jump because of the not completelly smooth collision mesh.

But I'm sure you can find a much better and less messy solution than that!

I love the Idea of using the real controllers!

[cjbruce]

Thanks for the info!

I have tried as well to make a robot combat game, didn't go very far, but I did encounter the problem of the wheels, I used a method where I have the collision model of the wheel not completely fixed to the wheel itself, but I used a configurable joint to make it like a shock absorber radially, so it doesn't jump because of the not completelly smooth collision mesh.

But I'm sure you can find a much better and less messy solution than that!

I love the Idea of using the real controllers!

I think you might be overestimating my abilities! 

How much of an issue did you find the jumpiness to be?  Did you try increasing the number of sides?

I also found that adding sphere colliders as skids seems to reduce the jumpiness.  Apparently PhysX computes friction for every contact point, so as the number of contact points changes, the friction changes. Maybe this is the cause of some of the jumpiness?  Spheres only have one contact point, which I am thinking would smooth things out.

Also

[F1Krazy]

Wow. I'm working on a robot combat game prototype too, but this just blows mine out of the water in terms of graphics. I wish you luck!

[Asbestosstar]

unity is a good dev environment, i use it, I will check it out,maybe i will use it in a GTM event. Will the rumbles allow more bots that RA2?


EDIT:Looked at it, good start, cant wait to see more,Looks in lots of ways better that RA1 ,RA2 and almost RA3 graphic wise.
Also, nice , that may be the best online fighting game, there are some but none this style, You should also port to tablets, I only know 1 other bot fighting game that is inactive, I would love to see that on tablets.

Also, You can Make AI to make the other bots move with these simple lines of code if you want to try.

Transform tr_Player;
   float f_RotSpeed=3.0f,f_MoveSpeed = 3.0f;

   // Use this for initialization
   void Start ()
   {

      tr_Player = GameObject.FindGameObjectWithTag ("Player").transform; }

   // Update is called once per frame
   void Update ()
   {
      /* Look at Player*/
      transform.rotation = Quaternion.Slerp (transform.rotation , Quaternion.LookRotation (tr_Player.position - transform.position) , f_RotSpeed * Time.deltaTime);

      /* Move at Player*/
      transform.position += transform.forward * f_MoveSpeed * Time.deltaTime;
   }

[cjbruce]

unity is a good dev environment, i use it, I will check it out,maybe i will use it in a GTM event. Will the rumbles allow more bots that RA2?


EDIT:Looked at it, good start, cant wait to see more,Looks in lots of ways better that RA1 ,RA2 and almost RA3 graphic wise.
Also, nice , that may be the best online fighting game, there are some but none this style, You should also port to tablets, I only know 1 other bot fighting game that is inactive, I would love to see that on tablets.

Also, You can Make AI to make the other bots move with these simple lines of code if you want to try.

Sweet!  Thanks for the AI script!  I have been wondering how to handle identifying a particular game component.  I suppose player1 and player2 would have their own tags?

When you say "more robots", do you mean more robots that are pre-made and ship with the game, or are you referring to a user's ability to create and store more of their own creations?

In either case, I'm working as a solo developer in my spare time (an hour or two each day) right now, so I have to be really careful to make sure the scope of the project doesn't get too big.  The priorities are:

Priority One:
- A complete basic robot model (2 wheels, no weapon) that looks like the real thing.  At this point, this means a lot more 3D modeling and texturing (ESCs, batteries, wiring, wiring harness, cable management, etc.).
- Physics-accurate (or as accurate as possible) controls and feel for the basic robot.  This will take a lot of tweaking with the physics engine, and some work to get game controllers working in "tank tread", single-stick, and double stick controls.
- A complete basic arena with a 2-minute countdown timer (our real-life "Rumbles" are all two minutes long).
- An intelligent scoring system that attempts to model the (entirely subjective) judging at our actual competitions.  This might prove to be the trickiest part, as it is mostly based on how "exciting" a particular competitor is if no one is knocked out.  Does anyone have any ideas on how to do this?
- Music, sound effects, and arena lighting
- Game UI
- Enemy robot AI
- 2-player local multiplayer controls

Priority Two:
- Basic robot wheel customization: Where should the wheels be?  How many wheels?  What diameter? Which motor?
- Robot weapons: Horizontal vs vertical spinner vs drum vs wedge vs flipper?

Priority Three:
- Fully-configurable component placement: Which style of motor should we use? Where should the batteries be? Tubular vs bracket vs welded plate construction? Wiring? ESC placement?
- Location-based damage model: This isn't something we typically see a lot of in competition though, as robots are typically knocked out in unpredictable ways (a wire comes loose internally, a battery loses charge, an ESC gets jostled).  The only real weapon damage I have seen in our competition is that when someone hits someone else hard enough, their own weapon breaks.  It is exciting, but embarrassing too.  I don't think I have seen anyone penetrate armor enough to cause internal damage to a battery.
- Gamification: New arena types - Unrealistic gravity? Fire/water/wind, sloped arenas, other craziness?
- Online multiplayer (this is money-dependent, and I'm reluctant to incur monthly multiplayer server costs unless I am confident that the game can be self-sustaining)

Priority Four:
- Reimagining the simulation as a game for mobile/tablets/AirConsole/console

At the moment, Robot Arena doesn't have anything to worry about as the premier platform for what it does, but I would like to develop Robot Rumble to the point where it is both useful and fun to play.

In the end, I hope to simulate the feel of the real competition.  These YouTube videos show our students in our first two year's of competition.  They are the inspiration for this project:

[Asbestosstar]

Sweet!  Thanks for the AI script!  I have been wondering how to handle identifying a particular game component.  I suppose player1 and player2 would have their own tags?

When you say "more robots", do you mean more robots that are pre-made and ship with the game, or are you referring to a user's ability to create and store more of their own creations?

[/quote]
I think you would tag the everybody"Player" and only give the script to the AI players. So th'all kill each other. Did you test the lines i sent you?

[cjbruce]

Sweet!  Thanks for the AI script!  I have been wondering how to handle identifying a particular game component.  I suppose player1 and player2 would have their own tags?

When you say "more robots", do you mean more robots that are pre-made and ship with the game, or are you referring to a user's ability to create and store more of their own creations?

I think you would tag the everybody"Player" and only give the script to the AI players. So th'all kill each other. Did you test the lines i sent you?
[/quote]

Regarding tags:  Ahh!  Nice!  I'm not used to attaching scripts yet.

I haven't tried the script, because isn't it written for non-rigidbodies? 

I was planning to give AI robots the exact same control mechanism as the players, which means applying torque to the drive wheels, rather than directly modifying the robot transform.  In Construct 2 I did this with the following:

1. Forward/Backward acceleration: Compute a dot product between the AI robot's forward vector (world space) and the bearing to the target (world space).  If the dot product is positive, then apply equal torque to both wheels to make the robot go forward. If the dot product is negative, do not apply torque.  This means the target is behind the AI robot, and they should just turn but not drive forward or backward.
2. Left/Right steering: Compute a cross product between the two vectors.  Apply turning torque to each wheel according to the cross product. 
Also, check the dot product to see if it is negative.  If so, then the target is behind the AI robot, and we need to apply the maximum turning torque to get the AI robot around as quickly as possible.

[kaiser]

Someone give this guy a medal.

[cjbruce]

Someone give this guy a medal.

Thanks for the vote of confidence, but I don't want to overpromise and underdeliver!

I figure I need to get everything in the "Priority One" list done before October.  If that happens, then I should be in good shape to turn out an actual shippable product sometime in the next few years. 2 months to get the basic game working, then 2 years to polish it.  :)

[Badger]

Someone give this guy a medal.

Thanks for the vote of confidence, but I don't want to overpromise and underdeliver!

I figure I need to get everything in the "Priority One" list done before October.  If that happens, then I should be in good shape to turn out an actual shippable product sometime in the next few years. 2 months to get the basic game working, then 2 years to polish it.  :)

Just keep plugging away at it my dude, frequent updates are a must to keep projects like this from dying

If you ever need development help, many of the people on the forum have lots of knowledge and experience, and I'm sure they'd be happy to help.

[cjbruce]

Someone give this guy a medal.

Thanks for the vote of confidence, but I don't want to overpromise and underdeliver!

I figure I need to get everything in the "Priority One" list done before October.  If that happens, then I should be in good shape to turn out an actual shippable product sometime in the next few years. 2 months to get the basic game working, then 2 years to polish it.  :)

Just keep plugging away at it my dude, frequent updates are a must to keep projects like this from dying

If you ever need development help, many of the people on the forum have lots of knowledge and experience, and I'm sure they'd be happy to help.

Will do!  The students keep my honest, and I need to stay on track to make sure they have a working simulator in October.

As far as help goes, I would love to find an experienced Unity dev to partner with.  I have my own company, and am willing to go 50-50 on revenue.

[Asbestosstar]

You could use the part of my code for facing the player in you game and just have other animation do the walking.