You may have seen the Balatro Discourse, which consists of people looking at a screenshot of code that is straightforward and getting angry that it's not more complicated.
I'd just like to posit here that a straightforward solution is an *excellent* default and you should have a really solid argument for the advantages of a complicated solution before you choose it.
Fine, I'll say one more thing about this.
If all you're looking at is the code in that one screenshot, you *can't possibly* make a good argument for a complicated solution, because that requires having more than the bare minimum of context.
@mogwai_poet Also, I am convinced that giant carbo-chains of if-elses power 90% of all code in production, worldwide.
@jmac Extremely plausible
@mogwai_poet There is also this now-deleted but memory-indelible Terry Cavanagh tweet from early 2020: "Every screenshot I see posted of terrible things in the VVVVVV source code only makes me more powerful"
(Cited in this Polygon article: https://www.polygon.com/2020/1/13/21064100/vvvvvv-source-code-game-development-terry-cavanagh-release)
@jmac Yeah, there's a tipping point where you stop worrying about code architecture and just start worrying about shipping the dang thing.
@mogwai_poet I ranted about that one on Tumblr, from the perspective of someone who does reverse engineering: every published game does this kind of shit, because that was what was needed to get it released. I'd rather have an inelegant game that exists than a perfectly architected unfinished prototype
@foone@digipres.club @mogwai_poet@mastodon.social or, as I keep repeating at $work (to myself, mostly): yes, this code is terrible, but it's been reliably making money for 20 years
@foone Yes, the Balatro devs, as people who have shipped a card game after working on it for years, have a much better idea of how to architect a card game's code base for performance and maintainability than any of the peanut gallery
@mogwai_poet @foone yeah it boggles me that people are going "lmaoooo long if/else chain" and then seriously saying "that should be an import from an excel spreadsheet into an enum"
yeah it might be inelegant but you know what, I bet it's REALLY easy to search through and add new entries to, or test!
if it's stupid and it works and is also not terrible to maintain it's not stupid, it's just using the minimum effort necessary
@foone @mogwai_poet Video game code is very much not the place for some fancy class inheritance pattern or whatever. If/then all the way
@mogwai_poet Any chance you could link to the screenshot? The original tweet seems deleted or something? I’m curious now
@noam Here's a repost: https://x.com/Hasen_Judi/status/1783091899651469663
@mogwai_poet Aw I'm sorry. Unfortunately I have to side with the haters somewhat on this -- code structured like this is harder to navigate and maintain than code similar to this restructured via OOP (so e.g. each card ability could live in its own class, and you'd keep a map of ability name -> logic object). I don't think it's the end of the world but a couple of issues stand out to me:
1. If you need a second function that also hinges on what the ability name is, you'll have to replicate the exact same if/else structure elsewhere.
2. If you have two conditions for the same ability name (e.g. `"red card" and self.abilities.mult > 0` in one place and `"red card" and G.GAME.hands[context...` in another, nothing requires those two to be near each other, meaning casual reading of the code could confuse an observer into thinking "red card" has only one condition.
Code structure concerns like this become important when a large number of people who don't have the context you do are editing your code as well, which admittedly might not be the case for indie games.
@mogwai_poet But also thanks for linking to context!
@noam I think these are valid concerns. If I saw this code in a project I was working on, I'd definitely consider a refactor, but I wouldn't jump right to putting it in a class hierarchy as definitely the right answer. We just don't have the context, of the rest of the code base, of the author's goals and constraints, etc.
(No anger here though.)
@mogwai_poet not that the world needs my take, but literally the only thing "bad" about it is that it'd be easy to typo the strings or rename a card and break things without noticing. but it's written in Lua, so that's inherently true for literally the entire codebase! you deal with it! it's a problem that is extremely tractable to address with testing, and I'm very, very certain that the Balatro dev has done an _awful_ lot of testing.
@mogwai_poet even out of context, if that screenshot contains the worst tech debt in that game's codebase, then it is an objectively better codebase than any I've worked on in the 24 years people have been paying me to write code.
code is bad when it generates bugs. architecture is important when it becomes too easy to write code that has bugs, or too hard to find bugs in the code that exists. this code does not have bugs. it solves problems. it is fine.
@SpindleyQ Agreed yes