ingame input graphic configuration... yay!

Hello!

We want to get rid of the pre-game setup dialog, mainly because, well, there isn't one on webplayers, and in general it's not very immersive and user-friendly (I'd say it's ugly but I wouldn't want to offend UT .

So I made this little test project where you can configure the resolution, quality and the input from inside the game.
Res quality were no problem, but the input was no piece of cake since we don't have any access to the input manager from script.... BTW if anybody has tried to do this before, I'm listening !


I'd love for people to try the demo and tell me how it works for them.
Just launch, play around (default: arrow keys to move around and space to jump), hit escape to get the config dialog, change the settings, see if it still works...
Also your preferences should be persisted between game sessions.

From what I've seen, it's flawless on Mac but not so much on Windows, no idea why... I receive weird keycodes sometimes.

They're no joystick support so far so don't bother trying, but I'll get around to it (it's actually another reason I started doing this, we couldn't get joysticks to work with our game).

Of course when I'm done I'll be happy to share the scripts with everyone, ingame input config is definitely a must-have!


On a technical note, I'm using the GUI 2.0 Event model as a basis for trapping the keyboard input... can't remember why I started that way, I guess it seemed a good idea at the time, but I'm gonna try to switch to good ole Input tomorrow, maybe that'll improve the thing on Windows.


On the gameplay note, you may have trouble jumping sometimes. On Windows it feels like sometimes the spacebar isn't very responsive (but maybe that's just my keyboard... or brain), but mainly it's because I lock jumping when the ball isn't on the ground (or else you can double-jump and start flying)... and I have difficulties knowing for sure when I'm on the ground!
Sometimes I get a OnCollisionExit but no OnCollisionEnter, even though the ball is stopped dead on the ground... weird!!
Right now I'm using OnCollisionStay which seems to work fine, but if anyone has any suggestions about how to know for sure if the ball is on the ground, I'm listening!

PS: by "on the ground" I mean "on any collider", whether the ground or the cube or the ramp.

 

This is Great!!!

I can't wait to make use of this!

 

Oh cool. I've been pondering the same problem. Looking forward to checking this out.

Thanks!!!!!!!

 

The input configuration routine seems to work perfectly here at home on my Intel iMac/Leopard 10.5.2. I confirmed that my configuration was saved between sessions. Very slick.

I'm really interested to see how you tackled this.

The cool thing of course about the built-in Input manager is that you can set up how the keys respond -- (gravity, sensitivity, deadband, etc. ) -- it seems like you must have to throw this out in order to accept arbitrary key mapping... ?

 

blenblo, as far as I can see, the Input class is still not configurable from inside of the game (also not in Unity 3.0 beta 4 as far as I can see). Did you add support for joysticks in your script? I am about to write one otherwise. Or does anybody else have a solution to how to configure keyboard, mouse and joystick movement from within the game?

 

Oooh, interesting!

I'm working on something like this myself, including joystick support, separation of multiple players for splitscreen and ease of maintenance for when Unity's underlying implementation changes or if you want to add support for a new type of device. I'll post the code on here once I'm done so we can compare and improve.

 

Sure, I'll do the same. My implementation is based on that the Unity Input Manager has to be setup in a special way (one axis for each joystick axis). That's the only way I have discovered doing this. Do you have a different approach?

 

Very nice. I like it. Will be putting it in game soon.

 

b.t.w., here is another implementation:

http://forum.unity3d.com/viewtopic.php?t=57501&postdays=0&postorder=asc&start=0

 

Nope, that's the only way right now. It's even explicitly mentioned in the docs (though a bit hidden), see: Input.GetJoystickNames

Roid's Input Manager is what inspired me to make my own system in the first place. He clearly identified the need for a much more flexible system, and he has my thanks for that. The thing is, his implementation isn't very good. It works, but the code is not reusable, maintainable or extensible.


What I'm doing is this:
- Encapsulating hardware peripherals as subclasses of a Peripheral class. (keyboard, mouse, joystick, plus any future devices that you want to add yourself).

- Buttons and Axis interfaces. You can Get() them just like you would from the normal Input system, but they also handle mapping buttons to axes and vice versa, without exposing how that is implemented. This makes it really easy to setup, and trivial to use.

- Virtual Input Devices. These encapsulate input from one or more peripherals (e.g. just one joystick, or keyboard-mouse combination, or two players that each have their own joystick but share the keyboard) for each local player. This is there to enable you to make splitscreen games. They also offer the ability to add 'contexts'. A game like Battlefield 1943 has many contexts such as 'on foot', 'driving tank' and 'flying plane', and you'll want to map different controls for those. In code you can then get input from the arrow keys with 'Forward' and 'Backward' while on foot, and 'Pitch', 'Roll' while in a plane. This makes your game and your code more transparent. Even if you don't have all those gameplay contexts, you can still use it to add a second set of controls for menu screen navigation; something nearly every game has.

- An InputManager class that handles assigning peripherals and their inputs to the Virtual Input Devices. You can use this not only for remapping keys, but also to have "press start to begin" screens that automatically map an input device to a player profile at the start of a session. Not to mention adding/removing local players during a game in progress. I'm even trying to set it up so multiple players can be editing their keys at the same time.

Still building:
- Saving/Loading implementations: PlayerPrefs, XML, support for any other saving mechanisms you'd like to add. These would allow input mappings to be saved for each local player profile.

- Adding default input profiles for supported peripherals. E.g. loading a default mapping for the x360 controller that you specified for your game.

 

nice...."benblo" how did you do your character controller, did you script yourself or you use from the Unity site??

really like to know how you did that type of controller.

 

@Tinus, that sounds very good. My implementation is purely a layer on top of Unity's Input Manager so that one can change keyboard/mouse/joystick mapping in-game. However, I am not creating the GUI or anything like that, just methods to call from one's own GUI to do:

* Loading controller mappings.
* Saving controller mappings.
* Reading user input (including virtual axis as well as joysticks).
* Discovering button/axis movement (when assigning).

I am almost done and will probably post a link to it here later.

 

Cool, that's exactly how I think it should be done. It's very model-view-controller.

 

I think Zelk allready posted my custom inputmanager allready,but i wana push it myself once more also, version 1.4 makes importing this in your projects very easy !

It haves even xbox controller support on both mac pc

check it out please :