Chasing a Bug, More UI



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.
Now on to something more interesting. Just kidding its the UI again. Since Unity Remote 4 comes with it, and Google released it for free enough usage, I think I can assume I can use the Roboto fonts, since they look nice.

So now that the basic UI thing was sorted out I added in the win and lose condition, which was pretty much just checking however many nodes and signals were left. Winning even has a cool effect! More importantly however is that from alpha playtesting, it wasn't apparent enough what each symbol meant. So I ripped the UI apart and stuck it back together again (actually I just flipped the positions around and mirrored the images from the origin).



Why? Well, its simply a case of where you put your finger. If you used your right hand, your finger would cover the signal count. A left hand would cover the pointer count. So I moved everything up, and since the phase text is only in the middle, you'll always see that anyway. I realised this much later than I should have - any sufficient glance at pretty much every mobile app shows how the bottom of the screen is where nothing happens, since the user will most of the time be unable to see it.

Anyway that's pretty much it. Next up I'll probably be implementing some better way to draw attention to value changes, then an actual clear and fail screen.

FUN FACT: I spent a while deciding what to show when you lost, going by this logic:
  • Fail: Too informal, sounds like an insult.
  • Lose: Doesn't sound right, more like something that forgot grammar. Lost doesn't fare too well either.
  • You Tried: Too condescending.
  • Try Again: That should be the button afterwards, well that or restart, not the failure message itself.
  • Wrong: Again, sounds too aggressive, like Fail. Plus it doesn't quite match.
Also another fun thing - this time a stupid test.


No comments:

Post a Comment