we’ve officially decided that a combination of mouse and keyboard play would be best for the game, now we need to decide what kind of controls we will have. here is the first round of options and their features:
[ul][li]“Analog Mouse”
[/li][list][li]mouse is aimed in circle on screen to determind speed and direction
[/li][li]keys are used to perform robot actions[/ul]
[/li][li]“Mouse Follower”
[/li][ul][li]robot aims itself in direction of mouse pointer on floor.
[/li][li]robot actions are performed by clicking on the object, robot will automatically perform the corresponding action
[/li][li]pausing, and choosing between multiple mouse actions from a menu in some circumstances would be doen through the keyboard[/ul]
[/li][li]“Voodoo Mouse”
[/li][ul][li]drive of robot is operated through keyboard
[/li][li]a second model of the robot is located in a box in one corner of the screen, which always corresponds with the one on the field.
[/li][list][li]players can click on servo-type mechanisms on this model to move them on the field model
[/li][li]players can click and drag arms and other parts of the bot that have many different possible positions.
[/li][*]players can rotate the model to reach all mechanisms[/ul][/list][/list]
Nooo, no, no, no.
Configurable.
on the OI, you have 16 analog inputs and 16 digital inputs. An combination of mouse, keyboard, or joystick axis/buttons can be accepted to control this.
And the mouse can be “Position” based (To the left side: x = 0) or “movement” based (keep going left tp keep x = 0).
As for keys, it’s simple. Left means X=30, Right means X=225.
Analog to digital is similar. Have a threshold. (X<30 means left, X>225 means right)
Anything else?
i have no idea what you’re talking about… i guess we can include this in round B2, but you should explain it more first
the point and click mode and have the robot follow and do stuff automatically doesn’t seem like a good idea… why not just have the keyboard do it all… sure the analog things would end up being digital things because the keyboard is on or off (1 or 0, digital). but i was actually picturing this from a First Person POV from the drivers box. And the user could program what ever buttons to do what ever they wanted, and if they had a joystick (or two) they could use that, so it would be like you are actually controlling that bot, instead of just kind of moving it around and having stuff get done automatically, thats not what FIRST is like at all.
By the way, i am starting the programming course tomorrow (the 7th) i think it goes for most of the summer… but i have no idea what language we are learning (it will obviously be c or a varient, whether its C, C++ or obj-C i have no idea, i hope C++ or obj-C)
i thought of that too, and i agree. thats y i changed my vote to the voodoo method. i think that will be the most efficient, easiest, and most vercitile method of control,
ok ok, what exactly is voodoo mode? do all of the controls on the keyboard with the voodo corner thingy as an extra or is that the primary way to activate the controls? i think putting everything on the keyboard would be most realistic, but the voodoo thing sounds cool too…
ok.
There is a config dialog. You can map each input to an OI pin.
The inputs are:
- Mouse X, Y, H, V (scroll wheel)
- Mouse buttons (1-5)
- Keyboard buttons (include alt, ctrl, shift, win?)
- Joystick axis 1-6
- Joystick buttons 1-32
- possibly dashboard/RC
1, 4, 6 are analog; 2, 3, 5, 6 are digital
Mouse XY can be based on position or rate of movement.
the conversion between analog/digital is actually pretty simple. It’s based on a value.
- in A>D, the value is a threshold. below = unpressed, above = pressed. also can make an axis do 2 buttons, one above center, one below.
- in D>A, the value is a number. (eg if Key=pressed then axis=number)
so how this all works together is that the sources map to OI inputs (16 axis, 16 buttons). These values are fed to the robot. presto! controls done.
As for connecting to the OI/RC, I have 2 ideas:
- use the dashboard port and set it to send OI data
- connect to the prog port on the RC and have it send the values. (in a 20 byte packet). I could write a program to do that, I think.
obviously, the OI setup would map directly to the inputs.
suddenly, every one of our computers have 4 more wireless gameports.
I agree that Voodoo would be the best option. If this is the option we decide to go with, I suggest that we consider a few things:
-
Some sort of function recognition for the player to know what part they are selecting, (i.e. The parts glowing and a name appearing when the mouse is hovering over it, etc.)
-
Rotating the Object would take game time to do, you could just have flags satellite off the model, with the different functions written in them for faster access
-
Possibly combine the Voodoo and the Follower models, have robot actions by clicking on the object and the robot does it to the best of its ability. I like that aspect of the Follower mode.
-
Maybe have Both modes and allow players to choose the type they like?
Don’t forget that we need compatibility with other years. (Maybe even '92! :ahh:)
Anything that complex means a massive overhaul of the current interfaces (which isn’t saying much).
for the voodoo mode, we would have small red circles on the robot called “handles” you just grab onto that handle and drag it.
let’s use MOE’s arm for an example:
say MOE’s arm is at a 90 degree angle. the player would grab the handle and move the pointer over. now we know that nobody can keep the mouse on the exact edge or the circle of rotation, so here’s essentially how it would work. when the pointer is moved, the computer draws a line from the joint to the pointer location. then it rotates the arm until the handle hits the line. basically matching the angle. well, this may not be exactly how it would be programmed, but essentially how it would respond.
now, let’s consider a 2-jointed arm, like my team had:
we would have a system like this for each joint, but for operating ease, we can have a special key to activate an alternate mode when held. the player would hold this key down, and grab the handle at the end of the arm. now, anywhere within the arm’s range, that point would go, and here’s how. the computer would form a triangle between the two arm segments and the line between the handle and the first joint. this way, it would be like actually grabbing the arm at the end (like we can on our controls) and pulling the middle joint in space, allowing the two to turn to the point where they fit.
these handles would act almost like the title bars on windows, click and drag.
Sounds nice, but I think it’s a bit complex for gameplay. I think it would be easier to have something like W=first stage up, S=first stage down, E=second stage up, D=second stage down (not necessarily those keys)
we use the same exact principal on our robot’s arm. it sounds complex, but when you use it (which i have) it is really easy. and fun :D. ask teknobrahma, he’s the arm operator… and he voted for voodoo.
I agree with HHSJosh. I think that the voodoo things may be too complicated to be handled well. I think that instead of making the user do most/all of the work by mouse, we should do something like:
- Robot movement - Done by the “analog circle” idea
- EX of an arm which has to joints and a winch/hook combination:
[list] - You hold down ‘a’ to activate the lower joint. That joint is now movable by the mouse in the analog circle. (I.E. the farther from center, the quicker the movement. The side of center in the circle would determine which direction. Position off of the vertical/horizontal diameter (depending on joint orientation) would be ignored as joints can’t move in more than 1D (mostly. good enough for our purposes))
To deactivate the joint and allow robot control again, just release the key. - Same thing for the upper joint, only with, say, the ‘q’ key.
- For the winch, very similar idea. To activate, hold done a key. The mouse then contols its speed/direction. (and, yes, we would limit it in one direct because it is a winch. Maybe we could ‘break’ it if it goes the wrong way…)
[/list]
So… I’m done… 
P.S. Oh, wow, that was scary. After I finished typing that, I posted it… and the site was down for backup. Lucky for me Firefox saved everything… 
actually, i was thinking about this, and i think now that the best way would be to have the voodoo method, but also have keyboard override.
How about you activate the arm with the ‘a’ key, but then use the up and down arrows to actually move the arm.
Really with the voodoo and that, even with moving the mouse to move objects with a keyboard select, that takes away from the movement of the robot for a second, doesn’t it? It would be better if players could multitask and move the robot while performing a specific function, IMHO. It doesn’t sound right if the driver has to stop, put the arm up, and move again, you lose valuable time.
Yeah, I agree. The biggest problem is that people only have two hands. FIRST matches actually have 2 drivers, which allows for control like that. To be able to do this, whatever you are doing must be movable in only one DOF (such as most joints) and two keys are mapped to it. One key moves it one way, the other key the other way. I.E. To move our arm up/down, you either hit ‘q’ or ‘a’. The largest problem with this is the difficulty for a player to learn a new robot’s controls increases and we can relatively quickly run out of keys to use. For instance, with a robot with an arm with 2 joints, a winch/hook system, and flaps which open on the sides (and can move independently), you need around 10 keys. Obviously we aren’t close to running out of keys with that simple robot, but just operating 10 keys while using a mouse at the same time and watching the feild will be extremely hard in my opinion.
Maybe we could implement some sort of slow motion on the other robots during the time the person is moving something that isn’t a drive component.
i have an idea which is an improvement of this. i call it the “Time Freeze Ghost” system. sounds weird, but here’s how it works. when players need to do a bunch of stuff at once, they can hit a special button which will freeze time. the player can then manipulate translucent elements of the robot, which will appear to come out of the actual parts like ghosts come out of bodies in movies. they can set all the ghost parts to how they want the robot to be positioned - arms, flappers, hooks, etc. now, they press the ghost button again and time starts up again. all the pieces of the robot will automatically move to seek these positions and then stop.
Ok. That sounds like it will work.
Great idea, Mike! Very creative, and it seems like it’ll definitely work.
–d0ri