Beginning of my journey in creating an open source controller for MCOC
Blizzard25
Member Posts: 67 ★★
Kabam please don't delete this again, this post follows all of your terms of service. Just read it.
So in my time playing MCOC, I've always felt like a controller would make this game a lot more intuitive and, in general, more enjoyable. After all this is just a 2D platformer, and 2D platform games are great with controllers. I do have sweaty hands which make extended gameplay difficult, and although there are thumb sleeves, the idea of a controller just intrigues me more. So I'm starting this thread which will serve as documentation for the processes of creating an Android controller with the following objectives: 1) Direct support explicitly for MCOC inputs, without actually being affiliated with any official Kabam code 2) Root mode should not be a requirement 3) Conforming to the MCOC TOS (i.e. no emulation) and 4) Configurable for other games and open source for anyone who wants to take on the task of adding additional support.
Now, before anyone says it, I know there are generic controllers out there like PS and XBox etc. I've tried a couple, but they have their drawbacks. One is a lack of support, Kabam has stated in quite a few forum posts that while there is some support for in-game controllers, there is no continuing development. You can find one of the many posts about this here: https://forums.playcontestofchampions.com/en/discussion/167009/controller-support
Also there are controllers which support specific games very well, but as stated earlier MCOC is not on any of their lists. If a controller does work, its input can be a little sketchy.
So on to the "fun" bits. This project will likely take me a while. Ideally under a year. Feel free to give your inputs on my design ideas and thought process, and I'll be updating the post as development is made.
Step 1: Choosing the options for the interface
So on a high level, a mobile game controller needs to be able to simulate user input. Did I swipe the left side of the screen, the right side, did I tap the screen or did i hold, did i press a specific button, etc. There's 5 ways (that I know of, someone add more information if I'm missing anything) that a controller can achieve this:
1) Modifying the game code directly to accept input from the controller. This is both against the TOS, a bannable offense, and honestly the most difficult solution, so I'm definitely not going to be using this method.
2) Android AccessibiltyServices (as of Android 4.0 or later). While this would be a really cool future enhancement to the controller, Android specifies this should only be used for those with disabilities. Looking through the documentation it does look like it has every event callback necessary to use. However I don't really want to abuse something meant for those with disabilities, and while again it would be really cool for the future for those with disabilities to be able to play, I have to pass on this for now I think. You can find out this service works here: https://developer.android.com/reference/android/accessibilityservice/AccessibilityService
3) Android InputManager. InputManager has an "injectTouchEvent" which does exactly what it sounds like. It can retrieve UI components and directly access their event handlers. However the way it does this is by modifying running code in memory, which Android won't allow you to do without a root device. Also this is pretty much like a 1a, it's still modifying the game code, just instead of doing it on stored memory you're modifying in executing memory. So I'm going to pass on this as well.
4) Human Interface Device (HID). To be quite honest, I don't really know that much about HID. I don't know if it works without root, if it's game specific, or basically anything at all about it except for the name and supported Android devices which you can find here: https://www.hidglobal.com/mobile-access-compatible-devices This might be an option, if anyone has any light they want to shine on it for me I'm all ears. However that's going to lead us to the final method, and then one I'll be exploring first
5) Sending USB commands from the controller to device over Android debug bridge, or adb. Now there is a small caveat here in that you do have to enable USB debugging, however 5 seconds of googling will tell you how to do that and enabling it takes even less time. While this is one of the more complicated solutions, it does exactly what I want within the requirements I specified earlier. Using an adb shell I can send simulated input commands based on x and y coordinates on the screen. Some of the challenges with this is that there are obviously a lot of varying screen sizes, and while I could allow the user to map touch inputs dynamically by just sending a request for adb shell getevent -1 and mapping the x, y coordinate of the touch, that's really not that user friendly. So the end goal here is just to have as many devices within the code itself that I can fit. If you have a better or more efficient solution, please let me know.
I'll likely start the prototype with an Arduino and USB shield and just hacking some parts on a bread board, but the end product will be its own PCB which I will use KiCAD to make, and then Fusion 360 for the controller design to 3D print. Mistakes will be made, but I'll keep you updated as I go. And as I said before, it's supposed to be open source, so if you want to join the effort with me just let me know!
So in my time playing MCOC, I've always felt like a controller would make this game a lot more intuitive and, in general, more enjoyable. After all this is just a 2D platformer, and 2D platform games are great with controllers. I do have sweaty hands which make extended gameplay difficult, and although there are thumb sleeves, the idea of a controller just intrigues me more. So I'm starting this thread which will serve as documentation for the processes of creating an Android controller with the following objectives: 1) Direct support explicitly for MCOC inputs, without actually being affiliated with any official Kabam code 2) Root mode should not be a requirement 3) Conforming to the MCOC TOS (i.e. no emulation) and 4) Configurable for other games and open source for anyone who wants to take on the task of adding additional support.
Now, before anyone says it, I know there are generic controllers out there like PS and XBox etc. I've tried a couple, but they have their drawbacks. One is a lack of support, Kabam has stated in quite a few forum posts that while there is some support for in-game controllers, there is no continuing development. You can find one of the many posts about this here: https://forums.playcontestofchampions.com/en/discussion/167009/controller-support
Also there are controllers which support specific games very well, but as stated earlier MCOC is not on any of their lists. If a controller does work, its input can be a little sketchy.
So on to the "fun" bits. This project will likely take me a while. Ideally under a year. Feel free to give your inputs on my design ideas and thought process, and I'll be updating the post as development is made.
Step 1: Choosing the options for the interface
So on a high level, a mobile game controller needs to be able to simulate user input. Did I swipe the left side of the screen, the right side, did I tap the screen or did i hold, did i press a specific button, etc. There's 5 ways (that I know of, someone add more information if I'm missing anything) that a controller can achieve this:
1) Modifying the game code directly to accept input from the controller. This is both against the TOS, a bannable offense, and honestly the most difficult solution, so I'm definitely not going to be using this method.
2) Android AccessibiltyServices (as of Android 4.0 or later). While this would be a really cool future enhancement to the controller, Android specifies this should only be used for those with disabilities. Looking through the documentation it does look like it has every event callback necessary to use. However I don't really want to abuse something meant for those with disabilities, and while again it would be really cool for the future for those with disabilities to be able to play, I have to pass on this for now I think. You can find out this service works here: https://developer.android.com/reference/android/accessibilityservice/AccessibilityService
3) Android InputManager. InputManager has an "injectTouchEvent" which does exactly what it sounds like. It can retrieve UI components and directly access their event handlers. However the way it does this is by modifying running code in memory, which Android won't allow you to do without a root device. Also this is pretty much like a 1a, it's still modifying the game code, just instead of doing it on stored memory you're modifying in executing memory. So I'm going to pass on this as well.
4) Human Interface Device (HID). To be quite honest, I don't really know that much about HID. I don't know if it works without root, if it's game specific, or basically anything at all about it except for the name and supported Android devices which you can find here: https://www.hidglobal.com/mobile-access-compatible-devices This might be an option, if anyone has any light they want to shine on it for me I'm all ears. However that's going to lead us to the final method, and then one I'll be exploring first
5) Sending USB commands from the controller to device over Android debug bridge, or adb. Now there is a small caveat here in that you do have to enable USB debugging, however 5 seconds of googling will tell you how to do that and enabling it takes even less time. While this is one of the more complicated solutions, it does exactly what I want within the requirements I specified earlier. Using an adb shell I can send simulated input commands based on x and y coordinates on the screen. Some of the challenges with this is that there are obviously a lot of varying screen sizes, and while I could allow the user to map touch inputs dynamically by just sending a request for adb shell getevent -1 and mapping the x, y coordinate of the touch, that's really not that user friendly. So the end goal here is just to have as many devices within the code itself that I can fit. If you have a better or more efficient solution, please let me know.
I'll likely start the prototype with an Arduino and USB shield and just hacking some parts on a bread board, but the end product will be its own PCB which I will use KiCAD to make, and then Fusion 360 for the controller design to 3D print. Mistakes will be made, but I'll keep you updated as I go. And as I said before, it's supposed to be open source, so if you want to join the effort with me just let me know!
11
Comments