The problem faced as we began building more visually complex games using PIXI was having layout specific logic in each separate view. The more things that could impact how a view could look, the greater this problem became. Quickly we started to mix layout logic with business logic.

Layout_Manager_7

code simplified slightly to emphasise issue

 

If you can imagine adding another factor into what could determine how the view could look to this code, you would quickly find yourself in “spaghetti code hell”.

The code had become inefficient, hard to read and harder to maintain.

 

The proposed solution

We came up with the idea for a Layout Manager to house all of our layout variables that we use for our PIXI views, and also to help manage having variables for specific orientations, platforms and devices. It returns what is essentially an object full of constants. The end goal of this was to abstract away the layout logic.

 

Setting it up

The process is started by creating a base layout file which contains the structure that the layout object will follow as well as the default values for all variables.

Layout_Manager_1

 

After this we can create a mobile, tablet and desktop layout file which contains any overrides for these platforms. These are split into separate objects for each orientation or any other scenario that would require a different set of values for the layout. The platform files aren’t actually a requirement and the Layout Manager will just use the base layout if the appropriate platform file doesn’t exist.

Layout_Manager_2

 

The Layout Manager also supports the ability to have device specific overrides:

Layout_Manager_3

 

This allows us to modify layout values for any particular tricky devices. This is quite often done for unusually small phone screens or small tablets with unusual aspect ratios. The functions can be as specific as we need, covering a single device or a range of devices.

We have considered moving the device overrides into separate files, but with the limited number of overrides and the simple checks in each one, the performance gain would minimal. This is especially true since the functions are currently only executed a maximum of three times in each game.

 

How it works

The Layout Manager api allows a little flexibility with what it returns. You can either access the game view, the chat view, or whichever of the two is currently applicable (i.e. if chat can be toggled and chat is currently open it will return the chat view). It will always return the current orientation for any of the views.

Layout_Manager_4

 

The process the layout manager takes to return the layout is as follows:

  • It takes the base layout
  • Merges the correct platform override object (e.g. tablet-portrait-chat)
  • Runs through all of the device override functions and applies any changes

Layout_Manager_5

 

Using the Layout Manager

Using the layout manager is simple. Once you’ve figured out which of the three functions is the most appropriate, it is just accessing variables in the returned layout object.

Layout_Manager_6

 

Conclusion

As the Layout Manager is quite new to the codebase, there are currently only a few games that use it. The results after doing this however have been positive, so there are plans to implement it into current/future games where appropriate.