Rhythm Quest Update 9 - Redesign!

Didn't do any work on Rhythm Quest yesterday, so today I thought that I would go ahead and implement the shield notes for the third button and doing some work on sound effects, maybe even other types of notes.  Actually, I ended up doing a completely different set of work than I set out to do!

The most obvious change that you'll notice right off the bat is that there are only two tracks here instead of three, and only two buttons instead of three.  This is a pretty major change to the design, but one that I'm almost certain is right.

First off, there are two main reasons that the shield button was even there in the first place:

1) Using three buttons allows for more complicated gameplay and patterns.  Ripple Runner used three buttons to good effect (jump, ripple, flip).  Shield could potentially function differently from the other two buttons, just like Ripple Runner's flip, where you need to hold it down instead of tapping it (though my game as it stands is not set up for that).

2) Two different tracks didn't seem like it was giving the player enough choice.  I really wanted there to be a lot of replay value for playing a song through multiple times, and the whole idea was to have the player be able to sort of choose their own musical path.  Having a binary choice didn't seem like it gave the player enough options.

At the same time, I do think simplicity is important, especially I after watched this amazing talk from Unite earlier in the day (here's another interesting one).  I was already starting to try and draw up some sort of sprite for the shield notes, but there were a huge number of problems that were actually being created by the presence of the shield button and third track.  Let's list them out:

- I needed to come up with some sort of obstacle that made sense to require a shield for, but was also obvious that you couldn't use your sword for.  The best I came up with was some sort of spiky enemy, but it wasn't 100% intuitive why you couldn't just attack these enemies.  Projectiles would be a nice one, but unfortunately doesn't work because the obstacles need to be staying stationary (the player is the one that's moving)

- Not only that, but the visual range of the sword is bigger than that of the shield, so making both of the animations make sense given a certain distance from the obstacle is tricky.

- I'd probably make the player tap shield in time with the notes, but it doesn't really make logical sense why you can't just hold your shield up the whole time while running.  As mentioned above I could make the shield button function differently so that you =are= allowed to just hold it, but how would I convey that to the player intuitively?

- Having three tracks on the screen seems a little cluttered and there's kind of a lot going on on hte screen at once.

- Composing songs that are both cohesive yet have =3= different variations that all make sense when transitioning back and forth seemed like an incredibly daunting challenge the more that I thought about it.  It's also a lot of work, even if I can do it.

- I was already planning on having more complex obstacles, such as an enemy that requires a double attack (a la Melody Muncher), or spikes that have a flying bat over them so that you have to jump and then attack (a la Ripple Runner), plus notes that you have to hold down.  If I add in a third button to the mix, it starts to become too much to remember at once.  At best, you probably just give up trying to look at the visuals of the game and just focus on the colored diamonds, which becomes boring, and at worst you just get confused and frustrated.

- Visual (*and* musical) theming for the third area was always a little weak.  It was easy to think of ideas for two tracks (e.g. earth and sky, fire and ice, sun and moon, drums vs melody, normal vs halftime), but the third never really fit in.

So I thought to myself again and decided to critically evaluate whether the third button + track was really necessary, as it would be nice if I could get rid of it.  I decided that two buttons really is enough to have complex note charts -- Melody Muncher already proved that, after all.  And two different tracks also might be enough variation for the player.  It does limit you to binary choices, but at the same time there is something very clean and clear about having polarizing opposites that you choose from (e.g. Pokemon Red & Blue, Sun & Moon, Orcs vs Humans, any other faction vs faction game).  Not only that, but it allows me to create level designs and backgrounds that play off of these dichotomies like sun and moon, water vs fire, night vs day, etc.  It fixes all of the issues above and in the end leaves me with a stronger, more intuitive game that still has its core ideas more than intact.

So I'm super glad I came to that realization!  Just looking at the new layout already convinces me that I have a real game on my hands now (there's so much more space!).

So I spent some time refactoring away the third button (it wasn't that hard at all, to be honest), as well as rejiggering the backgrounds and layout so that there are only two tracks.

At some point when I was redoing the pivot for my player spritesheet I came to the realization that my center-pivoted sprites were all half a "unit" off.  As in, the "base" resolution of my game is 500x300 right now, but it's being upscaled 2x to 1000x600.  But the player sprite, as well as some others that are center-pivoted, were offset by one pixel in the 1000x600 rendering, so they didn't actually align with the original 500x300 grid.  I figured out that while Unity's sprite shader has a "pixel snap" feature and it works perfectly fine, it of course only snaps to rendered pixels at the 1000x600 granularity.  My solution in the end was just to put a 0.5 unit offset to all of my sprites that have a center pivot.  I could have used some sort of script that would forcibly clamp the rendering to be aligned with the 500x300 grid...but not only was that becoming a headache to do, but I also wasn't even sure I =wanted= to do that.  Particularly for scrolling and such, maybe it's better to use the finer-grained "half-resolution" pixels anyways.  So that's what I'm doing.

Along the way I discovered a Pixel Perfect Camera script that was released fairly recently in July for free.  With a bit of trepidation (you never know how robust these things are), I tried it out, and while the "Retro Snap" feature was causing some artifacts in my initial testing, it seems that the actual Pixel Perfect Camera script itself does pretty much exactly what I wanted in terms of scaling the camera view in integer multiples up to a certain size automatically.  (Now, it doesn't let you adjust those settings manually, but that shouldn't be a difficult extension to make, if I do even want that.  Again, maybe simplicity is best here)

So I ended up fixing my single-pixel-off issue, and along the way also got camera scaling, woohoo!  I refactored the camera controller so that it positions the player 20% of the way from the left of the screen, which should work fine for pretty much any reasonable resolution.  It's pretty cool to resize the Unity window and see the game scale up and down correctly in integer multiples.  Yay!

I also did some nice work on sound effects for jumping (in general), jumping successfully over spikes, slashing, and hitting an enemy, so those are all in.  Plus, you'll notice that the slashing attack looks WAY more polished now.  I've added a bit of minor screen shake when you hit an enemy, plus a new animated X pixel slash effect that I drew myself and put together real quick.  I'm attempting to use the ol trick where you draw a dark silhouette of the effect during the first frame before the actual animation, to increase the amount of contrast.

You'll also notice that I've added horizontal movement to the sword slash, which took some tweaking to get right but I think really makes it pop and feel satisfying.  Also, I reduced the size of the debug text, which was gigantic before.  Lastly, I tweaked Unity's audio latency settings a bit for better responsiveness.  It seems like it might be difficult to get super duper low latency without running into buffer problems, but so far it seems to be "reasonable".  We'll see what happens when we get it onto some other platforms as well. =X

The game is looking, feeling, and sounding a LOT better after these last bunch of hours that I sank into it.  Feeling pretty happy about it :)  Next up I might want to try implementing the other note types, as that should actually be relatively straightforward.  Then I'll try making an actual song and see what the gameplay really feels like!