#game dev update

[angelpuns]

cry laughing cause I didn't know my screen recorder would capture the audio so enjoy this clip of Leo in his room with game grumps as the audio (on accident)

[clumsybearstudio]

The Hungry Horrors free demo is out now on Steam!

It’s our first ever Steam release – and we’re nervous, excited, and very sleep-deprived.

We’d love for you to check it out.

Hungry Horrors is a pixel art roguelite deckbuilder where you feed legendary monsters from British and Irish folklore instead of fighting them. Build your deck with traditional dishes like Yorkshire Pudding, Boxty, and Bara Brith. Each card is a meal, and every monster has their own taste.

Get it right? They let you pass.

Get it wrong? You become the next meal.

If you’re into:

• roguelites with actual strategy

• folklore, fairytales, and mythological creatures

• games like Slay the Spire or Hades

• cooking mechanics that aren’t just minigames

• grim but whimsical pixel art

…then you might just enjoy this.

The demo includes:

• 2 full biomes

• 6 unique monsters and 2 bosses

• over 20 traditional dishes

• deckbuilding, buffs, and branching paths

• and a really grumpy Buggane that hates potatoes

We’ve made everything in Godot, drawn every pixel in Aseprite, and poured our hearts (and stress) into getting this playable on Steam – including Mac, Linux, and Steam Deck.

If you give it a try, let us know what you think! Reviews help us so much with visibility right now, especially as a 2-person team self-funding everything.

Thanks for being part of this weird little cooking horror journey.

[omeletcat]

I FUCKING LOVE HEATHERS i recently watched the musical and i cannot listen. to any song that isn't Candystore, dead girl walking, beautiful or big fun.

i wasn't expecting so much suicide in the musical tbh, and also thought that heather (the red one) would be more of an antagonist but she just died.

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

[hellishcargirl]

Making a lil wind effect animation for when trees fall after being chopped down by the player in my game that I'm developing :3

[cultofgalaxy]

Some of the progress we've made so far! We hope to release a short demo later this winter.

Our game is planned to be a 2D metroidvania inspired by Kirby & the Amazing Mirror, in which you'll explore multiple planets and befriend starsprites, who will protect you on your galactic adventures. ✨🪐

[revon-aurora-borealis]

are you fucking kidding me...

[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

[l330-n-flesh-and-blood-game]

Little Update: Stairs :)

Yayyy

My plan rn is to finish the entirety of the prolouge before anything else, and then I will make that a Demo while I work on the rest of the game :) It will also help me figure out what's working and what's not so yayy

( can't remember if I already said all this or not but yeah )

[cryptid-campsite]

My, My… What do we have here?

A finished dialogue system perhaps?

Yes! Yes it is! How delightful~💕

---

original post date: October 6, 2024

[amones]

[clumsybearstudio]

Check out the brand-new trailer for Hungry Horrors

Our indie roguelite deckbuilder, developed in Godot and featuring hand-pixelled artwork created in @aseprite , brings mythical monsters from British and Irish folklore to life. Instead of fighting them, you’ll need to feed them dishes they love—otherwise, you’re in trouble! This latest update showcases new cards, revamped UI, new monsters, and the addition of an in-game compendium.

We’re also hard at work on our first demo for Steam, so be sure to wishlist Hungry Horrors to support our development! 👇

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

[alexfoundausername]

A Letter To Baji Keisuke (VN) Update

Hi, I thought I should at least give an update on those who were following me for the development of the visual novel based on A Letter From Baji Keisuke.

I am sorry to say that I am putting that project on hold for the time being. I wish it didn't come to this because I really wanted this project to be completed.

The reason I have to put this project on hold is because I don't have enough time and energy to work on a passion project while trying to earn enough money for gender-affirming care. After the US election results, I expect this undertaking to be even harder and more expensive. (If anyone wants to support me, please consider following me or commissioning me through my linktree)

I'm so sorry for the let down, as I was also very hyped for this project.

Here are some artwork that came out of this project so far as well as the script's draft that was never completed ~