Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - cjbruce

Pages: 1 ... 26 27 28 29 30 31 32 [33] 34 35 36 37 38 39 40 ... 49
641

Its a little impractical, but is something like this what you had in mind?


Not quite... I was thinking more along the lines of how a lot of four wheel drive robots work, with two motors connected to two sets of belt systems, in turn powering four wheels in parallels of two. (I could draw up a quick diagram if that helps??)

I love seeing what you did there though! It's gonna be perfect for drum spinners and dual vertical spinners!

Gotcha!  Here's the BattleKits Middle Weight configuration:

http://www.battlekits.com

I just tried it, and the system isn't set up to do that yet, but @tashic tells me that it is on his list of things to make work.

In this version, if a pulley is attached, it can be the only thing attached to a motor.

642
Not gonna lie, I was really hoping for some sort of belt drive and you guys have more than delivered once again! Cannot wait for the next build!

Out of curiosity - can the pulley system be 'doubled up' to potentially create two shafts powered by one motor? (For example, two wheels powered by the one motor)

Its a little impractical, but is something like this what you had in mind?

TwoWheelsAttachedToOnePulley.png


 


643
Nice! A new build incoming! That belt drive should make it a lot easier to build spinners than it currently is. Any other changes we can look forward to?

1. Driving.  Everything has to drive well and believably, from beetleweights to lightweights, to heavyweights.  Botlab and premade robots.  Its been a challenge to get everything working well across all of the weight ranges, particularly with spinners that aren’t quite balanced that throw robots into a wobble.  My first priority on this build is to clean everything up and make everything drive well.

2. Now that the spinner blur works, I can finally get to a proper kinetic energy-based damage system that doesn’t rely on the existing physics system.  It was a big challenge to compute the volume of revolution for a user-defined weapon, but it should make it possible for you do use something like the Spinner Damage Excel spreadsheet http://www.brjackets.com/robotics/files/spinner%20spreadsheet.xls to compute weapon energy for use in the game.

644
I believe so, but we would need to check with @tashic.  I’m not in front of the computer now, but I can try when I get home.

645
That should be nice and simple.  Just need to come up with a convincing visual for a thrown or snapped belt.

646
Neat. Will you be able to customize the lenght of the belt or is it preset like in DSL?

Good question.  See the red, green, and blue control handles?  You can pull the secondary pulley around and it will stretch the belt automatically to adapt to the new position. 

The pulley workflow goes as follows:
1. Place a motor.
2. Attach a pulley to the shaft of the motor.
3. Stretch out a second pulley from the first pulley.
4. Attach something to the shaft of the second pulley.
5. Test the motor/pulley system and adjust the pulley size ratio as necessary for the appropriate torque/speed.

With this system you should be able to create either a high speed spinner or a high torque lifting arm.

647
Oh yeah.  Spinner high speed blur is now a thing too.

648
 Here’s Phönix with the new belt drive system:

904F32F7-85C7-4D6B-967A-3782D3BA999A.png

649
A quick teaser for the next build:

 
62AF49A5-5723-4381-8FDA-D6B50EC84AD8.jpeg

650
I think the one thing missing - and I keep forgetting to bring this up - is some sort of "green-screen" function, so we can take screenshots of our robots in front of a blank background, like we can do in RA2. Once we have that, we can start making proper splashes for our RR2 builds.

Doesn't have to be anything fancy, could be just a "Greenscreen" toggle in the Bot Lab that replaces the workshop background with a solid colour.
That should definitely be something to add in the next build. I could see some cool stuff coming from that.

I like it too.  I will put it on the Trello list.  We have a bunch of high priority stuff happening right now (new driving system, flippers), but we can probably squeeze in a button to disable the renderers for everything except the robot in the workshop.

651
Should we have a BOTM for rr2?

Up to you guys.  Do you feel like the game is mature enough?

We are going to be making some massive breaking changes over the next few months...

652
Judges decision

Ah!  Thanks!

I think we need a scoring system for 2 primary reasons:

1. It is a way to build tension and excitement as you see one robot pulling ahead of another.
2. In single player or AI vs AI games, it is needed to determine the outcome of non-KO fights.

For me, the best part of the original Robot Rumble was watching the pips move as someone went on a particularly long scoring run, upsetting the leader.

653
Idk what to feel about the in built JD system in game tbh
 I think I still prefer the one where people made it themself as on any other robot combat game before RR2. Also for aggression, is it basically tied with control, or will you take other factor into consideration, like the controlled bot trying to force itself against the opponent even if being controlled, or trying to use their weapon, like bringing down their saw into the opponent?

Pardon my ignorance, but what does "JD" stand for?

654
Or even simpler: A robot gains control points by moving in the same or opposite direction it is facing, and loses points by moving in a direction perpendicular to the direction it is facing.

A stationary robot doesn't gain or lose control points.

This approach would favor driving at an enemy or away from an enemy, and would penalized getting shoved sideways.

655
If you choose to judge controll by tge time wheels have touched the ground keep in mind that there are walkers also no wheels at all. Also bots like pussycat have wheels not touching the ground on purpose

Perhaps a robot is "being controlled" if it is losing a driving battle:

The "controlling robot" is giving driving inputs in a direction, and the "controlled robot" is moving in that direction instead of the direction it is trying to move in.

"Driving Direction" = the direction the robot is facing * its "drive" signal

656
One thought is to do something like a sideways stacked bar graph that is constantly updated throughout the fight.  Image that there were 4 robots, "A", "B", "C", "D"

Damage: AABBBBBBBBBBBCCCDDDD
Control:  AAAAAAAAAAAABBCCCDDD
Aggression: AAAAAAAABBBBBCCCDDDD

In this case, B did the most damage, but A wins on control and aggression.

Too complicated?

The original "Robot Rumble" AirConsole game just had a pip for each robot.  Whoever's pip was on the top had the current highest score, and the pips would constantly swap throughout the fight.

657
*sheepish*

Thank you for the reminder about the RA2 tournaments.  I feel like a dunce. 🙂

Good suggestions regarding control.  They should be easy enough to implement.  Should a control score start at zero and be able to go negative?

658
Getting the smaller weight classes feeling good is going to be my focus over the next week or so.  In the current build, we are using the same drive system that has worked okay for heavyweights.  It doesn’t work for beetleweights.  I have a new drive system in mind that should be super smooth and responsive for all weight classes.  I tested an early prototype a few months ago that showed promise.  I’m confident I can get it working.  It will just take a little time.

@tashic is on the scaling issues.

Also, we don’t have small batteries or ESCs yet.  I have been leaving those out when I build a robot in game.  They will come!  I promise!  My target date for these is the beginning of September, as that is when I need to explain to my students what an ESC is, and why you need them in your robot.

659
Is there anyone here who has judged a robot combat event?  We just had our post-Bugglebots debrief and we were talking about how to do scoring in game.

Damage - Already done, we just need to display it
Aggression - Compute dot product of velocity vector and normalized displacement to other robot.  The result should give the amount of time that a robot is driving toward its opponent.
Control - ???

How does one measure "control"?  This one is super-duper subjective.  Any thoughts?

660
Not really.  Its mostly tribal knowledge right now, as we have been actively changing a lot of things for the past year.

In general:

1. Design a chassis.
2. Add motors.
3. Stick stuff onto motors.
4. Set up your controls for the motors.  You probably need to have at least one "Left" and at least one "Right".  The other thing that we've found is that you need to click the "Reverse Direction" on each motor.  This is something we still need to sort out.

What are you trying to build?

Pages: 1 ... 26 27 28 29 30 31 32 [33] 34 35 36 37 38 39 40 ... 49