#dev blog updates

[funkin-news]

funkin blog update!!: THANK YOU ERIC

lots of good stuff in this one :) i highly recommend reading the original blog post itself, there's so much juice that tumblr won't let me put all the juice in one post

but for the sake of tradition, summary ⬇️

so. been a while yeah

they've been working on a lot of stuff that's secret/under NDA/for a different update so they couldn't share any of that on the blog

while they've had instances of people having little things they could and wanted to talk about, they couldn't just put out a post that's like one paragraph and leave it at that lol

so, eric is now going to show us some stuff! yay!!

remember this?

well, eric's been working on rebuilding the chart editor from the ground up!

he's also been pulled aside occasionally to work on other stuff (redo input system, get cutscenes working, redo scoring, work on thing that was blacked out because NDA but when i clicked it i got this video, fix issues with gamepad)

ok now put this song on while you continue reading ⬇️

and now... the chart editor is COOLER!

now featuring:

chart isn't divided into sections to scroll through anymore, just one long scroll

opponent is always on the left and player is always on the right, no weird flips

waveforms under the character icons! you can see those!

icons can be clicked to change the character

measure ticks on the left (that thing that looks like a ruler!)

note preview on the further left

video-player-like controls at the bottom for the song

oh, and it's now powered by HaxeUI instead of Flixel UI, which allows for these toolbox windows:

and neat tools like this, which lets you set offsets for each of the tracks:

this new chart editor's toolbar has all kinds of neat stuff, like these!

for the third pic: "The Window menu. No the screenshot isn't cutting anything off you're imagining things." 🤨

there's more but at this point you might just wanna go read the original post

FNFC files - new standard for making charts! contains the chart data, including the audio files!

LOTS of new keyboard shortcuts for the editor too!

also a live input mode, where you can place notes at wherever the playhead currently is by pressing WASD/⬆️⬇️⬅️➡️

what that means is you can tap out some notes as the song plays and then proofread them after!

this is the part where i'd put another video because there's another one, but tumblr only lets me put one, so... go read the original post i guess

SONG EVENTS FEATURE! you see that ninth strumline on the right? anything put there doesn't show up as notes for either player, but instead runs a chunk of code at the given time

right now the only built-in events are camera control and getting a character or stage prop to play an animation, but modders are probably gonna have a field day

another video! i already forgot i can't add more than 1. damn you tumblr.

also, it, like, never crashes!

except for when it does!

[wishbonegame]

Wishbone Summer Y1 Beta Release!

At long, long last, the Wishbone Summer Year 1 Public Beta is COMPLETE! Download it here!

For those who haven't been following the project: Wishbone is a character drama-slash-farming sim game that takes place in a wild west-inspired setting. The player takes the role of a farmer, fresh off the wagon in a new town and tasked with building a successful ranch. The town of Wishbone might seem sleepy and mundane--albeit full of weirdos--at first, but there’s trouble brewing on the horizon: a fierce, prolonged standoff between the lawmen and the outlaws that will decide the fate of the town itself.

The Summer Year 1 beta represents a complete vertical slice of the first 25% of the final game. It contains around 10-20 hours of playtime, depending on how thorough you are.

[omeletcat]

I have had this joke stuck in my head for weeks now and i finally decided to crudely draw it i'm sorry y'all this is the peak of my comedy skills.

[last-sprout]

Last Sprout Dev Diary - Nov 22, 2024

Hello sprout folks! I'm Valerie, or @oneominousvalbatross, and I've been working on Last Sprout since July, and I'm wildly excited to share some of the things I've been working on with y'all.

Ignore that Twiggs' hat falls off that's natural.

I'm aiming for a Dev Diary once a week on Fridays, and I'm just gonna be giving a brief look into making a game! I'm learning how to do a lot of this stuff live, so I'm sure there'll be a ton of massive rewrites and changes. I have probably a dozen huge systems that are already built that I'm not going to be getting into in this post, since I'm already half a year or so into development, but I'm sure I will find space to include them later!

XP

I spent most of my time figuring out exactly how we wanted to represent XP in the world. We were pretty certain that we wanted XP to exist physically as a substance you picked up, so I started with a system from a previous build.

In that version, we just created a bunch of XP objects and scattered them into the world, then had some code that scooted them around. Of course, that means that we're tracking an individual unity GameObject for every single instance of a point of XP which is, uh, slow.

This is what we call 'suboptimal.'

So obviously we needed to not instantiate an entire transform every time we needed to spawn XP. Even if we re-used objects that would just be prohibitively expensive for an object that really just needs a position.

I'm not going to go over each step in the process, but after experimenting with GPU instancing to just draw a bunch of XP objects at once, eventually I landed on extending Unity's particle system, since it has a lot of the settings I wanted access to.

To make the XP move how I wanted, I wrote a pretty simple process that iterates through all the little blobs and checks how close they are to a designated collector, then uses an exponential decay function (with thanks to Freya Holmér) to make them move towards Twiggs.

I think every game should have an action that can be best summarized by making the noise 'SHWOOOOOP.'

Parrying

Parrying was a good deal simpler, but it still has its issues. Essentially, all a parry needs to be is a hitbox and an animation, with some callbacks to enemies to let them react to the parry. Whenever an attack hitbox intersects with either a Parrybox or a Hurtbox, it checks its tags to see if it's interacting with the appropriate entities, to makes sure enemies aren't hitting or parrying each other constantly. If it passes the test, it calls GetParried() on the intersecting object.

GetParried(), idiot.

For the basic behavior, parrying just interrupts the attack in progress and knocks the enemy back by a set amount, but there's room in the system to add all sorts of neat effects, which I'm sure we'll be taking advantage of in the future. It's been a challenge to juggle the various kinds of hitboxes, but it'll definitely be worth it going forward!

Of course, between all these bits there were a ton of bugfixes and little experiments, but that's a topic for a later dev diary!

[ourloveiselectrifying]

OLIE MONTHLY UPDATE!!! :3

Hello everyone, sorry have been busy, I'm not going to be answering many asks because I wanna focus on the game! But I'll answer a few here and there until the updates out, then I'll just answer everything if I can >:))

Stuff I've been working on (Spoilers!!)

THAT DINGO IS ANIMATED !!!

I've mostly just been replacing the old sprites with the new ones! It's really neat! The old sprite was just a ton of different images that take up a silly amount of space and makes it tedious making new slightly different sprites as Kevin has two forms, 5 outfits, a helmet, will have various bodily fluids on him, ect. SO the new sprite is a composite, every similar to the MC customiser! We playing dress up with him :3

It's also great because I can quickly take any expressions or outfits and easily update them in the future when my art abilities improve!

Kevin's sprite is much more dynamic and expressive now :3 Have some happy Kevin wagging gifs

Most of the fav animals are in the screen/not hidden within other animals now!

Added a few small additions to the sprites

Sketching out new BGs & CGs

Updated a few keychains that I was unhappy with, here is two of them!

New logo/presplash that's a lil' animated!

Side images! Have a look it moves! (Only on the first sentence and then is static until Kevin's face is in shot/final sentence, then it hides!) Also bonus Kev upside down because idk how to code

Writing the routes and figuring out the story some more!

Working on the dream buddy a little more!

New textbox character icons

[inkdragonworks]

Monthly updates are back! Who knows for how long…

I started back up on this mid-November, over a month ago, so I'll be combining that with December's work.

-------------------------------------------------------------------------

The bulk of it finishing functionality on the Chapter 3 enemies. Ratsa Go, Slush, and Chipper are completed now, and a round of fine-tuning was conducted on the rest.

Some initial tile-setting/background work has begun. Chapter 3 takes place in Snow Machinia, on the peak of Mount Glitteroam, so it'll have a wider variety of spots compared to Chapter 2's caves.

This one's the mountain peak pass towards the city! It introduces the snow and wind effects, something that'll persist throughout the rest of the chapter. Wind especially plays an important role in conjunction with the new Propeller Gadget.

The rest of December was spent jumping to the middle of Chapter 3, at the construction site, refining the level design and scripting cutscenes for it.

Chapter 3 is really where the story gets going by the end, and while that sounds weird, I think by that point you'll have a good grasp on who Poppin and Jupa are, and introduced to all the major characters of the main plot. The structure also helps support potential exploration and side quests, stuff that I really hope to get into in the future.

Here's a portion of the level design for now. These two larger rooms are separate buildings, with multiple routes to go up it. You can either stick to climbing one building, weave between the two, or explore both of them for all their chests.

Besides Chapter 3, some additional brainstorming occurred on Chapter 4. That part of the game has been the most tricky for me to settle on, and I feel like I'm closer to something I'm happy with. It's difficult balancing all the elements; the main difference is the second half of it is light on story cutscenes, compared to the rest of the game. Like a "dungeon" type of area… though I wouldn't say it's as complex as one.

-------------------------------------------------------------------------

I'm hoping that for January, I can finish up the level design and cutscene scripting for the Construction area, and finish up Chapter 3's main boss, Rickity.

A lot of his attacks were already completed way back, so it should be a matter of making his desperation phase, intro/outro cutscenes, and then balancing out the states of which attacks he selects.

And from there, idk, it depends on what I feel like doing. Jumping to the earlier part of Chapter 3, continuing with the rest, more tilesets/backgrounds, or maybe enemy/obstacle coding for Chapter 4. It's good to keep things open for the sake of interest and not getting worn out on just one thing. Coding enemies or cutscene scripts get less fun when you're on the 8th one in a row.

-------------------------------------------------------------------------

That's about it for Poppin & Jupa: Pocket Adventure! Enjoy the snow, if you live somewhere that still gets it.

[simbishy]

Heyy. I just wanted to shout into the void about an open world survival video game I'm working on with friends. It's kinda like a mix of minecraft, 7 days to die...and I can't help but put sims-esque building into it haha. On that note...I haven't had much motivation at all to work on the sims sorry, maybe one day I'll return to it but for now I really wanted to learn Unreal Engine which took me here for this moment. Here are some shots of the environment I worked on. I laboured over those trees so much we unofficially call this 'the tree game' now. It's still super early stages and we have a playtest going to collect as much feedback as possible. It's been a fun learning experience thus far :) Thanks for reading xx

[front-facing-pokemon]

[neonrain-dev]

Updated the scum key model.

Perhaps this is all new information to you but I wasn't satisfy with the old model that was just a simple textured pyramid object with sticks thrown in there.

Old model in question:

[eclipsettrpg]

Eclipse: a DIY punk TTRPG by @yvepaints

Welcome to Eclipse’s game dev blog!

Eclipse is in extremely early phases. It is not available for purchase anywhere. This pinned post will be updated periodically with the current phase of development.

Current phase: initial design & writing

[funkin-news]

funkin blog update: "the funkblog with factorio references..."

the summary below does not include nerd stuff, if you like nerd stuff read the full blog (there is a lot of nerd stuff) (it is straight up called nerd stuff and put in its own box in the blog post)

⬇️

MORE chart editor stuff!! there is now playtesting and it has a lot of customization, from where you start to what you load👍

meet HAZEL, one of the funkin' crew members who hasn't written on the blog before toda... *checks date* ...yesterday!

hazel manages server stuff and has built the API for online leaderboards in fnf!

the way this is gonna work makes it so they don't have to rely on the game to do calculations, which minimizes bugs fumbling your score AND lets them check submissions server-side to see if there's any cheaters!

that's not all hazel's done: they've also made nifty tools and automations and fixes for the devs to improve and speed up the work process in the long run!

see this?

that's a lot of time, right? well now it looks like THIS!

there's now also a funkin' launcher for the testers! (the final game will not ship with a launcher)

hazel's also set up a single-sign on (SSO) service so you don't have a kghjpillion accounts for every different funkin-related thing: just one account for all things funkin!

based on your login, the download page for any development tools will list out all the ones you can access!

there is also the log viewer for devs:

MERCH UPDATE! the pin manufacturer has 400 pins left to send! here's 2000 of the sent ones!

pin shipping is starting with about 500 orders shipped this week and then likely ramping it up to 1000 orders shipped per week!

"These are estimates from our pin shipper... so if they are off we will make sure to kill him..."

[wishbonegame]

May update!

Honestly... not a ton of updates to report for May. I was traveling for half the month, and many of my days off were spent preparing for traveling. I will ALSO be traveling this month, but not for as long. Phew! I am looking forward to not traveling for a bit!

I have been plugging along implementing the biggest event for Summer Y1, though. It's got a total of... geeze, maybe 16 "segments"? That's across two branching paths and some segments are optional/very short, so it's not like you have to play through anywhere close to 16 unskippable map transitions in a row... but it's still a lot, and quite time-consuming to implement. MOST EVENTS ARE NOT LIKE THIS...

In any case, I expect to be done with the first fork of the two paths next weekend. And the second fork will go a lot faster because it reuses stuff from the first fork.

After this... well, there's still more Summer Y1 event stuff to do. And other little things! But it'll be nice to be done with this big event, at least...!

[omeletcat]

I drew Fireboy and Watergirl in my pixel art style!!!!

[last-sprout]

Last Sprout Dev Diary - Dec 6, 2024

Hello again folks, I'm back for another dev diary, and it is Upgrade Month for Last Sprout!

If you haven't read one of these, I'm Val, @oneominousvalbatross, and I'm the tech half of the sprout team, and I'm doing these weekly to talk about the process of making a (very ambitious) game, including all the various missteps and learning that I'm doing along the way.

Here's last week's dev diary on Brains

Last Sprout is a roguelite, so that means we need ways to modify your build as a play session continues. So, this week I want to talk a little bit about what we need to prioritize when we're designing our progression.

Get that upgrade juice - you need it to UPGRADE

What an Upgrade Should be

This game is a roguelite, so that means we need ways to modify your build as a play session continues. So, this week I want to talk a little bit about what we need to prioritize when we're designing our progression.

By 'expressive', I mean that I want the choices I make to feel meaningful, and to feel like they are informed by what I want that build to look like by the end of a run. So, an upgrade like "Gain 10% bonus attack speed" is kind of the minimum level of expressiveness. Sure, if I like attacking I can prioritize that a bit more, but when it comes down to it I'd just compare this against other upgrade options and take it if it feels more abstractly valuable.

I don't think there's anything wrong with this, and in fact, I think some number of low-impact choices are helpful for a roguelite to keep a player from tiring out and just picking the easy-to-parse options by the end of a run. But that said, something like "Your melee attacks cause you to lunge towards the nearest enemy within 3m, but you can no longer block." makes your build look and play very differently from others. Plus, when you take big, build-defining upgrades like that, suddenly when you see a small attack speed buff, you think "oh, well since I can't block, attacking faster might be a way to mitigate that downside."

From a design perspective, I find it easier to design expressive upgrades by adding complexity, but that represents a pretty big development cost if you're writing all your upgrades by hand. That leads us to the tension I mentioned earlier - we also want there to be variety in our builds, we want you to have each run feel different enough from each other that you don't end up sticking within a single comfortable playstyle. But, if we want variety, we need quantity of upgrades, but making upgrades can quickly get very time consuming, especially for a team of this size.

To resolve this tension, we had two major ideas. One of them is still in early stages, enough that I think I'll save that for when it's more complete - unless you're in the patron discord, in which case you've already seen some mockups! I'm going to talk about the other option now:

Mods and ModActions

So first of all, I decided to make Upgrades a subclass of a Mod. A Mod is just anything that modifies an entity's capabilities, but it also includes Buffs, which are the temporary versions of upgrades. This is the data that a Mod stores:

BEHOLD

Ok so it's not that interesting. But that's kind of the point! A Mod, by itself, is just a container for a bunch of little pieces, that are all defined separately, the bones, if you will. The Mod itself is responsible for applying all of its actions to an entity, but it doesn't know what those actions are.

The meat of a mod. Or the brains? I'm losing track of this metaphor.

As a simple example, a mod action can define behavior for when the mod is added, removed, canceled, or activated. Added and removed are simple. Canceled is if the mod is removed in some way that isn't through natural gameplay, like if the entity needs to be refreshed to a base state. Activated is a sort of "whenever X thing happens." It's our container method for mods that will need to do something repeatedly, like when a player takes damage.

We aren't limited to just modifying the entity though! There's already a ModAction for playing an animation, which can be hooked up to any of the base three mod events.

BEHOLD AGAIN

The strength of these actions is that any Mod can contain any combination of these actions, attached to any stats! So the process of building new mods is, much like the rest of the design workflow, like snapping together legos. When we need something completely new, I can go in and write a new ModAction, and then that action becomes available for the rest of development, and in combination with all the other previous ModActions.

I've found that combinatorial approaches create a lot of variety for the amount of design work they require. If you create four mods that are all standalone, that's four different experiences. If you make those out of three individual actions each, suddenly you can mix and match these pieces, and the variety explodes out geometrically, not to mention how mods can interact with each other. Of course, then that can become a bit of a balancing nightmare, but that's a problem for Future Val!

Thanks for reading! If you have any favorite progression systems in roguelites (or roguelikes!) I'd love to hear about them, especially if they do something unusual. December is going to be pretty much entirely dedicated to progressing, both per-run and per-save, so next week I'll be back with something along those lines!

[glugslove]

Adding mechanisms like doors and bridges

you can also transform these with magic

[0enoth]

0enoth returns for the 32492384th time

Hello, yet again me, 0enoth answering some questions someone might have 👽.

Q: What even is a s0lavita and who even are you?

A: I'm the developer of s0lavita, it's a mainly surrealist and horror-ish & psychological rpg where you play as a (doomed) protagonist that meets wacky and weird people, such as "Chrom" "0enoth" "Vita".

You're introduced to Mors as a new caretaker, an observer of sorts, to be entretained by everything that happens. Mors will gladly tell you about herself.

She lives in an apartment complex with past hers' and people of paralel universes, they all have resorted to sell microplastics and computer parts to make a living, will Mors succumb too? Mors will show you around her art gallery, from there, you'll meet the in-game oenoth (that for some very normal reason and no hidden lore that you'll have to discover and put together) that for some reason you're very eager to meet, maybe you have unfinished business with them. Maybe not. Maybe you'll unlock hidden endings. Ah, after that, you'll play as "Chrom" and decide if to save her or not.

from there,you'll have different choices on what to do, that leading to different multiendings, including hints for the hidden ones.

(Keep reading if you're interested 👽 vorp!)

(Askbox open)

Q: Who is who?

Depending on the player's (YOU!!!!!) decided route, Chrom will grow fond of Mors, or not.

A: Chrom is a pale woman with a hairbun. She's a scientist that has an interest for the sideeffects of sickness and experimenting on people. She is almost always in her home, she isn't fond of going out unless is utterly necessary.

0enoth is a phyisically androgynous male-ish humanoid creature that has half body missing and a "core" in the middle of their chest (s0lavita lore stuff). He tends to be always putting on a smiling persona, he's also Mors' friend and probably Vita's sworn enemy.

There's two more hidden character, one is from a future game, prequel to S0lavita.

I cannot describe who "Vita" is, it's major spoilers lol.

Q: Is there any sensitive imagery or topics?

A: There's only blood, body horror (Oenoth's lower body basically) for imagery, as for topics:

Suicide

Cannibalism (slightly discussed/metioned)

Attempted murder/ murder

Stabbing ⤴

Body horror (flesh lower body)

Blood