Dev Blog 3 – more build system fun

Now that I have the startup flow working and the first pass on the UI / front end system for the game, I’m back to looking a bit at the build system again.

Note that even though this is a 1-person project, I have a fully automated build pipeline created for the project. I don’t want to have to worry about creating builds to get onto my phone (or potential testers devices) – so it’s important to get a pipeline up and running as soon as possible.

Let’s take a look at the build pipeline that I have created, and the various build projects that it involves.

Build Toolchain:

  1. Gitlab – I use Gitlab for all of my personal source repositories for several reasons. First – it has 10Gb free private repo’s – MUCH larger than something like Bitbucket, and infinitely better than Github. It also has LFS support, which let’s Git play nicer with big (larger than 10Mb) files – this solves a huge potential issue when using Git for #gamedev. If things get serious enough, they also have a free open-source implementation that I can set up locally if I wanted (or on a server somewhere) should I want to have a personal / private git server.
  2. uTomate – incredibly useful automation utility for Unity 3d. Lets me ‘script’ my entire build pipeline using a visual flowcharting system. It’s what I used at Namco Bandai to set up the Unity build pipeline – and was very useful. Extending it with custom methods is very simple and having everything in a nice visual flowchart makes things nice and clean.
  3. TeamCity – My preferred continuous integration system. Jenkins is also popular (mainly because it’s free), but I find TeamCity so much nicer to use. Note that for Unity builds, I do NOT use the ‘Unity Runner’ plugin that ships with TeamCity. Every time I’ve tried to get it working has been a failure – and setting up Unity as a simple command line batch build is easy enough to do. At Namco Bandai & at Roadhouse we use(d) Jenkins for our CI Server, but I’ve always found it a bit flaky. I also really like the built-in Nuget server that TeamCity provides, which comes in handy for more complicated build pipelines.  If you have more than 20 build configurations, TeamCity costs money, but for a small 1-person shop like me, it’s effectively free – which is always nice ;}
  4. HockeyApp – You can think of HockeyApp as a private Google Play (or IOS) store that allows you to distribute test builds to your team and/or testers. You can register any number of test users into Hockey App and they can download & install the builds for testing purposes. There is a free version available that allows you to get up to try it out. It’s well worth investigation – I use it for my single-person projects to get builds from my build server to the devices I’m testing on.

Why Do I Need a Build Pipeline?

Some of you may be asking – why do I need a build pipeline at all?

There are several reasons – and most are fairly important.

1) It forces you to test your game on Device regularly

Unity is an awesome toolset. Being able to launch the game easily is absolutely crucial for rapid iteration and development. However, many developers fall into the trap of either ONLY testing their changes in the Unity Editor or not testing changes on a real target device often enough.

In my case, I’m working on a mobile game – until the game actually works properly ON A MOBILE DEVICE – then I don’t have anything.  If there are issues building to the target platform – then I want to know what those issues are AS SOON AS POSSIBLE. If there are issues running or otherwise playing the game on the target platform – I want to know as soon as possible.

I tend to work on my project every evening after work (and after the kids & wife are in bed). By making sure I commit the evening’s changes to Git that evening, I know that TeamCity will run and upload a new build to HockeyApp for me to test on the bus the next morning on the way to work. It’s an awesome system that works very well. Eventually, I’ll (hopefully) have testers that I can use HockeyApp to distribute new builds regularly to them as well.

2) Builds should be reproducible


One of the biggest challenges when creating software is the ‘it works on my machine’ syndrome.  Every programmer, ever has run into this problem. When it comes to a project that is expected to be (in theory) up and running for an undefined period live in the market (like a mobile game), you have to treat the code and project like a service from day one. The sooner you can get reproducible, testable builds into your users hands – the better.

By forcing myself to use a build system to create the builds that I test, I can be extra sure of a few things:

  • I actually checked everything into the source control system (git)
  • Application settings were handled properly (setting dev / prod / testing modes / debug flags etc) – can (and should be) all be automated and handled by the build system to configure the game for the target environment. This includes things like Facebook API Keys, GooglePlay Services API Keys, Analytics keys and so on. Anything that needs to be modified or changed when switching from a development / sandbox testing environment to a live / production environment – should ALL be automated through your build system.
  • I actually make a build of the game regularly. I’ve seen situations where a team goes days or weeks (months? [shudder]) between the points of having a testable build that can be run on a device. This is horrifying. At the point when a build fails and can not be run on a device – you should stop everything and FIX THE PROBLEM.

3) You test the whole pipeline / system

As I mentioned above, Unity is great – it lets you get things up and running quickly and easily. However as your project gets more complicated and has more moving parts – it can be easy to fall into the trap of not actually testing all of the components of your game in a real-world production environment often enough.

What do I mean?

  • Asset bundles – are you using them? How are you building them? Where are they being deployed to? How do you switch between different versions of your app?  Android and IOS require different bundles (as a simple example). Incompatibilities between Unity versions may require you to rebuild the bundles and redeploy to your users. What about cache handling? Cache busting? Versioning of the assets? All of these use cases need to be tested and handled properly well in advance of launch – so you might as well make them a regular part of your build / testing system. If you wait until the end of your project, you are asking for a whole lot of problems.
  • Server configuration – if your game requires a server, you probably (hopefully) have a development, staging and live production environments of the server. How are you switching between them in your client? How do you configure switching between these environments?

For the PixelCommando client, I currently have the following target builds and which platform they are targeting:

Build Projects

  • Android Client
  • Android Asset Bundles
  • IOS Client
  • IOS Asset Bundles
  • Windows PC Asset Bundles

Wait! you say – Windows PC Asset Bundles? What’s up with that? I thought this was a mobile game?

And you would be correct – except that I’m running the Unity editor itself on Windows – and I have the asset bundle pipeline fully integrated into my local development pipeline. So when I modify assets (add new ones, update or modify existing ones), I need to build & deploy the asset bundles for my device target (Android mostly) as well as bundles for the editor as well.

The above are the build projects for the Client – the Server builds are slightly more complicated – and something that I haven’t quite worked out all of the details for yet. I’ll go into those at a later date.

The asset bundle builds run basically the same pipeline as the main Client builds – with one major exception – they will be automatically uploaded to the end delivery location once they are build successfully.

In fact, this is the step of the pipeline that I’m working on currently – handling where the Asset Bundles are uploaded to (Amazon S3 bucket? FTP File server? etc) and how to handle downloading of the bundles to the client. I’ll let you know more when I sort this out!

Til next time!

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:

  1. They exist within the NGUI depth hierarchy – so you can order groups of widgets as a single element
  2. They support all of the ‘tweenable’ properties such as Alpha / Position etc (for transitions)
  3. 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!


Very useful.

Organizing the Project

Pixel Commando uses effectively 3 scenes – 2 of which are used at runtime:

  1. Startup
  2. Gameplay
  3. 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!

First Dev Blog!

Well look at that, a developer blog!

Might as well start out by introducing myself. My name is Mike Wuetherick, I’m the sole dev on Pixel Commandos (so far anyways).

I work at a great company called Roadhouse Interactive as my ‘day job’, where I am the ‘Director of Shared Solutions’ – basically I oversee their central tech division. One unfortunate side effect of being a ‘management type’ is that I don’t spend nearly enough time down in the code actually working on games.

Which brings me to Pixel Commandos. I’ve been tinkering with a bajillion ideas on the side over the past while, but all of the game ideas were either too big in scope or just didn’t get much further than prototyping / experiment mode. Pixel Commandos is my attempt to not only keep the scope small, but also try out a few game mechanics and ideas that I’ve been wanting to at the same time.

Before we had a computer at home, I spent a LOT of time while I was growing up in the local arcades at the mall in my home town. There were 3 games that have been imprinted on my brain forever – namely ‘Commando’, and it’s sequel ‘Mercs’, as well as the classic ‘Gauntlet’. If I could have a perfect smash up of an ideal game, it would combine these games into one.

  • Gauntlet & Mercs – for the crazy local coop and multiplayer fun
  • Commando – for the difficulty level & random bullet-hell chaos that would ensue
  • Mercs – because you could commandeer vehicles & battle boss enemies
  • Gauntlet – for the endless waves of crazy enemies

For the past few years, I have been working on mobile free 2 play games, plus I play a ton of mobile games on the side. Some of favorites are endless runners like jetpack joyride, ski safari, crossy road / pacman 256 and their clone smashy road.  I’m hoping to combine the mobile-friendly fun & ‘core loop’ of a crossy road with the classic run & gun gameplay from commando / mercs etc.

We’ll see how it goes. As of this writing, I’m at the end of about week 2 of development, if you go by calendar days, but in reality it’s about 4 or 5 days that I’ve actually had time to work on the game. As is the joy of #indiedev, you sneak time in when you can. I’m never sure whether to track schedules by actual calendar days or ‘indie dev work days’, but either way I’m pretty pleased with the progress so far. The core mechanic & gameplay is pretty solid – I’m happy with the movement & camera system so far, and I have the first pass on a procedural environment generation system in place.

Next up is starting to work on data-driving some of the game (so I can tweak game parameters from a google sheet and sync them into the game) as well as getting the startup procedure implemented (which grabs the metadata / inits it, etc). I have some of the startup flow working, just have to finalize it and get the metadata store initialized.

Til next time!

© 2016 Pixel Wizards | Legal

Pixel Wizards is a small indie game studio based in Vancouver, BC, Canada.