Domo Yoro
patreon
Development Update: July 2024
🕑 Added 2024-08-01 00:50:34 +0000 UTCHey everyone!
Thank you for your patience as I continue working on the game- sometimes in silence, as it can be a little difficult to put a formal post together. I’ve realized that it’s been 9 weeks since the last post, so I want to detail how development is progressing.
40%
Firstly, and most importantly, I should announce that the upcoming Cherry Carry Cascade build will only feature 2 out of the 5 branches. Each branch is a full-sized level, and I think I bit off a little more than I could chew.
This decision comes from a number of reasons. Firstly, it’s not very good for the game if I focus on optional content before completing the main game- especially if I’ve spent nearly 7 months on it! There’s still 2-3 full-sized main game levels that need to be built- from scratch. Such a big time commitment is a risk when we don’t know what might impact development in the future.
Secondly, I have gotten a little fatigued from working with the same massive level for so long. I don’t really regret the grand scope though- this level was important for identifying a lot of issues with the current design tools, as well as with the mechanics featured in ‘DemoCarry’ / Junkyard.
I do fully intend on finishing the other 3 branches of this level at a later date! All the mechanics are there, working, and polished. I’ll be able to make a lot more level design progress when I can step back for a bit and evaluate the bigger picture.
These upcoming two branches of the level will focus on bombs and tires- and all the awesome things you didn’t know you could do with them. Like I said, they’re both basically full-sized levels, so there’s a lot to dig into here. (Currently, playtesting sessions last between 2 and 3 hours!) I’m really happy with the level design I’ve been doing for these levels, and I look forward to seeing everyone’s reaction!
6 Weeks of Polish
With that announcement out of the way, here’s a quick breakdown of the things I’ve been working on since the last post.
Level Design
Lots of level design- and a lot of edits to tighten up the overall concept. This includes adding extra rooms to further establish important concepts, changing the order of some optional challenges for when the player is more comfortable with them, and keeping the focus of a given room on its intended “story” (rather than having some random bits get in the way and cloud the narrative).
I also feel like my level design skills have improved! I’ve been able to make some funny rooms and more interesting secrets. I feel more confident with my auto / semi-auto room designs as well.
Bottomless Pit Indicator
The colors changing in the BG need their timing adjusted, but I’ll get around to it
This was something I mentioned in the last development update, but I didn’t quite finish it back then. It turns out the last 10% of the work was actually the last 50%. I had the right algorithm to map out bottomless pits, but Unity has some funny business going on when you try to query physics information from a non-level asset.
Anyways- this bottomless pit algorithm is interesting enough in a technical way to warrant its own post. Let me know if you’re interested!
Grab Box
These are boxes that allow you to grab an outlined object at any point in the box. I introduced this after it became evident that outline objects were sometimes hard to grab, especially when there was more variance in player position.
Grab boxes solve this problem by lowering the precision to grab the object. This lets the level design focus more on what you do with the object instead of whether or not you grab it at all. It’s a small feature, but it’s quality-of-life nonetheless.
(Also, I apologize for the softer image quality- I’m trying something new with how I record footage from the game in order to avoid manually cropping the recording for that pixel-perfect gif.)
Bottlecap Label Art
Every new bottlecap challenge requires new bottlecap designs, and those designs take time! All of the 30ish bottlecaps in Cherry Carry Cascade now have label art, assigned series, and are present in the collection screen.
The new bottlecaps are still missing names and descriptions, however.
Additionally, a few of the new bottlecaps required updating the 3D model & updating some bottlecap display logic, but that’s all taken care of now. You’ll know what’s different when you see it!
Flourish Animations
Flourish animations! I occupied myself with these animations whenever I felt fatigued from working on the level. It’s just a bit of extra visual polish on top to make some actions and reactions more clear.
There’s now an animation for when the penguin bounces off of an object by hitting it with their beak. Also, the pegs now have little animations & particles to help visually confirm that they’ve grabbed something!
Rotation animations are kinda my thing. I figured it’d be cool to see a bomb rotate through the air after you throw it!
Carry & Throw Changes
This change is subtle, but important: you can now interrupt the pickup animation by throwing immediately.
This change was made because one of the playtesters was having issues consistently throwing objects in the right direction. It turns out that they were releasing the grab input during the pickup animation, then they’d change their directional input after the throw input… except the throw would only execute at the end of the animation, and they’d get the wrong throw direction.
Before this change, you could only juggle about 3 objects. Now you can juggle as fast as you can mash!
Scale Platform Rework
After multiple playtesting sessions, I finally decided that scale platforms had some issues that were important to solve for this level.
Most notably: if you land on a scale platform, it will no longer sink automatically. In order to make the platform swing, you need to down burst onto it (or fast fall land on it). This will make “missing” the input more forgiving and less awkward. If I ever need to make it less forgiving, I could just make the scale platform crumble, too.
Secondly, scale platforms also had a lot of issues with how their platform momentum would be stored; they’d often send the player at diagonal, rather than horizontal angles. This is because platform momentum is normally stored as the greatest X & Y velocity components, which causes a diagonal bias when a platform changes direction.
So instead, the platform momentum stores a direction and magnitude. Whenever the player leaves the platform, this direction is biased towards a cardinal direction — the closer the direction to the cardinal, the more it’s biased. (If you’d like to see a visual breakdown, let me know!)
I’ve also fixed multiple issues with the platforms, making them as consistent as possible. Issues include:
Up burst from a platform would sometimes give the penguin incorrect momentum
Down throwing a tire onto a platform would sometimes cause the tire to bounce
Platforms sometimes registering as slopes
Platforms sometimes “eating” jumps
A couple more things that I can’t remember
New Art!
Although Magi had to take it easy for a bit due to a family emergency, things are good on his end. He’s been working on a lot of tiles & decorations, and they’re all absolutely awesome. Here’s some of the new decorations:
The new tileset needs a shader to look correct, and I’m still working on that shader. We’ll be showing the new cave look at a later time.
Fixes!
Normally I wouldn’t go this in-depth into fixes, but plenty of these also affect the ‘junkyard’ level.
Fixed a bug where throwable objects would disappear shortly after a room transition, even though it’s present in the new room.
A bug where a throwable object would be regrabbed when entering its original room while carrying it.
Bombs now explode more consistently.
Tires no longer bounce off of ceiling slopes
The penguin registers tire stomps more consistently.
Fixed the hit-stomp conflict: beak-bouncing off of an object on the same frame you stomp on it. (This is important because stomping on tires in the air now sends them downward.)
Fixed sloped semisolid spikes. This needed to be fixed more than once…
Fixed spring offset position. The original implementation would sometimes briefly place the penguin inside the ceiling.
Fixed an issue where the penguin would sometimes bonk on the ground behind a spring.
Fixed more issues with springs and boosters.
Fixed an issue where Assist mode couldn’t be enabled.
Adjusted FBurst animation to more closely match the penguin’s collider & beak position.
Adjusted analog stick deadzones to better support diagonal inputs.
Fixed an issue where the player was unable to collect bottlecaps when entering door to / from the hub
Fixed DemoCarry music sometimes going wonky
Fixed (or rather, properly implemented) layered music
Fixed a few camera bugs. They’ve been around in every build of the game!
Fixed and adjusted a lot more minor things.
Some of these bugs popped up after the release of the public demo, so not all of them are reproducible in older builds.
Other Polish
New abstract variant of scale platforms
Decoration rope!
Balloons now reset to their unpopped state when the penguin touches safe ground
Bottlecap collection status (on the pause screen or over a door) now supports more than 20 bottlecaps in a single level. It took a few hours to write up the script to create a second line of caps and split them up reasonably.
Optimized mountain / cave bgs + block particles
I’ve implemented the animation logic for the penguin standing on a ledge, as well as the penguin pushing up against a wall. The animations have not been finished yet, however.
Tooling
Organized a lot of things- data, sprites, filenames, etc
We have an internal spreadsheet for bottlecap names / descriptions- updated that too!
Made it a lot easier to work with bottlecap assets in the editor.
Reworked the bottlecap database to make it a lot easier to group together bottlecaps by series. (Bottlecaps had to be manually grouped one by one prior.)
Bottlecap assets now have icons in the editor
Created scripts to auto-build for multiple platforms; this saves me a couple minutes every time I create a build for a playtest or release/update a build.
Created tooling for testing background assets.
Where’s the other 3 weeks?
I’ll be honest: I made the poor decision of starting Cookie Clicker. It’s a game that rewards you for running in the background and checking in on it occasionally, and it rewards you even more for active playing. Those little checks would just turn into hours-long sessions. It’s a really unique game where numbers just spiral out in all directions towards infinity… I just couldn’t put it down! I took back some self-control once I kind of ran out of things to actively do.
After that, I took a week off to finally see some of my friends in-person for the first time- some of whom I’ve known for nearly a decade. It was a wonderful trip! I can’t wait for the next meetup. It also helped refresh my work mood.
Unfortunately, when I finally came home, I came back to a power outage. Since it was the week of July 4th, an american holiday, the power company wasn’t available to help resolve a billing issue. So I just… couldn’t work for nearly a week without power.
Due to these 3 missing weeks, I figured it’d be fair to pause billing for 3 weeks. This is time that isn’t spent towards game development, so no one should pay for it.
Why Polish This Build In Particular?
I always want to polish the patreon builds more than I have been able to. By holding myself strictly accountable to the deadlines I set, I would always have to move on from a patron build, leaving it under-polished. Furthermore, I also want to make up for a lack of a patron build in late 2023, as well as no build earlier this year.
We’re always thinking ahead to the next thing, and it seems like a good idea to maintain the same level of polish present in public demos for this level. After all, if we decided to run a kickstarter instead of a patreon, then we’d have to make the patreon builds accessible to kickstarter backers — and they’d expect a higher level of quality for those builds.
Lastly, it’s good to have data on how long it takes to develop a level from start to finish, including the art, effects, tools, and all the polish. This helps us create a more accurate time estimate for other levels.
So, How Close Is The Build Then?
There’s still a good amount of work left! With the sheer size (and sometimes complexity) of this level, I’ve needed more playtesting sessions than usual for quality assurance.
Remaining Work:
Free camera movement. While I try to make rooms as sight-readable as possible, some rooms would really benefit from the player being able to look ahead.
More fixes. Only a few of them are complex, and most of them are minor. It’s less work compared to what’s been fixed already.
Additional level design iteration, including reworking how one of the mechanics is introduced.
More options for throwing controls. Some playtesters struggled with timing their directional inputs before / after a throw.
Decorating rooms. Only about 10% of the rooms are decorated right now.
Maybe an extra visual effect? It’ll be complex to implement properly, but the prototype looked really cool.
Hopefully my next post is the actual release of Cherry Carry Cascade. Thanks again for all your patience and support!
