#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!

[angelswithscalywings]

Happy Anniversary, Angels with Scaly Wings! (+ Sequel Development Update)

Another year has gone by as today marks Angels with Scaly Wing's 8th birthday. Wow! It's hard to believe it's been this long. When I was initially planning the sequel (around 2017 if I remember correctly), I knew that the game with its increased scope and planned improvements compared to AwSW would take a long time to complete. It was then that I decided to create the webcomic Angels with Broken Hearts to both bridge the gap and give greater context to the setting and characters - which will be very relevant in the sequel. Of course, AwBH then turned out bigger than I initially expected as well, which I suppose is only fitting as it continues to tell new stories about the AwSW characters while I diligently continue working on the sequel. With over 300 pages already released, we may end up with over 400 in total when it's all said and done.

For the last few years I believed the end of development for the sequel to be in sight, and we have never been closer to that than we are now. However, after missing the previously announced 2023 release date I am hesitant to make any announcements I may not be able to keep. As such, only expect one when we are very close to release and I'm sure we'll make it this time - even though I do already have a date in mind I'm aiming for. But while development has certainly taken its time, for me it is finally starting to feel like we're getting there. Why am I saying that? Because in our current build, the first playthrough of the game (seeing the first ending) is already fully playable, including the possible endings and all main character routes. Why is this such a huge milestone? Because the first playthrough alone will take the average player longer to play than getting 100% in AwSW (with all achievements and endings). As such, it should be no surprise that the script of this build is already significantly larger than that of AwSW in its entirety. So, what is the current state of development? What have we achieved so far, and what is still missing? Let's break it down: - Planning / Game design is 100% done. This includes the plan for the overarching story, mechanics, mini-games, characters, main and secondary character routes, all endings, etc. - Character designs are about 95% done. - Backgrounds are about 90% done. - Music is about 90% done. - We have finished sprites for 30 story-relevant characters so far.

The sprites for about a handful of these characters are still missing (which makes a total of ~35 characters with story relevance in the game), and after that we only have to add an extra sprite to a character here and there based on other aspects of the game (such as what happens in certain endings and playthroughs beyond the first). AwSW had sprites for 21 different characters (with story relevance) + 8 one-off characters (cameos which only had a very small role in the game). The sequel will have many one-off characters as well, though they are handled differently this time. The current build has about ~30 of these so far.

- Programming/writing is about 80% done. I still need to write and implement everything that is not available during the first playthrough based on my extensive notes for what we have planned for this. This includes secondary character routes, certain endings and things that can change throughout the game based on prior playthroughs. While nothing to scoff at, this is dwarfed by the content that's already in our current build. - CG Illustrations: ? These are pictures that are usually only seen once during a playthrough, such as when meeting a character for the first time (like Adine in the rain in AwSW) or as part of the story. We haven't made quite as much progress with these yet as with the other areas, mostly because many CG illustrations are dependent on certain other things in the game being finalized first. But with the previous milestone being met, making more of these illustrations is a focus for us now. The good thing is there is really no upper limit to how many of these we can include. Most likely, we will just keep making more until it's time to release this game. With all the progress in mind, I feel like I can finally start to share a lot more about the game in the coming months. For example, I already have a gameplay clip in mind I want to release soon. Of course, I know people still have a lot of questions about the game. I believe these are answered best by experiencing the answer, rather than just being told. To that end, I am also considering to release a demo for the game that would feature the entirety of the game's first chapter. With over 70.000 words, the script for chapter 1 alone is already the size of a novel. Preparing something like this might only be possible once we are close to release, though. Perhaps another option could be to release a smaller chunk or two of chapter 1 as their own demos. What do you think? In the meantime, I'll try thinking of more fun and interesting ways I can share more about this game.

[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

[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.

[front-facing-pokemon]

[neonrain-dev]

Screenshot Saturday

Energy expansion upgrade + ammo capacity upgrades, self explanatory.

[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]

June Update!

The residents of Wishbone are taking it easy for the Summer seasonal holiday of Picnic Day! On this day, you can find them hanging out not in town, but out on the prairie, having little picnics with their friends and playing the town's favorite sports-adjacent pastime, "Ball".

(Apologies for the funky image quality and disco light flowers, the gif recorder is not very refined... this looks far smoother in game!)

You can talk to everyone on the prairie to have some special dialog, including some longer conversations with romanceable characters and their friends. Some of them will even share their lunch with you!

...Anyway, as I mentioned last month, this month was also somewhat busy. I did finish the Picnic Day event shown above, as well as the biggest event of Summer Y1 that I mentioned last month. I also did a bunch of small bug fixes (mostly related to the quest log and calendar... it's rare to find a bug involving any of the older core game systems at this point!).

The two current tasks on my plate are writing and then implementing one of the other big Summer events, and working on filling out the NPC ask about menus. I wanted to try out a new, faster approach for the latter... it's working pretty well.

Summer (in real life) is looking pretty busy for me overall (mostly in good ways right now!) so I keep having weekends that I can't fully dedicate to Wishbone, but I always carve out what I can where I can and am looking forward to implementing this next big plot event. I still have my eyes on finishing Summer and releasing another more up-to-date public beta that includes both Spring Y1 and Summer Y1 (a full 1/4 of the game!), but that's looking more "early fall 2024" at the moment.

See you next month!

[omeletcat]

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

[last-sprout]

Last Sprout Dev Diary - Jan 10, 2025

Hello, and welcome to the new year! After the break, I'm here for another dev diary - this one being a bit more about something conceptual. If you want to read the last dev diary from December, you can do so here.

If this is the first one you're reading, I'm @oneominousvalbatross, and I'm the tech side of the sprout team! This week I mostly worked on status effects, but I want to take some time to talk about a broader, more conceptual topic, and save the full breakdown for next week.

My poor boy, who has every disease.

Something I don't think I've really specified before in these dev diaries is my background in game dev, or, rather, my lack of background. I started seriously learning how to code a bit over a year ago, and entered my first game jam in February of 2024.

(The game was barely functional, but it did exist so like, there's something.)

My academic background is in philosophy (simultaneously the best and worst thing tbh), and apart from being pretty good with computers in a broad sense I didn't really have much to go on for this project. I'm bringing this up because I'm going to be talking about something that I had to figure out for myself, but that might be like, compsci 105 or something if you went through school for it. That said though, if you have always kind of wanted to make games, you can absolutely make games! I didn't think I was a math person, or a coding person, until I started doing it.

Game Development is Hard

I'm going to assume that software development in general is hard, but I haven't really done that, so I'm talking about game dev. I spent around two weeks not touching the game, and when I came back, the first thing I noticed was just how hard it was to get my head back around something with this many systems! This was also something I ran headlong into when working on that game jam, I reached a point in like, a week where I couldn't touch any system without potentially breaking every other system.

The solution I use, and the reason why I could come back to this without completely losing my mind, is to reduce the number of access points into a system to the absolute bare minimum. For example, we can look at the animation system. It's really complicated! It needs to be able to swap the sprites out on a variety of different renderers, it needs to be able to adjust animation speeds, control shader parameters, and it needs to be able to queue up multiple animations in sequence, plus it needs to send out events on animation end so that I can use them to time up other game actions.

If I was to condense all of this into a few sentences: A system can be as complicated as it needs to be, but try to envision it in its own little box, with precisely one entrance/exit. If you need to spawn a projectile, you should really just be able to go, like, SpawnProjectile(projectile), with as little external work as possible. This means if you need to completely rewrite how spawning projectiles works, you can do that, and all the other classes that spawn projectiles can still just do their thing.

A helpful diagram

The way I would've done this originally would have been to have, like, a SpriteAnimator class with a 'speed' field. I'd set it to one by default, and then whenever I need that speed to be different, I'd have whatever object needs to change the speed go in and set the speed to whatever. If you've done a lot of programming, you probably immediately realized the tons of problems this could cause - problems into which I ran headlong.

What do you do when you want one animation to play at a certain speed, then go back to the previous speed when it's done? If you do, do you assume that the speed was set to 1 before, and just reset it, or do you have one of the two objects involved store the previous speed to go back to it? If you do, what happens if, halfway through an animation, another object butts in to adjust the speed again? Say you're playing an animation at half speed, and then a speed buff gets applied that's supposed to last for a minute. Your speed buff goes in, sets the faster speed, the animation suddenly starts playing faster, then when the animation is finished, the object that was waiting to reset the speed goes back in and sets the speed to 1, leaving the animation playing at the default speed when it's supposed to be faster.

These kinds of problems will always be a risk, but in my specific case I split the speed at which an animation plays out into three places. First of all, an animation has a frame rate, which is meant to never change. We do most of our animating at 12 fps (on twos, I think is what you call it in the traditional animation world? idk, not a 2d animator), and each animation object keeps track of its frame delta (1 / frame rate) so that the controller can progress through the frames at the right speed.

However, we don't submit the animation to the controller in its unaltered form. Instead, we have a data structure called a PlayableAnimation. This contains the animation itself, but it also has the speed at which the animation should be played, as well as some other useful info that might change between two instances of the same animation. A controller maintains a stack of playable animations and can look at the individual speed of each one as it progresses through.

On top of that, there's a final speed modifier that can be submitted along with the playable animation, without changing its values. This way, if I want to play an animation at double speed for whatever reason, I don't necessarily have to set the value for the entire controller, I can just say this animation should be faster, and nothing else. Some animations have different frame rates, or are re-used with different speeds for different purposes, and I can do all that configuration without having to put all that weight on one field.

All of this sounds wildly complicated, and it kind of is, but importantly, if you're playing an animation from any other system, all you do is type in "Controller.PlayAnimation(animation)". You can also go like, "Controller.PlayAnimation(animation, speed: 1.5)" if you want it to play faster, but all of that stuff is handled completely without additional input. This is what lets me come back to the game and keep working on it when it's been months since I've touched a part of it.

Why This is Relevant Right Now

Status effects seem simple, but they kind of need to touch every other system at least a little bit, which is why I spent all that time talking about making systems. A status effect needs to be able to do things like apply damage, but it also needs to be able to play animations or sounds, and it doesn't always want to play those things on the source of the effect.

Some demos for the animations different status effects will use.

Plus, this is a roguelite, so we need to be able to add and modify status effect stuff within the upgrade system, which might mean modifying the magnitude of the effect, changing colors on animations, or tying other things into the effect when it goes off! As long as each of those systems has the cleanest possible entry/exit points, this is doable, but it's been a long battle making sure the game can keep moving forward and not get mired in constant bugfixing and complexity management.

I have a lot of cool game design thoughts on the effects themselves, but I think I'll leave that for a later week. As per usual, thanks for reading, feel free to send any questions or thoughts here or to @oneominousvalbatross, and I'll see you next week!

[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 & next phases of development.

Current phase: rough initial design & writing

Next phase: beta testing round 1

[glugslove]

Adding mechanisms like doors and bridges

you can also transform these with magic