search

robreuss / VirtualGameController

Software-based game controllers for iOS, tvOS, OS X and watchOS in Swift 4.2.
MIT License
462 stars 44 forks source link

Support for multiple appIDs / local search #7

Closed jakubknejzlik closed 5 years ago

jakubknejzlik commented 8 years ago

It would be great to be able to use one controller for multiple apps. I'm able to help with this feature, if it's possible to accomplish this. Is it even possible something like that? If so, could you point me where to start before diving deeply to your code? :)

robreuss commented 8 years ago

In your other issue, you had mentioned wanting to have a generic gamepad in the App Store. 1) Were you thinking of doing this for your own games or 2) more generally, so any developer could make their game compatible with it?

1) I think things are very close to being able to support a developer using a single controller with multiple games. As you'll see in the Peripheral and Central sample apps, the Peripheral sample displays a selector that lists all the available Centrals based on device name. You can see this in my screenshot. I always meant to make the device name provisional if a game name is not supplied, but overlooked it. By adding a game name (and falling back to the device name if none is supplied) you could simply name each of your games, and the user will be able to select which game they want to play when a selector screen displayed. No need to mess around with appIDs - you would just use one for all your games. If there are not more than one game available on the network, the Peripheral could connect automatically. Does this sound adequate to meet the needs of a #1 approach?

I'm going to do that approach today - it is very easy.

2) Creating a generic gamepad in the App Store that any developer could use with their game will require a little more work I think, but perhaps not too much. I think the general approach would be to use a common appID for all developers of games (e.g. "vgcGeneric") who want to utilize the generic gamepad. This could be added to the existing two NSNetService searches (one of them searches for "central" and one searches for "bridge"), which would allow an app to operate in both modes at the same time: a) normal mode where a game-specific appID is used ("myGame") and b) generic gamepad mode where the generic gamepad appID is used ("vgcGeneric").

On a side note, I just added support for bidirectional communication between a Central and Peripheral, so that Centrals can now send messages to Peripherals. With a generic gamepad, this could have some cool uses, for example, where each game could request slightly different arrangements of controls or different styling.

I think some of the benefit of software-based controllers is that they can and should ONLY have the buttons that are required for game play. For example, I personally think that implementing a full set of extended gamepad inputs like I do in my Peripheral sample app creates poor UX because it is so hard to track where your finger is positioned on a piece of glass without looking, without any tactile feedback. Instead, I think effective software-based controllers will have a small subset of controls that are large, and designed around the lack of limited visual and tactile feedback.

jakubknejzlik commented 8 years ago

We'd like to go with #2 approach and the "game specific layout" is one of the features, that would be highly recommended. Interesting idea about specifying common name for all games.

robreuss commented 8 years ago

Awesome!

I think that the principal that Apple established around MFi controllers that the "gamepad" profile is minimally supported is a good one. By having this "contract" in place, we can avoid compatibility issues to some degree. I'm not sure in the final analysis it is practical to do this, but it is something to consider.

It would be great if it was released supporting all three profiles: microGamepad, gamepad and extendedGamepad - that would allow for mix-and-match support with hardware-based controllers. But like I said above, I think the extendedProfile over-burdens the UI on an iPhone and is impractical for real-world game input. Perhaps I'm wrong about this and it could be done?

Apple has crossed the MFi design principal that calls for the gamepad profile as the baseline with the microGamepad, which does not support the gamepad profile, only a subset of it. In some respects, the microGamepad is a really valuable profile for us to support: 1) it will be really effective to implement on an iOS device because it's so simple, and 2) it adds a lot of value to the marketplace because currently more than one remote is not supported with Apple TV. Added to that is the requirement on Apple's part that all Apple TV games support the Remote - support for the microGamepad on an iOS device enables developers to leverage the effort they must put into supporting the microGamepad/Remote.

But I do think it is highly valuable to go beyond the standard profiles to create custom profiles better adapted to implementation on an iOS device. That does get us into compatibility issues where a version of the Generic Gamepad that resides on a user's iOS device may not support a custom profile requested by the Central. That is not a tragic circumstances since it can trigger a message to the user that they need to upgrade their Generic Gamepad - it just requires that we support some type of coherent versioning approach and protocol for the Central to make requests for profiles from the Generic Gamepad.

If this is all sounding coherent to you, I'll go ahead and create a basic spec and add it to the Wiki - should be short.

robreuss commented 8 years ago

FYI, I've made some progress on programming these changes. Should have those changes pushed along with some docs in a day or two.

jakubknejzlik commented 8 years ago

That's great, I've updated the podspec for cocoapods" for tvos compatibility. We also have our project ready for testing with multiple controllers. I'm going to create custom iOS peripheral next week (should be customized after connecting to tvos central)

robreuss commented 8 years ago

Sorry I've been slow about the custom Peripheral stuff. I've pushed out and documented something I call Peripheral Setup, which is an object the Central can send to the Peripheral to request certain UI and behavior. It's a minimal set of properties right now, just as a proof of concept, but I can easily add more. Not sure if you're still interested in doing something alone these lines! https://github.com/robreuss/VirtualGameController/wiki/Peripheral-Setup-from-the-Central