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 ... 29 30 31 32 33 34 35 [36] 37 38 39 40 41 42 43 ... 49
701
« on: May 05, 2019, 06:17:30 AM »
Currently, my job is killing my will to play the pc, but ive managed to make some changes to bull
(Image removed from quote.)
We are looking to put together a RR2 highlights video and were wondering if anyone would be willing to share their .RR2Bot files for the video. We were hoping to put the video together before the BuggleBots release in a few weeks. Please pm me if you are interested!
702
« on: May 05, 2019, 06:06:32 AM »
Currently, my job is killing my will to play the pc, but ive managed to make some changes to bull
(Image removed from quote.)
Wow! Beautiful!
703
« on: April 28, 2019, 05:26:56 PM »
I agree with Badger here. Also if there's ever modding with lots of custom components we might want multiple installs that don't interfere with each other, though there are other ways around that.
Is there anyway I can see what features are planned for future versions? Anyway, I have some suggestions after building in the botlab for some time. A lot of suggestions and a lot of them are complex, so I don't expect you to agree with all of them or try to implement much of what's here in the near future, I know you guys are busy.
I know you guys are not nearly done with the botlab and that given time you guys will make it great, but talking about the botlab right now as it is, it's still pretty clunky in the sense that it takes a very long time to use the controls and the tools given to you to make the botlab do what you want it to do. First of all, I think keyboard shortcuts would improve the building experience 1000%. Things like pressing x to focus the x coordinate, delete for deleting components, arrow keys/wasd + shift + space for moving things around/rotating, basically all the buttons and fields in the interface should have some keyboard mapping because clicking on everything takes forever. Remapping keys would also be great, i.e. i much prefer RMB to MMB for panning. As it is, it's very easy to make mistakes by putting the wrong numbers into the coordinates or into the wrong coordinates, and it's also way too easy to get yourself into a situation where you move something too far away and can only fix it through editing the bot file. An undue button would be a great help for this, and additionally some way to control the max distance from origin of all the components and toggle the room that you are in would all be huge helps. It's also really easy to get objects stuck inside of others, and there's currently a glitch where some small objects won't be able to be selected unless you exit and join the workshop. A lot of these issues could also be helped by having an expandable tree view of all the components like in the bot file and being able to select components like that. Being able to turn off blur from being too close would also be great. When using the moving sliders, they go in increments of .025, and if the component isn't currently at a multiple of .025 then it snaps to a multiple: there should be some way to turn the snapping to a multiple off, because a lot of the more complex builds will not use those multiples very often. This also applies to the rotation and size sliders. There should be a way to control what interval the moving axes move by, either through a field or through several hotkeys which are each set to common values, i.e. .01 and .005 with .025 as the default. It would be great if there was some way to change the directions of the coordinate system so that it doesn't have to be determined by what the object is sitting on, a lot of the times I just want the normal xyz directions. It would be fantastic if there was a way to copy the x, y, or z coordinate of one object and then set the coordinate to another in a streamlined fashion, e.g. hold x while clicking on another object. It would also be great if there was some way to clone mirrors of objects and flip each of the components. It would be nice if we could smooth components along a certain rotational axis. For the chassis and custom object builder it would be great if we could change the numerical values of the xy coordinates via text field of each of the vertices like we can for objects in the rest of the builder.
Thank you so much for taking the time to dig into the bot building process. There is so much great feedback here, it is going to take a while to parse through all of it. Right now we have an internal Trello board that is growing a lot faster than it is shrinking, so no promises yet on getting a public-facing version of it going. We are working as fast as we can, and I’m more than a little afraid of what would happen to our ability to process the feature requests if we opened things up to the general public at this point.
704
« on: April 28, 2019, 05:07:09 PM »
Suggestion, have bots be saved in the game install directory, instead of the AppData folder. Makes the game more portable and makes the files easier to find for sharing purposes.
True, but it also gets overwritten on app updates, and potentially suffers from permission issues, where only installers have permission to write to the directory, not the applications themselves. We can look into it a little more, but no promises on this one.
705
« on: April 28, 2019, 02:55:30 PM »
I fixed it bois
[ Quoting of attachment images from other messages is not allowed ]
[ Quoting of attachment images from other messages is not allowed ]
Had to edit the coordinates of the piece in the bot file. I also smoothed out parts of the disk and made the chain on the gears closer to the size of the chain in the air.
It's actually pretty effective in battle, and somehow the spinner is strong enough to self right, so its basically everything I could have asked for.
Unbelievable! Wow!
706
« on: April 28, 2019, 10:51:04 AM »
Holy sh**, you nd arcane are amazing. My BB rep is sh** compared to this. As for the part going off.. i guess if you moved the chassis a bit to the direction opposite of of the component, you might be able to move it. Maybe set a limit of components direction to 2?
Thanks. I'm not sure about the exact direction and distance of the piece though, and if I move the chassis to get the piece I'm pretty sure I'd lose the chassis then, unless I'm missing something :/. I'm guessing that the only way to go about this would be a bot file edit if that's possible.
I'm not sure if I'm dumb and don't know all the controls, but an undue button would be a huge help in the bot builder (I'm guessing that's planned). Also, the main culprit for these errors is because when entering in coordinates, if the number box is focused but not the text itself, and if the number I'm entering leads with a "." e.g. ".350", then the period gets skipped and just 350 is entered. That's how I got the necro.
You can bfe the bots, it is kinda complicated
Pardon the ignorance, but what does BFE stand for?
707
« on: April 27, 2019, 07:17:34 PM »
Tbh, looks a bit like what a bot could be on the early days of robot combat imo
Though weapon spam by teeth won't be effective by the full version basically
I’m considering adding a script to lower the height of the center of mass to make all robots more tip-resistant. It should help for almost every design except for something that is specifically designed to tip over. Off the top of my head, I can’t think of any real-world examples of such a design though. What do you guys think?
708
« on: April 26, 2019, 01:54:16 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
Hmm... So weird. I'll take a look to see if I can find anything fishy about the way the arena was put together. The only thing I can think of off of the top of my head is that the warehouse has a huge semi-transparent area, which tends to make things more difficult for a computer's GPU. This shouldn't directly affect the physics though.
709
« 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.
710
« 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. :)
711
« on: April 25, 2019, 05:01:23 PM »
Riptide
[ Quoting of attachment images from other messages is not allowed ]
I like it! I’m working on damage now. Puncture damage for spinners and axes should be a thing soon!
712
« 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.
713
« on: April 23, 2019, 08:01:11 PM »
[ Quoting of attachment images from other messages is not allowed ]
Red Devil - It doesn't fully articulate like the real thing but it can drive (just) and the claws move which is good enough for me.
I've been trying to find anything that's irritating when building within the bot builder to report back on here and for the most part I'm struggling to find much that isn't already mentioned or currently planned to be implemented later down the line. The only minor issues I've come across is that if you snap a new component onto an existing one on a subtle incline then the component will lay flat, not inclined. (Eg: I couldn't get the track pieces to sit at the same angle as the component they're snapped onto as they either lay flat or at too sharp an angle). And the rotation tool could maybe do with a few more angle points.
Also thank you to everybody that commented on my last post.
Wow. I'm trying to wrap my head around how you did this. And. Just. Wow. Were the track pieces snapped to surfaces on a sphere, or on a polygon?
714
« 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.
715
« 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!
716
« 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.
Apex Rumble 3.0
RULES:
-110kg max
-32 entries, 2, bots per person (2 because some other people shown interest for entering this)
-No clipping obviously, if your planning to make a 3 burst, burst motors can clip with eachother, just not into other motors/stuff (kinda want to make life easier with flippers)
-Dont be making your bot invicible
-Must have minimum 1 battery & 1 control switch/board
-No shells, No Rings
-Active Weapons can be only on 2 sides, either front and back, or left and right, you cannot cover your bot with active weapons
-Excluding the top and bottom, one side must be unprotected on a single weapon robot, 2 sides on dual weapon robot (best example: Drummer)
-No clusters, due to limitations
-No Dustpans or badnik fork grabbers, however Overhaul grabbers are allowed
-if you cant drive, someone else will
-1v1's Double bracket
-DM me enteries
-To export your bots go to 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!!!  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.
717
« 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?
718
« 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.
719
« 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?
720
« 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.
Pages: 1 ... 29 30 31 32 33 34 35 [36] 37 38 39 40 41 42 43 ... 49
|
Show Posts