HEY! we got greenlit!

I'd read in a lot of places that the specifics governing the greenlight process are quite elusive, and based on the results from our campaign it seems like our experience was no different. however I think it's always nice to munch on some data if you're in a similar position, so here are the main stats from our behind-the-scenes:

click for full-size

after our initial announcement it seemed to me like we were off to a good start - the main factors here being featured on the new releases page for 2 days (by default), and traffic via twitter. however given that this wasn't followed by any press boosts or anything, after we dropped off that front page there was basically no direct traffic. which is totally expected, but also very easy to just feel stuck in as a result. this was literally just a case of randomly receiving an email from steam notifying us, after several weeks of maybe 2-3 votes a day on average.

it only really hit me that we'd basically prepared no 'promotional' material other than the campaign page itself after we'd made the campaign public. as a result I sort of hastily scrambled together some resources for press copies of our very non-intuitive build at the last minute. this seems simple to stay on top of in hindsight, but we just lost sight of what we needed in the excitement of just telling people about the thing. a good lesson for the future!


--


anyway, aside from the cold analytic marketing world, I had a lot of fun making the little celebration gif. I had to revisit the leg code, the internals of which I'd entirely forgotten (it's some of the earliest still-surviving code in the game). in the process of figuring out which specific guide nodes I wanted to move directly or apply tweens to, I got to see some pretty fun gymnastics:

online froggos

@nordanvinden thanks so much! I’m looking forward to getting into more tech posts again soon.

---

ahoy mateys! most recently I’ve been playing with the way I handle multiple control systems. both ReWired and InControl are very promising options for the future, but right now I’ve got a legacy version of InControl, allowing support for non-standard controller setups. it’s a little unsatisfying to implement something that’s definitely meant for the scrap-heap, but the benefit is that we now have a build that has been sent to a few press folks, among others.
that said, it was quite easy to get InControl running, but I’d love to know if anybody has experience with ReWired vs. InControl and what challenges both pose in the longer run.

all of us have been in a little bit of a collective limbo recently given the marketing focus and it’s starting to feel a little like I haven’t actually worked on the game in itself for a long time – the upside of this is that I’m very excited to return to the more interesting problems!
I feel like things could be a lot more life-filled. podes aren’t nearly as expressive as I’d like, and I think there’s a lot of room for hilarious squash and stretch given the current physics-driven limbs. adding some more nuanced face animations and generally fleshing out the movement capabilities is something to I’ll be treating myself to soon, I hope!

kieryn was also playing with some customization options for the podes beyond their heads (the plan has generally been to allow different hats, body colours, and little booties). not really sure if this'll stick but I think it's pretty fun to look at:

for now, the aim is to get in touch with some streamers / youtubers since I think the game generally shines when you actually have people playing it. we always meant for it to be something to bring people together, and it’s simultaneously demanding and liberating to be making a game where the ethos is almost one of “make it fun enough so that people forget about the game for what it is, and appreciate each other’s company instead”.

please do vote for us on Greenlight if you have the time and desire – the motivational boost of seeing a few more votes roll in cannot be understated!

We're live on Greenlight, please chuck us a vote!

it's felt like a very long time since I posted anything here, but a lot has been going on internally! I wish I'd kept track of developments more as they happen, but as in my previous update a lot of it has been under the hood. I've got the old legacy version of InControl hooked up, which enabled me to finally get some solid gameplay footage with the help of some lovely friends. I'll need to go back in and update this at a later point in time, but for now it feels great to be able to hook up a bunch of random non-standard controllers and have people play.

I'll hopefully write a big ol' tech post of sorts soon as I do enjoy writing them and I have some good moments captured, but for now it feels like a nice hefty milestone to finally publish the greenlight page. after telling ourselves that it'd be ready by this past August (classic). I'm going to be sending out builds and information soon to press and publishers and so forth, and I really hope to both get some more peepers on it and mediate my rapidly accelerating social-media-refresh neuroses

here's the trailer, in its final 1-minute form after much deliberation, humming and hawwing:

have some gifs too!

just a lil bump to remind that Kieryn's currently showing Muddledash off at GCAP Melbourne, today's your last day to nab him and give the game a go if you're nearby! tweet at us if you wanna hang out in general, as he'll be there for a while.

some sweet updates coming soon!

I don't have much to add just now as I'm mainly working on game flow for AIE Gameday but this just happened and I think it's important that you see

camera tests in Muddledash

hey!
after a sultry move to california I am now ready to emerge from my chrysalis a plump and boisterous game developer once more. if you'll lend me your eyes, I decided I'd like to talk a bit about how the camera works in game. I've been tweaking it a bit more recently and it's returned me to the right headspace. so!

 

camera cameraderie

essentially from the moment we decided to focus on non-fixed-screen multiplayer I was very conscious of how the camera should behave to accommodate players in different stages of the race. the whole respawn system didn’t come for a while but I knew that I was invariably going to have to deal with players in very different regions of the screen at any given point in time. so ignoring the dynamic tag-team respawns, the problem in essence has always been: how do we keep the relevant aspects of gameplay visible on screen at all times in spite of players having freedom of movement over the entire level?

dynamic zooming + velocity lookahead

the camera smoothly interpolates from its current position to the “true” (goal) position, which is determined from the players’ positions. the naïve way to get a goal position ignoring all positional information is just to take the average of player positions. this doesn’t make sense in a racing context however, as somebody at the back of the pack has the same amount of power as anybody else to drag the camera towards them.

Code:

// Naïve positional averaging
if (EqualPlayerPriority) {
    // Regular averaging of positions
    tx = 0;
    ty = 0;
    foreach (Player player in GameManager.ActivePlayers) {
        tx += player.transform.position.x;
        ty += player.transform.position.y;
    }
    tx /= GameManager.NumPlayersActive;
    ty /= GameManager.NumPlayersActive;
}

this way, if we have 4 players in game, they each get 0.25 or 25% of the positional influence. I actually use this just for the spawn room before races begin, since there’s not really a concept of a “leader” in that context and it’s nice to have a bit of motion alongside player movement from the get-go.
in the race itself, we don’t want somebody who’s ultra-fast to entirely eclipse the other players, nor somebody lagging behind to feel overly penalised too early. I store the players in a list sorted by their position in the race (I’ll make another post about how this is figured out since it actually turned out to be less straightforward than anticipated due to the room generation algorithm detailed in a previous post). the goal position is then weighted towards players in the lead, ensuring that the camera’s progressively following the “action” without straying too far from the pack.

the weighted camera positional update then looks a bit more like this:

Code:

// Weight camera priority towards players in the lead
float total = 0;
tx = 0; // goal x
ty = 0; // goal y

// playerOrderList is sorted from the leader at i = 0 to the furthest behind at i = totalActivePlayers
for (int i = 0; i < GameManager.playerOrderList.Count; i++) {
      Player player = GameManager.playerOrderList[i];

      // 'inverse' weight based on position - higher val for further forward players
      float contribution = GameManager.playerOrderList.Count - i;
      if (i == 0) contribution *= 2f; // Give double the standard weight to the leader

      total += contribution;

      // Update from position alone
      Vector2 pos = player.transform.position;
      tx += contribution * pos.x;
      ty += contribution * pos.y;
}

tx /= total;
ty /= total;

this works great except for in situations where players have very high velocities, in the case of e.g. slippy surfaces – since the camera’s position is smoothed out over time, in rare occasions the leader is able to accidentally run offscreen and get killed by a trigger volume (more on this below). so I just added a similarly weighted velocity offset to the positional update, smoothing this over the course of a few frames, to make sure it doesn’t end up looking absurdly shaky when players jump around.

the final ingredient paving the way to the current version is dynamic zooming. muddledash’s camera has a bunch of triggers associated with it:

to make a bit more sense of things, here’s a colour coded version of it:

the key areas to look at are the innermost 2, the teal and green.

if we detect a player in the teal area it implies that they’re significantly away from the goal camera position, which is roughly the center point of the screen (aside from the positional weighting). so this will tell the camera to zoom further out as long as at least one octopus is occupying a teal trigger’s zone. there’s a limit on this of course, just to prevent the camera zooming out indefinitely.
the green area reacts in essentially the opposite way, but it’s a bit more forgiving towards the far-behind players: a zooming in will only occur when all currently active octopodes are within its trigger volume. this means that the camera is a lot more likely in an average game to be zoomed quite far out, but it has the added benefit of really emphasising how close the race is getting when players are all clustered near each other. I do this just by keeping a list of players currently within the zoom-in area, and compare it against the number of players currently active – that is, initialized in-game and in the race.

the red area is a death trigger for players just offscreen, which in turn adds them a list to be respawned at a later date by another player.
and finally, the purple outline is specifically for the gift – it’s got a lot more yield on how far off-screen it can go before disappearing. this comes into play in places where the gift isn’t in anybody’s hands, and it can roll offscreen – it’s very jarring to run after a gift and find that it’s disappeared into thin air!

¿where did it go?

 
the speed at which the camera zooms out is also quite context dependent. when players enter a down-transitioning room or hit an up-transitional booster I signal the camera to zoom way out, which allows people to plan their route ahead a little and overall just feels fairer. this needs to happen quite rapidly just due to the speed of the falling / soaring podes involved. after a transition the zoom rate slows back down for regular play.

I’m accomplishing these smoothing transitions using the absolute classic:

Code:

// smoothVal in range (0, 1)
value += (target – value) * smoothVal

which you should also be multiplying by Time.deltaTime if you’re running outside of FixedUpdate (ie in framerate-dependent code, if using anything other than Unity). for the rapid booster / down room transitions I go as far as smoothing the ‘smoothVal’ variable itself! when there’s a lot of frenetic motion it helps to ease these transitions out a bit so people’s eyes don’t have to jerk around.

and there you have it! that’s more or less how it’s currently implemented. through more playtesting some constants might change here and there but it’s more or less what I’d call the final version.

player in "front" has more of an influence on the camera (indicated by rectangular trigger areas) when jumping at the start

we’ve got a couple of deadlines coming up where Kieryn (aka SafetySnail – it’s time he gets unmasked) will be showing the game off at some events, we’ll have more concrete info on that soon. it’s a great development motivator! hopefully these tech posts are interesting, and if anyone has any specific implementation questions about what we’ve shown so far I’m happy to delve into it more. right now I’m mostly working on getting some UI elements in place and multi-controller support, so I will jump on any excuse to interact with other humans.

hello again! been a bit quiet the past few days but it's been in prep for a couple of things - namely getting the alpha video together, and packing my stuff up to leave Australia. I've had a lot on my plate and in my head but am very happy to get it to the next 'milestone' before exiting the country!

a slight change: the game is now called Muddledash! we were collectively very fond of that 'p' but it turns out that there's actually another game called that - we'd been emailing back and forth but collectively decided it'd be best to change while it's still relatively early days.

we also now have a website, which you can check out here. I've now written a presskit using the lovely toolkit() resources by rami of vlambeer and others, and we're gearing up towards putting our greenlight out there. and getting some more gameplay footage! I'd love to do something arena gods-style with a highlight video of people playing on webcam alongside the footage to get some reactions (it never disappoints).

there have been some gameplay additions evident in the video, most prominently the addition of a little present. I want to talk about this at a bit more length, so I'll dedicate a post to it very soon (and get back to some tech breakdowns, I love writin' them and have had some fun optimizing in order to capture the game semismoothly on my old laptop).

so, the alpha video is VERY much an alpha - we've got one of rj's demo tracks in but all the sfx are sourced haphazardly from various places and aren't representative of the final sound design (particularly that gift-get-gong noise). with that in mind, please let us know what you think! it'd be great to hear if people can 'get' the game from this video, if there's anything too confounding, etc.

www.muddledash.com

some progress on the party room. it's not so clear in the gif but there is now rave lighting.

also added some of SafetySnail's plants and hooked them up to the decal system. here's a pretty screenshot I got earlier (soon our start room will be a bit clearer!)

click for fullsize

The party rooms remind me of Nidhogg's victory screen  

soon they'll all have swords too


I was fiddling with the trap designs again a bit last night. it'd been bothering us both that the boosters looked very well-defined in the space yet didn't really fit with any of the other art. it was the only object in the game to have a defined outline around it, and it looked jarring. I removed the outer line and added a gradient to it in the hopes that it'd fit a bit more with the flora and fauna of the world and it looked decent but still didn't sit so well with me:

I then tried removing the gradient and making it fully opaque but then it looked kinda dead:

..so finally I restored the transparency but ended up with a gradientless, outlineless, otherwise basically identical version of the booster. and now I am a happier man.

I also made a few closeup gifs of the various world features we have so far:

seed switch



goop patch (sounds less clinical than 'slippy surface', even if we never refer to these by name in-game)



flatgrass

working on Muddledash I dropped our 'partying octopus' prefab into a folder that auto-imports everything within it to be used as a piece of foliage. ended up with this

progress on party rooms is coming along juuuuust fiiiiine

(after a few mis-steps along the way)

the final parties are going to have a lot more inter-pode variation to fit the theme of the soiree in question. I'm having a lot of fun designing dance styles for these lil dudes. please help me figure out which other dances are necessary for octopodes to perform. so far I have:

- the robot
- wiggling

those are the only two dances I know.

Puddledash

and I'm back! since I arrived I've been working on seemingly everything-and-nothing at the same time. lots of tiny behind-the-scenes tweaks and bugfixing but no immediate content developments that are worth immediately showing. one good side of this is a handful of performance improvements - premature optimization as I mentioned earlier is something I want to try and avoid but there were a few quick fixes I wanted to do that'd been weighing on my mind.

the first of these is that every room that has some sort of foliage or decal in it is still being simulated when off-screen. unity takes care of culling mesh geometry and the general rendering side of things, but all my little plants were still swaying away unseen. my first solution to this was to attach a trigger area to the camera itself and detect entry / exits of rooms, but it got a bit messy with all the collision layers we have going on and I couldn't stop the camera trigger from listening for all object intersections. this meant it was checking for overlaps from every plant in the scene and it ended up being even slower than before.
so instead, I now just do some AABB-AABB overlap checks by hand from each room in the scene to the camera's bounds, accounting for the camera dynamically scaling. this check also doesn't need to happen every frame just because a lot of the time players will be situated within a couple of rooms of each other, so I instead just fire it every half second, and scale up the theoretical camera AABB to avoid any 'popping in' of objects.

I know I'm being a bit of a sun-fried fool with the way the foliage system works, as currently there are a lot of virtually identical objects in the scene and I'm not doing any object pooling at all, so I'm keeping a lot more in memory than is really necessary. I'm also sure there's a way to achieve all this transform-scaling using vertex animations in a shader, but it's currently in 'ain't broke, don't fix' territory. this is definitely something I'll come back to and clean up, but for now we're focused on getting together gameplay footage and a greenlight campaign (please stop by this thread soon for news on that front!)


I've also finally been tackling the placeholder art for flatgrass, seed shooters and switches. it's been getting really difficult to balance all the colours going on, so I decided to impose the restriction that all interactive objects e.g. traps will have the same base hue, but vary in saturation and luminance. hopefully this will make it easier to differentiate between plants and traps on the fly, especially once the player knows what the base silhouette of each one is.

I'd really like some opinions on how this looks. it's important that the flatgrass's behaviour is intuitive - it'll slow you down until it's been run through once, after which it's squashed down.

I also fixed a bug with flatgrass where the spring stiffness of each blade wasn't being reset correctly, resulting in an amateur KISS tribute concert when you ran over them twice

old awful temporary flatgrass

seed shooters have similarly been shown a little more love, and I've added a ｃｏｓｍｉｃ trail to them. they're still missing some sort of impact effect, but the trail combined with a little shadow they project under them hopefully makes them easier to see at speed, and I don't have to worry so much about colour contrasts.

finally I've been cleaning up the switches. their graphics aren't in-game right now, so I'll be working on that tonight. in the meantime here's the beginnings of some bunting I'm going to add. are you ready to party??

hahahaha oh my god the shopkeeper's wink

everything's still looking great. well done on staying strong through the UI phase! looking forward to playing this when it's out.

thanks both of you!

I have nothing major to update with other than this slippy surface gif I captured. I think my ever-present impulse to keep sliding up and down it means that it's working

can't tell if I should smooth out the bounce responses between players or if it looks benignly glitchy in a sort of endearing way. I'm going to be away over the next couple of days but safetysnail should be puttin up some design oriented stuff while I'm gone. stay tuned!

I've been working on a LOT of different aspects of the game over the past few days so I have quite a backlog of things I want to talk about. it's now turning into a bit of a mountainous task to do the topics justice, but I'll be starting wiiiiith:

procedural colour palettes

yet another one of those things that had been planned from the very beginning. it's belonged to the 'visual pass' of the game that I was saving for later in development and I'm very glad I treated it as such, because otherwise I don't know how long it would've taken  to build the rest of the game. the only downside is that when I came to it, the codebase structure and our art assets weren't so well equipped to just drop random colours into.

after a lot of back-and-forth before I settled on using SVG assets and SVG Importer. the sacrifice that came with this was the loss of the original mockup concept of soft filters on terrain. however, what began as a compromise has now transformed into a very definite preference, at least on my end. we had some in-person feedback from somebody who mentioned they liked the 'flat' look, and initially I was just batting it away with 'yeah that's temp art', but the more I mulled on it the more I realised that the planned colour palettes, foliage, gradients AND image filters were just going to look messy. it's also an easy shortcut to 'ah yes. this game looks like it was made with Flash's built-in filters', which I'd rather avoid.

the reason this is relevant is that SVG Importer by default was lacking some things I found myself needing for the levels, namely non-additive alpha blending. we settled on having the layer of 'goopiness' be represented by a translucent SVG layer underneath the base terrain shape. here's an example of it in action with a test SVG file I'd been working with:

the issue with the one on the left is that if there are multiple rooms chained together, we can't guarantee that they'll link in exactly (plus it's just a bit of a nuisance to constrain level designs to always perfectly lining up). this means that we draw our level overlays with a bit of 'overdraw', i.e. they bleed into the next room's object space. it becomes very obvious to the eye that the game is a system of rooms if you can see where each area starts and ends like that, so I ended up writing a very small modification to a shader for the one on the left that uses a stencil buffer to ensure overdraw is accounted for.
for reference, the bright Wobbledog-magenta is recoloured dynamically in a second pass and acts as the 'highlight' layer to give some more ~sheen~.
combining this selective highlighting with the alpha blending above, I end up with just a single shared material for the entirety of the base level's structure, which is then tinted according to our base hue.

. . ¿ but what should our base hue be ?

I've had a few pages bookmarked on colour theory (and algorithmic palette selection) since the dawn of time and I was looking forward to finally getting to implementing the ideas I'd read in days of internet yore. initially I focused a lot on trying things out from this article by Herman Tulleken (it's very thorough!), and was keen on the colour-harmony generator he'd posted. I think this is a great solution but I found myself  feeling that it was 'over-parametrised', and ended up tinkering for perhaps too long. I also attempted generating schemes around pre-set triads (here is a good page with a very nice intuitive guide to colour harmonies if you're unfamiliar). the problem with triad-schemes is that it gets increasingly difficult to ensure things amply contrast where they need to. when we already have background + foreground required to contrast, adding both traps - which players NEED to see - and foliage on top of that - which would be NICE to see - it gets tough to ensure something will work when randomised a little.

I went back to another article he references that I'd initially avoided as it didn't seem flexible enough. it merely boils down to rotating around the imaginary hue wheel in golden-ratio steps to ensure colours are never too close to one another. it works out really well - consider that a full 180 degree shift (or + 0.5 on a 0-1 normalised range) around the wheel results in direct complementary colours, shifting by just-a-bit-over (0.618 . . .) ensures that things still complement one another, and won't just simply repeat in cycles of 2. I added some range restrictions on the hue to avoid murky greens on the background or garish yellows on the foreground and it's working quite well.


so almost everything is done in HSV space and then converted to RGB for Unity's internal purposes. just shifting hues around the spectrum isn't quite enough, though - I've been playing around a lot with randomised and tuned saturation + value params for individual items. the rough rule of thumb is 'objects have to stand out no matter what. foliage can be somewhere in between' - in other words, prioritise contrast over the exact hue or saturation associated with switches, flatgrass, etc. it's been a bit of a battle to keep things looking nice while being easy to distinguish at speed, and for certain items like the boosters I extended another shader so that I could specify an outline colour that then gets a darker value than the base colour:

a dynamic tint object, before and after

the only thing that uses rgb-based randomization is the grassy foliage decals, which I've also padded out a bit with things like little mushrooms and swirly vines.

in the process I ended up refining the 'squish/push-able' script to be a lot more customisable. I've ended up being able to use it on most dynamic items in the game without it seeming recycled (hopefully). I'll put up a more in-depth post about it if there's any interest.

I have a feeling I'm not quite done in the colours realm but for now I'm happy enough to move on. SafetySnail is goin' bananas with room designs and we're clonking our heads together to try and get party rooms at the ends of levels. overall this game needs a LOT  more balloons and novelty party items, is my feeling. RJ is also beat-tinkering behind the scenes and we're aiming to get an alpha video out in the world very soon!

--

Hey just dropping in 2 ur thread 2 say hi & that the grass & char movement looks rly sproingy & good.

thanks, snappo. I radiate waves of mutual appreciation out in your direction. ps I'm going to be living in california for a year starting this september, hit me up if ever want to literally high five or discuss shader internals in excruciating detail together!

Never heard of a foliage decal system like that, but it's looking good. Although in the GIFs, it doesn't look like the plants are always appearing squashed when they should be. Looks like they get squashed when a player runs on top of them, but not if a player gets bumped on top of them by another player. Bug?

good eye! not quite a bug though, more a temporary decision to just-leave-it-be for the time being. currently any time a trigger associated with a player leaves the collision region of a plant piece it'll spring back up, so if there's more than one player on top of a plant and one leaves, it'll unsquash itself. this will get a proper treatment soon, but I also like the idea of people being able to hide in the grass if they liked (thinking the dummy heads here, prior to respawning). for now I'm focusing on getting at least first-pass assets for every object in the game so that we can record a gameplay video and start gettin the wurd out.

here's a procedural palette result from earlier today that looked extra snazz:

jmas, thank you for bringing the topic back to life!

I'm still working on flow state albeit slowly. currently almost all my focus is on making Puddledash with SafetySnail, while I'm still staying with him in Australia. however I'll be returning to the long lost digital skateboarding dreamworld soon.


so, to come in a little late..

Saw this on Twitter, looks really interesting, first-person skateboarding is a lovely idea.

Watching the video, the movement doesn't quite appear to be terribly similar to riding a skateboard? There seems to be the ability to almost strafe a bit, and to turn so suddenly that the board looks like it rotates around the middle, rather than by the wheels.

The early Tony Hawk games certainly felt like an abstraction of what it's really like to ride a skateboard, or perhaps a better way to describe it was a cartoon version, very quick acceleration and small turning circles, but the basic movement-model felt and looked like what skateboarding feels/looks like, even if it's all exaggerated. Some of that is present here, grinding looks great, for instance, but I wonder if a few tweaks to how the board turns, and how direction is changed, might really help?

Oh! And one missing sound effect - the wheel screetch! When the wheels do slide rather than roll, there's that iconic friction-squeek.

Really looking forward to seeing this develop.

thanks! regarding the movement: you're definitely right. however this is a stylistic choice - from the beginning I've been inspired by source games + quake movement. however this may only really need to apply when you're in the air (I have a soft spot for airstrafing) and the ground motion perhaps needs some tweaking, even on the level of opening up new level design options and differentiating it a bit from other games.

Looks cool so far! Is there going to be a multiplayer mode as well?

no multiplayer planned unfortunately - it's a bit too big of a beast for me to want to grapple with as a personal project, but it's always an option on the horizon if I'm still working on this a lot further down the line.

idk if i ever told you but i love this. my only question is: what makes this Special in a world with perfect stride

figure that out and you've got something here

tusind tak, min ven. I actually discovered Perfect Stride really late, long after I'd started getting the core of the game in place. I emailed the dudes at arcane kids and they were SUPER nice about it all, since I obviously don't want to just be cloning their game. after playing it I'm pretty comfortable with the fact that our games seem to be heading in different directions - while Perfect Stride is keen on huge airs and momentum I'm keeping the gameplay focus more technical and trick-based. regardless, when it comes to skateboarding games: Why Not Both?

no easily discernable changes at the moment, but I've been working a lot on getting processes automated between the art asset creation and the code. I have rooms automatically assigning themselves their corresponding art overlays and it's handling shifting platforms etc quite well. I do however feel like as I get crazier with particles and moving decals etc that I'm probably not being so efficient (one of our modified SVG shaders may be unnecessarily drawing terrain pixels twice and I'm not really sure how to check). in any case I try not to worry too much about prematurely optimizing anything as it's still smooth as a whistle, but the feeling's more 'bracing myself for what's to come' - if anybody has experience optimizing 2D stuff within unity please get in touch!

I've also juuuust begun dipping my toe into procedural palettes, and have started experimenting with varying backgrounds. here's a glitch I got from some materials that went missing:

octokyo drift

I personally really like how the darker levels end up looking - things will definitely be able to get all airy and pastel-y but I'm trying to make sure there really is variation in every corner of the game.