Chasing a a Bug, More More UI

This one was particularly bad and I spent the best part of an evening trying to find and fix it, and as usual the error was because of some stupid assignment of variables that I must have wrote whilst half asleep or something. What happened was for some stupid reason I had the scripts activate the pointer in the array index equal to the number of pointer out rather than the first empty pointer slot in the array, meaning the whole thing broke if you added and removed pointers out of order. And the whole thing was dealt with by replacing the index numbers with the for loop variable used for finding the empty array space which I had already done at the start. Blegh.

Other than that, I've actually got a simple thing set up so that the levels can actually switch between each other, as well as a cheeky fade in effect to hide anything that could potentially be loading. Something that I discovered was that you have to enable a scene in File >> Build Settings... (Ctrl-Shift-B) in order to switch to them using code, otherwise you get the error telling you to enable it in the build settings. Unity is great for that kind of thing. It also seems to dictate load order, so I have a dummy scene set up at the top of the build list that initialises the static global variables (like the level the player is on) then redirects to the first actual scene. I'm not sure if this is the right way to do it but it works for me (cue crash to desktop/home screen).

All boring back end stuff, like trying to find out how to get on-scene GUITexture buttons to work, how to keep track of levels and how to make scene changes in code.

All in all, it's starting to come together. Sort of.

Making the End Screen

A winner is you!
So this post is about the process of making the end screen for a level. For starters, it was going to be a 3 star rating system, because its simple and effective. Plus, since the game uses limited tries, I figured that it was close enough to golf to apply similar rules - so each level has a "par" number and a "bogey", which translates to the signals left to give you a 3 or 2 star rating, after which you only get 1 star meaning you completed it. And of course no stars for a failed attempt. With that in mind I ran a few more ideas in my head of how the general structure of the thing would be, then sketched it down. The buttons are based on the standard symbols you find on phones for their corresponding tasks. This is a good inspiration for these kind of design choices.

Chasing a Bug, More UI

via Gfycat

Spent a while looking through code and rigorously testing various conditions whilst staring at the console log after my sister found a gameplay bug that caused Pointers to permanently disappear by randomly tapping on the screen. Turns out the problem was to do with the multi-touch to drag and pointers, which I've implemented in a really dumb way.

What happened was that when when the pointer was tapped on, the script sets the drag boolean to true, meaning it should run its drag code (moving around). The drag then finishes when the drag code detects that the finger was removed from the screen, which checks to see if the position is in the correct area to remove the pointer or not.

The error was caused by another piece of code that ran when the touch count was larger than 1, which set drag back to false again, but without checking for whether the pointer needed to be removed or not. Since drag was false, the event where you untapped the screen would never be registered and many problems were caused.

Actually looks like a UI

Or is that an UI. Oh english you so funny sometimes. Not much to report today, except this video - in dire need of needing to actually look nice. It also scales with phone size (see below).

Turns out GUI doesn't scale with different resolutions. But no matter - maths saves the day:

float tx, ty, width, height, multiplier;
multiplier = (1 / baseScreenHeight) * Screen.height;
width = g.pixelInset.width * multiplier;
tx = g.pixelInset.x * multiplier;
ty = g.pixelInset.y * multiplier;
height = g.pixelInset.height * multiplier;
g.pixelInset = new Rect(tx, ty,

Basically it just takes the original resolution (baseScreenHeight) which is set as a constant equal to whatever you set as the screen height for testing (such as 480 in a 320x480 screen). Then it does maths and changes the PixelInset of the GUITexture to the new screen resolution. Yay.

There's also a whole bunch of other stuff to consider, but I won't go into that - read this article. Especially the bit about density independence.

Unity: Scripts, meta and You


Can't add script.
Can't add component 'component' because it doesn't exist.
The associated script can not be loaded.
Please fix any compile errors and assign a valid script.

Only move scripts using the editor. Only rename scripts using the editor. Always make sure the file name of the script matches the class name in the script. These problems are generally due to meta file oopsies of one kind or another, since Unity provides so much integration between your code and the editor window.

Ya dun goofed. Check whether the script actually exists, and if the script's .meta file is in the same folder (or exists at all). If all else fails delete all .meta files and let Unity rebuild them all. 

Google it.

Fitting a UI in

Basically spent today planning up and incorporating a way to get the UI to fit in comfortably, as well as fixing several gameplay bugs, like being able to drag around invisible pointers and stacking every pointer on one space (issues caused by not ever disabling invisible pointers).

I've tweaked the zoom in various ways, such as the time it takes to zoom out, the way it picks the max scaling size (based on the largest direction - horizontal or vertical) and importantly increased the bottom portion of the screen's zoom border so that the UI won't interfere too much with anything over it.

The signals also no longer just disappear, but fade out once they reach the zoom border, so that looks pretty cool too.

Decisions, decisions...

That's a post title that will be occurring many times in the future. Things like how do I want the camera to move and zoom when the the user fires signals, and should the user be able to pan the camera around during the plan/wait phase.

I think it would be easiest to just ignore manual panning, as it simplifies things as well as makes it easier to keep track of everything. The camera max zoom will probably be bound as by the area needed to see all nodes, and the minimum zoom will be based on action - planning phase will allow zooming in all the way to the centre node, but during testing will follow the minimum bounds required to show all moving bits.

Moving controls to the phone

oh lawd.
Spent ages trying to figure out how to change the pointer from following the mouse to following the touchscreen.

Then I found this and that.

Tried to get the pointers (made multiple of them, one for each possible number of touches) to work with multi-touch, causing many, many array exceptions, since the size of Input.touches[] changes based on how many touches it detects. And when that didn't work, attempting to formulate some way of using ray casts from the tapped position to check against the collision of the entities.

Then I found this.

The moral of this story? Search the documentation before you jump onto the internet looking for silly answers to simple solutions. Also to note, is that sometimes Unity Remote 4 will stop working with unity when you run it. This is fixed by restarting Unity, at least its worked for me when it does happen (seems to be caused by things such as phone disconnection during gameplay). Also, Unity Remote 4 does actually support touch controls properly from the script, not just a translator for PC controls (meaning it does actually register Touch Phases).

Thinking up UI

So before I actually get into adding more stuff to Ping, I need to consider what it actually is going to be like as an interface. After all, no app has won any favour with unintuitive design and poor looks. Here are some notes of things I've considered.

Amazing design skills right here

Developing an Idea

I've hit upon an interesting idea  that could make for an android game.

an alt
Consideration for phone input is important.
And I've built a working prototype of this thing I'll call Ping. Time to see what I can actually do with it.

ping! pingpingping! pingpingpingpingpingping!

Iterative Design on bug wings

I always find that one of the toughest things about sprites is getting them to look just right, and especially for animations. An example is this flying wasp-thing I made the other day:

There are a surprising amount of choice in how you can animate this. The way the wings move in all three animations are based on things I have seen done similarly in the past, but its always a bit of personal preference as to which style fits best. I like the first one the most but it certainly wasn't the one I originally tried (in fact they made in order from right to left).

Thinking with Slopes & Platforms

I recently tried my hand at making a platforming game using GameMaker: Studio because of how much its changed, gained popularity and apparently is much less restrictive since the last time I tried to use it back in the 2000s.

The first thing about making a platformer is to consider what you want to go for at a later stage. This is important, especially in studios like GameMaker which only provide the basics, since it helps a lot to have support for things down the line - like if you want something to be moddable you do away with some things you'd usually make constants and instead assign them to variables. Not hard but can be a bit finicky at times if you plan to do it for a lot of variables. Plus it avoids brute forcing a problem (which is almost always a bad idea down the line, or immediately), and helps to avoid every build having a patch note along the lines of *tweaked X* or *fixed bug/exploit regarding X* or *fixed ctd caused by X*
For example, in my case I decided pretty early on that I'd use some slightly awkward things for my soon to be platformer engine to handle - namely slopes and one-way platforms like the ones in Sonic. This means things taking into account checking for single pixels increases in elevation and acting accordingly for slopes, and just generally awkwardness for one-way platforms.