Hacker News Reader

Comment by mattnewton | Hacker News Reader

I have never heard that assertion, I don’t know how anyone can play Balatro and not feel that it is a deeply intentional creation. I think localthunk would be the first to tell you they got lucky with how it found an audience outside of themselves, but everything in the game oozes polish and intention.

View on HN

The assertions are more around code quality. Game design is wonderful.

Apparently there are places where the code is like a thousand lines of if card_name then effect.

For a project with lots of variation being maintained by a single person that’s totally fine.

Yep, there are days I yearn for just having a super long set of if statements, vs the over-engineered messes that I deal with on a daily basis.

So many codebases end up impenetrable in the pursuit of fancy design patterns...

I think that too fancy code is just as bad as the original if-else spaghetti, but then even worse, because the patterns are abstract now as well.

Bad code can have a really high cognitive load to maintain. Just to illustrate what bad means, take a look at this:

https://www.reddit.com/r/programminghorror/comments/1cb6rca/...

I can see that having even bits of modification impacts lots of lines, where if written just a bit more saner, it could impact just a few.

Of course everyone is absolutely free to do the things however they want on their project. It's just that bad code, and bad choices bite back sometimes really badly. Project Zomboid is built in LUA for example, and it shows, it's a horrorshow not just to play, but to develop it as well. Their programmers spend a lot of time with just refactoring things. Besides functionality, maintainability should be a huge focus in my experience, so that the devs don't hate life if they have to touch the code again.

The example you post is out of context and maybe a bit overly verbose but again it’s one guy maintaining it and is perfectly readable. Does anyone really struggle to understand that?

I’m back working on a twenty plus year old codebase (and game) that’s ~3 millions loc and would kill for something simple like that rather than some of the overabstracted crimes lurking within.

Yeah, without context criticism of this code is silly.

What if this wasn't always how cards worked? What if the mapping was (at one point in development) not straightforward? Or localthunk had some ideas and wanted to leave the door open to a more complex mapping scheme?

Either silly, or 20 years in the business.

The problem is not with understanding, but with maintainability. If you need, for any reason, to touch that code again, instead of a few changes, you have to be consistently doing a lot of changes. This has a higher chance of manual errors. And it has nothing to do with other bad code, like the one that you encounter. Both can be bad code, and what you inherited sounds worse. I hate it when the badness is compounded with complexity. It feels pretentious to me.

That code is a few lines maintaining a mapping though, changing it is not going to be hard and all the mappings are captured explicitly which makes it even more straightforward versus shaving off lines of code by making some of them implicit (e.g. by seeing a pattern in the mapping and using an if statement to capture them all). I'd really love to know what you think it should be to be more maintainable!

Something like this would pass a code review, while the original would not:

  function createObject(value, id, nominal)
      return {
          value = value,
          id = id,
          nominal = nominal
      }
  end
  
  local objects = {
      createObject(100, 1, "nominal1"),
      createObject(200, 2, "nominal2"),
      createObject(300, 3, "nominal3"),
      createObject(400, 4, "nominal4")
  }

Still far from ideal, but I'm not that familiar with LUA either. And I do acknowledge that bad code can work, and heck, even I write them sometimes. My original point is that it has downsides and risks, and so I don't consider it fine. I have dreaded to touch such code (mine and others) many times, and made mistakes because of past laziness like that, many times.

This is not equivalent though so you fail my code review. :D

For starters its clear the code in the example expects self.base.value to already hold a value. So constructing an object blind isn't necessarily what's happening here, it's possible an existing object is even being decorated with extra fields. So your suggestion isn't preserving the semantics.

Secondly for the face cards there is an additional field being set which is not happening in your case.

That's what I mean when I said earlier that we can't just look at a piece of code contextless and say it's bad. Your refactor is definitely neater if we're initializing homogenous objects but that's an incorrect assumption on your part. It also comes with trade-offs for example it's not obvious anymore what any of the values relate to without going to the function constructing the object. Not the biggest thing in the world but if this is the only place in the codebase doing this then I'd argue that it probably isn't worth it.

Undertale's code base is apparently no better. For games I don't think code quality is nearly as paramount; there's not a whole lot of maintenance going on there, though this doesn't apply to live service games.

Reply on news.ycombinator.com