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 ... 33 34 35 36 37 38 39 [40] 41 42 43 44 45 46 47 ... 49
781
« on: March 25, 2019, 08:29:28 PM »
Quick suggestion: It might be a good idea to put the selectable bots in a list of some sort or another, instead of putting all the possible options on the screen at once. I think it'll look cleaner, and it will scale better with more bots than your current solution. Maybe look at how either RA2 or Robot Wars: Extreme Destruction do this. Slightly different implementations of the same idea.
I'm looking forward to testing the new build 👍
Thanks for the suggestion! I added it to the Trello list. Now that people can create their own robots, this will start to become an issue.
782
« on: March 25, 2019, 11:04:16 AM »
There is a new Alpha build coming on Thursday night! The latest build should be available on Friday at https://robot-rumble.itch.io/builds. Here's a preview of what you can do in the new build: 
783
« on: March 08, 2019, 05:19:19 PM »
I know its a buttload of extra work and also that I'm a bit late to the party but I think the most ideal way to program robots would be through a graphical language. Those tend to be much more friendly towards those that aren't familiar with programming (and would also be more familiar to people who use stuff like labview).
If you were to come up with your own icons it would probably be possible to have a 1-to-1 correspondence to miniscript (so at least a transpiler could be easy). Maybe just keep this as a suggestion for when after all the more important stuff is finished.
I hear you. It would be cool to make a block-based visual coding system. I would like to wait to get some feedback on the Beta (don’t forget to sign up!) before we march down that path though. I suspect that simple things like picking clear names for variables, and having a few good examples will go a long way though. Once this little piece of the game is ready for beta, I will most likely be shifting focus over to things like robot components, and getting a tournament system in place. I am definitely planning to come back to AI before launch though!
784
« on: March 08, 2019, 03:37:28 PM »
Here's D.B. staring down Crabsolutely Crawful. Neither of them are going anywhere at the moment. Setting hRaw and vRaw to something other than zero should do the trick... 
785
« on: March 07, 2019, 03:23:56 PM »
AI is now moddable with miniscript! Miniscript is completely sandboxed from the main code, which means that users shouldn't normally be able to cheat the game with miniscript unless they really try. Bear in mind that I say this without having done any user testing whatsoever.  Right now miniscript is accessible only by me. In the next few weeks I will be working on exposing the scripts to you guys for the Beta release. We have an in-game miniscript code editor in the works, so you shouldn't have to leave the game to edit your AI like you do for RA2. All of the old AI still exists by default, but you can override values and change things in miniscript. I have exposed all of the AI variables to be read by miniscript, and am allowing miniscript to control 5 values: vRaw, hRaw, axeDown, retractWeapon, and spinnerOn. If one of these 5 values is not set by miniscript, it is left in its original state. In the script I have below, this means that driving works as normal, but the weapons are never triggered. This means that the robots only push, but never turn on their weapons. Here is the current list of variables to be read by and set by miniscript. We will need to add to this list when we add things like trigger zone sensors in the Robot Workshop. Readable: selfPosition selfRotation nearestWaypoint // This is taken from a NavMesh. It is used if there isn't a direct path to the target. nearestTargetPosition nearestTargetRotation crossProduct // This is the cross product of our current heading vector with the direction to the target. It is used to compute the steering signal. controlSignal // This is the steering signal computed by the existing AI. dotProduct // This is the dot product of our current heading vector with the direction to the target. It is used to compute the forward/backward signal. nearestTargetImmobileTime isImmobile selfImmobileTime Settable: hRaw // The raw left/right signal given to the controller. This is equivalent to pushing the right/left arrows or "D"/"A" keys. vRaw // The raw up/down signal given to the controller. This is equivalent to pushing the up/down arrows or "W"/"S" keys. axeDown retractWeapon spinnerOn Here is the miniscript code I am using so that D.B. can beat up on Bubblegum. They are both using this script, and D.B. is a better pusher, and Bubblegum's weapon is never turned on: while 1
hRaw = controlSignal
vRaw = dotProduct
spinnerOn = false
wait(0.1)
end while
Edit: Added spinnerOn = false to force Bubblegum to not spin.
786
« on: March 05, 2019, 08:17:02 AM »
Things are tearing along at quite a clip right now. We are shooting to have our first Beta out at the end of March. Here are some of the things we are working on this week:
1. Fight your own custom-built robots in the arena vs pre-built robots in exhibition matches. (Done)
2. Give your robot a custom paint job. (Working, but with a very limited brush selection.)
3. RR2 Component Modding Tool - This is a separate Unity3D project that we will place on GitHub that will allow you to create your own robot components and import them into the game. (Under development. Probably won't make the first Beta.)
4. Write your own robot AI in miniscript. (Under development. I am hopeful this will make the first Beta in a very rudimentary way.)
5. More motor types: servors, linear actuators. (Under development. We should have at least some of these working for the first Beta.)
6. Tournament mode. (Started, but most likely will not be ready for the first Beta.)
787
« on: March 02, 2019, 07:27:03 AM »
Not sure if this has been mentioned, but will there be basic default AI scripts for different weapon types that the player can apply straight to a robot? Just thinking for players who might find writing AI scripts to be difficult, if they’ve never done any scripting or basic programming. That said, I did look up MiniScript and it looks pretty simple to use, even compared to python.
I showed miniscript around to quite a few people yesterday, and yours was a pretty common request. The first thing I would like to get working is a default AI script that simply drives toward the nearest waypoint. If there aren't any obstacles in the way, this means driving directly at the nearest opponent. This script will be exposed and editable in the Robot Workshop. I think the next step would be to have "code snippets", where you can copy-paste a script in to do a certain thing. I'm hoping that most people can use the code snippets, then tweak the numbers to their liking. No promises yet on anything more advanced than that (drag-and-drop, etc). Lets wait until after the first beta to get some feedback on it.
788
« on: March 01, 2019, 10:41:03 AM »
We are starting work on an in-game miniscript code editor today, and I'm hoping to have something very basic working by the first beta release. This should include a very basic script to drive toward the nearest enemy and turn on the weapon.
Once upon a time I mentioned by the end of March for the first beta, so I'm going to try to stick to that. We'll see though. We still have a lot to build before we are ready to release.
789
« on: March 01, 2019, 09:10:52 AM »
How complex is the game's AI going to be? Will it be like RA2, where the robots more or less just drive straight at each other, or will you be able to program more complex behaviours? Things like pushing opponents towards hazards, timing flips instead of hitting the button instantly, preserving CO2 when it starts to run out, trying to aim for specific points like wheels...
Basically, we've covered that the AI shouldn't be able to do anything that a human player can't. But ideally, the opposite should be true, and human's shouldn't be able to do anything that an AI can't. I know that's unlikely, but the more lifelike the AI is, the better, IMO. It would prevent what you get in RA2 sometimes, where two robots with equal wedginess just push each other slowly round in a circle for three minutes.
Caveat: We are going with miniscript for now, and I haven’t explored the language yet. Bearing this in mind, I can see two limitations at this point:
1. AI scripts are going to be limited to a single file — no includes.
2. The available inputs to the AI are whatever data we choose to include from the native code (C# in this case) side. I am totally open to taking suggestions at this point. We can choose to be more precise than just driving at the chassis origin or COM. If we want, we can choose to target the nearest motor, or get a list of all of the motors and target the farthest one. At this point we don’t have anything coded, so anything is technically possible. It is just a matter of converting ideas into reality.
What if we use actual artificial intelligence?
What did you have in mind?
Take Google's Deep mind AI, and use it in this game, this specific AI can learn by itself, and it has taught itself how to walk, so I think it could teach itself to play RR2, but it's probably impossible to do
That isn’t something we had planned to implement, and I don’t think miniscript has the ability to do http requests. It might be worth asking Joe Strout, miniscript’s creator, if he plans to include something like this though. If it is possible in miniscript, then it should be possible for any player to do it themselves.
790
« on: March 01, 2019, 07:31:39 AM »
How complex is the game's AI going to be? Will it be like RA2, where the robots more or less just drive straight at each other, or will you be able to program more complex behaviours? Things like pushing opponents towards hazards, timing flips instead of hitting the button instantly, preserving CO2 when it starts to run out, trying to aim for specific points like wheels...
Basically, we've covered that the AI shouldn't be able to do anything that a human player can't. But ideally, the opposite should be true, and human's shouldn't be able to do anything that an AI can't. I know that's unlikely, but the more lifelike the AI is, the better, IMO. It would prevent what you get in RA2 sometimes, where two robots with equal wedginess just push each other slowly round in a circle for three minutes.
Caveat: We are going with miniscript for now, and I haven’t explored the language yet. Bearing this in mind, I can see two limitations at this point:
1. AI scripts are going to be limited to a single file — no includes.
2. The available inputs to the AI are whatever data we choose to include from the native code (C# in this case) side. I am totally open to taking suggestions at this point. We can choose to be more precise than just driving at the chassis origin or COM. If we want, we can choose to target the nearest motor, or get a list of all of the motors and target the farthest one. At this point we don’t have anything coded, so anything is technically possible. It is just a matter of converting ideas into reality.
What if we use actual artificial intelligence?
What did you have in mind?
791
« on: March 01, 2019, 07:14:06 AM »
How complex is the game's AI going to be? Will it be like RA2, where the robots more or less just drive straight at each other, or will you be able to program more complex behaviours? Things like pushing opponents towards hazards, timing flips instead of hitting the button instantly, preserving CO2 when it starts to run out, trying to aim for specific points like wheels...
Basically, we've covered that the AI shouldn't be able to do anything that a human player can't. But ideally, the opposite should be true, and human's shouldn't be able to do anything that an AI can't. I know that's unlikely, but the more lifelike the AI is, the better, IMO. It would prevent what you get in RA2 sometimes, where two robots with equal wedginess just push each other slowly round in a circle for three minutes.
Caveat: We are going with miniscript for now, and I haven’t explored the language yet. Bearing this in mind, I can see two limitations at this point: 1. AI scripts are going to be limited to a single file — no includes. 2. The available inputs to the AI are whatever data we choose to include from the native code (C# in this case) side. I am totally open to taking suggestions at this point. We can choose to be more precise than just driving at the chassis origin or COM. If we want, we can choose to target the nearest motor, or get a list of all of the motors and target the farthest one. At this point we don’t have anything coded, so anything is technically possible. It is just a matter of converting ideas into reality.
792
« on: February 28, 2019, 02:45:22 PM »
I echo what Badger says. I imagine you can hide those values from the user.
The other disputed factor in RA2 was movements that were not "human reproducible" along the lines of rapidly switching a motor on and off to save power or doing fancy things such as meltybrain.
Sounds like you have a pretty good grasp of how it should we to though. I have very little preference for either language. What sort of math libraries do they include? I imagine that might be a factor in more complicated routines.
Uh oh. I had fully assumed that people would be okay with melty brain controls.
We can do something where state is only updated and made available to the AI every 0.1 seconds, so even though the AI can run at 60 FPS, it is only reading new state information at 10 FPS. Or we could do it in reverse, where state is read every 60 fps, but control signals are only applied to the motors every 10 FPS.
I fully expect that good AI controls would be able to kick a human player's butt. At least that is what I had in my head -- when competing against other players, you are putting your very best AI against their very best AI.
The issue with Meltybrain in RA2 is that it's ONLY possible with AI. There's no real way to do it (at least that isn't cludgy as hell) for a player-controlled bot. If you can find a way to get meltybrain to work for both player and AI driven bots, I can't see why it would be an issue
I hadn't really thought about that. I suppose the problem would be that as a player you could potentially fight against a meltybrain robot, but wouldn't have a chance to make one yourself. I have already solved a similar problem by making an electronic stability control system that works nicely by cutting power to wheels to help a player drive straight. I was thinking of making this an option that you could select while driving. Maybe I could make a meltybrain driving option that operates with the same basic principle? Has anyone driven a meltybrain robot before? Does it still use forward/back/left/right controls, or do you tell it to travel in a particular direction, then using a gyroscope or something to go in that direction? This could get interesting. Depending on how quickly the meltybrain is spinning, the physics system might not update quickly enough to actually control the robot. Physics currently runs at 400 fps. Does anyone have any experience building real-life meltybrain systems?
793
« on: February 28, 2019, 12:56:44 PM »
794
« on: February 28, 2019, 12:54:42 PM »
I echo what Badger says. I imagine you can hide those values from the user.
The other disputed factor in RA2 was movements that were not "human reproducible" along the lines of rapidly switching a motor on and off to save power or doing fancy things such as meltybrain.
Sounds like you have a pretty good grasp of how it should we to though. I have very little preference for either language. What sort of math libraries do they include? I imagine that might be a factor in more complicated routines.
Uh oh. I had fully assumed that people would be okay with melty brain controls. We can do something where state is only updated and made available to the AI every 0.1 seconds, so even though the AI can run at 60 FPS, it is only reading new state information at 10 FPS. Or we could do it in reverse, where state is read every 60 fps, but control signals are only applied to the motors every 10 FPS. I fully expect that good AI controls would be able to kick a human player's butt. At least that is what I had in my head -- when competing against other players, you are putting your very best AI against their very best AI.
795
« on: February 28, 2019, 10:53:17 AM »
I just asked the miniscript vs [moddable] question to a bunch of high school students. It was a 50% / 50% split between students who preferred the miniscript style vs the [moddable] style of coding. Awesome.
796
« on: February 28, 2019, 10:50:37 AM »
How much freedom are we giving?
Will it be a set of defined functions which we edit the contents of?
Or will there be a lot more available?
The issue with RA2 AI is that you could modify parameters which were unrelated to movement/weaponry and make instant win AIs.
I almost feel like a drag and drop overlay might be more intuitive from a basic programming level.
Right now I'm thinking that the most straightforward way to do it would be the following: 1. Expose a bunch of values to the AI. For example, all robots would have access to a pathfinding "findNearestWaypoint()" function that would come from a Unity navmesh, as well as rigidbody position, rotation, battery, heat, and other state variables. In addition, players will have the ability to add "sensors" to their robot. When an enemy enters a one of the sensor trigger zones, the AI should be notified. 2. The AI should be capable of sending input commands to the robot's motors, just like a button press on the keyboard or a controller would do. For digital inputs, control signal values would either be 0 (off) or 1 (on). For analog inputs, the control signal values would be clamped to a range from -1 (all the way negative) to +1 (all the way positive). 3. We would like to have complete flexibility for players to script any sort of AI they would like: behavior tree, FSM, utility, etc. It is worth noting that a complete script must be contained in a single file. Both [moddable] and miniscript allow you to create your own variables and functions for use within the script. There is someone in existence who has made a drag and drop UI (block coding) for miniscript, but that person is currently working on another game and is unavailable to work on RR2. Recreating Scratch or Blox inside of Unity is a pretty big task, but at a minimum I would like to get a basic code editor working. What were the instant win parameters in RA2? I would definitely want to avoid these!
797
« on: February 28, 2019, 09:32:03 AM »
Over the past few days I have been looking at different ways to do AI scripting in the game. At this point, I would like to build the scripting right into the Robot Workshop, rather than requiring users to leave the game and load up a separate text editor to modify the AI script as it is done in RA2.
Due to the amount of time and effort required to implement a working solution, it looks like Python scripting is not an option. Instead, I have narrowed AI scripting down to 2 languages: miniscript and [moddable].
miniscript looks like Python, with indent-based nesting. Here is an example of miniscript code:
for i in range(1,100)
if i == 42 then continue
print("Considering " + i + "...")
end for
[moddable] looks like javascript, with curly brackets and semicolons. Here is an example of [moddable] code:
//Loop through every movable object
for(objName : movingObjs)
{
//if moving objects should be stopped
if (!on)
{
//Stop the velocity of the physics component of the moving object
CallNativeFunc(objName,"ScrollingObject","Update");
} else
{
//Otherwise re-initiate the physics component of the moving object to start the movement again
CallNativeFunc(objName,"ScrollingObject","Start");
}
}
The idea is that every player has the option to create their own AI for their robot. When you share your robot with someone else, the custom AI script that you wrote goes with it. Assuming all goes well, writing custom AI code will become a core part of the game, just like positioning motors and shapes on your robot.
Given the choice between the two AI programming languages above, which language would you prefer?
798
« on: February 06, 2019, 08:50:18 PM »
That's what I thought, cool. (I'm from the UK so that date I wrote is 05 Sept and not 09 May ha)
Oh man. Sorry about that -- I totally didn't consider that possibility. Gotta love inconsistent conventions!
799
« on: February 05, 2019, 03:02:39 PM »
Pretty sure it's the same build from 05/09/2018 as before. Excited for new updates and beta stuff soon though!
The build available on itch.io is the Alpha build from September. It includes the ability to create robots and fight them, but is still pretty rudimentary as far as features go.
800
« on: January 22, 2019, 05:26:10 AM »
“Daisy chaining” already works in a primitive way in the Alpha release. You can add components to an axle, but you can also “weld” anything onto any other surface. Want to make spiked wheels? Just add spikes to the surface of the wheel.
ah so its like attaching two components together except without ap's so stuff can go anywhere?
Exactly. Right now objects just snap to any surface. If you snap an object to an axle, it will spin. You could do spike->spike->spike->wheel->spike->wheel->shape->spike->etc... It is possible to attach motors to axles in such a way as to make a huge daisy-chain of motors that all spin. Of course, if you try to do too many of these, things will break pretty quickly. Linked physics joints tend not to be stable. Play around a little with DB Mk2's flail for physics explosion fun. :)
Pages: 1 ... 33 34 35 36 37 38 39 [40] 41 42 43 44 45 46 47 ... 49
|
Show Posts