Project Title: Ouya Console Development
Development: ActionScript 3.0
My Role: Programmer
This project basically allowed me a chance to spend time considering some of the unique solutions required to develop and deploy to console devices. Typically, since I'm used to building and testing content on computers, I have rarely had the chance to think about how various choices might impact or differentiate if I was intending the game for a console / television release. Therefore, I wanted to spend a bit of time experimenting with some of the possibilities. Before beginning the project, I was mindful that there would be several obstacles along the way, but ultimately I could not predict exactly what would hinder development.
First of all, I wound up working within the Ouya environment, particularly because of its accessibility. The Ouya itself offers several links to various sets of documentation for different game engines. For simplicity, I wound up choosing to work with Air, knowing that Air's method for creating apk files for the game would further increase productivity by providing a simple route for deployment. The apk files could either be brought manually to the Ouya device, placing it in the Android download folder, or the apk files could be linked to a Dropbox, allowing for the apk to be installed simply by accessing the Dropbox application on the console.
This ultimately would allow for ease of deployment, ensuring that new builds could be quickly tested on the device at any time. The only downside of this process is the inability to readily debug on the console. Regardless of what route is taken, this seemed to remain an issue universally for all game engines deploying to the Ouya. However, since the majority of simulations can be tested and debugged on a computer with controllers, the Ouya device would primarily serve as a means to test the usability and visuals of the game. Furthermore, I also implemented a Console output system to compensate for the lack of a debugger on the Ouya, providing a means to sample controller inputs and function calls.
One of the first hurdles I ran into is the reality that a television's screen does not necessarily mimic the swf output available on a computer. This is largely because the swf will always be set to its dimensions, while a television resolution is mostly unpredictable. Early on, this meant that not all contents were available on screen. I was aware of overscan, which was simply disabled via the monitor's menu, but this did not entirely remove the issue.
Ultimately, this required examining some of Air's settings. There are many different options that can be utilized, but for the moment I chose to apply the EXACT_FIT option, therefore rendering all aspects of the screen. Then, by setting the swf dimensions, accessing the information allows for all graphical adjustments within the application to correspond appropriately with the resolution, therefore scaling and positioning objects as expected, but with some distortion depending on the monitor in use.
Controllers wound up being the most tasking process for the duration of the project. Air's GameInput API allows some useful interactions to note the adding or removal of devices. With this information, I was able to create a ControllerInput class to warp the four possible controllers within the game environment. This class monitors the adding and removal of devices, setting the controllers with their player indexes and device references. This allows for a static call to the ControllerInput to access any particular controller within the collection. Each controller can also respond within device data, and note whether or not it has been connected.
GameInputDevice each contain a function to access input values at certain indexes. Each index represents one of the controller interactions, and the value may either be between 0 and 1, or between -1 and 1. The first range represents button pressed, while the second range conveys axis input. However, due to the difference between various controllers, there is no standard for reading input.
As a result, I created a GameController class to wrap the basic functionality of controllers. From there, I was able to create several Controller Profiles based on Ouya, Xbox, and Playstation controllers in order to read from the proper buttons without having to differentiate outside of their classes.
The GameController contains a Dictionary of ControllerButtons. Each ControllerButton contains the input index, the value, and the Test case. Each key in the dictionary represents the commonly understood titles, such as RIGHT_BUMPER. In the example of the Right Bumper, each Controller Profile might have a different index set. Each update, the GameController will set all of the values, and therefore would set the Right Bumper between 0 and 1. The Test value for Controller Buttons is defaulted to 1, but could potentially be changed depending on if the interaction does not default to the 0 to 1 range.
While the majority of buttons can be handled with a simple update loop, and called by applying the key term, the axis values required additional functions. The Left Stick, Right Stick, and DPad each have their own functions, which allow for values to be gathered and returned as a point representing the direction on demand. Each Controller Profile must override these functions or update the Indexes for Controller Buttons to change the manner in which input is applied.
There were several issues relating to controller development. The GameInput did not allow for universal controller readings between computer and console, therefore requiring the creation of different settings for deployment profiles. Furthermore, it took a bit to calculate all of the input interactions for the various types of controllers.
Limited to only a few devices, I discovered that there is a method for pairing Playstation controllers to the Ouya. This mostly takes advantage of the Bluetooth features by connecting the controller to the Ouya, pairing it, turning off the device, and restarting it to complete the connection. This quickly enabled me to begin testing with the maximum number of players at all times.
After working through the resolution and controller hurdles, I eventually was able to create a basic system for the application. This mainly takes advantage of the ability for controllers to scroll though options, allowing all players to be able to input commands on the menu screens. The current game eventually brings players to a connection screen, showing the currently connected devices. Players may then hit the (A) button to join, and press it again to begin the game. All players that have connected and joined will then be added to the game roster at the start.
At the moment, the game is extremely simple, mainly revolving around collecting stars for points. However, future development will likely move toward a more complex direction, now that the initial framework for the console development is completed.
As expected, the Ouya console development required several examinations of the deployment process, resolution settings, and controller implementation. After learning a bit about how to efficiently develop and deploy to the console, I eventually created a simple application and game to demo the framework. From this point, I intend to continue working on a design of a larger game, potentially examining different forms of AI. These implementations will also allow further console testing in terms of performance and player experience in a local multiplayer environment.
