ysaie

31 / ⚧ / code, music, art, games

──────────────────────────────
🌸 many-shaped creature
✨ too many projects
🚀 cannot be stopped
🌙 stayed up too late
:eggbug: eggbug enjoyer
──────────────────────────────
header image: chapter 8 complete from celeste
avatar: made using this character builder


📩 email
contact@echowritescode.dev

nex3
@nex3

Okay here's my actual decade+ software engineering experience take on the Balatro if. Huge caveat that game development and software development are actually wildly different skill sets and I'm not very good at the former, so take this more as "inspired by" than "about" Balatro's code specifically.

Knowing when to do things stupid is a critical skill.

A lot of software engineering education, as well as on-the-job discussion of what sorts of practices can improve engineering outcomes, focuses on abstraction and automation. And indeed, finding the right place to to create an abstraction that makes it easier to think about the problem space, or a tool that will save you way more time than it takes to write, can be hugely valuable. I once spent a big chunk of time pulling everything about Sass's deploy process into a nice clean re-usable package and now all our improvements are shared among our several CLI tools as well as tools made by other people we don't even know. Fantastic!

But there's negative space that's also very important. Sometimes—a lot of the time—it's better to just do it the hard way. If you try to do everything the most generic way from the word go, you'll never have time to actually get anything done. Worse than that, you're way more likely to end up abstracting the wrong thing! Getting your fingers into the manual code is critical for understanding what parts actually need to be abstracted and what parts are either so context-dependent they need a human's touch every time, or just easy enough on their own that the abstraction doesn't add any real value. (The latter is where Balatro's if statement presumably falls.)


ysaie
@ysaie

i think defaulting to doing it "the dumb way" and then developing your sense for where the "okay, this is silly, i'm making a tool to help me with this" line sits is a very reasonable way to do most software development


You must log in to comment.

in reply to @nex3's post:

I fully agree. At the same time, I also see folks on the other side of that discourse being very dismissive of the utility of generalization and abstraction — doing things the general way and doing things the brute force way are both absolutely tools in the toolbox with their own uses and their own advantages and disadvantages.

The thing that pushes games even further to lower abstraction models is that game design is quite often the process of explicitly breaking your models and have your systems cross talk in ways that heavily abstracted models make much more difficult. Games are all sorts of deeply in each other's business systems and global state, so they should be modeled differently than you would want to model other types of software.