16Naughts

Spring is here, so take the order To Go - Crescent Roll now runs natively on Steam Deck!

Happy (late) Thanksgiving! v1.6.0 of Crescent Roll is out, so now I get to do a bit of a status update.

Initially, v1.6.0 was going to be all about the Tiny Shade Garden, but once again, we had to adjust our plans a little bit. We mentioned previously that Android and IPhone versions were in the works, however they've gone a bit dormant due to us wanting to get to v2.0 before releasing them, as pushing updates to 4 different SKUs as fast as we do would be rather annoying. Because of this, Google gave us a bit of a scare at the beginning of the month, threatening to deactivate our developer account if we didn't do anything with it. Getting that account set up took a solid 2 months and lot of hair-pulling, and so it was war-room time to figure out if we needed to rush production, or if there was anything else we could do to keep our position. We got the Android build up and publishing again, created a beta store page, and now have a way to go through Google's special signature stuff. Fortunately, that was enough to satisfy them as being "active". Although it ended up requiring quite a bit of technical changes behind the scenes, which is why this update is just a little light on the cool new big stuff compared to the previous ones.

We're now looking at v1.7.0 scheduled for sometime around Christmas/New Years Day, and it's probably going to be a significant number of changes to the way the modding system is structured, potentially with it coming out of beta and Steam Workshop support, if all goes right. I really, really want the level editor to be included as part of that, but before that happens, the UI toolkit needs a few more bells and whistles, so it may or may not make it. As for the TSG, it plays a significantly larger part in the next title, so some of the previously designed enhancements may be deferred until that is a little more solid and closer to being out.

So, the current update schedule looks something like this: v1.7.0 : Late Dec 2025 - Mod and Workshop Update v1.8.0 : Feb-Mar 2026 - Campaign Update v1.9.0 : Apr-May 2026 - VS Update v2.0.0 : Jun-Jul 2026 - Clean Up and Android+IPhone Release

Happy Halloween! v1.5.0 of Crescent Roll just came out, which includes the first version of the new Tiny Shade Garden. Though this is the dev blog and not an ad, so you'll have to read the Steam post if you want the finer details. Admittedly, it's also a little lightweight on stuff to do with the little beasts just yet, but we might just have something good here by Thanksgiving.

Going forward, I'm only going to be posting here for sprint postmortems and planned stuff after new versions rather than the preview kind of thing we were doing weekly before. A lot of the "getting off the ground" stuff is over at this point, and turnaround on features is either so quick that there's nothing to really talk about, or in a lot of cases is something that we want to keep a surprise and can't talk about anyway so a lot of the previous updates just turned out to be fluff.

So, we've already done a few posts about the development of the TSG, and there's not a whole lot more that we could cover without getting into the next update. The TSG in the code is considered completely separate from the rest of Crescent Roll, so for anyone looking to modding it, it's not quite supported at the moment. We had to take additional care for how modded items affect the stat growth of the Shades, as well as how transfer of those Shades to other games would work if they have modded appearances, so it will likely be another update or two before that is all opened up.

To recap, the next update is probably going to be somewhere around Thanksgiving, if all goes well. It's mostly just some things for the TSG that we weren't able to completely polish in time. Probably a few more stages and hopefully another set or two of Challenge Mode levels - the typical Holiday style updates we were doing in the Spring again. Christmas might have something bigger, but it's too early to tell at this point, so no promises.

We have hit another issue with the Linux WebKit stuff becoming significantly harder to deal with - our testing apparatus on Windows to emulate a Steam Deck setup had a massive performance hit to the point where it's completely unusable. Ironically, the Steam Deck itself now runs faster than ever, so it's something Microsoft changed with WSL2 interfacing. Fortunately, checking everything in CR is pretty quick, but we did have to scramble a little bit to fix a coding discrepancy where our version of WebKit was missing some Iterator functions somewhat last-minute. So, at some point in the near future, we're going to need to take the time to set up some real testing infrastructure, especially once the other platforms come into the picture.

We're moving right along with the Shade Garden addition. It's a lot of little tweaks and additions, and not a whole lot of fun stuff to talk about. Which seems to be the general theme with a lot of these updates, but you know - that's life in general.

One thing that we've been kind of keeping our eyes on in the background is the continued growth of Linux in the gaming sphere. Since Valve made the Steam Deck, a lot of other hardware companies are starting to jump on the bandwagon. Which, as long as the Steam Deck remains the minimum specs, Crescent Roll should run on any Linux box that supports Steam.

...Up to 1280x800 60Hz, that is...

Call me paranoid, but I still haven't gotten over the pain of that WebKit saga. We've done everything we can to get it running at full speed, but having the final draw to screen being bottlenecked to the CPU by WebKit itself dashes all hopes we could have of getting to 4K on Linux, even though our Windows build can handle it effortlessly. And now since even the Switch 2 does 4K, that's not a good look.

If Valve releases the Steam Runtime 4.0 based on Debian 12, we can upgrade WebKit, and then the new version uses a GPU-based compositor and everything is golden. But there hasn't been any kind of official announcement, so we're still picking through alternatives to WebKit.

Ladybird is a completely new Web Browser, and is looking really promising, but right now it has the same problem that all of these kinds of independent purist projects have - you have to compile the dang thing yourself, and it has a laundry load of prerequisites and takes _hours_ to do so. So please, if you're a developer, and you have a public project with a CI build, also make that build publicly available. I can spin up a VM with any OS in a couple of minutes to test the thing out and maybe help with some bug reporting or reproduction investigation, but we have full time jobs, so it's not worth wasting a week screwing with custom build scripts.

Another, slightly older alternative is Servo, which is based on the Firefox stack. It was mostly dormant for a bit, but this past few years did some major catching up. It's got some weird little quirks about different JS modules that don't exactly work how they do in other browsers, but for our purposes, it's good enough. I think. We've only really messed with the Windows version, and would need some significant development for our engine to be able to bootstrap it for Linux, but from what we've tested so far, yeah - that's a definitive maybe.

Our house is the last house on the block to stick up Halloween decorations at this point. It's the middle of September. I'm feeling peer pressured.

The Shade Garden work is progressing smoothly, albeit a bit more slowly than I was aiming for. Code is great and easy. Music is considerably less so, and art is just a slog if you can't catch a wave of inspiration. The little creatures are all running around at this point, but the menu designs are just not coming together. We still have a month or so though before my self-imposed deadline, so nothing to do but keep throwing stuff at it until something sticks, I suppose.

Something kind of exciting for me is that I was finally able to knock down that loading time a little. To summarize, we found that on average for our machines, it takes 1-3 sec for all of the game data to load (and I mean all BGM, stages, animations, the whole thing), and then an additional 10-15 sec for the shaders to compile. Which, we can't pre-compile, and we can't cache due to limitations in the WebGL specification, and we can't switch to WebGPU because Steam Deck can't support it.

So, I took a couple of days to mess around with different parts of the shaders to see what was actually causing it. I changed packing order, tried hard-coding attribute locations to avoid lookups, manually inlined stuff. Just all kinds of weird tricks to poke and prod what the compiler was having such a hard time with. Then we found it: by dummying out the texture lookup code, the shader compilation time dropped to a few seconds. So bingo - we found our root cause.

Crescent Roll uses a batch rendering system for its sprites, where every texture slot on the GPU is filled up (16 for the GL standard), and then it sends the draw call to the GPU. Talking to the GPU is expensive, so this causes a pretty big speedup for the game. This complicates the shaders a little bit, as there's now conditional logic for picking exactly which texture slot to use (as you can't index arrays with non-constants like in most other languages). Conditionals are famously slow for GPU programming, but we've already done profiling for this that, and switched from a 16 case conditional to a 4-level binary tree check for the texture selection to get that running super fast on the GPU. However, what we did not initially notice is that this nested branching seems to be the root cause of the majority of our compilation time woes.

So, what to do? Obviously, we have to reduce branching. How do you do that? OpenGL has the function "mix", which does linear interpolation between two values based on a third value which is 0.0-1.0, and then "step", which is a cheaper non-branching version of "return a > b ? 1 : 0". We can fake a conditional by using a mix with a step as the third parameter.

Observe, the 16-texture switch-off:

I am pleased to report that this strategy drops compilation time from 10 sec down to merely 4 sec on my 1070Ti, while only increasing GPU usage from about 5.5% up to 6.0% on the Main Menu (currently our most demanding scene).

The only unfortunate part is that any work done for the two value arguments for mix are always calculated no matter what, unlike a real conditional which can just skip that. However, in the case of modern GPUs, the next instruction of code is already being executed before the current one finishes, and in the case of a conditional, it essentially has to guess which one to use before it knows for certain. And if it gets it wrong, it has to back up and re-do the other side of the branch. This is the expensive part, as the execution pipeline might be 10+ stages long, and if you have to throw out 10 cycles worth of calculations, that's a lot of energy spent on just generating heat. In our case specifically, all 16 textures are used in rotation, but it's always one incremented after the other, so the same branch path will never be taken twice in a row, and it will always miss (minus when the program would get divided up into multiple cores and the same one would run for the same texture slot every time, but we're getting so far into the weeds at this point as it is). Yes, it's doing the additional sampling(s) on the texture, but two samplings in a row are cheaper than sampling the wrong one and having to backtrack to do the other.

I'm typing this up as the Nintendo Direct wraps up, and I'm always amazed at the sheer range of games announced and showcased. You've got Overcooked, Stardew Valley, and Suika Game, then here comes Resident Evil and Mortal Combat, then over to Mario and Pikachu and Lego. Every size of developer all sort of hanging out in this mishmash of genres for every age range in essentially a commercial news broadcast. If you think about it too long, it really shouldn't work on paper, but these are now one of The Gaming Events of each year. But everyone has that One Series they really care about, and when it gets its screen time, the hype is unreal. Also Virtual Boy. There's balls coming out of left field, and then there's your third baseman getting thrown a basketball.

Just yesterday, we pushed out patch v1.4.6 for Crescent Roll. I was hoping to hold off on any additional updates until v1.5 here, but, unfortunately, our hand was forced due to Microsoft rolling out an update that caused some flickering on the Main Menu. The scary part was that it retroactively applied to _every_ single version of Crescent Roll, and there's nothing we can do to fix those.

Crescent Roll is an HTML5 game written in Ecmascript (no calling it JS until Deno wins the patent nullification) played in a special desktop harness application that uses Microsoft WebView2 under the hood to essentially use the Edge web browser core for interpreting the code. The practice of baking in a Web Browser with the OS is pretty common now - only Linux doesn't want to do it (which caused a saga with the Steam Deck, but we've already gone over that). So it's write once, run everywhere. For the most part.

At first, I thought it was just my graphics card dying, as I've had similar problems in the past on a laptop well past its prime. Once one of our associates noticed an issue though (on the Steam release that's been there for almost a month), that's when panic set in. We figured out that the GPU was suddenly drawing all of the GL commands too early pretty quickly, but on seemingly random frames. Nobody else was complaining about this online, so it was definitely something somewhat unique to our setup.

The first thing that we did was attempt to switch to using a fixed version of WebView2 instead of the Evergreen one. It was surprisingly easy, (and we've left that option in as a secret in the runtime if we ever need to tell people to use it to fix other issues in the future), and we were horrified to find out that the issue was present even in those older fixed versions - so we now knew that the change was something deep down closer to the display driver, which we just can't hack around. Flickering can cause seizures, so we scrambled to check the CEF runtime that we had on backup, and fortunately, it seemed to be fine, so we at least had an out if we couldn't fix the root issue. But we knew what was happening already, so I decided to go for the fix.

After some "throwing things at the wall to see what sticks" attempts, we stumbled out of the GL calls and into the setup of the canvas itself. And within the HTMLCanvasElement object, the getContext call. We've had to tweak this a couple of times to try and squeeze the best performance out of the system, and there was always a little confusion about what exactly every single option meant. So we went one-by-one, and presto: disabling "desynchronized" fixed the premature draw. Originally, I understood the documentation to mean "don't implicitly push at the end of a frame and instead wait for an explicit gl.Flush()", but apparently, it actually means "just push whenever idgaf". Which, okay, sure. I don't know how that's actually useful, or why Edge is the only one doing it right now. But we found our issue. Problem solved, I guess.

I _suppose_ this might be how they want you to go about doing double-buffering by first rendering everything to a texture, and then just drawing that full screen with some post-processing. Which could technically save some performance if that implicitly flushed when it detected that render to texture. But, I'm just spitballing and that seems kind of risky that you have stuff where you're using that texture render in the scene itself. So, honestly, I have no idea. And I have no idea if this is a Chromium or Windows bug, if it's something with Edge or actually a Display Driver thing, or if this was _actually_ the expected behavior since the beginning and the previous behavior was the bug.

And we're back. Boston was nice - reminds me a bit of Pittsburgh, except every single building is super-sized. Like, seriously. I think every 3 Pittsburgh street blocks is 1 downtown Boston block.

Silk Song has also released, which uh, might slow down some things. Just a little. The storefronts being unable to handle the demand and crashing is absolutely hilarious in the best way possible. It brings me a small malicious spark of joy imagining there's some high-level execs out there gnashing their teeth in jealousy that this title made by a essentially a team of 3 is going to do gangbusters compared to their multi-billion dollar cooperate franchise, but I digress. Here's to hoping that all independent creators can find even a fraction of this kind of success moving forward. Anyways.

As far as actual progress, there's not a ton to report on this week. The standard structure for releases is the One Big Version Update that takes about a month or so to make, and then after that, just a series of minor updates for fixes, additional content, and minor tweaks. And since we're at the start of v1.5.0, most of the stuff is just internal changes to boring engine stuff.

One thing I will bring up though, is our investigation into pairing down the load time at the beginning of the game. Even though it takes only about 10 seconds at most and is hidden by the intro cinematic if you let it play out, it's been a major sore spot for us since the beginning. The entire game is under 100MB, and since we've been very diligent about background loading stuff like the BGM, the game really only needs about 10MB of that stuff to get into the Main Menu, which loads in less than a second on most modern PCs even if you're using an HDD. Then, we do the rest of the stuff passively, so technically, if you're stupid quick with a stupid slow computer, you could hit another loading screen when entering any game mode, but I've personally never been able to. The thing that is eating up the entire time, is the shader compilation. Literally, it's 95% of the startup time.

It was sort of a major breakthrough to be able to play the intro animation without stuttering back in v1.4, but it actually didn't do anything to improve the full time taken for the startup - the moon just rotates without hitching. Even though we're using Ubershaders, the full program is less than 100 lines, so it's not the size. There's no loops for unrolling, or any of the other 'gotchas' that we've read about so far that could be contributing to the time, unless the branching is somehow blowing it up, but no conditionals are nested. There isn't any support for saving or loading the bytecode, so caching after the first compilation for subsequent runs is out (although when running in dev mode, we have hot reload, so it's literally only the first time you start the exe that it's slow). The extra frustrating part is that compilation is super quick on mobile, but it's only on Desktop that it takes forever, especially with certain Intel chips.

Oh man. I was already trying to schedule for Mina the Hollower, Kirby Air Riders, and Katamari before the end of the year among making time for any interesting indie titles that pop up, but now you're telling me Silksong is going out in like, 2 weeks? Guess we're closing up shop for the year - I've got too much other stuff to do.

Alright fine - Landlady told me no. So we'll keep going.

Since I'm going to be out the entirety of next week, I've been trying to avoid starting anything big or risky. That ended up being the JSON Modding API docs. And they're looking pretty spiffy now, if I do say so myself:

These are baked straight into the game itself, and are accessible through the Options => Mods => Docs option in Crescent Roll. They're dynamically generated based on the code, so they're always up-to-date for whatever version you're running. There's also a couple of tutorial pages for how to do things like add Hats and Stages that I'm working on, as well as a file browser to poke around at the main game's mod files to use as an example. The file browser even lets you preview text content, images, and play audio files in it! Neat!

Obviously, these are webpages with the hyperlinks and buttons and such, which we can only do because Crescent Roll is an HTML5 game (which is also why I was able to get it together so quickly). The best part is that this view is tied to the engine's contract system and not the game itself, so we can just pick this up and drop it in to any game we ever make with the same engine. Instant Mod support right out of the box.

Toree Saturn came out I think last week, and it was wonderful. A super quick, nice and simple sample of about a dozen speed platform stages. I was able to 100% it in just under two hours, which is just absolutely perfect. Most people I mention it to have never heard of Toree though, which is a massive shame.

So, if you're a dev and have a game or kickstarter or demo or anything, please plug it on any of our posts guilt-free. Doesn't matter the genre or size or price, and don't bother trying to tie it into whatever the post is - just slap a description and link right on there. We're drowning in a sea of slop right now, so just having something that was made by somebody because they wanted to is a diamond in the rough. I'm desperate for a little beacon of hope, and anybody else willing to read long dry development logs on Tumblr of all places likely is too.

Anyway. Yeah, dev log:

I have a small trip planned here the final week of the month, so I'm trying to avoid sticking anything potentially breaking in the updates until after then, as I have recently realized that I do not have a working laptop right now. And with the current tariff situation, I do not believe that would be a sound investment.

Doesn't mean we're twiddling our thumbs, though. v1.5 sometime mid to late September should include the Garden. It will be a little basic at first - expect the Tiny Chao Garden from Sonic Advance rather than the full-fledge Console version. But, like with everything else, once the foundation is laid, building on top of it becomes easy. And yes - it supports modding too. We're taking extra care to try to build the systems to automatically balance different item stats so that everything remains compatible with Vanilla. Mostly a cost-tradeoff system where the better the stats boosts, the higher the price, rarity, and how long it takes for the tree to grow for fruits. Hats and other cosmetic stuff is just free reign for whatever you want in your mod though - the auto balancing is just for stuff that affect stats that in turn affect progression.

It's probably obvious, but we should explicitly mention that the priority of the Campaign stuff did get shuffled to v1.6, and the Multiplayer aspect too been slightly delayed because of it. Not just because of the Garden, but also to bump the priority of the Modding API exposure, as we've had a couple of requests relating to it (thus the Mods sub-menu in Options). So, don't expect a stage builder or Steam Workshop support just yet, but I'm shooting for the first stable version with public documentation before Halloween. Could be sooner, could be later, though.

I've been out of school for just about a decade now, but still get this kind of inherent primordial panic when August starts.

Kind of as a preamble disclaimer - Multiplayer for Crescent Roll is still moving along, as is the additional Challenge Mode stuff. This is something that has been in the works for a bit, and there's just not a whole lot of fun technical stuff to talk about for those other two right now. I might do something about the networking in a bit, but that's kind of dry. Instead, follow me on another weird counter-intuitive development ramble.

A huge part of picking pieces for game design is the balance between sources and sinks for various resources and rewards presented during game play. Too little a reward for doing too much makes everything a grind. Arbitrary points that are just the end to their own means can make your game feel hollow. Crescent Roll has the Cosmetics, but there's no push-and-pull to the process. It's "I have $500, time to roll the dice", and that's it. There's no decision that has to be made, and the system is kind of flat. Once you get an outfit you like, a lot of people lose interest in trying to find anything else. So, even back during the planning phase, we decided we need something else to spend the money on. I immediately thought "Add a (legally distinct) Chao Garden. You freaking love the Chao Garden". And then another voice went "No, don't do that." And that kind of sat with that for a while, but then I started thinking "well, actually, why not?" And then my little shoulder Takashi Iizuka just kind of shrugged. Which is weird, because I was always the Nintendo kid. But I'm the project lead here. Now, I've actually done this type of pet raising mini-game maybe 3 or 4 different times now, all at different points of skill level over the past 15-odd years. Which, in this most recent iteration, has made me reflect a bit on some changes in the approach as I've become a better developer. Behold, a tree:

It does what you expect - you plant a seed, wait a bit of real time, and then you have something that produces fruit (beans in our version). This description, however, is a major over-simplification. You have to be able to buy the seed, the tree can't allow other things to be placed on top of it, the fruit has to be attached to the tree and then come off, the time the tree has been growing needs tracked. That's on top of standard object manipulation, Z-sorting and similar. This doesn't even have shadows now. Plus, since we have the modding kit, now we have to worry about organization. Can mods add their own plants? Do they affect base stats for your creature? We want to be able to transfer creatures between games - how does that interact?

What I did in the very first version many years ago was just slap that Tree object down using the pre-existing Object system, saying that we'll add the rest later. No fruits, the hitbox was weird, and the other changes never happened. The second one, we started with the seed, got the plant growing. No bugs this time, but it still got buried and ignored too. The third one, we didn't even attempt it, because we knew the full scope of what needed to actually be done to get it into a usable state. This fourth one, it's part of the MVP.

The thing that I realized this time around is that somewhere between the second and third attempt, my approach shifted from a bottom-up wing it kind of thing, to a top-down full system analysis. There's the running joke when the Senior Dev says adding a button takes at least two months but the Junior Dev says it would only be a day. But it does suck when the Junior Dev's single-day button starts crashing the program next week when they changed the color of the title bar. In most cases, it's not even his fault - it's just that he didn't account for the weight of the entire system, and his button somehow ended up load-bearing.

And thus ends July. Next week's update for Crescent Roll is mostly a bunch of minor tweaks, including a neat work-around that we found to make the loading go a little faster and not freeze while the shaders are compiling. Text now has automatic newlines when it reaches defined bounds, which is nice. There's a bear of an issue where the Sound Mixer is showing WebView2 instead of the actual game that we're currently working on, but I mean, technically speaking, it's not really a game bug per-say. You know - nothing much exciting, but stuff that needs done.

Like I mentioned last post, the current focus is getting Challenge Mode promoted to Campaign when 7 challenge sets are available (a new one will be here Monday, so that's 4 total), which will also lay the foundation for everything we need for Multiplayer VS. Between doing that though, I've been sneaking in some extra work getting the modding stuff ready. It's going to be super important for the next few titles, so I'm hoping to get it as close to perfect as possible to avoid heavy revisions down the line.

Crescent Roll uses a series of enhanced JSON files defined by an internal contract parsing/enforcement framework we call Plinth. There's 2 types of data: additive data such as Stages and Cosmetics that you can stitch together dozens of mods to bootstrap in new content, and then replacement data such as Menu Schemas and Animations that can only ever be defined once, and any subsequent mod overwrites data for it. This system has existed since before the game was made, and it works 100% right now - the root game content is just the default mod, and you can bootstrap mods in the public release right this very instant. We just haven't brought attention to it, as the internal format for all the stuff wasn't finalized yet and you can still crash the game with bad data in some spots. But once we add some safeguards, I believe we're actually pretty much at that state now.

Challenge Mode has officially been added to Crescent Roll last week, which is a huge burden off of my shoulders, as now the game is finally in the state that I wanted it to be for the actual launch. We still need a good number more stage sets, but I feel like we're past Flash Game and it's now something you could pick up on the DS. Now, just gotta make it feel like it's first-party. After quite a bit of discussion, it looks like the next major milestone is going to be some kind of Multiplayer aspect. I was originally gunning for the mod kit stuff and stage editor, but we kind of realized that our survey sample population was heavily skewed toward the interest of other developers, and that most others aren't going to care about it quite as much as being able to play with friends. We actually have a couple of ideas for what you can do with other players. A standard Race mode is the obvious choice. Although, just by running any of the Double stages in Challenge Mode, having the players interact physically on the stage won't work - a lot of the stages are too cramped and have zero opportunities to pass each other. Items are another story though. We can place the pickups randomly in place of the coin positions, and then use any of the effects from the stage modifiers, and presto - maximum chaos without needing modders to do anything special with their stages.

Looking at my calendar, I believe that today marks the one-year anniversary of when we decided to make Crescent Roll our first official game (which, it technically existed as a tech demo template thing for the animation engine before then, but today would be when we decided to promote it to standalone and essentially re-started from scratch). So, that made it about 8 months for v1.0 up on Steam from then, and it's now been 4 months of updates since the public release. And surprisingly, no death threats yet. So I'm marking that as we are doing a spectacular job. Good work, me. As long as our internal Steam Deck validation works out today, Challenge Mode should be up and available on Monday. I'll have to apologize ahead of time, as it's a little bit unbalanced right now. Some of the challenges might be a tad on the difficult side, and since it's random, you might just have your run prematurely shut down if you roll bad. However, I think that's kind of part of the fun, so yup - getting released into the wild. Good luck. File your complaints here, and maybe we'll be merciful with a balance patch. I only talk about Crescent Roll and the engine itself here (and those two do eat up the majority of our time), but we are working on other projects. It would be kind of stupid to make an entire engine, and then only do one game. So, how about an in-progress song from one of those for today since I don't have a programming rant prepared:

Happy Belated 4th! Hopefully you have emerged unscathed. For the keen eyed, Crescent Roll update 1.4.0 obviously did not make it out this past week. Which is a shame, because I think our little bumper for Independence Day turned out pretty good. Oh well. This is why it was only mentioned in a dev blog post and not a Steam announcement. Fingers crossed for this Monday.

There has only ever been one singular outstanding bug in the entirety of Crescent Roll - you could not scroll down on the Cosmetics Tabs to view all of the items. This never mattered much, as equipping different Balls doesn't affect anything (yet), but this is the reason why there has only been 12 different cosmetics for each category. I've been meaning to fix it forever, but there was the bigger domino of needing an infinite way to get currency to be able to buy a bigger selection of items. Which has finally fallen with the addition of Challenge Mode, so it was time to bite the bullet.

As I've mentioned before, Crescent Roll runs on a completely custom engine. No Unity or Godot - all of it is my own hand-written JS (minus one little bit I plucked from MatterJS to handle only the Wall Collision detection, credit where due). All of the Menu stuff is technically an interactive Animation, kind of like how Flash worked, except instead of ActionScript, it's a special type of JSON schema layout closer to Godot just without the ability to inject scripts. Highly moddable, very nice to edit on the fly. I'll do a writeup at some point this year.

As part of the library, there's a special set of UI nodes that can be added to the menu that add interactivity, being "Menu", "Button", "Slider", and "Joystick". They're just animated objects with special properties to configure animations to mix between for different states. Animated Objects, in turn, can be extended with special "Control" definitions to run code specifically for them. The eyes for the character and cat are one of these.

Menus have been a significant pain to work with for the longest time, as they started out as super specialized and had to be essentially hard-coded for the game code, but have been slowly working their functionality back down into the base graphics toolkit objects as the toolkit matures and more stuff is possible in the JSON schema. However, even though that's getting simplified, since we support both Mouse/Touch and Joypad/Keyboard, there's a lot you have to do to reconcile switches between state. Menus track Active Elements when you use a controller, but don't when you touch, as it's 100% expected that multiple buttons will be able to be pressed at the same time. Dealing with this and Scrolling is a borderline nightmare, as the systems for dealing with it are completely different based on the control scheme.

If you click on the bar, it's expected that the scroll moves directly to that position. If you move the cursor out of the screen, it's expected that the item scrolls into view if not already visible. But if you can see it, it shouldn't move. The scroll also needs to be smoothed into, and the bar needs to show the position. Also the bar shouldn't show up if you can't scroll anything. The bar should move if you use the Mouse Wheel. The design expectations for the scrolling is so fractured compared to any other common UI component for the different control styles that there's really no way to make it feel natural for each without making almost entirely different systems. I haven't even added Touch yet, which should move when the area is dragged, but not activate buttons unless they are explicitly clicked. That's going to be a nightmare. But we have at least the other for now. And that only took a week. Oops.

Heck yeah! The Steam Summer Sale is now live! If you're also headed over to Mr. Newell's picnic, be sure to swing by the dessert table for 50% off Crescent Roll!