Kodi Community Forum

Full Version: GSOC 2020 - Draft Proposal For Discussion - Ioannis Prokopiou
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
4.10 Player Manager for RetroPlayer
  • Name: Ioannis Prokopiou
  • Forum/e-mail: [email protected]
  • Summary: Currently, player assignment and controller selection is hard-coded. This project would allow the user to configure which controllers are connected to the virtual console, enabling multiplayer in games that are currently hard-coded to single player.  Basically everything can emulate everything. We need a player/port manager that can handle this mess with a simple remote-friendly dialog. Not just emulators, IMO player profiles are a must have including avatars. Player profiles should be independent from Kodi users though. All the stats etc. can be in a separate database. Assigned ,maybe changeable, randomly-assigned avatars 8-bit, pixelated, animated little characters ( https://github.com/kodi-game/OpenGameArt.org ). Feature: to have multiple controllers on a port. Buttons allows you to configure/reconfigure the (downloadable) controller buttons. User must be able to map controller to up to more than one devices at once, dialog must support multiple physical controllers per each virtual controller, up to , maybe, 16 players , dialog must respect both physical and logical topological restraints (https://xd.adobe.com/view/07368653-8b14-...aebd5c487/)
  • How will I achieve this: This is my first time applying for google summer of code and I am planning to follow all the discussion and the issue progress found here: https://github.com/garbear/xbmc/issues/87 . I want to change all the hard-coded parts and ultimately change virtual input devices and choose which player number they are. Since there is work that has been done it the future it will be much easier for a beginner like me to get a grasp really quickly. I intent to work with C++ using Visual Studio + Windows environment(with ReSharper C++). I have already built Kodi for UWP and normal x64 and seen all the “good first issue” issues on github giving me a grasp of the code in general. Starting from the retro parts and having seen clearly all the previous tasks that had or hadn’t been done and I plan to start with steps towards completing the non completed player manager requirements with the feedback of the discussion. Of course I am more than happy to learn whatever I possible can and will get me forward.
  • What will the project focus on: The main focus is for the players to be able to change virtual input devices and choose which player number they are while all the main points of the summary are the small goals/tasks.
  • Benefits: The main benefits or for us the developers, team Kodi and players themselves. First, me, as a developer, will gain great knowledge and get my hands in practical topics that are not only professional but fun. Secondly, I think it will be very important for team Kodi to develop a very well player manager for retro player as it will be a very nice feature of the application. Lastly, the players will get to have more fun being able to manage and configure all the emulators, controllers in a player friendly environment making their “stay” at Kodi’s a fun one.
  • Goals: As I mentioned above, some work is done already so I intend to follow the issue and the discussion and contribute with my ideas. Sub goals (following the discussion):
  1. User must be able to map controller to up to more than one devices at once
  2. Dialog must support multiple physical controllers per each virtual controller,
  3. Up to , maybe, 16 players
  4. Dialog must respect both physical and logical topological restraints
  5. Avatar resource add-ons
  6. Relative pointers emulation
  7. Touchscreen
  8. Hub support
  9. Multitap subclass
  10. Direction buttons to analog stick mapping
  11. Additional hardware buttons etc. (all the open tasks from https://github.com/garbear/xbmc/issues/87 )
  • What does it touch in Kodi: All the retro parts should be looked up as well as anything that has to do with players, controllers, emulations. We need to make the UI for the users so they have a seamless experience. I understand it may touch a lot of areas of the code but the fact that this project is fun and the fact that there is a well defined previous concept to rely on will make it easier. For sure, it touches:
  1. PlayersSelectionRule
  2. GameClientController
  3. GameClientInput
  4. GameClientDevice
  5. GameClientTopology
  6. ControllerGrid ( and specifically ::AddController )
  7. ControllerTree
  8. ControllerManager
which contain hard-coded parts or useful information about them.
  • Requirements: 
  1. Environment (VS  + Windows)
  2. C++
  3. understanding of general programming and will to make things work, which I have
  4. understanding of Github
  5. ability to quickly understand existing code - adaptability
  6. good communication
 
  • Possible mentors: Place to add possible mentors (Team-Kodi will add this).
Summer division by tasks:
All the tasks are divided in 2 general topics which are the player assignment and the controller selection. The topologies are also a topic which applies to both of them.

At the start the topics regarding the topology should be made clear and resolved (let’s say the first month since both basic topics have references). Secondly, for the second month the controller selection and everything around controllers should be resolved (second month). The third month will be focused on player assignment and if times allows it the menus should be perfected as well as the dialogs.

The months of the controllers and the players could go reverse, meaning player assignment first and then controller selection.

As the time may not allow us to do everything, the most important features to be scheduled first are:
Topologies: buttons to analog mapping - hardware buttons - DFA - map device
Controller: controller topology (ending of topologies) - Context menu when selecting controller - Controller settings
Player: choose device - assign controller- player numbers ------> finally constructing player manager

Regarding controller selection:

Controller feature support:

  1. -relative pointes emulation
  2. -mouse game API (retro)
  3. -touch screen
  4. -hub support (retro-topology)
Topology support:
  1. -multitap (liberto - topology)
  2. -buttons to analog mapping (liberto - topology)
  3. -hardware buttons(liberto wired topology)
  4. -DFA (topology)
Controller panel:
  1. -controller topology
Controller menu:
  1. -map device(topology)
Menus:
  1. -Context menu when selecting controller
Avatar menu:
  1. -Controller settings
Regarding player assignment:

Controller panel:

  1. -player manager
Controller menu:
  1. -choose device
New dialogs:
  1. -player profile selection dialog
  2. -assign controller dialog
  3. -Peripherals dialog with player's peripherals
  4. -Controller profile selection dialog
Avatar panel:
  1. -player numbers
Menus:
  1. -Context menu when selecting avatar
Avatar menu:
  1. -Change player (fades focus texture, avatar follows focus as it moves across players)
  2. -view profile
  3. -Choose profile
  4. -Assign controller
UI Mock up:
The goal is for the players to be able to change virtual input devices and choose which player number they are. So, following the discussions I edited dome of the photos to better explain my ideas.
 
There will be a menu before the start of the game but the players will be able to make configurations during the game through game menu. The players will be able to move their avatar to their preferable number to change or exchange position with a player in a certain number. Below will be displayed the icon of the controller/profile and below that will be a button to open controller configuration.
 
There will be various controllers depending the game that they are playing in which they can make their personal profiles configurating the buttons. The buttons can be rearranged which is a way of displaying all the options and making quick changes while it is easier to code.
The second picture is just for the display of the virtual ports menu in which I have no argument.


Link to mock up in Google Drive