#Balatro 52 (or Balatro Royale)

1 messages · Page 1 of 1 (latest)

eternal burrow
#

⚠️ This thread is currently for discussion only. Active development will start later, after I've gained a bit more experience with Balatro modding

After some thought and discussions with friends, I've come up with an idea for a multiplayer mod for Balatro. Since head-to-head has already been excellently done in the Balatro Multiplayer mod, I've decided to instead take inspiration from Tetris 99 and Mario 35 and go with parallel play

In summary, you will be playing Balatro alongside (hopefully) 51 other players, and the goal is to be last one alive. You won't be battling other players directly, but will have ways of interacting with them

Each of the example games has elements that would need reimplementation in this mod:

  • A timer of some kind. This is in place to force players to move forward and not idle. In Tetris 99, the core gameplay loop does that by default, and in Mario 35 it's an explicit timer. In both cases, playing well (clearing lines or killing enemies) gives you more time. So a logical way of doing this would be chips countdown. At the start of the game and whenever you gain chips, they get added to a total that is constantly going down, and does so faster and faster. If it reaches 0, you lose just like if you couldn't clear a blind
  • An indirect way of messing with other players. Tetris 99 has garbage lines, and Mario 35 has gray enemies. What I imagine for Balatro would be anti-tags. On some condition (maybe defeating a boss blind) you would get to pick an anti-tag (a tag with a negative effect) to send to other players. Those tags would apply effects to blinds or the run in general to handicap the other players (adding boss blind effects, messing with your jokers or money, etc). Whether this would go to all other players or specific ones with a similar targeting system to the example games is up to debate
  • A reward for eliminating players. Determining if you have eliminated a player would be fairly simple, by considering that if a player dies in the blind/ante after receiving one of your anti-tag, you are credited with the elimination. This would mean multiple players could get credit. What kind of reward this could give you is to be determined, whether this would be an in-game effect (bonus mult, bonus money) or purely within the mechanics of the mode (reduced chips drain)

Finally, on the technical side, I don't believe good-faith networking like the Balatro multiplayer mod uses is possible here. 52 strangers getting into a game incurs an overwhelmingly high chance of at least one player having a mod that gives them an unfair advantage. This means server-side authority will be necessary to ensure a fair experience for everyone, which has two possibilities:

  • Running a Balatro instance for each player on the server that replays the actions (sent from the client) and validates them. This has the big advantage of being guaranteed to have no differences with an unmodded client, and allows the addition of other mods fairly easily, but has the big flaw of being very inefficient. All the visual elements that could cause most of the lags are useless for the server to have and could result in the server being unable to keep up, especially if multiple games are running at once
  • Reimplementing the Balatro engine in a more streamlined way. The way I see it would be to do so in Typescript, so that it could interface with Node.js. This has the huge problem of being a massive amount of work, and runs the risk of different behaviors in specific cases, and necessitate extra work for other mods. It would allow more control both over the serverside code (and allow me to write it in TS rather than lua which I will take)

There are probably other things to consider, but those are the main ones imo. Hope this sounds interesting to other people, and that I will get the time to work on this some time in the future. Thanks for reading! jimbo_spin

spiral fox
#

sick

granite hatch
#

What on god's green earth

velvet fractal
#

hype?

#

holy, reimplementing the engine

eternal burrow
#

It would probably make up the majority of the dev time if I were to go with this, yeah

#

Client side mod so far feels all like stuff that's possible and rather easy with Steamodded (custom tags/consumables/packs, new UI, simple mechanical additions)

robust tangle
#

oh god please don't reimplement the engine

#

you're gonna support zero mods

#

I could see this using a harsher form of mod hashing where a lobby / the lobby host dictates a mod list to be used and you can only join if you match exactly. Since hashing isn't lossless, it could additionally save each player's full mod list either for manual review or do additional parsing on it

eternal burrow
#

You can't trust the clients to send hashes

#

A crafty modder could just reply with whatever hash they want, since Balatro is completely open to being modified
And you can't trust they're not using some modified version of the Balatro 52 mod that also ignores this check
There is no verification that doesn't 100% involve the server that can't be spoofed or modded out on the client

cunning ruin
#

i must've missed balatro 51

robust tangle
#

but if the alternative to a system that can be cheated with some amount of effort is to allow no mods at all, I don't see the point

#

it may well be a fully separate game at that point

olive elk
#

honestly imo having this game mode in lue of mods is a fine tradeoff (for me at least)

eternal burrow
#

To be honest, getting this working on vanilla (except fully cosmetic mods) would already be quite an achievement, before thinking about compatibility with other content mods. Planning for this compatibility early is probably the best move though, but if it involves making the server very resource demanding, then it will have to be traded off

#

Balatro is not a very demanding game, but 50+ Balatros at the same time might be

#

(To be clear, the 52 figure is arbitrary, but I do want to make this able to accommodate a large amount of players)

robust tangle
#

If the standards you hold the project up to are fundamentally barely compatible with mods, not planning for mod support means you probably will never add it

eternal burrow
#

Well, they're not directly incompatible, it's a side effect of using the game itself for validation. A middle of the road option would be to extract the purely engine-related part of the game and remove all the visuals, but seeing how Balatro is reliant on events I don't know how possible that is

fair seal
#

Maybe a suggestion for player elimination:

Say you successfully eliminated a player, you then can "loot" what jimbos they had in their slots. The game selects a selection of jimbos that the eliminated had and you can work on what kind of build you're trying to go. So if a player was trying to build twords a Baron/Mime build, as an example, you can take whatever seems useful to you and build a different kind of build that might fit with what you're trying to go for.

#

That will also make finding specific jokers easier if the shops weren't being nice to you

eternal burrow
#

I'm also currently not entirely sure how "using the game for validation" would go, in particular running multiple instances (or one instance and hot swapping game states), so this would be an open question
I am going to privilege this approach for several reasons for now (peace of mind regarding divergent behavior, reduced workload, and mod support)

eternal burrow
robust tangle
eternal burrow
#

That could be provided for with an API, and would always be less work than reimplementing them in a different environment. Perfect integration out of the gates with every mod feels hard if not impossible to achieve

eternal burrow
fair seal
#

but it's always an option that you can take if you want to play a bit differently, perhaps

eternal burrow
#

Maybe. I could always include a dummy joker (or override the skip) that gives you a flat bonus if none interest you, like some money

robust tangle
#

sounds more like a consumable

eternal burrow
#

Fair point