Stupid Unity UI Navigation Tricks

A few months back, I played around with (yet again) rebuilding a half-finished Metroidvania-style game I’ve played around with off and on over the years.

One of my goals in this experiment was to use base Unity functionality as much as possible, replacing 2D Toolkit and custom systems as much as possible. One of the prime candidates for such a rewrite was the menu system:

If it’s not immediately obvious, that’s essentially a vertical menu with items that have horizontal behaviors. When “Equipment” is selected, you can choose an item to use or equip on the horizontal axis. When a volume slider is selected, you can adjust the value with the horizontal axis.

Importantly, the game’s intended to be played with a gamepad, so I didn’t want the presence or absence of mouse or touch input to affect this behavior.

Unity UI navigation is pretty smart, and got me most of the way there. If you’ve focused on mouse/touch interface when building your UI, good news: if it’s a grid-ish format, it probably works the way you’d expect. That’s thanks to…

Continue reading

Using a Kindle Fire as a demo device for gamedevs

I’ve been readying my demos for the Knox Game Design booth at the Knoxville Gaming Convention, which includes setting up some new demo tablets. Having used a Kindle Fire for demos a before, I feel like it’s a fairly reliable setup for anyone who develops Android games, so I thought I’d share it.

First, why?

The goal here is to have a device specifically for demos. I’d rather not put my personal tablet or phone, which is linked to my Google Play or Amazon Appstore accounts, up for public access.

I have an Intel Compute Stick (which runs $100-$200) that I can use to run full-fledged PC demos. It’s nice and flexible, but it means I have to carry around a TV for each demo station I want to run.

I like Kindle Fires as demo devices for a few reasons:

  • They’re cheap if you’re patient. If you watch Amazon.com deals and Woot.com (under Computers > Tablets), you can occasionally find good deals on older 6″ or 7″ Kindle models. For your average hobbyist developer, you don’t need anything fancier than that. I’ve bought a couple for $20-$30.
  • They’re fairly reliable. Given how fragmented Android is, I’m not inclined to trust the performance of off-brand tablets for games, so getting a name-brand tablet (especially a name brand that’s essentially building its own platform) seems like a safe bet to me.
  • Most models have a physical HDMI out. This was the real selling point for me. Sure, you don’t need it all the time, but it’s nice to be able to mirror something on a larger screen. (For a booth, it’s definitely more attention-grabbing than a row of tablets.)

Pay attention to the Android version

Remember that recent versions of Unity (e.g., within the last year or so) will not build to versions of Android before 4.1. If you’re buying a demo device that runs Android, make sure it can be officially upgraded to 4.1 or later, or you’ll need to rebuild your game in Unity 5. (Yes, there may be homebrew ROM upgrades available, but it may take some trial and error.)

For Kindle Fire, this means anything 2013 or later. If you want to be sure, there’s a list of versions and their corresponding devices on the Wikipedia page for Fire OS.

Setting up your Kindle Fire

If you’ve bought a tablet, you know how this goes. Your first startup is a tour of all the basic questions like language and wifi access, usually culminating in the option to login.

The key point here is to skip registering an account. You should have the option to do this during the process (for some models, you may have to go back to the previous step to do so), and the tablet should still work if you do.

If you bought a Kindle off of Amazon, the device may come pre-registered. You should find an option in Settings > Account to de-register the device.

Side-Loading your App

You don’t have to put your game on the Amazon Appstore to install it on your device; you can copy over the APK and install it from a file manager.

  1. Connect the tablet to your PC with a USB cable, and copy over the *.apk file to the file system.
  2. Go to Settings > Device and set “Allow installation of apps from unknown sources” to “Yes.”
  3. Open either Docs (newer) or OfficeSuite (older). (If you open OfficeSuite, you may have to open Filter and select “Show all files.”)
  4. Open the APK and choose to install the application.

If you get a “parse error” when you open the APK, go back and compare the tablet’s Android version to the minimum Android API level you selected in Unity.

Once installed your icon will show up on the complete list of apps. (It won’t necessarily show up on Games or certain other sections, simply because those aren’t available unless you register your Amazon account.)

Connecting to a TV

Physically mirroring your tablet to a TV is easy, but it requires some extra equipment you probably don’t have laying around.

The Kindle Fires I have use either SlimPort enabled USB (newer?) or micro-HDMI (older).

In the case of the USB, you can buy an adapter that will allow you to connect to both a HDMI cable (for mirroring) and a USB-B cable (for charging). This is the model I bought.

In the case of micro-HDMI, you’ll have a micro-HDMI port alongside your USB. (The HDMI port will be the wider of the two.) In this case, all you need is a micro-HDMI to HDMI cable.

 

 

Four ways to handle UI text in Unity

While converting some old 2D Toolkit-based Unity code to plain vanilla Unity recently, I ran into a conundrum: Unity’s got great support for standard font formats, but still isn’t quite up to par with tk2d’s support for building fonts from spritesheets.

An example of a sprite font

An example of a sprite font

It’s a minor issue–after all, it’s easier and more legible to drop in an existing font–but I wanted to keep the hand-drawn look.

So, I fell down the rabbit hole of cataloging the different options Unity provides for UI text (including TextMesh Pro, recently acquired by Unity and built in to 2018.1). While my knowledge of typography is pretty shallow (and it seems to be a rather complex topic), this should give you an idea of what’s out there and why you might want to use it.

Continue reading

Using Source Control with RPG Maker VX Ace

I mentioned in my intro to RPG Maker scripting post (and in the panel that’s based on it) that you can use source control systems like Mercurial or Git with RPG Maker VX Ace, allowing you to take periodic snapshots of your work.

(First, you’ll want to read a tutorial about how your chosen source control system works, such as hginit.com for Mercurial. This post will make a lot more sense once you do.)

What I neglected to mention is there’s two big, easy-to-forget gotchas with this setup.

Continue reading

RPG Maker VX Ace scripting: Thinking through a UI change

My last post was basically an info dump on what I’d learned about RPG Maker Ruby scripting during Ludum Dare 37. From the comments I got on it, I realized “info dump” is not an exaggeration–it’s literally a bunch of abstract, raw information without any examples, and so it’s confusing if you haven’t messed with it before.

So, let’s walk through how we’d think through a very simple change.

Continue reading

Instantiating a Procedurally Generated Platformer in Unity

This is a follow-up to my last post, Building a Procedurally Generated Platformer, which (not being a disciplined blogger) I’d sort of forgotten about until a comment about an off-hand remark I’d made about another blog post popped up in my RSS feed. Then (again, not being a disciplined blogger), I forgot about that half-finished post until I started thinking about writing a new post and checked my WordPress admin.

In the last post, we discussed one way you could randomly generate a two-dimensional array of values representing ground, platform, and trap tiles. For example, it might look like this:

ProceduralGeneratedPlatformerBlog9The trick, of course, is to convert each of these chunks into actual Unity objects, and to do so in a way that performs well.

Because we’ll be adding new chunks as needed, we want to make sure we don’t freeze play due to adding large chunks that are costly to instantiate. Because we want to restart the level quickly (without reloading the scene), we want to minimize the cost of creating new game objects.
Continue reading

Game Interface Design Gotchas

Over the course of the last two Ludum Dare jams (and subsequently developing Shifty Shapes and Retrofuture into full-fledged games), I’ve started thinking about user interface as a significant part of the design process. I won’t say it’s a grand unified theory of inputs, more like a checklist of where I’ve been bitten in the past.
Continue reading

Building a Procedurally Generated Platformer

ProceduralGeneratedPlatformerRecently, I’ve been playing around with a “procedurally generated endless runner” game concept in Unity. It’s really meant to be a set piece for Knox Game Design–a  multiplayer game that we can show off that’s both quick to play and has a lot of replay value. Here’s an explanation of how I accomplished that procedural generation. Continue reading

Ludum Dare 35 “Shifty Shapes” Post-Mortem

Here’s a quick rundown of the ups and downs of my compo entry, Shifty Shapes, which was written in Unity. (You can play it on itch.io.)

What went well

Concept

Shifty Shapes

Usually I make some notes about the top themes in each round of voting, but this time I went in cold. (Honestly: I have a few different game ideas floating around in my head right now, so I was open to doing something off-the-cuff.)

Once I decided to go with the “shape” wordplay, I had all of the rules for the game written down within minutes.

The sliding concept was inspired by a board game called Ricochet Robots that I played in analog gaming at Geek Media Expo, plus standard match-3 mechanics which I’d already figured out an algorithm for in Ludum Dare 30.

Animation

I knew I wanted this game to have some nice visual effects, since I envisioned it as one of those shiny mobile puzzle games.

Fortunately, there weren’t a lot of moving pieces in the concept, and I started building the effects early (even before I’d replaced the placeholder art).

Animation is something I don’t tend to think about (or I think about so late in the jam that it’s complicated to implement), but a little bit seems to go a long way.

Bouncing UI elements and blocks/items flying to their respective counts were easy to implement. I feel like my biggest win was making item and score counts only increment when the block/item reached it.

Music

The main riff was based on something I’ve played around with before on guitar–variants of C, with Am and Em thrown in, followed by a quick “bridge.” It worked pretty well, which means I spent about 10 minutes working out the tune, leaving most of Sunday for recording and mixing.

Unity UI

Because I wanted new blocks to fill in like a circular progress bar, I ended up having to mess with Unity UI early (as it supports “filled” images). I’ll confess, it’s something I’ve avoided for the longest time, because it’s intimidating.

Rather than mess around with the large block of numbers that don’t seem to change anything (Unity just recalculates the X and Y positions when you change them), I’ve preferred to stick to world space, Camera.orthographicSize and Camera.aspect, 2D Toolkit, etc.

However, I feel like I’ve made serious progress learning Unity UI thanks to this game. And because I didn’t need to dip into 2D Toolkit for text, I think this is the first Ludum Dare where I’ve had no Asset Store dependencies.

Coding

There are few things more satisfying as a coder than being able to call a “Reset” method after a Game Over screen (as opposed to “screw it, I’ll just reload the scene”).

What didn’t go well

Block pop-in effect

One of my big plans for visual effects was to have blocks “fill in” like a pie chart. That’s actually pretty complicated if you’re using Unity’s Sprites, and I spent more time than I’d like trying to make it work. Once I realized sprite masking was going to require shader code, I gave up on this approach.

Even though I was reluctant to mess with Unity UI, UI Image supported this exact feature, and I got the effect I wanted. However, I wish there was a way to do this via Sprites, and I spent more time than I’d have liked chasing that solution. (Although, I did do this first thing on Friday night so I could budget my time.)

Graphics

I’ve been playing around with Krita recently, and because of some of its pen and paint effects, I initially picked it over GIMP. However, the art I created didn’t feel right–it had a dark, hard-contrast feel.

This wasn’t Krita’s fault, I just wasn’t familiar with it. It was definitely a case of thinking a tool based more on physical mediums would magically produce something “painterly” without me having to understand how it worked. I ended up redoing everything (except the cloud particles) in GIMP, and was pretty satisfied with the result, despite spending a lot of extra time on unused art assets.

Music

Because I guess I have something to prove, I decided to try to mix in cajon, banjo, and mandolin in with guitar. I can’t tell whether it works or whether it’s all out of tune, because my first impression changes each time I listen to it.

I suspect part of the problem is I changed the speed on the guitar part in Audacity, and then tried to increase the pitch by the same percentage to compensate. Also, I’m not enough of a musician to pull this sort of thing off with consistent quality (which is why you’ll note all of the non-guitar tracks are mixed very low and silenced in places).

Build and release

To be fair, it went OK, but this is the first time I’ve been frustrated with myself for not planning in advance.

I always go in building for the default Unity 960×600, only to remember on Sunday afternoon that it’s slightly too large for the LD site’s embed (and even a little awkward in the browser alone). I really need to standardize on a resolution and aspect ratio before I go into a jam. I tend to just jump in the preview window and forget about this part.

Also, given that WebGL builds seem to take somewhat longer than Unity plugin builds did, I need to start planning for this in advance. Luckily, I did a release to itch.io on Saturday, so I was able to iron out some WebGL issues with particle effect sprites early, but it would’ve been stressful if I had waited until Sunday.