Results 1 to 4 of 4

  Click here to go to the first staff post in this thread.   Thread: Technical Blog #9

  1.   This is the last staff post in this thread.   #1
    Technical Director John's Avatar
    Join Date
    Apr 2012
    Seattle, WA

    Technical Blog #9


    Gamepad support

    After my mobile porting efforts were complete, I switched focus to adding gamepad support to the Banner Saga. The idea was to complete a comprehensive gamepad scheme that worked well both for Xbox and Playstation style controllers.

    We contracted an outside agency, a company in Sweden called River ( to develop a UX design and wireframe for our game. We started with the most complex areas, such as combat.

    With this initial design in hand, I was able to go through the game step by step, implementing Gamepad control schemes, using the River design as a sort of dictionary of concepts.

    Adobe AIR has some built in Gamepad support called flash.ui.GameInput. This support is low level and handles notification when new controllers are attached, reports the state of controls, and provides notification when controls change. Atop this low level support we constructed our abstraction layer and game implementation. By this time, our Scaleform port of Banner Saga was well under way, so we investigated how this support would work across both Adobe AIR and Scaleform runtimes. Scaleform does not support or implement the flash.ui.GameInput APIs, but we determined that if we programmed to that API, our Scaleform port could provide a custom implementation for the necessary classes and functions in the API.

    The most difficult part of the port was making a mapping of low level inputs to game level abstracted inputs. On PC, Mac, and Linux, every controller reports a maddeningly different set of identifiers and names for controls. There is very little consistency. Some Directional Pads (dpads) are reported as analog sticks. On some devices, the analog triggers are reported as 2 different controls that range from 0 to +1. Sometimes they range from -1 to +1. Some Xbox controllers treat the 2 analog triggers as a single control that ranges from -1 to +1 depending on which analog triggers are pressed. You can't make this stuff up.

    I created a system that allows us to specify a mapping from low level controls to game level controls. This way we are able to specify mappings for a handful of known controllers. At the very least, we want the Desktop version of the game to support PS3, PS4, Xbox 360, and Xbox One controllers out of the box. However, it became clear very early that since we were dealing with 3 different Desktop platforms, each of which has several different possible drivers, trying to determine all these mappings myself was going to be impossible.

    So I decided it would be necessary to create an in-game gamepad mapping screen. This allows me to easily take a new and unknown controller, map it, and then incorporate my mapping into the mapping file that ships with the game. Furthermore, it allows QA to do the same thing, multiplying the effectiveness. Finally, for players who have even more obscure devices, not only can they use them (hopefully), but they can mail me their mapping files for inclusion into the default settings.

    Aside from creating the actual control logic of the game, I needed to come up with a system of representing the control hints overlaid on the game screen, and these control hints needed to look appropriate to the type of controller you have attached. River created control hint icons for 5 platforms: PS3, PS4, Xbox 360, Xbox One, and PS Vita. If you are mapping an unknown controller, the game asks you to choose which of these is the closest relative to your unknown controller.

    Furthermore, many tutorial text messages describe how to operate the game, but now we need to be able to tell you which controller button or stick to use. This is typically communicated in iconic format, so we had to develop a system allowing us to embed gamepad icons within text. This should be easy, and the flash TextField class is supposed to support inline html image tags, however as the now-familiar story goes, it simply doesn't work properly with our linked images. This necessitated the creation of a custom system for formatting the text and embedded icons. During this work we ran up against yet another bug in TextField, this time having to do with the reporting of text and character locations and sizes, in particular a serious bug in TextField.getCharBoundaries(). I eventually found a hacky way to get around the bug. You can read more about this issue here:

    The end result was a very satisfying gamepad controller scheme for Banner Saga. It is really enjoyable to play the game that way, and I can't wait to see the game on console. We release the gamepad controller support on Steam in April 2015. Based on some player feedback, as well as some mock reviews provided by Aim Assist ( we have identified some additional improvements and streamlining for gamepads. We are working on making those changes now for the upcoming console port releases, and will retro-fit those improvements back into the Steam build as soon as possible.

    Next: Technical Blog #10 (Linux and Console Ports)

    Previous: Technical Blog #8 (Mobile Porting)
    Last edited by John; 09-26-2015 at 12:38 PM.

  2. #2
    Skald Aleonymous's Avatar
    Join Date
    Mar 2013
    Sounds like implementing gamepad support was not as trivial as one would think. The most complicated part, in my opinion, is designing how the game will play with the gamepad, i.e. what buttons to push for what action etc. So, it was that River company that did that "dirty work"? Once that is set (tested and balanced) then the rest is just, uhm, technology! I would like to note that implementing that in-game gamepad-mapping screen was a true win for me as well, because my generic/no-name gamepad is otherwise never detected by Steam games.

    And a small piece of feedback: You should allow toggling on/off the gamepad-related icons on the HUD/GUI of the game.

    Finally, as the game is definitely meant to be played with a mouse (or on a touch screen) I found it exceedingly distrurbing trying to play it with the gamepad... And, to all those Steam/GoG players that wanna relax in their couch and play on the TV, I say: Get a wireless mouse! Playing on consoles is a totally different story, of course
    Together we stand, divided we fall.

  3. #3
    Thank your information

  4. #4
    Junior Member Ozariig's Avatar
    Join Date
    Sep 2015
    Thanks for posting this, John!

    The most interesting thing for me is that Gamepad support wasn't necessary for the initial release, knowing that ports would be planned. I can see now that PC (and recent console) devices and drivers are crazy, so it does seem wise to move Gamepad support out of the critical path of development. Very insightful!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts