#16naughts

[16naughts]

Dev Log Apr 18 - Pro Tip: This ain't Hollywood. Stick at it.

This is a bit of a rant separate from my normal topics about development here that you'll likely never see again, but I really feel like I can save some people a little bit of heartache with this. My forte is (obviously) the technical side, but this is currently a one-man show, so I also have to draw and animate all of the graphics, compose all of the music, record all of the sound effects, design the stages, and do all of the marketing and business stuff. I can afford to do it because of some extreme planning spanning over a decade and a couple of lucky breaks. But, if you want to go fully indie, you will be doing most of this too at some point. So at this time, since it's still relatively quiet around here and nobody can claim survivorship bias, I really, really want to impress on anybody also considering taking the plunge: Your game is not going to blow up overnight. Ever. Period. The concept of the game dev has been extremely romanticized as this David vs Goliath struggle against the AAA industry, and being tied so closely with the flash-in-a-pan culture that is the internet, it's kind of bled over into mainstream culture as well. The cold reality is that if your game makes it to release, you're in the minority. And then if you can crack 5 sales on your first title within the first year, I'd consider that an overwhelming success. When Crescent Roll released on Steam, I counted 75 other titles released the same day. The fact that we sold any copies at all was a miracle in my eyes, but I'm not getting the same response from anybody else. It's always "what a shame, it looks so nice". And this isn't the schoolyard bully pointing and laughing - it's your friends and family trying to be consoling, but in doing so are inadvertently labeling your efforts a failure. They don't know that it hurts. A lot of people in art communities get it, but a lot of the people in more tech-oriented stuff (like game development) don't seem to experience it quite as much: gaining traction takes time. Pizza Tower? 5 years of development. Marketing for it started before development actually began, as McPig was using Peppino in comics and other games. Terraria? Redigit found his team and an audience working on the fan game Super Mario Bros X. Balatro? LocalThunk had 48 wishlists at the end of the beta. Go read his website. Among Us sat for almost 2 years before blowing up, and Henry Stickman was already popular. Nobody ever bursts onto the scene and just immediately grabbed the world's attention from nowhere. If it looks like they did, you're missing at least half the picture. it will be soul-crushing when nobody wants to play that thing that you spent a year of your life on. But making any kind of art is always a slow burn. The key is going to be persistence. And I don't mean just throwing as much stuff at the wall as you can - pick a direction, put out your best work, and just keep pushing it forward. It doesn't have to be free updates: make more good games, post art, whatever. Keep your presence known. Obviously, this is all talking to the dreamers who have been sketching level concepts in their notebooks since grade school. If you need money, you're really looking in the wrong place. And you should really, really make sure you can take care of yourself financially before venturing out into no-man's land here, 'cause you'll be in the hole for a while. So this isn't so much an inspirational thing, as more of a warning for others considering going full indie - it's tough. You'll need discipline to get there, and then more discipline to keep it up. I thought I was over-prepared for our jumping-off, and we still ended up having to defer features for after release, and still don't have a real trailer yet. So, if your plans require overnight success, you might want to stick with your day job for a bit longer until it doesn't have to. Which it won't. Trust me.

[16naughts]

Dev Log June 27

The Steam Sale launched yesterday, and I've been seeing a fair number of complaints about the deals not being that good any more. Which, from snooping around it seems a lot of the AAA stuff didn't really go down all that much. The smaller studio stuff though is where it's at. Current personal recommendations if you want something just a little bit off the beaten path are Have a Nice Death, Blasphemous, Dungeon Defenders, Overcooked, Vividlope, Anton Blast, and Demon Turf (okay, some of those are only like 25% off, but come on - they're like $20 to begin with at most. That's like 2 cheeseburgers at this point or half the price of a skin in something like LoL. Throw 'em a bone.) Enough using the company blog as my personal soapbox- back to dev stuff. We're currently knee-deep in adding Campaign mode, which is a bunch of little challenges back-to-back kind of WarioWare style picked randomly from the assortment of base stages with modifiers applied. Which, initial testing is proving to be quite popular. I knew we should have waited to ship with this mode, but the external pressure to have something out there was a bit too great. At least I was able to stave off having to stick out a demo and the other platforms until it was ready, so here's hoping we'll still be able to turn it around. However, we had to do a bit of iterating on the concept after we found that the entire choose-your-path thing really wasn't adding anything to the experience. Most people wouldn't be able to look at a stage name and go "oh, I know I have trouble on this one, I will need more time", so the risk-reward was kind of falling flat. Instead, we pivoted a bit, and now the challenges can't be modified but we have these coins that show up in levels instead. Most are slightly out of the way or in sub-optimal paths, so you're trading time on the fly. The number of coins that show up increases as you get farther, so more opportunities to test your greed. So far so good. Another weird issue is that, even thought the different objects were made to be able to handle multiple balls, the stages themselves weren't made with modifiers in mind. Which, I think makes it more fun. But it does mean that you have to be extra careful with which modifier gets added where. Two balls have a hard time making it through a lot of corridors. So, we shrunk them down a bit. However, that currently reduces their weight, and as such they go farther when shot from cannons. Which is a bit of a problem as they can get shot so fast in certain stages that they puncture walls and pop the bubble (which is a mechanic most people won't even hit normally). And this is actually part of the reason why we're still missing 2 sets of stages from Main Course mode - the gimmick was supposed to be shrinking/growing the ball when you hit certain fields, and some of those stages rely on the weight change. It would be very inconsistent if the Campaign Mode modifier shrinking didn't have the weight change, but the one in the regular course did. I can divulge this here due to the limited audience and this being more of an informal journal type thing rather than any kind of official announcement, but what it's looking like is that the initial version of the campaign with probably 3 sets of stages labeled as a side "Challenge Mode" will be released in the themed update sometime next week (not sure if it'll be Monday or we'll do it Friday specifically because it's the 4th and there's a couple little extras it'd be neat to sneak in). In the next couple of weeks, I want to get the total count up to at least 7 or so different sets, and then we'll be promoting this mode up to be the "main" mode of the game. Multiplayer VS gets added using it, free demo gets made, other platforms get published, mod kit gets released, badda bind, badda boom - I'll finally feel okay with charging money for this thing. Maybe even before the end of the summer. Who knows - I'm a pretty fast developer, all things considered.

[16naughts]

Dev Log Mar 7 2025 - All Hands on Deck

Crescent Roll v1.0 is now live on Steam, but with it being something of a soft launch, there's quite a bit of work still to be done. And our first order of business is getting together a Steam Deck version so the more players can take advantage of those all-too-essential motion controls.

The Steam Deck is a Linux machine with a custom OS (aptly called SteamOS) that has a compatibility layer called Proton that lets you run most Windows games straight out of the box. However, Crescent Roll is not most Windows games. We use .Net8 and WebView2 on Windows, neither of which Proton is able to efficiently emulate straight out of the Steam library (you can do some trickery on Desktop mode to get it running, but the point of the Deck is to make it easier for non-tech people, so that ain't gonna fly) Fortunately, we've already thought on this for quite a bit. The .Net platform can be embedded in the executable itself with no need to install anything, which solves problem 1. The replacement for WebView2 is a little more tricky - we have to embed essentially an entire web browser into the game. Steam uses something called the Chromium Embedded Framework, or CEF, to show the popover that you see in games, as well as their storefront and a bunch of other little widgets. It's essentially a self-bundled customized Chrome instance that you can stick in pretty much anything. That would be perfect, but unfortunately for us, after searching for days, it doesn't seem to be exposed anywhere in the Steam runtime, so we can't piggyback off of that. Unfortunate. Embedding it ourselves is also going to add a whopping 1GB to our 100MB install, so uh, perhaps not. So, alternatively, there's WebKit. It's to Safari what CEF is to Chrome. Just the bare minimum of a web browser that you can slap into anything. SteamOS doesn't have it pre-bundled, but it's around 100MB-ish, so you know - better than CEF. So, there we go. Except, CEF expected you to just drag-and-drop libcef.so into your project, and WebKit wants to be installed separately. Which you can't really do on the Steam Deck. So, what I've been doing for the past week is chopping up and patching pieces of the WebKit2GTK project to get it running on the Deck under our sub-directory. Which has not been remotely fun, and will probably get its own write-up here to help out anybody else doing the same thing. But...

It works. Well, as of writing this, it's mostly works. The audio isn't playing, and we're locked at 20FPS display even though the game runs at full speed and is only using 10% of the CPU, but it's actually entirely playable. We were hoping to start releasing a weekly update every Monday starting next week. Fingers crossed we'll be able to iron those last two issues out for it. Although this is big enough that if we're close, we might just wait for Tuesday to ship out both at once. Fortunately, nobody seems to be knocking down our door for this, so we've got a little bit of leeway.

[16naughts]

Dev Log Mar 14 2025 - What's Taking so Long?

The Steam Deck version of Crescent Roll is moving along. The full game is playable, most of the audio issues have been resolved, but there's still the very slight teeny-tiny issue of WebKit being abysmally slow and we're sitting at only 10% CPU usage and 20FPS. Joy. We can fix it though. Without having to switch Web Browsers. I explained a bit before that the two options available for Web embedding are either Chromium/Chrome or WebKit/Safari, depending on your platform. Windows, Android and Xbox all have Chromium natively for you to use, Mac, IPhone, PlayStation, and Nintendo have WebKit, and then Linux and therefor Steam Deck don't have a standard one installed. We went with WebKit for Steam Deck because it's 200MB instead of 1.5GB and we have to bundle it with our game. When I said we can fix it, it's not that the actual game part of Crescent Roll isn't optimized - we actually did a pretty good job with all of the movement on-screen every frame - but there's some very specific things large surrounding it that we know are hurting performance considerably. Here a visualization of the call stack of a random average frame on the Main Menu from the Chrome profiling tools from my 10-year old i7-4770k machine:

The grey "Task" bar is the full length of the execution. The brown-yellow underneath are what run during the actual "Animation Frame" portion, then the Blue sections are Crescent Roll code, and Green is Phaser rendering code. So in this frame, it took 4.16ms for the full frame, of which, Crescent Roll used about 1.8ms to do its stuff, then Phaser took 1.5ms to do the render, and the remaining ~0.8ms was system stuff like GC and doing memory transfers to the GPU. 60Hz refresh rate would mean that you need to render in under 16 ms, so about 4ms for Windows Desktop means that I could theoretically get somewhere around 240fps if I let it run free. Which I mean, is pretty respectable. Why doesn't it run well on the deck? Technically, it's running okay, just not displaying okay. The internal game logic does all physics and animation calculations with lag compensation in mind. So whether you're getting 500 fps or 5, the in-game logic always calculates 60Hz. So sorry - no cheesing stage times with slow-mo. One reason the display is having issues is that it's single threaded. Which means we're not doing _anything_ in parallel. All of the game logic, graphics rendering, controller polling, etc. are all being done every frame in order every single time. The kicker is that we actually built the game to be able to do those things in parallel, but Javascript just doesn't have the concept of Threads for you to be able to just run whatever you want however you want. You have to implement Web Workers, which is essentially a completely separate program that you can't share memory with, forcing you to use a message bus, making life difficult. But not impossible, and that's all that really matters. Just splitting it in 2 would already get us a 25% improvement, and we could very likely do better than that. The other, slightly more major performance sink is that green bar for the Phaser rendering - that can be entirely eliminated at this point to cut the time in half. We've been replacing it piece-by-piece with our own code, and now, we're really just leaning on it for WebGL pushes at this point. Unfortunately, since it's an engine, there's quite a bit of extra baggage that it likes to do that we can't just turn off, so we're essentially running a lot of the same types of graphics calculations twice. Phaser is a perfectly good engine - don't get me wrong, but it's just superfluous for our use at this point, specifically for us.

So yeah - it's going to take another week or so to get that 100% sorted out. There's a patch incoming Monday for full Controller support and couple of minor improvements. In the meantime, you can swap to the beta branch on Steam if you absolutely must try the Steam Deck version now. No complaints about the speed though - I warned you.

[16naughts]

Now Open for Business

We at 16Naughts are pleased to announce the Grand Opening of Crescent Roll! Stop by our brand-new Steam location before March 14th for an Early Bird special!

[16naughts]

Dev Log Feb 21 2025 - One Week Left

One week left until release. Or, more accurately, the public 1.0 version. We've still got a long roadmap ahead for this one, so development ain't stopping yet. So what's next? For one, I can start actually sharing some of the upcoming stuff here. First order of business will be polishing off controller support and Steam Deck version. Technically, both already partially exist, but just weren't 100% finished by the cutoff date, so it should be (hopefully) quick to get out. Same goes for a bunch of courses and some mini-games. I do have to say the idea of finally throwing it out there is kind of nerve-wracking. There's still a million little things that aren't polished enough, and probably never will be. But we'll never know if we're moving in the right direction at all if we don't start garnering some external feedback. And I don't think it's too bad for a first attempt, all things considered. So, whether we want to or not, it's time. Just don't find too many bugs, please: I want to sleep next weekend.

And with that, don't want to cut it short after essentially saying nothing, but I've been slacking for too long. Back to the grindstone.

[16naughts]

Dev Log Feb 14 2025 - Space Dust Shader

Two weeks left until release. And I almost forgot to post the dev blog post on the second Friday. Whoops. Since it's late, I'll be quick. Since I promised some shader stuff last week, I should probably deliver on that. For those unfamiliar, shaders are tiny programs written to be executed on the GPU for handling rendering of graphics for the game. It's a bit hand-wavy, but there's a bunch of different types that you can write for different stages in the rendering pipeline, which itself can be configured differently based on what the game is. Most modern games using OpenGL and similar pipelines have at bare minimum a Vertex Shader, meant to populate the shapes of the things, and a Fragment Shader, meant to draw the colors of the pixels. Usually it's just a texture on a plane for most 2D games, but you can get creative and make some neat stuff. Here's a still image (not a gif, sorry) of the attractor/repulsor objects as seen in the first trailer:

It's kind of a neat effect (not to pat myself on the back too much, but you know). There's little dust particles flying into/away from the little swirly hole in the middle. The best part is that it's not actually particle objects - there's no calculation for those individual dust particles at all. It's just one single texture that looks like this:

The image is a composite of a layer of pure Green and Black on the bottom in a conical gradient, a radial gradient of pure red to transparent from the middle on top of that, and then a circle of pure blue with a slight transparent blue tint inside. The trick is that there's a really simple little shader applied to it (code for those who want to commandeer, feel free to use for anything, but note that this is used in the Phaser WebGL pipline and will not just drag-and-drop into most projects) :

precision mediump float; uniform sampler2D uMainSampler; uniform float uTime; varying vec2 outTexCoord; void main() { vec4 c = texture2D(uMainSampler, outTexCoord); float t = fract(sin(c.g * 12.9898) * 43758.5453); float a = clamp(fract(c.r + uTime * 0.05 + t) * c.r * 2.0 + c.b, 0.0, 1.0); gl_FragColor = vec4(0.6 * a, 0.7*a, 0.8*a, a); }

The gist of it is that it takes the image, uses the amount of Green at a specific pixel to determine which 'column' of dust expanding from the center to the edge belongs there. Then, the 'closeness' of the dust is specified by the Red value of the pixel, and more visibility is granted to specific small range of Red values over a function of time with a little bit of pseudo-randomness to make it look nice. Mask it off with the Blue, and increment over time, and voilla - super cheap space dust particle thingy. Obviously, we use shaders quite heavily for a lot of the things that do weird little cyclical movements, including things like the stage shimmy and the wavy effect for the company logo. However, you'd probably be just as surprised how much isn't shaders, and is instead just standard compositing and masking, like the stage background and UI elements. Some clever design and a strong art direction do a ton more for a game's visuals than just throwing raw computational power at it.

[16naughts]

Dev Log Feb 7 2025 - The Stack

Ahoy. This is JFrame of 16Naughts in the first of what I hope will turn out to be a weekly series of developer logs surrounding some of our activities here in the office. Not quite so focused on individual games most of the time, but more on some of the more interesting parts of development as a whole. Or really, just an excuse for me to geek out a little into the void. With introductions out of the way, the first public version of our game Crescent Roll (https://store.steampowered.com/app/3325680/Crescent_Roll juuuust as a quick plug) is due out here at the end of the month, and has a very interesting/unorthodox tech stack that might be of interest to certain devs wanting to cut down on their application install size. The game itself is actually written in Javascript - you know, the scripting language used by your web browser for the interactive stuff everywhere, including here. If you've been on Newgrounds or any other site, they might call games that use it "HTML5" games like they used to call "Flash" games (RIP in peace). Unfortunately, Javascript still has a bit of a sour reputation in most developer circles, and "web game" doesn't really instill much confidence in the gamer either. However, it's turning more and more into the de-facto standard for like, everything. And I do mean everything. 99% of applications on your phone are just websites wrapped in the system view (including, if you're currently using it, the Tumblr app), and it's bleeding more and more into the desktop and other device spaces. Both Android and iOS have calls available to utilize their native web browsers in applications. Windows and Mac support the same thing with WebView2 and WebKit respectively. Heck, even Xbox and Nintendo have a web framework available too (even goes back as far as Flash support for the Wii). So, if you're not using an existing game engine like we aren't and you want to go multi-platform, your choices are either A) Do it in something C/C++ -ish, or now B) Write it in JS. So great - JS runs everywhere. Except, it's not exactly a first-class citizen in any of these scenarios. Every platform has a different SDK for a different low-level language, and none of them have a one-click "bundle this website into an exe" option. So there is some additional work that needs to be done to get it into that nice little executable package.

Enter C#. Everyone calls it Microsoft Java, but their support for it has been absolutely spectacular that it has surpassed Java in pretty much every single possible way. And that includes the number and types of machines that it runs on. The DotNet Core initiative has Mac, Windows, and Linux covered (plus Xbox), Xamarin has Android, and the new stuff for Maui brought iOS into the fold. Write once, run everywhere. Very nice. Except those itty bitty little application lifetime quirks completely change how you do the initialization on each platform, and the system calls are different for getting the different web views set up, and Microsoft is pushing Maui so hard that actually finding the calls and libraries to do the stuff instead of using their own (very strange) UI toolkit is a jungle, but I mean, I only had to write our stream decompression stuff once and everything works with the same compilation options. So yeah - good enough. And fortunately, only getting better. Just recently, they added Web Views directly into Maui itself so we can now skip a lot of the bootstrapping we had to do (I'm not re-writing it until we have to, but you know- it's there for everyone else). So, there you have it. Crescent Roll is a Javascript HTML5 Web Game that uses the platform native Web View through C#. It's a super tiny 50-100MB (depending on the platform) from not having to bundle the JS engine with it, compiles in seconds, and is fast and lean when running and only getting faster and leaner as it benefits from any performance improvements made anywhere in any of those pipeline. And that's it for today's log. Once this thing is actually, you know, released, I can hopefully start doing some more recent forward-looking progress things rather than a kind of vague abstract retrospective ramblings. Maybe some shader stuff next week, who knows.

Lemme know if you have any questions on anything. I know it's kind of dry, but I can grab some links for stuff to get started with, or point to some additional reading if you want it.

[16naughts]

Dev Log July 25

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.

Now, we could just do splitscreen, but that causes problems with the phone versions, and since the Steam remote stuff can't work with the game due to the split GPU process utilization, that'll hamper it as well. We'll need to do network connection, but I believe we'll avoid any kind of matchmaking and keep it local like Minecraft LAN play for now. But that now means that you'd need 2 copies if a friend just wants to try it. And that's more sales for us, theoretically, I guess. But if you're at a party, and somebody says "play this cool game with us, but it'll cost you $10! :)" chances are, you're not joining. If only we had DS Download Play... ...Oh wait, we actually _do_. I've mentioned this previously, but Crescent Roll is actually an HTML5 game in a special wrapper application to let us do a couple of extra things like access more controller features and save your data to disk. However, those _technically_ aren't required for it to run. Any (modern) web browser can run it. So, just make the desktop game run a tiny lightweight web server, and boom - buy one copy, connect and share on any device. We actually have a working prototype already, but are still ironing out the fine details. The major flaws are 1) you have to type in the IP address and port into your browser, and 2) it's HTTP only, as we cannot have a certificate for a changing local IP address, so most browsers will put up a fight and the layman won't understand what's going on. Save data is also weird. We can't do money or record transfers back because it's fairly easy to cheat with access to the browser console. We still want players to be able to pick outfits, though. I'm thinking we'll need to stick up a separate free app on Steam called "16Naughts Download Play" or something at some point to make this easier, but that's a lot more logistics to figure out, so we'll probably wait for later for that. Last week, we got our first external bug report, and I want to say huge shout out to you, anonymous email guy. I don't think I've ever met anyone quite as polite on the internet, ever. They provided concise specs and even tested it on multiple machines, and we were instantly able to find and fix the issue. Wish we had physical merch or something I could send you, 'cause you absolutely rock.

[16naughts]

Dev Log July 18

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:

I'm a programmer, not a composer, so maybe not the best thing ever, but I think it's kind of catchy, and definitely memorable. The song is pretty close to final, but I think some of the instrumentation might need tweaked (especially those hits. Those are a bit rough). I have to admit that it's very difficult to peel away from Crescent Roll though, as there's still so many more things that it needs to be perfect. Not that I'm expecting anybody to be clamoring for a reveal of something new any time soon (Most studios seem to forget only the shareholders get excited when you say "new IP coming soon". But I digress), but I can completely empathize with Concerned Ape for why he keeps updating Stardew Valley instead of working on Haunted Chocolatier. From the creator standpoint, at least. From the consumer standpoint, I want to be Gosh Dang Willy Wonka. C'mon, give it to me already, dammit.

[16naughts]

Dev Log July 11

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.

I think I already mentioned it before, but I'm really, really stressing this for new devs: menu stuff is going to eat the vast majority of your development time. And it is so easy to screw up if you don't give enough thought to your UX ahead of time.

[16naughts]

Dev Log June 20

One week left to go until the Steam Summer Sale. It's kind of strange participating in it but this time on the other side. This does mean a little bit of crunch time getting Campaign mode up and running. But it happens. It's usually extremely tricky to talk about or show anything "beta" regarding Crescent Roll because we really don't stub in any assets or have things only partially working at all in-between these Friday reports. The feature is either Done, or the game doesn't compile. The graphic doesn't exist, or it's on its final revision. Most demonstrable stuff gets knocked out in a day or two, but today we actually do have a very rare clip of something in-progress! The video at the top is the transition from taking an order in the Campaign mode to the gameplay. (I'm not sure what's up with the frame drops on the exported video, but it's 1080p 60FPS when actually playing). Before each round, a little menu pops up, and you get to make tradeoffs on modifiers for the level. Making it harder earns more money, but if you're running low on time, you might want to swing the difficulty in your favor until you can catch back up. Although, this video is only one day old, and it's already significantly outdated. There's a moving background now like the other modes, and the timer is changed to remove the hearts and best time and instead highlight the time remaining and list the current score and streak. If this is moving so fast, where is all of my time going on this project? I checked the git history (and the stuff I've been complaining about here), and we're looking at a solid 75% or more dedicated to Engine coding work. That's graphics rendering, file format manipulation, mod support, and system runtime, including all of the performance enhancement and porting work. You know - just about everything supporting the game, but not a lot for the game itself. Which in any other circumstance, would be considered a really bad investment. However, in my case, the engine was originally made to support a 2D animation software suite. Crescent Roll was just a little tech demo thing that turned into full game, so its existence is more of a bonus from that perspective. For anyone else that specifically wants to make a game though, I'd really, really recommend just going with Godot or something. People usually charge for game engines for a reason - the amount of support that you have to provide around it (even to yourself) is just stupid sometimes.

[16naughts]

Dev Log June 13

In a previous place I worked, one of our lead testers also published Friday updates, but usually theirs was a witty snippet, a subtly applicable Dilbert comic (before any of the controversy, mind you), and then a quick report on bug count and performance changes. I guess I'm 0 for 3. Anyway. The current development focus is on getting that long-awaited Campaign up and running. Which is mostly just menu and asset work at this point. Speaking of menus:

(It's not exactly final - the Streak and High Score are missing, the other stage sets aren't in there yet, and there will need to be a way to switch between different campaign "worlds", but you get the gist) Campaign levels are a bunch of re-mixes of stages from Main Course, just with additional modifiers in place that change the way the game is played. You play a randomized order, and as you get farther, the time added to complete the stage gets smaller and more modifiers get piled on at once, but the multiplier on how much cash you earn grows too. The Menu design for a lot of these is a little tricky. I subscribe to Masahiro Sakurai's and other designer's ideals of the fewest button presses to gameplay as possible, but have to play it extra careful with keeping the game well-suited to Controller, Mouse, and Touch all at the same time. We could, of course, had the left panel show first, and then whenever you select a stage set, the right panel would pop up. However, the requirements section throws a wrench in this a bit. In order to play the remixed versions of the stages, you first need to clear the recipes that it uses without any modifiers in the standard Main Course mode that already exists in the game. You can click the little button there, and it'll bring up the stage select to give it a go. There's also this idea of 'crumbs' that you can earn for beating specific recipe stages (in a later update, not this one), so checking that has to be extremely streamlined for whenever somebody is searching for one particular type they need. So side-by-side it is. However, this side-to-side panel has a slightly different issue now. How do you switch between the two with the Controller? You can select your world with A, I suppose, but that would imply that pressing B would bring you back, and the hotkey is already in the top-left to go back an entire menu screen. We already hit this issue when attempting to design the Cookie Jar menu, and opted to just make it so that you have to press Start to being the stage with no way to normally highlight it. Which you can already see the hotkey here. So, what I'm thinking (and this is not entirely final), is to do away with the per-recipe shortcut buttons, and just have a single button for the entire set that opens up the Main Course selection menu modified to only show those specific sets. It's one more interaction, but one that everyone will perform a lot less often, as eventually, you'll have all of the recipes unlocked, but will still keep unlocking new Campaign level sets that use them. The standard Main Course menu will still exist to be able to pick out from any of the sets to do time trials. I suppose this in itself is kind of a warning for a lot of aspiring developers - UX is going to eat up more than 50%, maybe even closer to 75% of your development time, and if you screw it up, it'll turn people off of the game despite how wonderful everything else around it may be. Any time I hear complaints about Zelda TotK, it's always about the materials selection list. Never mind you can literally glue a rocket to a sheet of plywood and use that to launch a horse into orbit - it's clunky to pull out that plywood, so a lot of players dropped it and missed out on the joys of the impromptu equestrian space program.

[16naughts]

Dev Log June 6 - Surprise! That didn't work either.

May has wrapped up, and it's really starting to feel like summer out there. Which in Nondescript Northeastern US town means hazy, hot, and humid. Not that we do much outdoors except for an evening walk anyway, so, you know- still business as usual. I know it's not the most amazing soundtrack, but I decided it would be a decent idea to stick up some of our game music on Newgrounds, if you're interested in using it in anything (it's Creative Commons, so you know, nothing commercial. But independent YouTube videos and free games and the likes are good) Last week I talked about switching away from WebKit for our Steam Deck build. Long story short, Steam is stuck using Debian 11 as the base for all games. WebKit dropped support for Debian 11 before switching away from using the CPU to do graphics compositing, and I can't backport because they also changed their toolchain that also dropped support for Debian 11. So Crescent Roll has to be super performant and use less than 25% of a single thread the CPU at all times or you get frame drops specifically on the Linux version. We got there, but then something changed, and now it has to be 20% or less, and now the Main Menu and certain stages drop down to about 45 FPS. Which isn't unplayable, but come on - it's a 2D flash game. This gizmo can run Cyberpunk. That ain't a good look. The only real alternative right now to WebKit is CEF (Chromium Embedded Framework). In fact, most things use it, because WebKit is specifically known to have poor performance in comparison. The only issue is that the Linux install for it is 1GB, while our game is 30MB, which is also not going to fly. However, that's the Linux version - the Windows version is about 200MB, which is actually less than the WebKit Linux install size. Steam Deck has a system called Proton on it that lets you run Windows apps, so why not use that?

So, on Friday, I went to work, and was able to use CefSharp to easily hook in the CEF instance to our runtime. There was a couple of tweaks that needed to be done in order to get the packaging right, but in less than 8 hours we had it - a 200MB completely standalone exe with no external dependencies. You didn't even need dotNet installed - it was all self-contained and completely portable. Beautiful. A bit on the chunky side, but pretty much what we've been aiming for from the start. Except it doesn't work with Proton. At all. And there's nothing I can do about it.

Proton is technically a layer on top of Wine, which is the de-facto Windows compatibility layer for Linux that's been around for just about a good 3 decades now. Apparently, Chrome does some really weird stuff under the hood in order to run as well as it does. And Wine has not, and is not interested in supporting whatever this weirdness is. So that super cool CEF version of the game is just sitting on my hard drive, completely useless. I suppose it's not so bad, as I only spend essentially a day and a half on it. But, guess I have to squeeze more blood from our stone. And we just kind of twiddle our thumbs until Valve adds a Debian 12 option. Or Google trims their package size down. Or Ladybird releases Canvas support. Or Microsoft ports Edge to Linux like they said they would. Hmm... You know, it really feels like I bet on all the horses, but somehow we're still losing the race.

[16naughts]

Dev Log May 30 - It's baaaaack (the WebKit issues, that is)

Last week we released the Sweet Bee update for Crescent Roll, which had some substantial changes both in terms of content and some of the inner organization. It was supposed to be a little bit bigger than it ended up being, but we decided to split up the changes into a couple of chunks to give it more polish and not have to re-do things for the public API release. (Which the PM in me wants to apologize to somebody for the delay, but I was the only one who set the time table anyway, so we'll have to work on breaking that "everything has to be done Yesterday" mentality.) As a quick recap - Crescent Roll is written in Javascript, which means it runs in a web browser. For Windows, Android, iOS, and practically every other platform, you can write your program to hook in to the OS native one and not have to install anything. For Linux (which Steam OS is a fork of), there is no native browser. Valve technically _did_ include Chromium as their front-end for their store, but they embedded it directly into their application and as such nobody else can reach it. Which is bad news, as if you want to embed it yourself, that's an extra 1GB of space. Which is bad for our 30MB game. So, in order to keep install size lower, we ended up opting for using WebKit instead. WebKit is what Safari is based on, just like how Chrome and Edge are based on Chromium. Fortunately, it's a lot smaller at around 200MB, which is technically still more than 5x bigger than the application, but it's better than the 30x. This, however, is proving to be a rather bad move. The Steam Deck uses a container system that runs self-contained little mini operating system runtimes that can just be stuck on pretty much any flavor of Linux with minimal compatibility issues. The unfortunate part for us is that it is Debian 11-based. Which is only 4 years old at the time of writing, but gcc and clang (C compilers) already dropped support for it, and thus WebKit also dropped support for _right_ before they did a major overhaul to a lot of important internal systems that fixed a lot of performance problems. When testing the newest update, apparently some of the libraries that were being provided by the OS received updates that have severely interfered with the game's performance. The startup now takes about 5-10 seconds on a black screen before anything shows up. Shutdown will keep playing the music and also requires you to press B to close for some unknown reason. The Main Menu had also dropped to 45FPS out of nowhere, and something with the audio playback got completely screwed over where it suddenly decides to stop playing music, and then every single sound that was attempted in rapid succession at faster speeds a few seconds later (In what world is that ever the expected behavior?! Just don't play it if it can't. This one is just stupid.) Fortunately, none of the issues actually affect gameplay all that much. Most levels still ran at 60FPS, and even when they dipped, we built the system specifically to support variable framerates, so the game speed is still exactly the same with no lag. The update was still published, as the issue was apparently caused by the OS changes and not our changes, so even old versions are still affected. As a result though, much of this week's work went in to optimizing the graphics system even more and attempting to play around whatever the heck is going on with that audio playback. We were able to hit 60FPS again, but at the time of writing, are still having the audio thing happen occasionally. So, what now? I think I've officially given up on WebKit. We're squeezing blood of out a stone at this point in terms of optimizations I can make to the game itself. It seems kind of silly that Windows is able to pull off 4k at 120Hz on 15-year old hardware, but the trimmed-down Linux port can't even handle sub-1080p at 60Hz. I've had an idea to try and use the Windows version of CEF specifically for the Steam Deck, which will keep it around 300MB and maybe solve some of our issues. It's going to take a bit, so fingers crossed.

[16naughts]

Dev Log May 23 - Work-Life Balance, emphasis on the Life part

Bad news - the new Fantasy Life is just about everything I had hoped for. Which is why this dev log titled May 23 was actually published May 24. I mentioned it before, but on the 26th here we're hoping to publish a decent-sized update. Most of that is good to go, however some of the stuff relating to the Cosmetics system changes are kind of iffy at this point and need just a little bit more polish. So it's probably going to be split into two here - one update on May 26th for the UI improvements and Cookie Jar stages, and then one the week after that on June 2nd for the Cosmetics system changes and Main Course stages. Everything is subject to change though - it's been a little bit chaotic around here, so we might have to shuffle things around. Although I wasn't able to procure a Switch 2 pre-order, so my June is looking mostly clear at the moment, much to my dismay. Apart from this brief poking my head up to report an update, most of our work is the same as it was last week - simplify Menu declaration for both our sake, as well as the future mod kit. All UI processing for the gameplay portions was completely re-written last week to get rid of all the Bind stuff and switch over to Tags. Any button can now go anywhere at any time, and all special boilerplate is completely gone from the menu declarations. Not super exciting from a standard user standpoint (apart from the addition of the ability to swap stages during the little victory animation), but it does mean that the API for the Main Course is very nearly at its finalized state, and we can start working toward adding full Steam Workshop integration in the near future. Now if you'll excuse me, I have some trees that need chopped, and some ores that need smelted...