Shroom and Gloom Soup: Pot System and Card Records

The official Steam description says that enemies can be roasted and placed into a pot to cook game-changing soups. That is enough to describe soup as a real part of the game’s reward and survival fantasy, and it is the reason this page can answer the broad system question. Keep that point within the source and version boundary.

The store description does not provide a complete recipe list, a fixed drop table or a universal rule for how many soups appear in a run. Keep the broad concept separate from card-specific records so a later update can change one layer without rewriting the other. Use the exact result in your build as the next check.

The captured NiaMeowDB record labels Awesome Soup as a Combat Food card. For Demo build 25221077, the stored action order lists Heal 6, Draw Damage Card: 1 and Gain 1 energy; the card details also show Energy 0, Shop cost 4 and Uses 6. If the evidence changes, update the claim rather than guessing.

Those values are useful because they are tied to a named record and a stated build, but they are not automatically current Early Access rules. The same page says the packaged record confirms the record itself, not that every run can obtain the card, so keep the build label visible whenever these details are mentioned. Keep that point within the source and version boundary.

The captured Growing Soup record also labels the card as Combat Food. Its Demo build 25221077 action list records Increase Damage: 3, while the details show Energy 0, Shop cost 2, Uses 3 and a repeat reward marked allowed. If the evidence changes, update the claim rather than guessing.

These are not a promise that the current build uses the same wording or values. The record is a third-party database entry, and the captured wording includes database-specific presentation limits; use it as a lead for an in-game check rather than as a complete balance statement. Keep that point within the source and version boundary.

Another third-party record lists Unsettling Soup and a Vulnerable effect. The supplied capture did not establish a fully reviewable current card page, so the safe phrasing is that the database contains a candidate record, not that the card is guaranteed, fixed or currently balanced that way. Keep that point within the source and version boundary.

The supplied gameplay transcript mentions a soup pot and watery soup, but no visual frame review was completed. The transcript can show what the speaker said; it cannot by itself prove unseen card text, exact values or an interaction that was not visibly checked. Use the exact result in your build as the next check.

When the named card appears in your run, compare the visible card with the stored record before relying on it. Capture the card name, deck, class, cost, effect order, uses and build together, because changing only one field can make a copied guide misleading. If the evidence changes, update the claim rather than guessing.

If the visible card differs, keep both observations instead of silently choosing one. The evidence pack should record whether the difference is a version change, a wording change, a database placeholder or a genuinely conflicting value, and the page should lower its certainty accordingly. Keep that point within the source and version boundary.

• Keep Demo build 25221077 in the note.
• Separate a card record from an obtainable-card claim.
• Do not turn two examples into a full recipe table.

The supplied material does not confirm every soup recipe, the complete pool, the exact way a player obtains each card, whether values scale, or whether a card can repeat across all paths. It also does not confirm that the two named records are the best choices for any character. Use the exact result in your build as the next check.

Do not use this page to invent a cooking route or a tier list. If your immediate problem is surviving the first run, return to the guide and decide whether Food should be eaten now or saved for a shop; soup details should only change that decision when the current card is visible. This is guidance for reading the evidence, not a new game rule.

The safe public answer is the system-level soup pot concept, with card examples clearly labelled as third-party Demo build records. That gives players a useful explanation without pretending that the current Early Access card pool has already been fully audited. This is guidance for reading the evidence, not a new game rule.

The collection date is 2026-09-17, and the page remains intentionally cautious. A future in-game check can promote an individual card only when its version, visible wording and conditions are recorded; until then, exact card data stays To be confirmed for the current build. If the evidence changes, update the claim rather than guessing.

This page answers the Shroom and Gloom soup query only from the supplied material and keeps each claim close to the source that supports it. A source may establish a broad system without proving a complete rule, route, card pool or platform result. When the evidence stops, the page says To be confirmed instead of filling the gap.

That boundary matters during Early Access, where a preview, a community run and a database record can describe different builds. The article keeps observed behavior, source wording and editorial guidance separate. You can therefore use the practical steps without mistaking a lead for a guaranteed result.

• Read the claim with its source type.
• Keep a version limit beside any exact detail.

The sources attached to this entry do not all have the same authority or purpose. Official pages are used for game-level or announcement claims, while gameplay transcripts, database records and community posts are kept as attributed reports. A report can be useful without becoming a universal rule.

If a sentence describes one run, one player, a preview or a historical discussion, read it with that limit attached. The wording is intentionally narrower than a definitive guide because the supplied evidence does not justify a broader conclusion. This protects the page from turning repetition into proof.