#Game dev diary

[poorly-drawn-mdzs]

A fierce duel commences!

[masternest]

Game Dev Diary # 3

I’m really horrible at doing a regular posting thing XD but thank you for reading anyway.

So where to begin? A few weeks have passed now since my last update. To summarize, I’m taking a new class now so I don’t have to be part of a group anymore. In truth, I felt that I wasn’t as helpful as I could have been. I didn’t want to take a leadership role in the group mainly because I wanted the others to rise up and get that needed experience for themselves. Because of that, I ended up being the UI guy XD which was fine. I ended up learning a few cool tricks when it came to making a good UI at least in the basic sense.

I wasn’t perfect by any stretch of the imagination but neither were my team mates to be frank. Regardless, we were able to get all the work done and submitted everything within the allotted deadline. What I’d really like to do is to get those projects from Perforce and take some time to review them again so that I can retain those certain code structures. They’d definitely be handy in the future but hopefully I can still access it all.

My current classes now are two and they seem pretty easy. One of them is even about mythology which I love so it’s going to be great XD but I do need to try and collate all the projects that I’ve done in the past; mainly because I do need to start setting up to get my portfolio going. I need to make a website for that as well but we need to do one headache at a time.

With that in mind, I need to keep practicing my game dev skills as the two classes I’m taking aren’t as hands on as I’d like. I can’t get too rusty especially since I do want to get a job using these skills in the future eventually. So I was thinking that I’ll finally start diving into RPG Maker to make something simple with it. My goal would be to see what I can make with the limited resources I have and just a finished product that way.

So that’s it for now. Thank you for coming to my TED Talk. I’ll update when I can XD

[ddwcaph-game]

The Narrativium Update Has Arrived!

Retcon the narrative to your heart's content in the latest update to...

Dear Diary, We Created a Plot Hole! is written as a love letter to all the kids-at-heart out there, who’d like to revisit their childhood and reimagine it as one big fantasy adventure.

If you like episodic shows and stories with a deeper overarching narrative, then this story is just for you!

🌌 【Play it here!】 🌌

~ 608,000 total wordcount (including code) ~ 99,000 additional words (including code) ~ New average playthrough of 129,000 words! (up from 115k)

14 New Secrets/Variations to Discover, 25 New Trinkets to collect, 9 New Sidequests, 4 New Achievements!

6 New Character Traits, 12 New Ancestry Passives, 2 New Phobias, 4 New Status Effects!

Revamped Heritage Passives!

Retcon the narrative and your choices with the new Narrativium Points mechanic!

Revamped Health & Intimidation Stats, Traits and EXP System!

Revamped Chapter 1 Twin Fight Scene!

Added new Sleepover Branch!

Updated bestfriend scenes!

Crush sidequests can now be declined!

You can now change what your MC calls certain characters via the diary!

Added more backstory details about MC's dad, and you can now choose his home country if MC is Half-Filipino!

Increased save slots to 20!

New and improved gender and pronoun options!

Updated diary entries!

Updated content warnings to include themes that will appear in future chapters!

Fixed missing background music!

Tons of new choices, edits, adjustments, and additional flavor text/variations/characterization details!

Roselyna is now approximately 20% more huggable!

The Trinkets & Secrets Guide has also been updated!

If you encounter any errors, or have any questions or feedback, feel free to send me an ask. The complete change log for the update is almost 400 lines long, so I hope it was worth the wait! 😊

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

[ophanimkei]

dream diary jamming

[pixiebombblog]

Dev Diary #1 (Oct 27, 2024) - It All Starts Here!

Hi! I'm Pixie, and I am currently in active development on a new large-scale, fully voice-acted & immersive Skyrim follower mod named Seraph!

I've decided to start up a regular Developer Diary (You Are Here) to share progress & roadmap the release as she gets further along! Also if you haven't already, join the Discord (link after the jump) to stay updated & involved or just to say hi 🩷

Here's some early development highlights so far:

✨️ For Seraph's custom follower framework, I've built a new & improved core framework that is much more effective, elegant, & efficient than the framework most follower mod authors start with, & one of the benefits of this is that it's much harder for external problematic mods like AFT to break her brain!

✨️ Seraph's character and story has been deeply developed already, & her personal quests will be expansive! Her main personal questline is currently planned to play out in four acts/chapters, with an optional fifth chapter for...

✨️ Romance 💖 Seraph will be romanceable (& marriageable) for certain types of player characters! Without saying anything spoiler-y, Seraph's romance is not frivolous, exploitative, or lazy (as is often the case with romance options in many mods out there), it is an important narrative aspect of her character, and adds to a story that plays out over the course of your adventures together. Romance is not the main focus of the mod, & is completely optional, though just as much time & care is being put into it as any other part of the mod.

✨️ Seraph has a complex Approval system that feels much like the companion approval in Baldur's Gate 3, which has already been built & implemented. Your choices will matter, what you say and do will affect your relationship & things can turn out very differently based on dialogue chosen, playstyle choices, and more.

✨️ Seraph is feature-rich, and full of customizable toggles, options, and mechanics that range from functional and helpful to ones that just make her feel alive and fully fleshed out as a character. She can spar with you, have discussions on books and lore topics, bail you out of prison (with potential Approval ramifications!), won't call you the Dragonborn if you don't want her to, and a lot more. She also has all of the customary bells & whistles like follow distance controls, lore-friendly summon ability, relax/sandbox behavior options, etc. Many of these features are already built & implemented, or in various stages of that process.

✨️ I've also been working closely with my fantastic 3D artist @legendaryfirewizard (the artist who created Redcap's custom helmet model & several of Xelzaz's custom models) on a visual centerpiece that I don't want to spoil just yet, but that is central to Seraph's story & makes her very unique from any other follower mod.

There's so much more I'm excited to share, but without spoiling too many of the character & backstory details juuuust yet, I hope this first Dev Diary can give a small idea of what I'm hoping to achieve with this follower.

I've learned so much over the past few years of creating mods, and I've grown so much as a creator and a person in that time. Seraph is my love letter to creating, to character writing, to fantasy and RPG's, and to The Elder Scrolls which starting with Morrowind inspired me to imagine characters and stories within the world of Tamriel and beyond.

If you've read this far, I hope you'll give Seraph a download when the eventual release happens. In the meantime, feel free to join the Discord - to keep up to date with the project as it progresses!

- Pixie 💖

(Mod author, Voice Actress)

[st-just]

Endlessly amusing to me that (I assume to basically random contingencies of where the fanbase developed) the by far most developed and carefully researched area of Hearts of Iron's 'what is Germany won WW1?' mod is now China.

[impairedpixels]

Maya almost fell

Maya almost fell while trying out prosthetics but Max lucky caught her sending her prosthetics flying. You can find out more about this story and support my work on Patreon or SubscribeStar.

[kuppikahvia]

Only after watching the development diary I realized how amazing this announcement at 2021 game awards was, I love the way they handle all that meta stuff

[twinklebyisnthere]

"what is this blog" - context

This is the shit-posty Twinkleby dev diary, run by a game dev who’s spent 15+ years being NDA’d by previous employers and who just wants to chat about a game project they love. Making video games can actually be fun – who knew? Anyway; let’s shitpost our way to the game release, and gossip about all the behind the scenes shenanigans the team runs into along the way.

And what is Twinkleby?

Twinkleby is a cozy decoration game where you map out an archipelago of floating islands and build dioramas for a society of spacefaring neighbours. It’s an escapist, cozy, stress-free game made by devs who desperately crave something escapist, cozy and stress-free in this day and age. Check us out on steam for more info (presented in a way more professional manner than this blog haha)

[thelovelydoggycatmadi]

Happy (late) MCD anniversary, I made these back in July. And I'm sure a lot of people will be disappointed that we made so many big changes to some characters, (I'll post a inspo board for each soon) but ultimately not being fully tied down to aphmau is the best for us.

A REMINDER IF YOU WANT TO SUPPORT MADDOG STUDIOS TO SUPPORT THE ETSY AND KO-FI! I ALSO ASK ABOUT COMMISSIONS. DO NOT REPOST!!!

Bingo bonga

[poorly-drawn-mdzs]

Dungeon Meshi: The RPG

[torchship-rpg]

Dev Diary 12 - Destructive Testing

Breaking from the usual format for this one, and it’s going to be a bit shorter, but this is important.

At the beginning of November was Metatopia, a convention dedicated to playtesting roleplaying games. It’s an excellent place to go to break games in order to fix them stronger than ever, and in that respect Torchship did not disappoint. While its parts all worked beautifully, there were some issues with the connective tissue tying it; the game needed a stronger mechanical framework to put these pieces into.

With that in mind, we’ve started a new draft of Torchship designed to be rapidly playtested and iterated, into which all the other stuff we’ve built up can be plugged back. This new draft focuses particularly hard on making sure the game’s fundamental tablefeel is strong, that you always know what to do and where to go next.

Which is to say, fans of my games having big circles in them somewhere? There’s a big circle in this one now too. Torchship now has two distinct modes; an Action mode where you go out and gather information, and a Reflection portion where that information is managed, damage gets fixed, and plans are made. Action takes the form of ongoing narrative play, dropping into turn-based combat when needed, where Reflection takes place in a series of special scenes called Vignettes to represent timeskips, with more impactful ‘Resupply’ Vignettes acting in some ways as bridges between episodes or story arcs.

While it may sound similar to some of our previous games, this isn’t like in Flying Circus where each part of the Routine is a commitment to a certain kind of gameplay before you can go back. You’re able to switch between the two pretty readily; so long as there’s nothing bearing down on you this minute, you can go into Reflection and play out Vignettes, with the number available before you need to go back into Action depending on the in-universe time until the next important thing.

This structure imitates the back and forth you see in many episodes of Star Trek. To use Devil in the Dark as an example, the Action scenes are things like arriving at the planet to meet with the staff, or going out into the cave to track down what’s killing the miners. When they go back to talk about their findings, prep security crews, or bring in new resources, that’s Reflection. It covers your beloved TNG meeting room scenes, the cut to sickbay as we find out what happened to the redshirt, and the montages of inventing or building the tools that’ll solve this week’s problems.

As part of these rewrites, some parts of the game have been modified from previous dev diaries. We’ve simplified the way Harm works; you now have two Harm tracks, Injury and Panic, and a new accumulating penalty called Strain which builds up quickly as you make checks or use medicine to manage the other tracks or boost your abilities. Strain is easy to clear so long as you have supplies available, so it acts to pace out scenes and give less-skilled characters a reason to roll; if you know there’s a lot of a certain kind of work ahead, you might want to save your expert for the rolls which really matter!

(Radiation no longer uses a whole track, but instead consists of a small card the GM can hand you entitled “Congratulations, you’ve been irradiated!” with a list of dosage effects.)

A variety of changes large and small have emerged from these changes. Relationships act as an excellent starting point for Vignettes, while access to meetings have let us place restrictions on the number of checklists out on the field at a time, as you can always call meetings to retire checklists, propose others, and figure out what your next Big Question is about the mission. We’ve created a new XP system where you train skills directly by using them, with the pace of advancement limited on a per-episode basis to encourage you to play wide and learn new things.

Finally, we’ve come up with a neat solution to one of the longstanding problems that original sci-fi games often run into, where players are unsure what their technology can do, resulting in decision paralysis. We’ve added a very distinct CAN & CAN’T field on the info cards which lists exactly what everything does and what their limitations are so you can jump straight in without slowing the game to ask the GM where the boundaries are. 

Things are bound to change more over time as the game is refined and tested, but that’s a good thing. Good games take time, revision, and a willingness to recognize and rewrite when things aren’t working as well as they could.

[ddwcaph-game]

Chapter 4 & 5 is finally out!

The wait is finally over. Grab your plot armor, Chapter 4 and 5 of Dear Diary, We Created a Plot Hole! is finally here!

🚌 Play it here! 🚌

To celebrate the release, a +50% ✨EXP Bonus Event will be running for the next couple of weeks!

The full change log is over 500 lines long, so here's an overview of all the new stuff:

🌈 UPDATE HIGHLIGHTS

~ 509,000 total wordcount (including code) ~ 278,000 additional words (including code) ~ New average playthrough of 115,000 words!

New Stuff to Discover!

52 New Secrets to discover, 8 New Trinkets to collect, 12 New Achievements

30 New Character Traits, 15 New Heritage Passives, 3 New Phobias, 16 New Status Effects

3 New Main Quests, 12 New Sidequests

and 1 New Song to sing along to!

New Scenes!

Introductions to Wayne, Lily, and JM's parents!

New exclusive bestfriend scenes!

Get a sneak peek into the story worlds you'll visit in future, in the Story Exchange!

Revamped crush confession scene with your twin!

Steal a kiss on the cheek from your crush!

Catch a preview of Chapter 6!

New Choices and Customization!

Choose the name of MC's dad!

Choose a second bestfriend, other than your twin (and give them a custom nickname)!

You can now choose to have two different pronoun sets!

Choose a mild swear word for your MC

Added B as a crush option

Tons of Diary and Stat Improvements!

New, updated, and expanded character diary entries!

New unlockable codex entries!

Write custom post-scripts in your diary!

Added new toggle settings for simple/detailed view of traits/passives, and background transitions

New trait option that reduces the frequency and gives additional context to Filipino expressions

Improved diary and stat notification layout

So Much More!

Added lots of new character art!

Added gameplay tips!

Lots of references to In Auctorem Credimus!

Roselyna is now approximately 20% more huggable!

---

I've also updated the Trinkets & Secrets Guide, as well as the Twin Character Templates!

If you encounter any errors, or have any questions or feedback, feel free to send me an ask! I'll go through my ask backlog after I have recovered from the update.

I hope it was worth the wait! 😊

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

[dazzleluminosity]

This may be too much an intersection of my disparate interests for anyone else to get it, but: Unity's last week was basically point-for-point Eletra from Barish-Estranza trying to hold hostage the people who just gave her the supplies to repair her ship.