Dev Blog 2 – UI Experiments & the Core Loop
Now that the basics of the game are functioning, it’s time to hook up some of the startup sequence, which in turn meant that I need (at least) some basic UI so I can display things and launch the game etc after load.
The Core Loop
Being an engineer-type, UI (and graphics in general) are far from my specialty, however one thing that I do like working on is the ‘game loop’. In any game, the ‘game loop’ is the basic cycle that the player repeats while playing. For ‘free 2 play’ games, a good game loop incorporates any theoretical monetization points etc as well as upgrade / enhancement hooks as well. For example, if you have a way to enhance or power up characters (Fusion / Evolution), you’d want to have this incorporated into the main Core Loop.
Anyways, other people that write about this stuff better than I do have explained this much better than I – definitely worth the read if you are working on anything like this yourself. Even if you aren’t working on free 2 play, understanding your game’s Core Loop is crucial to keeping your players engaged and coming back for more.
For Pixel Commando, incorporating things like Rewarded Video, randomized character rewards and power ups is a big part of the core loop. Before diving too far into actually building ‘anything’ the first thing that I wanted to do was actually detail what the ‘core loop’ was for the game. This helps drive what features are necessary and how they are incorporated into the game (UX Design).
The game that I’m influenced the most for Pixel Commando is Crossy Road. The idea of combining classic retro gameplay with an endless runner style game is at the core of what I’m trying to build. Luckily for me, there are more than a few articles that describe what Crossy Road does well, and why it has worked so well and become a huge success. My simple objective is to build on their success and see if I can create something that captures some of that same style, done with a different flair.
UX Design & the HIG
One interesting thing that I’m attempting to do with this UI is to at least pay some basic attention to the Human Interface Guidelines (HIG) that Apple & Google provide. The important thing to note is that both Apple and Google have invested a LOT of time and money in their interface guidelines – they have some of the best UX design talent in the world working at their respective companies. As app designers, we ignore their advice and recommendations at our own peril. They have created these guidelines to make our lives easier – it’s in our best interest to learn from the lessons that they have learned and make our apps better and more usable.
This includes simple things like how bit a button should be, but also incorporates details like ‘how do humans prefer to interact with an touch screen based application’. Interesting stuff, and extremely relevant for game creators, which is a point that I feel like I need to re-emphasize – just because you are working on a game does NOT mean that the native UI guidelines provided by Apple and Google should be ignored – in fact they are as equally important for games as they are for native applications.
UI vs UX
One interesting discussion that comes up often is the balance of UX vs UI design. Until recently, most game studios didn’t have anything remotely like a UX designer as a dedicated team member. The game designers were responsible for coming up with mockups for their UI while designing a particular feature. They in turn handed the mockups to a UI artist, who implemented the (already designed) UI and basically was responsible for ‘making it look good’.
This ‘may’ have worked for typical console or PC games (I say ‘may’ because this is arguable) where the UI for a game typically means throwing a few health bars onto the screen and calling it done. With the shift to mobile development however, the UI requirements for a typical game has increased significantly. For many mobile games, the ‘out game’ aspect of the app (the part of the game that isn’t the primary gameplay – typically the ‘battle mode’) is much larger and more complex than the ‘in-game’ gameplay modes (the battle mode).
Fortunately the role definitions and team makeup has changed in the past year or two – and the rise of proper UX design in the game industry is a huge step forward. Instead of simply building a UI because one was needed (and handing it off to the most junior person on the team to design and implement), the UX designers (or team) are now responsible for not only building the UI art assets, but driving the discussion about ‘why’ and ‘how’ the User Experience should be defined for a given feature or application.
UX design is basically the equivalent of data-driven game development – another buzz word often thrown about in mobile development – basically the practice of making decisions about a feature or element in the game based on objective, data-driven information, and not just because of a ‘hunch’ about how something should be portrayed.
The end result can be seen in many of the top-grossing titles on the Apple and Google marketplaces today. The reason these games are so successful is not a fluke – companies are investing quite a bit of time and effort into making sure that the User eXperience in their games is as intuitive and robust as possible.
Tips & Tricks
All of this is pretty heavy stuff if you have never encountered it before. Simply reading the Apple HIG documents takes a serious investment in time. It is a lot of information to digest and process, but it is well worth the effort.
When it comes down to implementing some of these lessons in my game engine of choice (Unity), and using the UI system that I have chosen (NGUI), there are definitely a few tricks that we can use to get us started down the correct path:
Setting your UI Root Scaling Style before you build anything:
The Apple HIG tells us that 44 pixels is the smallest ‘interactive area’ that we should target. This includes buttons, switches etc. However we also have to factor in the different display resolutions and aspect ratios that our game may run on at launch. Certain devices (more and more actually) support different pixel density (such as Retina displays etc). If you have ever done Native Android development, you may be familiar with the 2dpi, 4dpi etc assets that need to be considered when targetting different screen sizes & density. We must do the same thing for our mobile graphics.
The 44 pixel interactive area from above is based on a 320 pixel screen width (portrait) – but if we want to support the larger screen sizes of newer devices – AND still achieve pixel-perfect UI designs – then we need to apply the necessary scaling factor to our UI design, and UI Root (in NGUI terms) to make the UI work properly at all screen sizes. If we want to target larger tablets (with their 4x graphics pixel density) then we actually need to design our UI at a 1280px wide portrait width (or landscape height). This is actually much larger than most mobile game UI are designed for in my experience.
NGUI lets you apply a necessary scaling style on the UI Root object (& component), and will automatically adjust the UI scale and positioning based on this scaling factor. The settings that I’m using are shown below:
Note that this is assuming that the game will be displayed in a portrait orientation. The ‘content width’ property is the primary driver (the ‘fit’ checkbox) and the width that I have specified is 1280px wide. This means that the various device heights will not affect the UI placement that I have designed, and my UI will be pixel perfect for any aspect ratio.
NOTE: If you are designing a game for Landscape mode, you would set the ‘Content Height’ to 1280 and check the ‘fit’ option to achieve the same thing.
Anchoring & Placement
One of the most important things that you need to factor in when designing UI for mobile (and tbh any platform) is how you anchor the elements to the various edges of the screen. If you have done much Unity development, you’ll probably be familiar with the concept of using so-called ‘Empty’ GameObject’s for organizational purposes in your scenes. NGUI provides a similar concept that can help you organize elements as well – the UI Widget component.
Simply select the Parent object in your UI, and go to NGUI ->Create->Widget to create an empty widget. If you want to organize elements of your UI into sections, adding them into ‘Widget’ parents is very useful for a couple of reasons:
- They exist within the NGUI depth hierarchy – so you can order groups of widgets as a single element
- They support all of the ‘tweenable’ properties such as Alpha / Position etc (for transitions)
- They can have Anchors applied to them.
In the screenshot below, you’ll see that my Homescreen UI panel (pHomeScreen) has 2 widget containers – HighScoreContainer, and CurrentCoinsContainer – each are simply ‘UI Wdget’ components with an anchor applied – the Coins container anchored to the upper right, and the HighScore container to the upper left. This means that they will remain in position irregardless of what screen size the game uses – including Landscape orientation!
Organizing the Project
Pixel Commando uses effectively 3 scenes – 2 of which are used at runtime:
- UI Dev
The scene in question here is the ‘UI Dev’ one – basically a ‘working’ scene that I use to test the UI while in development (duh). Note that the ‘GameSystem’ parent object / prefab that the UI Panels are in is the actual prefab that I use ‘in-game’ – so the UI Root & Camera settings are correct and I know that the UI will render the same in-game.
Each of the Panels in the UI is created as a Prefab that the code will either load on demand during gameplay – or optionally the Startup scene has a ‘preload’ system that will asynchronously load the panels when the game is starting up. Depending on how many panels the game uses / requires it may or may not make sense to load the whole UI up front or not. In this case, the UI is fairly simple – what you see in the screenshot above is pretty much the whole UI minus a settings screen – so I’m preloading it when the game starts and then it will stay resident during the remainder of the gameplay.
Speaking of getting the preloading organized, I’m just working on getting all of this hooked up and wired together – next time I’ll probably talk about the random level generation…or possibly the pickup / powerup system (as that’s next on my list). Possibly both because that’s what I’m working on next ;}
Until next time!