Thread Rating:
  • 0 Vote(s) - 0 Average
Player Manager
#76
(2017-10-12, 17:52)grumpygamer Wrote: Hello, I put together a small idea about how I think it should work.
I have no clue how the machine looks under the hood and doing this is quite difficult from a distance Wink so I hope I got it right!
Please don't bash me around for the styling etc... it's just a prototype in a VERY infant stage and put together in 10 minutes.

https://xd.adobe.com/view/07368653-8b14-...aebd5c487/

Click the plus symbol to add a controller
then just click thorough it, create another controller and click configure.
Hope this helps

Love the style. Got some comments on the functionality.

How does this scale to 8, or even 16, players? How does the player choose which virtual hardware is in use? Some SNES games react differently depending on if a Multitap is attached or not. Which means that one player can have multiple virtual devices (multitap + controller for SNES, or joystick + mouse + keyboard for DOSBox). Also, navigation - this doesn't look too remote friendly, which breaks away from the rest of Kodi.

I feel this is a good starting place, and it looks like it can scale to handle our design requirements. Here's a few:
  • User must be able to map controller to up to three devices at once (mouse, keyboard and joystick)
  • Dialog must respect both physical and logical topological restraints (see examples of physical topology and logical topology) including hubs and daisy chaining
  • Dialog must support multiple physical controllers per each virtual controller (allows turn-based multiplayer e.g. Monopoly and some multiplayer handheld games)
  • User should be able to switch ports
  • Up to 16 players (via scrolling in the dialog)
BTC: 1JtXwJdGdE9YnYgThWBT2StFCU5sEYkbVD (personal), https://kodi.tv/contribute/donate-bitcoin (foundation). Donations in the form of controllers, especially ones that don't work in Kodi, are also appreciated.
Reply
#77
Quote:How does this scale to 8, or even 16, players? 


How does a SNES (for example) do that? Or are you talking about an arcade machine?


Quote:How does the player choose which virtual hardware is in use? Some SNES games react differently depending on if a Multitap is attached or not. Which means that one player can have multiple virtual devices (multitap + controller for SNES, or joystick + mouse + keyboard for DOSBox).


So you're saying I can add a virtual controller to the SNES emulator and map it on to a physical controller? Or to multiple physical devices?
What's the benefit? It seems such an edge case scenario! Whoever wants to go to that level of sophistication will have the actual machine... 
I am quite perplexed about this, but I'll think about it. 
I certainly don't feel like it's a priority, but you're boss Smile

Quote:Also, navigation - this doesn't look too remote friendly, which breaks away from the rest of Kodi.

Yes, yes I know... It was only a basic concept Tongue


Quote:User must be able to map controller to up to three devices at once (mouse, keyboard and joystick)

Not sure why, but ok..


Quote:Dialog must respect both physical and logical topological restraints (see examples of physical topology and logical topology) including hubs and daisy chaining

No clue what this means...


Quote:Dialog must support multiple physical controllers per each virtual controller (allows turn-based multiplayer e.g. Monopoly and some multiplayer handheld games)

Is this the same as the one above: controller mapped to 3 devices at once?


Quote:User should be able to switch ports

Yep, cool


Quote:Up to 16 players (via scrolling in the dialog)

Again, this seems valid for arcades, but not so much for home consoles... anyway this shouldn't be too much of an issue.
Reply
#78
(2017-10-12, 20:13)grumpygamer Wrote:
Quote:How does this scale to 8, or even 16, players? 

How does a SNES (for example) do that? Or are you talking about an arcade machine?

I'm talking about any game. Arcade machines. I think Genesis supports two 4-player hubs. If we hard-code a 4-player limit now, it will be prohibitively expensive to change this later.

(2017-10-12, 20:13)grumpygamer Wrote:
Quote:How does the player choose which virtual hardware is in use? Some SNES games react differently depending on if a Multitap is attached or not. Which means that one player can have multiple virtual devices (multitap + controller for SNES, or joystick + mouse + keyboard for DOSBox).

So you're saying I can add a virtual controller to the SNES emulator and map it on to a physical controller? Or to multiple physical devices?
What's the benefit? It seems such an edge case scenario! Whoever wants to go to that level of sophistication will have the actual machine... 
I am quite perplexed about this, but I'll think about it. 
I certainly don't feel like it's a priority, but you're boss Smile

Certainly not a priority, but a design requirements nonetheless. We don't have to launch with this feature, but we can't choose an architecture that prevents this, unless we change our design requirements.

(2017-10-12, 20:13)grumpygamer Wrote:
Quote:User must be able to map controller to up to three devices at once (mouse, keyboard and joystick)

Not sure why, but ok..

Think about a joystick DOS game that requires the enter key or a mouse action to launch. Omitting this feature would preclude these games. We can certainly do this if we change our design requirements, otherwise we have to support this edge case.

(2017-10-12, 20:13)grumpygamer Wrote:
Quote:Dialog must respect both physical and logical topological restraints (see examples of physical topology and logical topology) including hubs and daisy chaining

No clue what this means...

Topology is how things are connected. I've split this into two kinds of topologies:

Physical topology is how devices physically connect to each other. For example, you can physically plug a multitap into another multitap. Physical topology obviously can never change.

Logical topology is what the emulator logic can handle. This is strictly a subset. For example, you can physically plug a multitap into a multitap, but there's no emulator logic that can handle this, so it's not allowed. Logical topology can be different for each emulator and change over time.

Topology is important because it lets us describe things beyond the trivial topology of a direct controller-console connection. Without topology, we couldn't describe hubs or daisy chaining.

We have a difficult job. Our data is described topologically, but we need to hide this complexity from the user. However, the simpler the dialog, the more work needs to be done under the hood. I'm hoping to find a happy medium.

(2017-10-12, 20:13)grumpygamer Wrote:
Quote:Dialog must support multiple physical controllers per each virtual controller (allows turn-based multiplayer e.g. Monopoly and some multiplayer handheld games)

Is this the same as the one above: controller mapped to 3 devices at once?

No, this is exactly the opposite - 3 physical controllers mapped to a single device. The inputs are multiplexed together so even though it's three people, it looks like a single player to the emulator.

This design requirements came from a forum request. Like all design requirements, it can be dropped, but this is something we need to decide to do.
BTC: 1JtXwJdGdE9YnYgThWBT2StFCU5sEYkbVD (personal), https://kodi.tv/contribute/donate-bitcoin (foundation). Donations in the form of controllers, especially ones that don't work in Kodi, are also appreciated.
Reply
#79
Hey, I have read the above, I still don't get all the topology thing, but I will re-read it maybe tomorrow.

I am happy to take on board all your requirements and try to find a way to make it simple for people to configure, but I honestly think it's a bit overcomplicated for a launch.
I experience this nearly on a daily basis, the project is big, it has to have bells and whistles and support every possible scenario, but in the end it's very hard to launch with all the features fully fledged in a reasonable amount of time.

My approach to this would be to leave the code "open" so that the bells and whistles can be developed at a later point and start with a simple thing that just works.
Then slowly add features you were mentioning, the UI will change to accomodate the new functionality.
I think all software nowadays tends to do it like that, but maybe I'm just speaking rubbish.

At the end of the day I doubt that the average player who wants to use emulators has the need for a "multitouch" interface or some other fancy thing, but most users would probably prefer having a working rom browser that elegantly loads the game (for example)

Baby steps of things that work - and then expand from there - is what I've grown up to understand.
I just want to point out there is no offence meant here, nor critique, just expressing my point of view.

I will try and see what I can get done in regards to what you have explained to me.
Thanks
Reply
#80
(2017-10-13, 00:00)grumpygamer Wrote: My approach to this would be to leave the code "open" so that the bells and whistles can be developed at a later point and start with a simple thing that just works.

You are as wise as you are grumpy Wink I'm perfectly happy shipping a stripped-down GUI initially.

My main concern is the backend code, due to my experience with the controller dialog. That project had equally steep design requirements, and look at how long it took (almost a year). It was such a massive project, that every time I adjusted the design due to a newly discovered joystick driver bug, I would spend days, if not weeks, making a single change.

There's a difference between leaving holes in the implementation and leaving holes in the architecture. Adding code is cheap. Refactoring code is expensive. Would you say GUIs follow this same pattern? I wouldn't, because a GUI is a single presentation layer. The joystick code, on the other hand, is built of around 5 layers of abstraction, from the bools and floats of the driver layer to the physical features of the controller profile layer.

Anyways, I think we should build the GUI in a series of steps, from simple (basically what you posted) to fully-featured. In order to build your concept, we need player profiles. How do you think these should work?
BTC: 1JtXwJdGdE9YnYgThWBT2StFCU5sEYkbVD (personal), https://kodi.tv/contribute/donate-bitcoin (foundation). Donations in the form of controllers, especially ones that don't work in Kodi, are also appreciated.
Reply
#81
Quote:Think about a joystick DOS game that requires the enter key or a mouse action to launch. Omitting this feature would preclude these games. We can certainly do this if we change our design requirements, otherwise we have to support this edge case.

a keyboard can't be owned by a player as there can be at lest two players on one keyboard (I remember playing DOS games with my brother on one keyboard). So there can only be a virtual abstraction of the keyboard which is mapping specific keys to a certain player. But how these keys are mapped must not be controlled by Kodi - it actually can't be controlled by Kodi. If player One is using WASD and player Two the cursors must be in the domain of the game, because the Keyboard must still stay a generic input device to f.e. enter a nickname on highscores or do whatever textinput required.

Regarding the mapping of multiple controlers to one user: I think the approach from Grumpygamer would still work for this. All we have to do is to split the management of players and controllers. So you first add a player, give it a nickname and maybe even an avatar, and in a second step you manage it's controllers using the same technique Grumpygamer demoed (click "add controller" in UI, click any button on controller, done). But I honestly don't see that we really need a complex controller matrix that shows which controller is mapped to which user as long as it's just two clicks to remap a controller to another user via Game OSD
Reply
#82
Regarding grumpygamers question about consoles with up to 16 players... I don't think any support that many, but the saturn supports 12 players on some games (using 2 x 6port multitaps) and the first Playstation supports up to 8 (2 x 4port multitaps), both of which currently have libretro implementations.
Reply
#83
yep, what is the likelihood that most player are going to use these?
I am still looking into this, but I would just ship the basic stuff initially and then expand later.
Anyways I might have time to have a better look this evening and update the prototype.
Also I have no idea where these "expanders"/"hubs" are attached to
Is there any logic behind these?
For example if they are attached to a game port you can't add one of these virtual controllers if 2 controllers are already plugged in
Reply



Player Manager00