Recovery mode

Both myself and my son Matthew managed to catch a particularly feral virus a couple of weeks ago.  For me, it was fever chills and sweaty sheets and sore throat glands and general flu-like symptoms, although I don’t think it was the flu per se.  For Matthew, it was a slight temperature and a sore tummy and time off school with Dad looking after me, yay! so it’s been a not entirely productive schedule on the game development front lately.  We seem to be on the mend now, but this last week past, just as I’d settle in for a solid morning’s work, I’d have the school call three days in a row to come and fetch a certain rather ill-looking malingerer who seemed to suspiciously perk up and demand McDonalds or KFC for lunch immediately after leaving the school premises.

Anyway.  A quick check in my source control commit log shows that, despite the setbacks, I’ve still managed to work on a fair bit of cool stuff since my last post:

  • Fixed some long-standing visual bugs, such as menu boggling, incorrect face LODs, and a few other miscellaneous horrors
  • Added in the “solution viewer”.  Every level comes with its solution built in as a list of moves, and the solution viewer will iterate through the list and show how to solve the level onscreen.  This allows players who get really stuck (or who have solved the level but want to see the “official” solution) to spend a “Mood Point” to view the solution.  I already had the stored moves, so to implement this I created a new HUD panel (with “Exit” and “Forward” buttons) and some tweens to swap this in and out with the regular panel.  Then when the user presses Forward, the camera lerps to the right location and also shows a crosshairs to help identify the coordinates, pauses for a moment, and then does the move (a tap or push).  It all works pretty well.  I still need to do some tidying up and visual refinement, maybe add a bit more “juice”, and put in some code to prevent user actions while the solution viewer is working, but it’s 80% done
  • Did a Unity version upgrade and then wasted two days finding and fixing obscure particle and texture problems caused by that
  • Wrote a tool which detects mobile orientation changes without constantly polling Input.deviceOrientation every frame.  The trick is to create a standalone canvas and standalone camera on their own layer, and put a marker GameObject with a transparent texture on the canvas just outside of Portrait sizing, so that it will only show up when the phone (or editor window) is rotated to Landscape.  Then I put a script with OnBecameVisible and OnBecameInvisible functions on the object, and those then pass the information up to my tools class to let the app know when the current display is either Portrait or Landscape, and to detect if one has changed to the other.  To be honest, the device polling wasn’t really costing all that much in the profiler, so this is kind of an over-engineered solution, so I mostly was curious to see if the idea worked more than having any real need for it
  • Started cleaning up FaceAnimationHandler class.  This and EmoterHandler are the two remaining handlers I need to clean, and then in theory most of my pooling bugs should be fixed
  • Finally solved Maths Nightmare #2 from my list of three unsolved maths-related obstacles: getting push forces to show a visual radius.  Rather than try to describe what this means in words, check out this video (the force radius is the “forcefield-like” green staticky stuff that expands out underneath the grids as the push grows):

I’m pretty pleased with the effect.  It’s not perfect – if you push to the maximum and then pan the grid around, you can see some overlap where the perspective distorts out past the grid edge a little bit – but it’s sufficient, and to fix that perspective issue would be incredibly difficult, so I’ll leave it like this.  Basically the goal was to have a visual radius effect expanding out when you push, to better show the radius of effect and help users know how much area the push covers.  Without this, the only visual indication was the bending of the grid itself and the slight shadows this produced, which wasn’t very easy to see where the curve was.  Now it’s more obvious without being overwhelming, and I like the cool forcefield effect – looks almost like an old SF movie green tractor beam.  Once I get Maths Nightmare #1 solved as well (tilting the world when you push, to really drive home the 3D effect) then it’ll look even better.  That challenge has defeated me several times now, although I’ve managed to get close, so I know it can be done if I lift my mathematics game enough

So a productive enough ten days or so, despite being in illness recovery mode.  I’m looking forward to next week (with Matthew back at school and hopefully not trying to skive off by exaggerating his sore tummy) when I’ll tackle some even tougher tasks on my To Do list.  The plan is to really hammer out most of the functional systems before I head back to Australia for a visit over Easter, and then work on content in the level editor while I’m there, ready for plugging in when I get back.  And then, finally, a release hopefully around mid-year.  Unless I get sick again…


Leave a Reply