Robot Rumble 2.0 - Robot Combat Simulator - Under Development

[cjbruce]

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

For this version of the game, I am looking to control movement through the physics engine, rather than directly via the transform.  I think a mobile version might benefit from simplified transform-based movement though -- it is further down on the list, but still definitely an option I would like to explore.  I'm pretty sure I could bust out a top-down version of a mobile game relatively quickly once the full PC version is done.

I'm hoping to put out an announcement on the game in the next week or two.  Still waiting on a few details... :)

[toAst]

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

i would imagine a system that would record the speed of both bots upon impact when it's a non-weapon hit and speed/damage upon weapon hit, maybe even including something like a 'sparks' system that would sway judge opinion in favor of those who generate more sparks from their hits, but also to make things fair for flippers and shovers a counter-point system that reverses judges favor through hazard impact and slams (flips, too) as well. sounds complicated but probably possible if fine tuned juuust right

[toAst]

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

For this version of the game, I am looking to control movement through the physics engine, rather than directly via the transform.  I think a mobile version might benefit from simplified transform-based movement though -- it is further down on the list, but still definitely an option I would like to explore.  I'm pretty sure I could bust out a top-down version of a mobile game relatively quickly once the full PC version is done.

I'm hoping to put out an announcement on the game in the next week or two.  Still waiting on a few details... :)

*record scratch* say whaat

do you understand how long i have been begging to see this happen? so many mobile developers out there and nobody has had even the slightest impulse to try a robot combat game for mobile devices! it has the potential to blow the **** up, i'd think! imagine the online multiplayer... /swoon

[cjbruce]

*record scratch* say whaat

do you understand how long i have been begging to see this happen? so many mobile developers out there and nobody has had even the slightest impulse to try a robot combat game for mobile devices! it has the potential to blow the **** up, i'd think! imagine the online multiplayer... /swoon

Again, I don't want to overpromise and underdeliver.  There already are at least two games out there, one of which is the original "Robot Rumble", that kinda-sorta do robot combat in a very gamified way.  The big thing that RA2/RA3 have that don't exist on mobile is the bot building aspect.  In my mind, this is *way* harder to do in 3D.  It is pretty simple to do in 2D, if you aren't worried about 3D physics.  But a 2D physics-based robot combat game is also a very different game.

My core competency is actually 2D mobile development, but my fear is that it is really difficult to do mobile controls in a satisfying way for a 3D robot combat game.  I already started the process in the original Robot Rumble for AirConsole, then spent another two months iterating on things until I had cut everything down to a 2-button control scheme (left button - go forward & turn left, right button - go forward & turn right, both buttons go backward, no buttons drive forward).  It isn't perfect, and I want to rethink everything in a proper 3D PC game first before trying to tackle mobile again.

Another option is to pretty much require a MFi/game controller if you want to play on your phone.  It might cut user base, but it would make the controls so much better.

[toAst]

i think the most intuitive way to allow controls to be handled would be to allow you to kind of 'drag and drop' useable buttons for your robot onto your screen kind of like how one would customize the button placement for a mobile emulator on their screen. but again that would take a certain amount of know-how to do (not trying to imply that you don't have that kind of know-how, but i have no doubt in my mind that creating a game in any respect for a mobile platform is no easy venture)

[cjbruce]

i think the most intuitive way to allow controls to be handled would be to allow you to kind of 'drag and drop' useable buttons for your robot onto your screen kind of like how one would customize the button placement for a mobile emulator on their screen. but again that would take a certain amount of know-how to do (not trying to imply that you don't have that kind of know-how, but i have no doubt in my mind that creating a game in any respect for a mobile platform is no easy venture)

This is an interesting idea!  Make the game about creating control schemes as much as creating robots...

Imagine someone puts seven motors/actuators on their robot, each controlled by their own button.  They would quickly find that they have created a huge driving challenge.  I wonder if this could be fun, or if everybody would quickly realize an optimal control scheme and stick with it.

[toAst]

ha! now that's some way to think about it, you're absolutely right though. especially considering you've only got so much space you can allow yourself for buttons on a mobile screen before you've run out of space to see what the hell you're doing, it does it's own work keeping outlandish and unrealistic design in check.

[cjbruce]

ha! now that's some way to think about it, you're absolutely right though. especially considering you've only got so much space you can allow yourself for buttons on a mobile screen before you've run out of space to see what the hell you're doing, it does it's own work keeping outlandish and unrealistic design in check.

I kinda want to prototype this today...

[maybeChrisJack]

I've found that everybody has their own preferred control scheme regardless of game. For controlling robots I've toyed with Tank-controls, Single-stick and even car-style (RT drives, LS steers). If it's something you can afford to develop people will likely enjoy having the option.

[cjbruce]

I've found that everybody has their own preferred control scheme regardless of game. For controlling robots I've toyed with Tank-controls, Single-stick and even car-style (RT drives, LS steers). If it's something you can afford to develop people will likely enjoy having the option.

I have a project that I played with back in february that let you switch between eight different standard controller options, so this is definitely something that could be put into a game.  I think it would be cool to try making a fully customizable smartphone button configuration that goes beyond what you could do with a physical controller.

[cjbruce]

ha! now that's some way to think about it, you're absolutely right though. especially considering you've only got so much space you can allow yourself for buttons on a mobile screen before you've run out of space to see what the hell you're doing, it does it's own work keeping outlandish and unrealistic design in check.

Here's an initial stab at a mobile-friendly robot control scheme builder.  I didn't have enough time to finish today, and will try to work out the bugs tomorrow:

http://nerdislandstudios.com/botlabprototype/index.html

Forces are not being correctly applied by the motors, but at least you can see how things might work.

To use:
1. Add two motors and drag them to the left and right sides of the robot.
2. Add as many buttons as you want and drag them to the gray control area at the bottom of the screen.
3. Tap on a button to select it.  Once it is selected, you can tap on motors to change that motor's control direction for that button.
4. The red "X" deletes the button.
5. The "hand" icon allows you to reposition a button.
6. When you are satisfied with the control scheme, tap the "Play Mode" text.
7. To go back into edit mode, tap the "Edit Mode" text.

[Starcore]

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

i would imagine a system that would record the speed of both bots upon impact when it's a non-weapon hit and speed/damage upon weapon hit, maybe even including something like a 'sparks' system that would sway judge opinion in favor of those who generate more sparks from their hits, but also to make things fair for flippers and shovers a counter-point system that reverses judges favor through hazard impact and slams (flips, too) as well. sounds complicated but probably possible if fine tuned juuust right

I would comment to not forget F= MA. While you can do shortcuts of how much damage a weapon does and assume a lot of things if one bot is much lighter than another and/or if you scale the weapons at all to the scale of the bot size then please don't forget to scale the amount of damage it can do in collisions, ramming and weapon contacts.

Also on your movement, if you do dot products to decide if a bot can move towards a foe or not, you are not taking into account if one or more motive wheels have been removed or damaged. If they planned for redundancy in having more than usually 4 wheels and that using dot product checks and the opponent is at nearly right angles will cause pretty strong errors in the movement.

Finally, the dot product method assumes always the same level which can be an assumption you can take if you plan on always having flat arenas but will be a problem if you later change mind to have ramps, bumps, multi level options.

Sorry if I have missed things in diving in midstream and seeing some possible issues.

Starcore

[toAst]

nice work with the control setup! that's pretty much exactly what i was talking about. i think that would be a perfect way to implement your control schemes in a way that's customize-able to each robot 

[cjbruce]

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

i would imagine a system that would record the speed of both bots upon impact when it's a non-weapon hit and speed/damage upon weapon hit, maybe even including something like a 'sparks' system that would sway judge opinion in favor of those who generate more sparks from their hits, but also to make things fair for flippers and shovers a counter-point system that reverses judges favor through hazard impact and slams (flips, too) as well. sounds complicated but probably possible if fine tuned juuust right

I would comment to not forget F= MA. While you can do shortcuts of how much damage a weapon does and assume a lot of things if one bot is much lighter than another and/or if you scale the weapons at all to the scale of the bot size then please don't forget to scale the amount of damage it can do in collisions, ramming and weapon contacts.

Also on your movement, if you do dot products to decide if a bot can move towards a foe or not, you are not taking into account if one or more motive wheels have been removed or damaged. If they planned for redundancy in having more than usually 4 wheels and that using dot product checks and the opponent is at nearly right angles will cause pretty strong errors in the movement.

Finally, the dot product method assumes always the same level which can be an assumption you can take if you plan on always having flat arenas but will be a problem if you later change mind to have ramps, bumps, multi level options.

Sorry if I have missed things in diving in midstream and seeing some possible issues.

Starcore

As a physics teacher, I couldn't forget F=ma if I tried! 

To be honest, I have a lot more game playing to do -- I just recently downloaded RA2 (where has this game been all of my life?) to see how everyone else has solved these problems.  My gut instinct is to use change in kinetic energy (1/2mv^2) for damage and change in momentum (mv) for relative movement.  I still consider myself really naive, as this question of how to handle damage has been solved many times before, so I will keep playing around.

I'm not quite sure I understand your statement about problems with using the dot product in the case of wheel damage.  In the original Robot Rumble, the dot and cross products were computed to determine an intended direction of motion, and torque was applied to the wheels to make that happen. If the intended direction was 90 degrees from the current robot heading, the dot product would be zero, while the cross product would be maximum and result in a maximum turning signal.  The system was self-correcting though.  In the case of a lost wheel, the dot and products would constantly adjust, changing the signal to each wheel to compensate so that an AI could still steer precisely toward its target, albeit not as quickly due to the loss of a wheel.

I totally get what you mean about more complicated arenas.  How did you solve the AI problem in this case?  Did you use an A* algorithm, or similar?  How did you handle multiple levels?

I am brand new to AI programming, so any tips would be greatly appreciated!

[Badger]

Kinteic energy applied would be the smartest move for a points system I would think. I personally think that you're planning too far ahead, though. IMO you should get a working prototype of 2 bots interacting in an arena before even worrying about anything else, like bot building, points systems or damage models. Walk before you run, so to speak.

[Asbestosstar]

Applied........

[cjbruce]

IMO you should get a working prototype of 2 bots interacting in an arena before even worrying about anything else, like bot building, points systems or damage models. Walk before you run, so to speak.

Considering that we just lost our Unity programming lead, you are probably right.

If we can't find someone to work in Unity, I'm confident that I can get Robot Rumble 2.0 up and running in Construct 2, but I was hoping to migrate to a development environment that is not nearing its End Of Life.

In either case, there are lots of scope and design decisions to make (Do we have multilevel arenas? Do we try to do realistic or gamified damage? Do we support online multiplayer? etc.)  It helps to sort these things out early on in the process.  For Robot Rumble we had the game working fairly quickly, approximately one day to get two robots moving and fighting.  The rest took an additional four months.

[Asbestosstar]

Can i be a proggramer dude?

[cjbruce]

Now available - playable 2D mockup!  Here is a link to the mockup:

http://nerdislandstudios.com/rr2D8-17-17/index.html

Over the past week I have been mocking up a new version of the game in 2D.  We still intend to build a 3D version, but this 2D version will allow us to try things out and rapidly iterate before committing to an idea and building all of the 3D artwork and gameplay.

Edit: The robots are controlled entirely by AI.  You can drag&drop them around the screen, but I wanted to see how things would play out with AI-only robots.  When the robot lab is built, you will be able to make new designs and AI rules.

[cjbruce]

Full disclosure: Thanks to help from @Starcore and others on the forum, I just recently realized that AI battles are a huge part of the RA2 experience.  I had assumed that people played RA2 because of PvP multiplayer (either local or online multiplayer), but realize that because of the robust AI built by the modding community, the game is now so much more than that.

This has changed my opinion of what Robot Rumble 2.0 should be.  Perhaps RR2.0 should be primarily about building AI bots that battle in tournaments.  AI should be an integral part of the Bot Lab, with screens dedicated to designing AI behavior.  What do you think?

Is AI design important enough to make it the central focus of the game?