Tom (tired of the computer)

For solo dev especially this sort of thing is perfectly workable. The minute I'm working with a non-coder game designer, I would split this out into a thing that has an editor interface or digests a .csv file or something.

The distinction between code and data is basically fake anyway, and one of the most powerful tools as a programmer is "i will hardcode all this data" and its twin "i will turn all these functions into data objects that my coworkers can arrange in a list"

I'm not disagreeing but I think I get antsy around attempts to make this point because I don't think the point should be "you don't need fancy abstractions if the 'simple' thing works". I think it should be "the 'simple' things are also abstractions that have the own strengths".

Like here specifically the big if statement is making a choice that grouping the behavior of all cards together is more maintainable than grouping all the aspects of a single card together. It's easy to look up cards since every statement has a string comparison at the start that works well with a text search.

I can imagine a version of Balatro where new cards can be added by DLC where this becomes a little more annoying to manage. Or a version where you want modders to be able to add new cards easily. That doesn't make this version worse, of course. It's appropriate to what Balatro actually is.

I guess I think the solution to abstraction fetishism is to abandon the idea of simple vs complex as a useful axis on which to measure them?

i see no problem w this, trying to 'simplify' it would make this a zillion times more complex to work with and therefore liable to fuck up wouldnt it. cuz each of these statements has multiple trigger conditions of different types

i have written a high performance threaded web server that had a very specific use case and was about 150 lines of if statements. was able to saturate a 10gE connection with it on p old hardware cause it was so single minded.

edit: i forgot the point which is this was part of an 7 9s (3s downtime per year) SLO with a 6 9s SLA (30s downtime) and one year we achieved zero downtime on the part i was in charge of.

The tweet has since been deleted or hidden, so I can't view it and can only speculate based on Plato's shadows of discussion around it; either way this should apply.

Part of what I learned from Big O Notation with regards to algorithmic efficiency is that your pool of data is a factor in building a system. If you only work with pools of 10-100 items then a chain of that many if/case statements, while slightly annoying codewise, would have barely imperceptible performance impact except for the most exponential of cases.

If the covered portion of the Big O graph doesn't hit the most extreme points 99% of the time then it's fine. Doubly so for games.

Sure if there is 100,000 data points that are being processed continuously of O(n^n) you should look into abstractions and optimization; but hash lookups for 100-200 entries is nothing on that scale.

I have seen the inverse, of performance critical code handling more data in more professional settings, such that it was to the detriment of the application and its maintenance; and that is where more care should be taken.