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 ... 31 32 33 34 35 36 37 [38] 39 40 41 42 43 44 45 ... 49
741
« on: April 13, 2019, 09:22:41 AM »
I've downloaded the alpha now and toyed around a little bit. Looks like good fun with quite some building options and freedom. First bot I made might be a bit too light or something? I dunno. Sometimes when just driving forward it decides to turn on its own.
I do wonder... Why when I choose to make a new bot was there some axe bot being spawned in the area, that could even be controlled there?
Yeah there is Royal Bobby (axebot)
Also turn on motor braking for drive, its a godsend
Also, what do you guys think of doing electronic stability control to help drive in a straight line for keyboard control? It isn’t hard to implement, but is it too much?
742
« on: April 13, 2019, 08:07:33 AM »
I've downloaded the alpha now and toyed around a little bit. Looks like good fun with quite some building options and freedom. First bot I made might be a bit too light or something? I dunno. Sometimes when just driving forward it decides to turn on its own.
As far as the robot feeling too light, I’m planning to go back and look at physics again once everything is working in the botlab. The goal is to be able to support all of the real-life weight classes, from antweight to super heavyweight. It is going to take some serious tuning to get it right. The single player game needs to feel like you are fighting in real-life tournaments: Bugglebots, Motorama, Sparkfun AVC, etc. There is a lot of physics “feel” work that needs to be done over the summer to meet this goal.
743
« on: April 12, 2019, 08:28:27 PM »
Well not even a full day and we got a new type of flipper:
Wowsers! That is effective! Nice work.
744
« on: April 12, 2019, 01:25:01 PM »
Oh yeah... Double post, but uhh...
WELL DONE!!!! So awesome! I had no idea this was even a thing! I take it that this is Parsec? Is there something I can do to make it work better?
745
« on: April 12, 2019, 09:34:33 AM »
...then how do you build spinning drums, without exposing the motor?
Without gears or pulleys, you can't accurately replicate robots like Minotaur (drum spinner) or Carbide (bar spinner). Pulleys and pneumatic systems are on our Trello board to do list though.
746
« on: April 12, 2019, 09:11:24 AM »
Here's what I've been doing.
[ Quoting of attachment images from other messages is not allowed ]
[ Quoting of attachment images from other messages is not allowed ]
[ Quoting of attachment images from other messages is not allowed ]
How to export bots?
Those look really good!
Do the gears actually transfer motion?
Seconded! Gears are decorative. They have colliders so things will bounce off of them, but they don't transfer torque.
747
« on: April 12, 2019, 05:51:14 AM »
Didnt think i was gonna do a double post, but oof
(Image removed from quote.)
Well done on the eyes! I was worried that people wouldn't be able to do decorations without a fully functional painter tool, but I love the way you got around the limitation.
748
« on: April 12, 2019, 05:48:56 AM »
Maybe make an exports/imports fooder, and add that function too?
Its simpler than that now. Any .RR2Bot file that is in the /Robots folder will be loaded by the game automatically. No need to import or export.
749
« on: April 11, 2019, 09:50:16 PM »
Here's what I've been doing.
[ Quoting of attachment images from other messages is not allowed ]
[ Quoting of attachment images from other messages is not allowed ]
[ Quoting of attachment images from other messages is not allowed ]
How to export bots?
Your robot is saved as a [robot name].RR2Bot file. Depending on if you are using a Windows machine or a Mac, the file is saved in a different location. Since it is just one file, you should be able to email the whole thing, or post it somewhere online if it is really big. On a Windows machine it should be the following. I can't verify this at the moment on my Mac: C:\Users\username\AppData\Local\Nerd Island Studios LLC\Robot Rumble 2_0\Robots On my Mac, the file is saved here: Users ▸ [username] ▸ Library ▸ Application Support ▸ Nerd Island Studios LLC ▸ Robot Rumble 2_0 ▸ Robots Here's the reference for where it goes, depending on the platform: https://docs.unity3d.com/ScriptReference/Application-persistentDataPath.html
750
« on: April 11, 2019, 09:43:36 PM »
(Image removed from quote.)
Not the best, but still trying to get the hang of it. Im just waiting for the day we get hinges and rams for functional flipper
Not bad! Its better than what I have created so far. I'm looking forward to flippers too. The prebuilt ones are super-satisfying, and I'm dying to get one built and AI'd.
751
« on: April 11, 2019, 03:07:35 PM »
Hi guys, quite enjoying myself so far, I must say.
Couple of questions about future plans.
- Belted motors, are they happening?
-Circular custom weapons?
-Wiring UI and process being more streamlined? (Which tbh Idk why I'm asking this, you already answered this).
-How soon can we expect creations vs AI fights?
Overall tho, cracking stuff, I've been messing around in the multilayered chassis creation section for hours alone!
Cheers, I'll be posting some creations in the other thread once I get stuff ready <3
1. Belted motors are on the Trello board todo list already. We are working through servos, linear actuators, and pneumatics first. 2. Circular custom weapons might have to wait for the RR2 Component Modding Tool. This will allow you to build whatever you want in a 3D program like Blender (free download at www.blender.org), import it into the RR2 Component Modding Tool Unity project (free download at www.unity3d.com), then export it for use in the game. This workflow will involve additional steps, but will allow you unlimited freedom to create and texture the shapes. Part of the reason for this is that making convincing-looking 3000 RPM spinners procedurally is kicking my butt, but it should be a much more tractable problem if you use a proper 3D modeling tool like Blender. 3. I'll let @tashic know about the wiring UI! :) 4. In the current Alpha build there should be a default AI assigned to your BotLab robots. I am frantically trying to get the new in-game AI code editor running. Its been a beast, but I've worked out most of the bugs and am hoping to put out another Alpha release to the public sometime in the next 2-3 weeks. I'm glad you like the game, and can't wait to see what you post!
752
« on: April 09, 2019, 09:31:40 PM »
I think it's important to understand why AI is important in RA2. It acts as a way to fairly battle bots in lieu of multiplayer. It's a bandage on the problem of the game's netcode being so bad as to be unfit for purpose. As player vs AI fights are unfair, the only way to have a fair fight in RA2 between 2 player created bots is to have an AI battle between both. The problem with this is that it leaves out a large component of what makes real battles interesting, which is the battle of driver vs driver as well as bot vs bot.
What I'm hinting at is that it might be worth looking into multiplayer over an AI scripting language. I don't want to come off as though I think I'm entitled to decide what you should/shouldn't prioritize in the game, but I think chasing this AI system might not be wise, looking through the lens of a player. RA2 already does this well, what we're missing as a community is multiplayer. Unfortunately I'd assume that multiplayer would be a lot more complex on the developer side than an AI system.
Honestly, I think that maybe Parsec can work rather than an in built multi-player system
I disagree. Again, I think Parsec is just a bandaid, and not a particularly useful one looking at its lack of adoption for RA2, which would seemingly be the ideal scenario for the service. It has several issues, such as it being inherently unfair (the host has a sizeable latency advantage), being a pain in the ass both to set up the service and to set up bots and controls and relying on very solid network speeds. These issues combine to result in it barely being used in GTM as of late.
Badger, I really appreciate your honesty and your insight. I know that players have wanted a good online multiplayer experience for a long time. I think you have accurately summarized the years of frustration that many people have felt with RA2. I hope that the following helps address some of these concerns: First off, don't forget about local multiplayer! A good, solid local multiplayer experience is one of our core requirements. Heck, the game was originally conceived as a way for my students to prototype their designs and learn to drive robots against each other before we got to an actual arena. Player vs player with game controllers is really fun. I would love to create a great online multiplayer experience as well, but there are a number of technical and financial reasons why we have not pursued this: 1. Because of the 400 Hz physics tick rate, doing non-buggy online multiplayer is extremely difficult without writing a deterministic physics engine. I'm pretty good with physics, but this is well beyond what I am willing to attempt for the game. 2. RA2 and RA3 both attempted to do online multiplayer. They had to scale back their physics tick rate quite a bit to make it work. The result in both cases was a game that didn't have the physics fidelity that people wanted, and didn't have enough players to warrant investing heavily into making the experience better. There are plenty of nonrealistic multiplayer robot fighting games out there already. We wanted to build a realistic one, which meant sacrificing online multiplayer. I am really excited about the new AI system, though I totally get it why I might be the only one -- You guys haven't seen it yet.  We are bringing programming out from the modding shadows into the game itself. Live coding a running robot is really frickin' cool: 1. You type some code. 2. The robot instantly responds. It is that simple. Just because you can use the old RA2 AI logic doesn't mean you have to. That logic will be there as a starting point, but I expect that people will rewrite the AI to be more effective in battle. Every player writes their own code, or they can modify something they found in a forum. I fully expect that given the appropriate inputs and enough time, people will be able to write AI that will absolutely demolish a human player. Remember that the computer runs at 60 Hz. The fastest humans alive can sustain control signals only at about 5 Hz. The bottom line is that I view RR2 as a member of a new genre of game. It is building game AND a coding game. You get to build and code your own version of The Terminator. The community here proved the concept by modding RA2. RR2 builds upon that and makes robot combat AI coding much more accessible. I'm excited for it, and I hope that you guys are too. As for online multiplayer, let's get the game out and see how it goes this year. It is quite possible that with Google Stadia, GeForce Now, and Blade Shadow all in the mix, we might well be revisiting this conversation again in 2020.
753
« on: April 09, 2019, 02:19:54 PM »
Thank you to everyone for providing feedback on AI. Based on your feedback, I am rewriting all of the AI inputs from scratch, this time cribbing off of the RA2 python files. I’m going to try to make a 1:1 match so that it should be relatively easy to transfer over the existing RA2 AI to the new game.
Please note that miniscript is an entirely different language than the python used in RA2, but it should be close enough.
754
« on: April 08, 2019, 02:47:43 PM »
I think the best starting point is to determine:
1. The processes that are active throughout the whole match (immobility check, enemy tracking/mobility check, win condition evaluation, obstacle evaluation that modifies the shortest path between the bots).
2. A default engagement tactic that is active only while mobile, armed, & powered.
3. The processes that are triggered by mid-match conditions (new engagement tactic when new win condition is determined, such as keeping distance when enemy is stuck, shoving when disarmed, evading when crippled/stuck/low on power, etc.).
Then from those processes you can derive the necessary data to build your functions upon:
- Positioning and mobility status for the processes in #1
- Battery, air, drive, weapon, & armor statuses for the processes in #2
- Control signals that are triggered from the processes in #2 maybe a bit from #1
My engineering background is in microelectronics so I might be over-complicating things. Someone who has a strong background in control systems, feel free to correct me. 
Not a bad approach. The outputs are all set now (4 analog axes + 4 digital buttons), and I'm getting close to done with the list of inputs (see above). Once outputs and inputs are set, it will be a matter of building an AI system using the given set of inputs and outputs. That's the hard work, but it is also something that can be done over a matter of months or years because all of the code will be written in miniscript, and under the direct control of the individual player. I fully expect that the logic will evolve over time as players come up with new ways to tackle AI. Maybe one player will entirely ditch the existing state machine and come up with a behavior tree or utility based system that completely dominates. All of the AI code will live in the .RR2Bot file, so when you share your robot, you are sharing all of its AI code as well. You will be able to copy-paste code to and from www.gametechmods.com. I can't wait to see what people post here on the forums. :)
755
« on: April 08, 2019, 01:33:01 PM »
This one goes out to all of the AI programmers in the crowd. I need your help! Please let me know if I am missing anything!
The following is a list of all of the inputs I think an AI would need to make decisions on which tactic to choose:
1. position and rotation of self (in 3D world space)
2. position and rotation of nearest enemy (in 3D world space)
3. position of nearest waypoint from navmesh (in 3D world space)
[Example: Distance to nearest enemy is computed using #1 and #2.]
4. list of our own motors
5. list of our own smart zones
[Example: If all of our weapon motors are gone, then switch to shoving.]
6. location of nearest edge
[Used for pushing battles.]
7. location of scoring zone
[Used for "king of the hill" arenas.]
8. time of my last good hit on enemy
[To decide if my attacks are working.]
9. self immobile time
10. self isImmobile
11. nearest enemy immobile time
If we do this right, everything that an AI needs could be derived from the above inputs.
Am I missing anything?
Maybe, for robots with CO2, how much they have left? So if they start running out, maybe they prioritise self-righting over mindlessly swinging at anything in the vicinity, and when they run out, they know to stop firing the weapon. Robots in RA2 will keep firing their pistons long after their CO2 has run out.
Also maybe a list of arena hazards (for avoidance and/or shoving opponents towards them)? Or does that come under "edges"?
Good call about prioritizing CO2 for self-righting. The game is pretty mindless about this right now, and flippers get themselves into trouble. I was also thinking we might do something similar with heat and battery. They aren't an issue right now, but heat and battery management are definitely something I have thought about including. Getting "edges" from Unity's NavMesh system is really easy to do right now -- just a single API call. It probably does make sense to categorize them somehow. In the Test Arena, being shoved up against the railing is annoying, but not game ending. However, being shoved into the pit means game over. I'm thinking something like having a "pit" trigger volume: 1. Have the NavMesh system report the location of the nearest edge. 2. Place an invisible test sphere in that location. If the test sphere overlaps with a "pit" trigger, then prioritize staying away from it at all costs. If not, then don't worry about avoiding it.
756
« on: April 08, 2019, 12:03:39 PM »
The following is a list of all of the inputs I think an AI would need to make decisions on which tactic to choose:
There should probably be a separate item between 5 & 6 that checks for the currently attainable win condition (so as to not waste processing power on edge location on closed arenas and whatnot).
But to be honest, while a list is nice and all, it's kinda hard to see the whole picture without those fitting in multiple flowcharts (immobility checker should run concurrently with the other combat functions, for example).
Here's what I have so far. Possible win conditions: 1. Last robot standing (KO) 2. Most points when time runs out 3. Out of the arena (tabletop) 4. King of the Hill (points scored per second spent in target area) I imagine that #1 and #2 would always be active. #3 and #4 would only be true for certain arenas.
757
« on: April 08, 2019, 10:58:17 AM »
The following is a list of all of the inputs I think an AI would need to make decisions on which tactic to choose:
There should probably be a separate item between 5 & 6 that checks for the currently attainable win condition (so as to not waste processing power on edge location on closed arenas and whatnot).
But to be honest, while a list is nice and all, it's kinda hard to see the whole picture without those fitting in multiple flowcharts (immobility checker should run concurrently with the other combat functions, for example).
Nice catch on currently available win conditions. I hadn't thought of that. To be honest, we have been putting off thinking about arenas until the beta. The whole picture doesn't exist yet. Right now the default AI miniscript simply drives toward the nearest enemy and presses button1 when close. All we need at the moment are the inputs to the system. A decision making process will come once the inputs are fairly stable. Of course we can always add more inputs as necessary, but I was hoping to capture as many as possible as a starting point before we start writing default code.
758
« on: April 08, 2019, 08:38:24 AM »
This one goes out to all of the AI programmers in the crowd. I need your help! Please let me know if I am missing anything!
The following is a list of all of the inputs I think an AI would need to make decisions on which tactic to choose:
1. position and rotation of self (in 3D world space)
2. position and rotation of nearest enemy (in 3D world space)
3. position of nearest waypoint from navmesh (in 3D world space)
[Example: Distance to nearest enemy is computed using #1 and #2.]
4. list of our own motors
5. list of our own smart zones
[Example: If all of our weapon motors are gone, then switch to shoving.]
6. location of nearest edge
[Used for pushing battles.]
7. location of scoring zone
[Used for "king of the hill" arenas.]
8. time of my last good hit on enemy
[To decide if my attacks are working.]
9. self immobile time
10. self isImmobile
11. nearest enemy immobile time
If we do this right, everything that an AI needs could be derived from the above inputs.
Am I missing anything?
759
« on: April 07, 2019, 09:34:21 AM »
Im the test bot area (after i press the controller icon
The first thing that comes to mind is that maybe the wheels aren’t attached to the axle correctly. Is it possible that they are affixed to the body of the motor instead? Maybe try mounting a motor vertically, then attaching a bar spinner to the axle, then calling the motor a drive motor? 
760
« on: April 07, 2019, 08:43:06 AM »
 Here's a screenshot showing the assignment of a left motor.
Pages: 1 ... 31 32 33 34 35 36 37 [38] 39 40 41 42 43 44 45 ... 49
|
Show Posts