BGE Standard Controller Platform Proposal
Let’s Improve Controller support in the Blender Game Engine!
Warning, gigantic post follows:
The keyboard vs. controller debate has been going on for ages, and there’s no need to rehash it here (PLEASE don’t, I really want this thread to be productive - this thread is for BGE users and developers wishing to improve controller support in Blender- not for keyboard vs controller, console vs console or any other type of irrelevant debate or flamewar.) Each input method has its advantages and disadvantages for certain genres of games. Plus, sometimes, you just want to lay back on your couch with a controller!
Advantages of Improving and Standardizing Controller Support in the BGE
Controllers offer analog control for movement and camera orientation
The possibility for controller specific in-game prompts for faster explanation of the game’s interface to the player (this can be done with keyboard and mouse as well, albeit with a key-hunting safari)
A unique advantage for the BGE to offer developers and players making development and enjoyment of controller – centric Blender games fast, fluid, and predictable. As far as I know, no commercial or free game development platform has, or has even attempted to streamline support for controllers in this manner outside of dedicated gaming consoles (and they typically force you to use their proprietary or licensed solutions) - this is a (relatively) simple project that would give Blender a distinct edge over other platforms.
The Blender Game Engine currently has support for gamepads and joysticks, but barring extensive user configuration, no clearly communicable way for users to “plug and play” currently exists. While many controllers feature a similar array of controls, those controls can map to any number of “buttons” from the perspective of the game engine. For this reason, it isn’t practical to develop a BGE game, even one designed specifically with a controller or gamepad as the primary means of input, and expect users at home to be able to use his or her own controller without digging into the logic bricks or a configuration file of the game.
Even if a developer owns a large number of controllers from different manufacturers and tests them all extensively, (which I imagine would be a huge timesink and hassle not to mention expensive) when future controllers become common, or a player owns a “compatible” (in terms of numbers of buttons, joysticks, etc.) device that hasn’t been accounted for by that particular developer, that player will have to consult a (possibly nonexistent) manual for that game, learn how it is played and about all possible actions, then painstakingly map those actions (possibly in a very unintuitive poorly laid out way) to his or her controller. Anyone who’s tried to play a Games For Windows title that’s designed to work with ONLY the wired Xbox 360 controller with one’s own pad of a different make knows how frustrating this is. This BGE game better be amazing because the player is probably already really frustrated before even starting to play.
There are probably as many controller configurations out there as there are flavors of ice cream, but in the last decade a de facto standard has emerged. Not only is this format familiar to millions of gamers around the world, a large number of us probably already have these lying around. For those who don’t, there are both high quality (Sony, Microsoft, etc.) and cheap, but functional and compatible knockoffs that can be easily obtained at your local gaming store or big box retailer.
This is the type of controller I will discuss in my initial proposal here, but there’s no reason we couldn’t define subsets of this configuration to support devices with similar, but leaner controls. (For example, a Super Nintendo controller shares 4 Face Buttons, Start and Select, a D-Pad, and two Shoulder Buttons with its current-generation counterparts – this type of device could be supported “automagically” if the developer uses only these functions.)
What does a modern input device designed for gaming look like? Naming conventions for controls may vary from letters to shapes, to primary colors, but strip away the branding and they’re mostly the same. Thus, if we look at these controllers with a common naming convention, players and developers can talk about button layout transparently, regardless of the manufacturer of the controller. Below is an operationalization of this class of gamepad’s functions and one or more example terminology for labeling these functions for demonstration purposes, but I’d love to hear others’ suggestions- this is a community effort!
Format: Descriptive name (Abbreviated name or symbol for graphical or colloquial representation)
Two Analog Sticks each with a Vertical and Horizonal Axis
LS Left Stick (or Left Horizontal, Left Vertical)
RS Right Stick (or Right Horizontal, Right Vertical)
Two “Stick Clicks”
Left Click, Right Click (LC, RC)
Left 3, Right 3 (L3, R3)
Four Face Buttons
Alpha, Beta, Gamma, Delta (A, B, gamma, delta – don’t know if these characters would display properly)
North, South, East, West (N, S, E, W)
Four Shoulder Buttons, two on the right, two on the left
Left 1, Right 1, Left 2, Right 2. (L1, R1, L2, R2)
One Directional Pad with four Directions
Up, Down, Left, Right (Up Arrow, Down Arrow, etc.)
Two System Buttons
Start and Select (ST, SE)
One Meta Button
Meta (Blender Logo? )
Note: Could possibly be used as default button to terminate the game (ESC Key equivalent) or to bring up configuration options for the game.
Now that we have a common terminology for controller functions and the user can easily see (feel) which button this is on the controller he or she is holding, how does the game engine know which button is which? Again, not the only solution, but here’s my idea:
We (the BGE community) compile a list of common (as well as not-so-common) controllers and which of their buttons map to the previously defined standard. These values would be stored in a standard configuration file (probably just ASCII) multiple configurations in each device’s file for each particular platform supported by the BGE. Configuration files for all currently supported controllers would come packaged with this module and the user’s device would be automatically behave as expected as soon as he or she provides his or her A) Platform (OS, OS version) and B) Controller Type. If a configuration file appropriate for the player’s device is not present, that player can edit and existing configuration file to get it working locally, then submit this information to the maintainer(s) of this module and from then on, every subsequent version of the module would support that controller (on that platform). Or, alternatively, share the file on the forums for other users with the same controller until a new version of this module is released.
Initially, this would just be a Python script and configuration files passed around on the forum or in someone’s git, SVN or personal website, but if it becomes robust and comprehensive enough, maybe someday it could be included with Blender. In the future, we could think about things like rough calibration files for each controller, or even some standard scripts to make it easy for a user to calibrate his or her controller and send in configuration and calibration data.
What we can start doing immediately, however, is post information about controllers we own and what the BGE Joystick Sensor identifies those buttons/ axes as on Linux, Mac, Windows.
Possible Questions/ Concerns
Sounds like a lot of trouble. Shouldn’t the Blender developers do this?
No, I don’t think so. Developers are too busy working on more difficult, and frankly more important problems. This is not only something the community can do, but probably more effective at managing. There are exponentially more users than Blender coders, thus the community is in possession of more makes of controllers. The only coding required would be in Python, which most of us already know at least a little of. Hell, I think a lot of the code required for things like calibration is already floating around BA, but wouldn’t be that tough to write in the first place.
Why don’t you do it yourself if you love controllers so much?
I’m not a developer by any stretch, but I’ve fiddled with a lot of scripting languages over the years (Python lately) and I could definitely contribute some code. However, I wanted to present this proposal to the community first though, to see if there’s any interest in the first place, and because I know a lot of people on Blender Artists are a lot smarter than me and might have a better solution to the problem. (Weeks of coding can save you hours of planning!)
I’m a mod and I want you hanged for writing such an enormous post.
Sorry! I have a lot of time on my hands between semesters!
Whew, I guess that’s about all I have to say for now. I apologize again for the lengthy post, but I’ve been thinking about this for a while, and I’m just that big of a dork. I have a plethora of USB controllers myself and can provide data for them on both Linux and Windows, assuming anyone else cares about this.
What do you guys think?