Moving the mouse with a gamepad would make certain games playable for people who are really uncomfortable with a WASD+mouse setup, which is why I'm keen on that.
Lefties. Say what you mean.
Guilty.
Ter13 wrote:
Guilty. | |
Lummox JR wrote:
Multiverse7 wrote: I thought that might be the case. Some kind of gamepad-specific procs would be nice, and it's the only way to say that gamepads are fully supported. Online multiplayer games are going to be network hogs in general. There's no way around that, but some better solutions may become apparent once the client can tick on its own. The issue is the same for the mouse procs. Mapping the gamepad to the keyboard doesn't really make sense. A gamepad provides a level of precision that just doesn't translate to keyboard keys. At the same time, gamepad sticks are not very good for moving a mouse, especially without controlling the sensitivity. I agree with you on the D-pad and front buttons. Those will easily map to the keyboard in any case. Although, I could argue that with a controller plugged in, some games could be designed to use the keyboard strictly for typing. In cases like that, relative mapping just wouldn't work. I didn't make this very clear. I was referring to the precision offered by the axes (the sticks and possibly triggers, depending on the type of gamepad). There may be some confusion here and I can understand why. There has been a war going on that transcends and yet influences all of the console wars. It is the war of D-pad vs analog stick. Nobody agrees on which one should go on the top and which one should go on the bottom. To complicate things even more, there are even disagreements on whether the top or bottom half of a gamepad should be considered the "dominant" one. To simplify things, what you end up with are two groups of players: those that use a D-pad for movement and those that use an analog stick for movement. That was before the Steam Machines rolled out of The Twilight Zone and everyone became completely insane. To be fair I have never used one, but just what are those bizarre touchpad abominations they decided to put on the controllers? Anyway, I prefer to use an analog stick for movement. There was a time when the D-pad was the only thing I would use to move, but now it just feels like a vestigial leftover from a bygone era. The sticks just work the best, even for 2D games. Take the Land of Fire skill tree for example:  What would be the best way to jump between any of the different nodes? Clearly the answer is an analog stick with full precision, since it can provide vectors that the D-pad or keyboard can't. Mapping to the mouse isn't even an option, because it can't really "snap" to anything. Ter13 wrote: Analog deadzones and scalars and pressure-senstive face buttons are great for 3D games, but 2D games don't inherently have to require them. At this point, something is better than nothing. There are many 2D games that can and will require them. There are at least three BYOND games in development right now that use the mouse position to get a vector for making the mob aim at things. For a good example, here is Cavern:  Would you really want to just map the gamepad to the mouse, or work with the actual values of the axes? It will just feel like a really creepy hack when you have a phantom mouse cursor flying all over the screen whenever you make a move. Why would you use the mouse to do something that has nothing to do with the mouse, and everything to do with the gamepad? It just sounds crazy to me. When we use the gamepad, we are not going to use the mouse and we don't even want to see the mouse, so why would we want to use the mouse position rather than the axes? Let's just assume that mapping an analog stick to the mouse is completely sane and will work perfectly. This opens up some interesting questions. Should the mouse stop when it reaches the edge of something, and if so which thing should it stop at; the current map, pane, or window? Should there be some kind of setting to configure this? What happens if a player bumps the mouse while they are using a gamepad? How will that not just mess up everything? Should some form of mouse control be a feature on its own? Could the mouse get "stuck" inside the game? Do players just deal with that if there is a bug? What if a player opens something malicious that they don't know how to escape from? Is BYOND really prepared to open this huge can of worms? You don't have to worry about any of that if you just use gamepad-specific procs. Also, if you have a game that is anything like Cavern, Lux, or Epoch, and you plan on supporting both gamepads and the webclient, you will have to use special procs. | |
Multiverse7 wrote:
I agree with you on the D-pad and front buttons. Those will easily map to the keyboard in any case. Although, I could argue that with a controller plugged in, some games could be designed to use the keyboard strictly for typing. In cases like that, relative mapping just wouldn't work. Well to clarify and ease your concerns on that point, I wasn't planning for the buttons to fire WM_KEYDOWN and WM_KEYUP messages. Rather, my thinking is that a gamepad will maintain its own internal map, which will be combined with the system's key state. The routines that handle macros right now and make exceptions for input controls would simply bypass those exceptions when being fed key events by a gamepad. I didn't make this very clear. I was referring to the precision offered by the axes (the sticks and possibly triggers, depending on the type of gamepad). The way I plan to handle stick-to-movement cases is by letting the author or player specify whether the stick is 8-way or 4-way, or 4-as-8 (e.g., up+left pressed at the same time) and then just mapping that to the appropriate arrow keys. It's just a matter of deciding which keys are represented and at what angle ranges. Take the Land of Fire skill tree for example: Hrm, I disagree. I think the game could be made capable of snapping to the nearest node. Not by forcibly moving the cursor, but simply by telling which is closest and highlighting it. Let's just assume that mapping an analog stick to the mouse is completely sane and will work perfectly. This opens up some interesting questions. Should the mouse stop when it reaches the edge of something, and if so which thing should it stop at; the current map, pane, or window? Should there be some kind of setting to configure this? What happens if a player bumps the mouse while they are using a gamepad? How will that not just mess up everything? Should some form of mouse control be a feature on its own? Could the mouse get "stuck" inside the game? Do players just deal with that if there is a bug? What if a player opens something malicious that they don't know how to escape from? Is BYOND really prepared to open this huge can of worms? The mouse cursor escape issue is valid. I think it makes sense for joystick-mapped mouse controls that if the mouse cursor is over the main map, it should stay there, and if it's not then it should snap to the map. And like the keyboard, a mouse button press initiated by this setup would be strictly internal. I've made notes of these. You don't have to worry about any of that if you just use gamepad-specific procs. Also, if you have a game that is anything like Cavern, Lux, or Epoch, and you plan on supporting both gamepads and the webclient, you will have to use special procs. Because gamepad support is a bit spotty right now, I think it'd be sensible to create a gamepad .dms control that could handle such things, and those games could hook up their own special verbs for those cases. | |
Would the stick-to-movement exclude the ability to read a joystick as direction+value?
It'd be interesting to be able to tie movement to the value so that creep/walk/run could be implemented. As well, the secondary stick would be used for aiming in Lux, and I'm not sure 8 directional aiming would go so well. | |
Lummox JR wrote:
Multiverse7 wrote: Are you saying we will get something like a +PAD modifier to use for macros specific to the gamepad? That wasn't the best example. Input controls are not really what I was talking about. The way I plan to handle stick-to-movement cases is by letting the author or player specify whether the stick is 8-way or 4-way, or 4-as-8 (e.g., up+left pressed at the same time) and then just mapping that to the appropriate arrow keys. It's just a matter of deciding which keys are represented and at what angle ranges. Why stop at 8? 8-as-16 should be perfectly reasonable for an analog stick, especially if your keyboard has a numpad. Take the Land of Fire skill tree for example: Maybe it could, but that sounds like it would be hard to do. You would have to convert the mouse position into the kind of relative vector that actually makes sense. The mouse cursor escape issue is valid. I think it makes sense for joystick-mapped mouse controls that if the mouse cursor is over the main map, it should stay there, and if it's not then it should snap to the map. And like the keyboard, a mouse button press initiated by this setup would be strictly internal. I've made notes of these. Would there be some kind of new param to determine whether or not a mouse proc has been called through a gamepad? I can see it working better if that was the case, but I still think gamepad procs would provide a much better solution. Such procs wouldn't need to pass nearly as many arguments as the mouse procs do, so they would likely generate far less network activity. When using a gamepad, I don't care what specific object the mouse might happen to be over, and since all of the usual information will still have to be passed in that case, it will generate a ton of lag that could have been avoided with more simple procs that are designed with axes in mind. You don't have to worry about any of that if you just use gamepad-specific procs. Also, if you have a game that is anything like Cavern, Lux, or Epoch, and you plan on supporting both gamepads and the webclient, you will have to use special procs. There's nothing wrong with that but it's still kind of working around the problem. It isn't a universal solution, as it doesn't apply to Dream Seeker. Bravo1 wrote: Would the stick-to-movement exclude the ability to read a joystick as direction+value? This is exactly the kind of problem that I'm talking about. Mapping to the keyboard or mouse isn't going to solve it. You made that clear. | |
Multiverse7 wrote:
Are you saying we will get something like a +PAD modifier to use for macros specific to the gamepad? That wasn't the best example. Input controls are not really what I was talking about. No, I don't intend a +PAD modifier. The way I plan to handle stick-to-movement cases is by letting the author or player specify whether the stick is 8-way or 4-way, or 4-as-8 (e.g., up+left pressed at the same time) and then just mapping that to the appropriate arrow keys. It's just a matter of deciding which keys are represented and at what angle ranges. I'm not sure we're on the same page at all. I'm talking about for cases where you specifically just want to map an analog stick to the keys normally used for movement, of which there are only 8. For more freeform movement, some other scheme would be desirable. The mouse cursor escape issue is valid. I think it makes sense for joystick-mapped mouse controls that if the mouse cursor is over the main map, it should stay there, and if it's not then it should snap to the map. And like the keyboard, a mouse button press initiated by this setup would be strictly internal. I've made notes of these. I think you're confusing the issues here. I think there are valid use cases for using the analog stick that don't necessarily have to do with the mouse, and there are plenty of valid cases that would use the mouse. The mouse case should be fairly straightforward. Adding specific procs, like client/GamepadAxis() for instance, is absolutely not on the agenda. That would create lag, even in cases where the axes weren't important. Instead, to use analog sticks I would want a setup where the game author could set a verb like "stickmoved $x $y" (actual format to be determined) and have the coords fed in that way. For games whose authors don't provide that sort of thing, but their games do have mouse controls, a mouse mapping could be very helpful as a general catch-all solution. | |
Lummox JR wrote:
I'm not sure we're on the same page at all. I'm talking about for cases where you specifically just want to map an analog stick to the keys normally used for movement, of which there are only 8. For more freeform movement, some other scheme would be desirable. I wasn't sure if a better scheme was going to be provided, other than the mouse. I think you're confusing the issues here. I think there are valid use cases for using the analog stick that don't necessarily have to do with the mouse, and there are plenty of valid cases that would use the mouse. The mouse case should be fairly straightforward. The issue is that the mouse seems to be the only freeform option. Adding specific procs, like client/GamepadAxis() for instance, is absolutely not on the agenda. That would create lag, even in cases where the axes weren't important. Instead, to use analog sticks I would want a setup where the game author could set a verb like "stickmoved $x $y" (actual format to be determined) and have the coords fed in that way. Earlier you said this: I'm really not sure how axes could be mapped to verbs in an analog way, unlike simply treating them like a D-pad if desired. What you're suggesting would be a proc that would be called any time the axis changed, which could be once per tick. I think there might be some use cases for that, so I'll keep it in mind, but I think it's likely to be a network hog. That gave me the impression that verbs were out of the question, and if anything, a proc would have to be used. Are you now leaning towards using some kind of verb command? For games whose authors don't provide that sort of thing, but their games do have mouse controls, a mouse mapping could be very helpful as a general catch-all solution. I'm not against mapping to the mouse, as long as it isn't the only freeform solution. Sorry if I'm making things more complicated than they are. | |
Verbs aren't out of the question; they're a part of my vision. They're only not going to be available for user-defined control schemes if the game sets control_freak with the no-macros flag.
| |
Multiverse7 wrote:
If verb commands produce less lag than procs, could something similar be done for the mouse? I don't think there is a difference since procs and verbs are fundamentally the same thing. | |
No I'm not. I think you might've wandered into the weeds here, since we don't seem to be on the same page with a lot of this.
To reiterate: - Games and users alike will be able to map the D-pad and buttons to keys, or to mouse buttons; both are virtual. - Games and users alike will be able to map an analog stick to the mouse. The mouse will be limited to the main map area when moved by the gamepad. - Games will be able to map the above to verbs. Users can do so too, if not prevented by control_freak. - Games and users alike will be able to map an analog stick to arrow keys, using either a 4-key, 8-key, or 4-as-8 mapping. | |
Lummox JR wrote:
No I'm not. I think you might've wandered into the weeds here, since we don't seem to be on the same page with a lot of this. That worries me. - Games will be able to map the above to verbs. Users can do so too, if not prevented by control_freak. I'm not sure if I'm understanding this or not. When you said "stickmoved $x $y", did you mean the $x and $y are actually mouse coordinates? I was expecting these to be axes. | |
Multiverse7 wrote:
I'm not sure if I'm understanding this or not. When you said "stickmoved $x $y", did you mean the $x and $y are actually mouse coordinates? I was expecting these to be axes. To further question is the x and y the amount it is attempting to move or just the coordinates of where it's moved to? If it's the amount it should work fine, but if it's just the position it moves to then there may be an issue, as the edges of the screen would keep values from changing if it's just the coordinates. Also I apologize for grilling you on this, I just want to understand what the plan is beforehand so that you don't end up doing work and then we all end up not liking it, as we had the wrong impression. | |
You guys are really getting up in your own heads and over-complicating this stuff. All that he's talking about is allowing users to map the mouse cursor to an analog stick in order to move the cursor.
At this point you should really just wait for the initial beta release and provide feedback based upon that. | |
At this point you should really just wait for the initial beta release and provide feedback based upon that. Agreed. It's a lot easier to identify feature gap than debate the merits of a nonexistent implementation. Lummox has always been good about making changes to stuff when it's in beta based on community feedback. The reason some things can't be changed in response to community feedback is usually because of breaking changes screwing up games that have already used a feature for a while. I trust Lummox. The man's listened to us a lot more than Tom ever did (gooble gobble) and he's done some amazing things lately. | |
Sometimes it's best to confront issues early on, to avoid insurmountable problems down the road. The hard truth is better than a scary surprise.
This topic has actually had very little discussion, since it was completely derailed for a while. The fact that Bravo1 is saying exactly what I'm thinking leads me to believe the concern is valid. Lummox JR even mentioned that Lux helped inspire this feature, so Bravo1's opinion should matter. His game and others will be affected by this. I'm just trying to help. This could be one of the most important features in BYOND's history. | |
The bit you brought up about the map bounds was helpful, so I agree there's value in discussing this stuff up front. But I think you're still really missing the gist of a lot of it. A lot of the concerns you've brought up are either invalid (e.g., lag vs. regular keyboard/mouse use) or are things that are already being addressed.
| |
Lummox JR wrote:
The bit you brought up about the map bounds was helpful, so I agree there's value in discussing this stuff up front. But I think you're still really missing the gist of a lot of it. A lot of the concerns you've brought up are either invalid (e.g., lag vs. regular keyboard/mouse use) or are things that are already being addressed. I'm just curious about how exactly the sticks would work, so I can prepare myself ahead of time in order to implement it quickly. My main question is whether or not the stick will be a 0/1 or if it will scale base on how far the stick is pushed. If it's the latter then I have zero qualms about the rest of the system. | |
Lefties. Say what you mean.
And yeah, I've got a set of USB NES, SNES, N64, and Gamecube controllers for my PC. Analog deadzones and scalars and pressure-senstive face buttons are great for 3D games, but 2D games don't inherently have to require them. At this point, something is better than nothing.