Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Currently (subject to change) this runs on an Amazon t3a.small EC2 instance, which costs me $0.0188 an hour on-demand (was easiest to go with AWS since I already have other stuff running there), which is pennies compared to the non-selfhosted options out there. More importantly, it all seems to work, and it's even synchronizing everything to a github repository in XLIFF format, so I can breathe much easier knowing that rollbacks or tracking down issues are going to be that much easier.
I can probably stand to make this even nicer later on, but this is already a welcome change, and nobody has to wait those extra 5 seconds sitting through the Unity logo before the game starts, woo~
A long time ago I did some nifty optimizations around backdrops that had large opaque areas (obscuring big chunks of what was behind them). Essentially, if we know that the entire screen below a certain point is covered up, we don't need to bother rendering any of the backdrops below that point.
...eeexcept if the backdrop in question is transparent, in which case we =do= have to go ahead and still render everything. Now of course, I have a lot of backdrops that are opaque, so this is still a good improvement.
...eeexcept when I'm crossfading between two sets of backdrops in the menu. This special case has caused me a lot of headaches in the past and it was never performant on the Switch despite my best efforts. There's multiple problems at play here:
In the new setup, each set of backdrop layers is rendered at full opacity to two separate temporary render textures -- one for foreground layers, and one for background layers (for those of you who are familiar with how rendering works, we need to use premultiplied alpha here to handle transparency correctly). We can then easily crossfade between our temporary textures without having to worry about weird transparency blending artifacts. This took a bunch of work to set up, but actually massively simplified the menu backdrop handling code as I don't have to worry about doing weird juggling of the sort order of a bajillion different individual layers.
As usual, Unity gets you kinda halfway there but then you have to pick up the pieces, leaving you wondering whether you should have just implemented the entire feature yourself in the first place. Unity provides a virtual mouse cursor implementation that (fortunately) will hook into their UI input system, except:
Gamepad input is understandably something really hard to deal with (given the number of hoops you have to go through sometimes to get a given console controller working with your system), but I'm going to blame Unity for this one given that their old input manager implementation still picks up the gamepad's input in this case.
Ah yes, the telltale sign that you were about to play somebody's first Unity game. Anyways, fortunately for me, Incontrol's old open-source package contains device profiles for many known controllers. Granted, this hasn't been updated in the past 3 years (since Incontrol became a commercial closed-source asset), but I found that it was good enough for my purposes, at least for now. I integrated Incontrol's input handling and mapping, updated it to work with Unity 6, turned on XInput support, and "just like that", I have gamepad input testing and working for my XBox360 controller on Windows and on my PS3 controller across Windows and Mac.
This one is kind of on me. Unifont is designed to render minimally at size 16 (or 12, depending on what you're plugging it into), but because my game pixels are often already upscaled, I was having it sample at that size and then setting it to display at 50%. The UI canvas would for example be scaled up by 2x, so it ends up balancing out to present at 1x scale and render crisp pixels (which are 50% the size of the rest of the game's "pixels").
Of course, now the font is just bigger, so I run into issues where the glyphs can't really fit properly into the areas they're supposed to. But if you're using a language where the unicode font is used, you reallllyyy ought to not use the pixel-based font anyways (and the game is smart enough to default you to smooth font rendering in this case). Unless of course, you're playing at like 500x300 resolution for who-knows-what reason. In that case, this is actually an excellent change because the unicode pixel font now reads really well at that size, and you probably don't mind that the lettering is bigger!
Since this isn't immediately obvious how it would work, I've provided the tutorial icons below to show where the ghost ends up. It's actually simpler than it looks, as the timing is just equivalent to regular eighth notes (like a normal double-hit enemy). But now I can use this triplet->eighth note rhythm as a satisfying way to cap off a phrase.
This is another instance where I'm secretly making the rhythm easier to parse by adding extra elements -- the green combo enemies allow you to have a more obvious indicator of when you need to jump.
I feel okay using this tricky purple + yellow ghost combination as a "fixed pattern" since I already introduced it in level 6-3 at a slower tempo. As you can see, I'm also leaning more into variations on 16th-note flying enemy patterns as well.
I liked the way that looked, but wanted to add something more to it. My first attempt was just to do some mountains (clouds + mountains...just how many of my previous level backdrops are variations on this?):
It wasn't the worst (the dithering on the shading of the mountains was a nice touch), but I felt like it wasn't quite hitting right, plus it didn't really feel like it vibe with the whole space theme. I decided to try using translucent triangles instead, kind of like how I did in world 5, and that looked much better:
I'm scared at how this might perform on the switch (this is the kind of backdrop set that requires toggling off some layers when in low-quality graphics mode), but it looks beautiful when you see all of the translucent layers scrolling at different rates and blending together.
Past the very start of the song, you spend the entire time in the air through combinations of air jumps and flight patterns, as a nod to the theme of the song. The scrolling speed also increases bit by bit with every checkpoint, adding to the frenetic nature of the song. (PS: I spy mountains + clouds in the backdrops...)
This one is more laidback -- kind of a repetitive song, to be honest, but I made sure to chart each repetition a little differently so that you don't end up falling asleep (like I did during those music recitals...). It's also notable for being the first song I've charted that makes use of a non-4/4 time signature. (Hm? Yes, that functionality totally worked the first time that I tried it, there were no bugs to speak of, nope, not at all. ...why are you looking at me like that?)
Loading
