Designing a flexible and one-size fit all controller system?

I've been working on a controller system with the following goals in mind:

1) Multiplayer
2) Compatible with any type of input (touch, mouse clicks, joystick movement, etc.).
3) Flexible

It's quite difficult and want to know how everyone has designed their controller system. Here are some conclusions I've come up with / things I've done:

1) Virtual keys. Basically, all 'real' input (mouse clicks, taps, touches, joystick movement, etc.) are mapped to a virtual key. Everything interfaces through virtual keys. Virtual keys receive real input and do an action (move a character, jump, etc.) in response.

2) UnityEvents / Reflection will need to be used. Interfaces are not very flexible here. This is the part I'm having difficulties with. I think each key would carry one of 3 pieces of information: null, position (vector), and float. (Could a key possess a float and a vector?). In any case, the action(s) performed by the key should not be forced to implement a method with specific parameters. i.e. a mouse click will always have a position, but maybe the position aspect of it is not cared about. Another difficulty is what about key press duration? Let's say you have a method like this:

Move(Vector2 position, float speed).

And you want it to be invoked when the user releases a key? the "speed" would be the duration the key was pressed for but what about "position"?

Any thoughts? Advise?

 

If you want to do multiplayer, you would need to make sure it's compatible with most networking systems for Unity. Unet, Photon, etc. Also consider mechanim implementation and maybe make a custom editor window to make it easier for people to use and understand without script knowledge.

Try to have universal options for most build settings. Maybe a option to just switch the controls to Xbox or Mobile.
There is tons of stuff you can do with it, just depends on much you want to do with it.

 

Controller for what?

One size fits all generally means it fits badly in most places.

 

Make games, not tools!

I am with BoredMormon here. Why do you think other people want something that you don't want yourself? Just write a game, make a nice lib out of your controller part and then give it to other people.

But writing a jack-of-all-trades is no good. Do you really think a controller system can fit "hotseat, multiplayer, short-reaction time FPS" games as well as "massive multiplayer strategy play-by-email" games. Not to mention "causal tablet match-3 clones"...

Anyway, if you still want to go on, here some tips:

With all "tools before games" ideas, I suggest you either target "coders" or "non-coders" as your main audience.

If you target "coders", make a loosely coupled library of efficient (and allocation-free!!!) tool functions/scripts. Document well. Make them usable without each other. And write 3-4 simple games that uses your library.

If you target "non-coders", your stuff has to be usable without writing code, of course. Heck, it has to be usable without the need to "think like a coder". So you should heavily invest in visual tools and editors.

Some tips about your concrete idea:

Virtual keys: If you target coders, you should make the "detection" of the key non-descriptive, but done by code. What I mean here is, that users can provide a piece of code that determine whether a virtual key was pressed, instead of just make this one big enum or a list of properties.

The reason is, that you might need actions like "tap a button, then relese, then tap again within 0.5s and then drag it at least 10px" to be a different action than "double click". You simply can not forsee what crazy virtual key action scheme your users will have.

UnityEvents: Interfaces are too inflexible? I don't buy that. The hint that Unity itself moves away from "SendMessage" with its "flexible" parameter approach towards interfaces should give you a hint that your premise might be wrong. Just saying..

I would suggest you use exactly unitys event system. But if you really want to do yet another home brewed system, then keep it stupid simple and with the fewest C# magic possible.


Also, remember that unity is currently working on a replacement for their controller system.. Take a look at their event system in the new Unity UI to get a feeling of what might be their direction (source code somewhere on bitbucket).

 

Not sure what you mean by "Why do you think other people want something that you don't want yourself?".

How would you use UnityEvents for this? That's the part I'm having issues with here.

 

Oh wait, you are building an input system. You should have said that. A controller is something completely different.

Your best bet for multiple parameters is to use an interface or delegate with all of the parameters. Then let the user choose to ignore the ones they don't need. For simplicity you can wrap them all in a struct.

 

But what if you have a component with multiple methods you'd like called on different input?
Also, right now I'm making a mobile game. Let's say sometimes the user taps the screen, something should happen at the location of the tap. At other times the location won't matter. At other times, the duration will be important. Something maybe all.

 

Code (CSharp):

1. public void DoNothingMethod (Vector3 ignoreMe){
2.     // Do something else
3. }

 

Sorry but I don't understand how this will help me.