OSC 
Proposal : Open Source (Game) Controller 
The next generation gaming platform interface for use by Disabled people

Author: Graham Law, Celtic Magic  
Contact: graham@celticmagic.org 
Version: 1.05

Glossary:    2
1 Goal    2
1.1    Advantages for OEMS    2
2 Premise    3
3 Basic Proposal    4
4 Advantages of Third Party Hardware    4
5 Architecture    5
5.1 Hardware Architecture    6
5.2 Software Architecture    7
6 Restrictions to Limit Abuse: The RLA System    8
7 Legacy & PC gaming    10
8 Future possibilities    10
 
Glossary:
OEM        Predominantly Microsoft & Sony

OEM-Module    Original Equipment Manufacturer supplied hardware that is incorporated into third party OSC products providing controller access

OSC          An Open Source Controller device, comprising of an approved OEM module enclosed within a product developed by third parties

OSC1/2/3      The access level of an OSC device for a given user that is displayed to other users during online play

RLA         Restrictions to Limit Abuse,  a security system to give full control access for disable users 

 
2 Premise

•    Microsoft/Sony (OEMs) el al cannot produce the specialist interface that suits every disabled user.  Nor should they.   

•    General purpose controllers such as the Microsoft Xbox Adaptive Controller and the Access Controller from Sony are worthy but will only help a section of the disabled communities and exclude many that require more support from custom devices and macros.
To date these assistive devices have been relatively simple general purpose controllers, with no or very limited macros incorporated.

A Macro is piece of  software designed  to fulfil a complex task automatically such as:
    Automatic and complex shooting or combat patterns
    Ability to change input control functions dynamically. Ie joystick operates as paddles or switches and back quicky
    Inertia & stability compensation for weapons
    Pre programmed complex character and vehicle moves
    Single stick driving and exploring with viewing  (Typically used for disabled users)
    Many more game specific automations designed to give game advantage

•    It should be recognised that the technology used to cheat is the same as that which is genuinely beneficial to disabled users.  Such as macros currently running on third party devices  (Titan / Cronus) or pcb soldered daughter boards onto OEM controllers.   

 

Cheating users cannot be eliminated, only reduced.

This is an Arms Race
and disabled users are squeezed by this situation and need to be isolated from it as much as possible.

 
3 Basic Proposal

With well considered restrictions in place (see section 6 RLA), OEM manufacturers of the leading gaming platforms should offer full access into a game through a wireless interface module manufactured by the OEM or better as a joint venture by both main OEMs.   

For the purposes of this document will refer to this hardware as the OEM-Module.  This would contain a unique ID number that would identify that device and used by the Restrictions to Limit Abuse (RLA) system.

    The OEM-Module hardware in many ways is the ‘easy bit’.        See 5 Architecture
    The Restrictions to Limit Abuse (RLA) is the bigger challenge.      See 6 RLA

4 Advantages of Third Party Hardware

•    Offers a variety of options for all disabled users
o    With full access into the game platform, an Open Source concept of controller hardware through small manufacturers and Maker communities would produce the variety of specialist hardware solution the disabled user requires.   
•    Maker communities should be naturally enthusiastic as demographically many are already gamers and not least it should be ‘fun’ and therefore motivational.
•    Gaming charities focused on disabled access could encourage small manufacturers as the hurdle of permitted access into the game play is openly granted.
•    Example Open Source code for interfacing through the normal Open Source platforms would be encouraged
•    Liabilities on the OEM for product safety and compliance would be largely transferred to the third party producer of the hardware.   
o    Wireless connection gives electrical isolation.  
o    The OEM would be responsible for ensuring EMC compliance of the OEM-Module.

5 Architecture

The OEM-Module is considered a component not an end product.  There would be no enclosure beyond the  shielding necessary for EMC compliance.  This approach places the compliance requirements onto the small scale manufacturer as the OEM-Module would be considered similar to an electronic component within the larger product.   The ID number of the OEM-Module will identify the hardware to users and thereby the user could use the same hardware across other gaming platforms or later iterations of the same console with same access.

OEM-Module Hardware:
•    Wireless
•    Internal product ID and serial number 
•    On/off control from third party button
•    Provide battery management
•    Provide load protected battery supply to the third party hardware
•    SPI connection to third party mother board
•    Twin USB connection to OEM buddy controller
•    Support Aux i.o  such as microphone & local speaker outputs, rumble drive etc

OEM-Module Firmware:
•    The OEM-Module firmware controls the user performance limits restrictions for OSC 1 and 2 use. See RLA section 6.
•    Library provided to Arduino platform and others as necessary.
o    Low latency inputs to all controls: buttons, joysticks, triggers, track pad, gyro
o    Outputs from OEM-Module to third party.  
    Rumble, microphone, speaker and other effects
    Status of OEM-Module
5.1 Hardware Architecture 
 
 
5.2 Software Architecture
 
 
6 Restrictions to Limit Abuse: The RLA System

There needs to be layered approach and a method incorporated into online games where the type of controller being used can be viewed by everyone and accepted by everyone playing the game.   Most easily by group policy for that game instance. 
There would be three levels of Open Source Controller: OSC1-3.  The traffic light colours red, amber, green are used to denote the nature of the OSC levels.
Online  games may allow or disallow any of these at the behest of the games user group.   Users of an Open Source Controller must accept this potential restriction on the grounds that cheating from nefarious players is a possibility.  It should be hoped that the highest level, OSC3, would be approved and would be accepted as authentic by most communities and embraced in a positive way.     
The OSC device itself could be validated online outside of the consoles control, and indication of its OSC state indicated by a RGB status led so that the user has direct confirmation.   If performance limitations are invoked the same status led would flash indicating that the user has exceeded the performance envelope  permitted and has been restricted.

OSC1  User name will be red 
Performance is limited to that of an average player.   This limitation is to primarily reduce the power of any macros used by able bodied users. eg would limit repeat times for buttons and possible bandwidth restrictions from analogue inputs.
OSC1 is for trailing the technology with new users and to encourage Makers into the eco system .  
Fellow gamers will have natural and healthy suspicion of OSC1 classed users and this would encourage upgrading to OSC2 or 3 levels 
OSC2  User name will be amber
Performance may be limited to that of a good player.   
To obtain OSC2 level of access a solemn declaration is made on an online form to declare oneself ‘disabled’ in a way that restricts ‘your ability to play’, and acknowledge that a OSC controller is necessary for them to compete on equal terms with those able to use a standard controller.  
The tone of the messaging is important so as not to offend and stigmatise valid disabled users.  Rather the positive messaging that this is necessary to reduce potential abuse by able bodied players.   
It would be expected that the majority of able bodied players would feel uncomfortable cheating by declaring themselves disabled to gain advantage.   This is a useful psychological barrier but admittedly not fool proof.

OSC3  User name will be green
Performance is unrestricted.  
To obtain OSC3 status the user must be ‘approved’ by a recognised body or charity associated with assisting disabled users.  This process should be simple and quick to administrate and such approval bodies could be appointed on a pyramid model where a charity such as Special Effect / AbleGamers / Warfighter Engaged / etc can grant authority to become an approval body to other organisations and interest groups that they trust and work closely with.  The process should be simple to administrate as possible and may be run by vetted web based volunteers.     
Such approval could be revoked if abuse is reported.  The reporting system is not outlined in this proposal and mentioned here to acknowledge the potential need.
A disabled user would apply online for such access, if unknown to the approval body a valid proof of their condition such as a email direct from a Health Care Professional, may be required before their OSC3 level is granted.   The exact nature of such approvals is not detailed here and is a topic for wider discussion but should try not be burdensome to any party.
OSC3 users should expect peer approval in regular games, however tournaments or closed groups would have the right to accept only valid OEM controllers at their discretion, with no ill feelings.   It is important for all to consider this as fair and reasonable for RLA process to exist at all.
 
Example: In game display of players
Displayed to all players prior to playing    

Nickname/name    Controller in use    
Graham Law    STD    name in black using a standard OEM controller
Graham Law    OSC1    name in red using a Open Source Controller Level 1
Graham Law    OSC2    name in amber using a Open Source Controller Level 2
Graham Law    OSC3    name in green using a Open Source Controller Level 3
Graham Law    UND    Name in red, using an unidentified or non standard controller.  Treated as OSC1

7 Legacy & PC gaming

Implementation of the RLA system as documented in 6 above maybe easier to impment with new titles.  For legacy games and non console play where peer competitors can not view controller type in use the RLA system could be different.
For example invoking time limits for OSC1 (red) to make full game play impractical,  stricter enforcement of performance limitations for OSC2 & 3.

8 Future possibilities

The above system RLA systems also lends itself to encompass existing third party hardware such as Titan and Cronus via the USB connection into the OSC device or implemented at the console level without any OSC hardware.
The registration process at the heart of the RLA system could grow to be a passport style access that has been suggested in the past.
Graham Law
November 2023