last-sprout

[last-sprout]

Following a Twitter trend - here’s 15 seconds of our video game, @last-sprout 🌱❤️

[last-sprout]

Last Sprout Dev Diary (sort of) - Jan 17, 2025

This is gonna have to be a short one, because, well…

Every programmer does this on occasion ... right?

There's not a ton of cool stuff to share this week, and the stuff that is, I'd rather save for when my brain hasn't been reduced to jelly from my own mistakes.

If you wanna read last week's (full) dev diary, the link is right here!

Let this be a lesson to you all

Git feels like it's complicated, version control seems like a hassle. You should absolutely do it anyway. If you're thinking of getting into game dev, I promise, it will be easier to try to get your head around using git than it will be to unpick the two weeks of changes and tweaks you realized you need to completely revert because they just aren't panning out.

I've been pretty good about in generally but I spent monday and tuesday building a few different things, then realized I needed to go about it completely differently, then had to spend Wednesday painstakingly getting everything back to the "it is functional state," because half of the work was good and should stay, and half was busted. My options were to either roll all the way back to the last pushed build, or deal with it. I would love to say more, but the thing I'm building this week is only mostly done, with a lot of polish to work on. But that said, it's an old adage that every game is better with this feature :)

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

[last-sprout]

Last Sprout monthly update video #2 is out!

Link below, in this video we check out how the early upgrade system is working, and see how quickly we can break the game ❤️🌱

[last-sprout]

N Y O O M 🌱

[last-sprout]

Our first update video is out for patrons! 24 minutes talking about Last Sprout, available to £1 tiers and above !!

if you wanna support my art, and see what we’ve been making, pls check out the link below :D 💖🌱

[last-sprout]

Last Sprout Dev Diary - Dec 20, 2024

Hello again, welcome to this week's dev diary! I finally (finally) got the upgrade system functional this week, which means that we're one-ish system away from the game loop being essentially complete! I'll briefly talk about the system itself, but as it exists it's pretty basic, so afterwards I'll write a bit about all the hidden things that crop up when you try to develop things like this.

Last week was a short one, if you want to read it you can do so here.

Faster, faster, until the thrill of speed outweighs the fear of death.

Getting Upgrades

On the surface a system like this is pretty simple. When you hold down the interact button, you slurp up all the xp in the area, and that increments a counter.

That counter is tracked by a Leveler script, which contains the formula to calculate level up thresholds. Once the value of the counter is higher than the value of the threshold, the Leveler invokes an event called OnLevelUp, and it sends its attached entity along to a UI that handles grabbing the upgrade cards, displaying them, listening for input, and then passing the mod back to the entity to apply it.

Because the upgrade ui doesn't need any knowledge about the game world, anything can say "hey I leveled up," and it will dole out the upgrades as needed.

We're basically done with this, right?

So why does it look kinda bad?

I don't think it's hard to see that a lot of parts in this clip are a little janky and awkward, right? I'm gonna take some time to break down everything that's gone into making it look like this, and how many tiny decisions are involved in relatively simple builds.

First of all, the text! There's obvious decisions: What font to use? we have a custom one that I think looks really cool, but it's missing a lot of unicode characters, which means that if we were to localize this to any language that uses another script, or even just diacritics, we'd need a second font for that, which means we need to find one with robust unicode support that matches the aesthetics. Plus, it needs to look good at the same size as the english text, or we need to make separate sizing and kerning settings. Also, there's no guarantee that the text will be particularly close to the same length in every language, so we need to be prepared for longer or shorter title bars.

How do we display the text? I opted for a teletype effect that plays after the animation ends, but I could also fade them in word-by-word or line-by-line. I could just have the text appear all at once, but you either need to find some way to hide the text in areas where the card animation is still see-through, or you need to drop it in after the animation, both of which have downsides. You also need to determine dynamic sizing - some upgrades have a lot more text than others - do you have the text auto-size? If so, what boundaries do you use? It looks weird when one card's body text is much larger or smaller than the others, so there's a limit on how much you can have the text resized. If the text gets too small, people playing in a window or on smaller screens will have trouble reading it!

Not to mention we probably want to have an option for accessibility that lets you switch out the font for a dyslexia-accessible one, so all the previous considerations apply there too. From a user interface perspective, the transition to leveling up is a little jarring - how does one smoothly switch between gameplay and leveling? When do you allow that trigger to happen? If you have it happen automatically you risk disrupting the player at a critical moment, if you have it function on button press you risk a player outright forgetting about levels, or dying with levels banked, both of which are feel-bads.

Behind the scenes, you also have to decide how to shuffle the upgrades, especially as they get weirder. If you have a rare upgrade that outright removes your ranged weapon, how do you make sure that ranged-exclusive upgrades don't appear in the pool anymore? To be honest, I could go on for a while still, but I think this gets the point across - everything in a game is complicated, and even if a player doesn't realize it, these decisions have a cumulative impact over the length of a 20-40 hour game. Even using really good tools like TextMeshPro still leave a ton of design decisions that a code package can't make for you. When it all comes together it's pretty incredible, but it requires an absolute ton of tiny tweaks and bugfixes in the meantime.

I felt like this needed one more gif to space out the text but I didn't have any ideas so here's Many Twiggs.

As per usual, feel free to send asks here or to @oneominousvalbatross, and thanks for reading this! There won't be a dev diary next week, we're taking some time off to avoid burning out after 6 months of grinding, but I'll be back in the new year to talk about cool visual effects!

[last-sprout]

Last Sprout Dev Diary - Dec 13, 2024

Hello again! It's still Upgrade Month for us on Last Sprout, so this week I've been focusing on in-run progression, leveling up, and applying upgrades to the player.

Twiggs has gained the ability to Chill

Going to be a short post this time around, the level up flow is still going through some serious growing pains, and things aren't really solid yet, so anything I say could very easily become irrelevant in a month. Last week, I talked about what a Mod is; if you want to read about that, you can do so here.

Leveling

One key pattern I've been trying to stick to is making sure that an Entity in game doesn't have to be fundamentally different if it's controlled by the player. To make sure that the entity class doesn't end up with a bunch of redundant features, I made a Leveler component, which sticks to an entity and listens for the XP variable (which is stored as a separate asset file) to cross over the level threshold. Then the leveler sends out an event to yet another object, the Upgrade Selector, which pauses the game and shows the cards.

This is an extremely rough draft, but it exists!

The UpgradeSelector received a signal that contained the entity that wanted to level up, and it is also responsible for applying the mod to that entity. What this also means is that, in theory, npcs are also capable of leveling up! Will this mean anything in the long run? Unclear! But if there's one thing I like doing, it's building out systems to be way more robust than is necessary. So far I've found that it pays off the vast majority of the time!

Plus, I will definitely be occasionally playing runs as random enemies just to see what it's like. Who knows, maybe that'll make it in as a side mode or something.

I think I'll spare you from reading about the 200 tiny changes I've made, unmade, and remade trying to figure out how I want stats to work, as it turns out, absolutely nothing in game dev is simple, including the act of "tracking numbers on a character."

Thanks so much for reading this abbreviated dev diary, I very much appreciate that there are folks out there who care about this project! As per usual, if you have any questions or are interested in anything in particular, feel free to drop an ask @last-sprout or @oneominousvalbatross!

[last-sprout]

Our first update video is out for patrons! 24 minutes talking about Last Sprout, available to £1 tiers and above !!

if you wanna support my art, and see what we’ve been making, pls check out the link below :D 💖🌱

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

[last-sprout]

Last Sprout Dev Diary - Nov 28, 2024

Hello again! This is one of those "low progress" weeks as I battle with shader code and scriptable renders.

What I see in my nightmares.

So, for this week's Dev Diary, I wanted to take this opportunity to talk a bit about one of the core systems for Last Sprout - Brains.

Hopefully this is interesting even if you don't know much about programming, but I could always use the feedback.

I live my life assuming I'm some amount of this comic.

Brains & States

Part of my process in developing Last Sprout is taking the time to build systems that are as generic and abstract as possible - any time I'm thinking about writing something directly into the code, I try to find some way to pull that out into some kind of data that can be changed in the editor. Mostly because, as much work as it is to do the programming, it's also a ton of work to do the tweaks and edits that make it feel right.

A Brain isn't actually much on its own, just a framework that defines the bare minimum an Entity (the core 'thing' that exists in the game) needs to interact with.

Less fleshy than I'd like for this game.

The key here is that Brains just give instructions and move on, they don't know or care what happens once those instructions get passed to the Entity.

Brains don't take actions, they make polite requests.

So a Brain really just says "I would like to move in this direction, aim in this direction, and perform these actions".

Actions are bit flags, which means inputs are stored in one integer number that uses its 1's and 0's as true/false values. A brain toggles these bits based on a lot of different parameters - for instance, the PlayerBrain just listens to user inputs and sets its instructions accordingly, whereas an AggroBrain contains logic to look for valid targets and chase them down.

Hopefully this is a little easier to visualize for people that aren't familiar with bit flags.

An entity, every frame, asks its brain to update its instruction. Then, it passes that instruction along to a State. The State is responsible for actually taking the actions the brain recommends, So they'll have names like IdleState, WalkingState, MeleeState, and so on. States are also where animations live, so a given IdleState (which is an object that lives in the game files), will have an associated animation for Idling, and it will play that animation when the state is entered.

Not the most interesting state, but the easiest one to understand.

The state is what decides what input flags to listen for, and which states to exit to. Because states always have an EntityStateType, and Entities have a list of all their allowed states, they don't actually have to know what the options are, they can just say "Exit this state to a Walking state" and the entity will find a match.

This is a ton of words, but the core of it is that Brains and States are separate, and don't know anything about each other. This means that you can attach any Brain to any Entity, and it just works. If you want to test the attack range on an enemy, you can just slap a PlayerBrain onto them and suddenly you can control it! You can duplicate the player, change its tags to Hostile, and put an AggroBrain on them and suddenly you have an AI controlled hostile copy of Twiggs! While it adds a layer of complication to developing behavior, it also means that our code is reusable and modular, and it lets us experiment freely in engine.

Brains are one of many lego brick style systems, maybe next week I'll talk about another. Thanks for reading this, and if you have any particular questions, feel free to drop and ask to @last-sprout or my personal tumblr over at @oneominousvalbatross. Fair warning though, the answer may be extremely wordy.

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

[last-sprout]

UNCROPPED 🐦‍🔥

[last-sprout]

do you have any pets? are there even animals in your world? (if you do have pets i would love to know their names)

Ah I wish I had pets! I once had an acquaintance whose family had a few cats, I even saw a some photos! Such sweet things.

I made a lot of robots for a while, who kind of felt like pets. Co existing in the same space, and we programmed them so you could say hi and pat them on the “head” and they would react and stuff like that. And around the same time in my life, our living space had a lot of fish farms you could go and visit. Those huge tanks filled with shimmers of silver, I could sit there for hours sometimes.

I know I am sounding like a broken record at this point, but my plants have always felt like, not pets, but… close. A living thing I’m responsible for, I watch grow, I cherish.

[last-sprout]

I know you said you couldn’t pick a favourite plant, but do you have a least favourite plant? one that just really grosses/freaks you out?

Truly, honestly, I think all plants are wonderful! Seeing any splash of green in a world of greys makes my day, I still feel so lucky that here in my workspace I can be surrounded by that greenery all day.

But, that’s not to say that there aren’t weird and gross plants! Titan Arum was also called the Corpse Flower (ooooo how spooky). It would emit an odour like decaying flesh, I can imagine that creeping anybody out. I don’t think I could manage with a smell like that in such a confined space like this!

Or for an extant species, Hydnellum peckii is a kind of fungus that looks like it’s a bleeding, oozing, tooth. Gross right! I managed to see an amazing sample before, during my studies. The biology central back at CRADLE is the closest I imagine I will personally get to touring something like the Natural History Museum. Such an incredible, living archive.

[last-sprout]

You've mentioned your boss and higher ups a couple times, where do ya work for? And how is it there?

Oh, I actually got a similar message to this that I already answered, but my research is funded by the CRADLE initiative. As for how it is, I can’t complain. The outpost is quite small and out of the way, so with that in mind and alongside the general lack of personnel, it’s just me stationed here. I like the silence, and solidarity, I listen to a lot of music, and get things done in my own time.

I write daily reports, and hop into calls if needed to update back at headquarters. My supervisor is a nice guy, I’ve known him for a long while at this point. Every month or so he’ll come up here and check in for a few days, as well as restocking rations and the like. It’s nice to chat to another person face to face :]

I mentioned in that other message, but CRADLE has been part of my life for a long time, I went through the entire education system, so working under them has always felt like my assumed path. I was digging through some old stuff and actually found my graduation pictures. God - this feels like a lifetime ago now.

[last-sprout]