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 ... 41 42 43 44 45 46 47 [48] 49
941
« on: July 28, 2017, 03:15:29 PM »
Sadly for yall, yall gotta be 18 and sign a contract.... if it wernt for that.. i would have probobly entered.
Thank you for pointing this out. Robot Rumble 2.0 is a commercial project with money involved and all of the intellectual property issues that come with it.
942
« on: July 28, 2017, 11:42:03 AM »
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.
943
« on: July 28, 2017, 10:19:55 AM »
HELP WANTED: -Programming Lead for Robot Rumble 2.0 robot combat simulator -Experience shipping a game in Unity3D (preferred) or similar -Multiplayer game architecture experience desired The person we had lined up as the programming lead on Robot Rumble 2.0 is unable to continue with the project. We are now looking for an experienced programmer to help build the game from the ground up. The team currently consists of @Tashic and me, but we are looking for a third person to fill the lead programmer role. Unity3D is preferred, but if you have significant 3D game development experience in something besides Unity, we are still at a state where we could switch to a different engine. For more information on the project, please see the Robot Rumble 2.0 thread: https://gametechmods.com/forums/index.php?topic=20145.0If you are interested, please send me a pm.
944
« on: July 28, 2017, 06:39:43 AM »
- 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!
945
« on: July 27, 2017, 04:43:24 PM »
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.htmlForces 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.
946
« on: July 27, 2017, 08:22:21 AM »
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.
947
« on: July 27, 2017, 07:47:39 AM »
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... 
948
« on: July 27, 2017, 07:06:54 AM »
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.
949
« on: July 27, 2017, 06:24:56 AM »
*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.
950
« on: July 26, 2017, 06:47:55 AM »
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... :)
951
« on: July 19, 2017, 07:40:58 AM »
Never got em'. I just double checked. I'll PM you my email though, that's the best way we can talk.
I received your pm and sent an email. Were you able to receive the email on your end? I have a sneaking suspicion that my email is being blocked.
952
« on: July 18, 2017, 10:23:56 AM »
You can scroll back a few pages for something playable.
I'm currently doing all the boring / difficult stuff that needs to get done to lay a framework for the game to be good, as opposed to getting 'something playable.'
It is no fun, but that's the way it is.
@Jules I sent a pm/email -- not sure if you got them, or are even interested, but please let me know so we can collaborate and/or deconflict. 
953
« on: July 14, 2017, 05:23:56 PM »
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.
954
« on: July 14, 2017, 05:09:14 PM »
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. :)
955
« on: July 14, 2017, 04:42:59 PM »
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.
956
« on: July 14, 2017, 03:33:14 PM »
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:
957
« on: July 14, 2017, 12:20:48 PM »
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
958
« on: July 14, 2017, 10:41:01 AM »
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.
959
« on: July 14, 2017, 10:32:26 AM »
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.
960
« on: July 14, 2017, 10:18:49 AM »
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): 
Pages: 1 ... 41 42 43 44 45 46 47 [48] 49
|
Show Posts