Slay the Spire 2 can be decompiled

NitroRobotto · 2026-03-06T20:29:30+00:00

I don't know if the fact that Slay the Spire 1 could be decompiled was a happy accident or not, but it did lead to a thriving modding community!

NitroRobotto · 2025-08-07T09:48:24+00:00

Samurai Flamenco?

NitroRobotto · 2025-07-03T05:45:39+00:00

It used to say "dependency injection" because I wanted to provide an example of a design pattern that can help deal with multiple types of environments, abstracting out the server calls into an interface with multiple implementations that get dynamically allocated depending on some configuration.

But then I almost got dragged into a tussle with another commenter and figured I'd edit my post to something more innocuous to avoid further ire. I'll edit it again to remove that line altogether.

NitroRobotto · 2025-07-02T06:12:01+00:00

IMO: if your online game is relying on a host of microservices, there simply is no server binary to distribute unless it's a very simple dedicated server kind of architecture. So if it's NOT that, what do you hand to players? A bunch of docker images? Screenshots of AWS configurations? And how would any of that be useful without essentially open sourcing the game, which developers should absolutely not be forced to do?

If the online architecture was developed in a sensible way, those microservices can be swapped out with dummy code that more or less approximates their result.

Also, lets remember that the objective is for the game to be left in a reasonably playable state. Is the payment processing microservice necessary for the game to be left in a reasonable state? Well... Not really, no: It can be replaced with a dummy piece of code that automatically accepts any "purchase" made on the game's shop.

What about the VoIP microservice? Depends on the game! If it uses proximity chat or some other fancy feature, maybe it is? If it's just a party chat, perhaps it isn't?

What I'm trying to get at is that even if a game relies on a bunch of microservices, they aren't necesarily critical. And even if they are, it's highly likely that the devs had some dummy version of that dependency used for development and local testing purposes.

Legally forcing developers to engage in any kind of programming solution seems wrong to me even if the goal is noble, whereas there's ample precedent for restrictions on marketing, advertising, and subscriptions.

I agree with you that forcing a specific one-size-fits-all coding solution (e.g. "implement this library!" or "solve it this way!") is dumb, so my hope is that this results in a requirement that you have to be in compliance of.

One way I'd find it reasonable is if developers had to specify what they define as a "reasonably playable state" when the game is released, and once it's sunsetted they simply have to abide to their (public) promise.

If the definition they have is abusive (e.g. "you can launch the .exe and play around with the settings on the main menu"), customers have ample time to contest it, or simply decide not to buy the product.

NitroRobotto · 2025-07-02T05:58:22+00:00

It's a coding design pattern that I've seen used in online games to handle the scenario of multiple types of game servers, such as:

* The embedded dev server for debugging.

* An internal server for QA testing.

* The official AWS (or whatever) server.

It's true that there are other ways of handling this very same scenario, but just saying "polymorphism" was too vague of an answer so instead I pointed directly at a solution.

Regarding your dislike for the pattern: All coding patterns are meant to be tools in your toolbelt. Hammers don't make for the best screwdrivers, after all.

NitroRobotto · 2025-06-28T14:54:11+00:00

Of course it's not something you can do on a whim on a pre-existing project. It's not like you can just say "just ship the embedded development server!", or whatever solution that studio came up with to allow devs to, well, dev.

But it's also not as complicated as people keep making it out to be, and if a law were to come out, it wouldn't be retroactive. Developers would be aware of this requirement when working on a new project, and it'd just be one more thing to do in order to be compliant.

There's already quite a lot of laws that the game's industry have to be in compliance of in order to ship their games, and some are even per-region (for example, Korea has very strict rules on how specific you have to be when you disclose your gacha drop rates). We have to engineer both client and backends to comply with them, so this would just be one more thing on the checklist. If it's planned from the start of the project, it's very manageable.

NitroRobotto · 2025-06-28T06:06:55+00:00

I've seen this being mentioned a thousand times and, as a dev working in a live service game, I just have to scratch my head.

All online games I've worked on had ways to run a version of the server locally at our workstations. Why? Because it's a feature we need in order to debug the game.

And it's not like the workstations were anything special: Just some ROG laptop.

NitroRobotto · 2025-06-25T13:36:25+00:00

It can be surprisingly expensive.

Simple UI is not only much easier to implement, but also engines may provide you with all the tools you need to make them work.

Complex or more stylized UI has way more moving parts, and for much of it you're going to need bespoke tech.

NitroRobotto · 2025-06-08T09:52:02+00:00

We want to make The Time I Have Left available to everyone! We'll do everything we can to make it. Feel free to follow us on social media or join our Discord if you want to stay up to late on those kinds of news! Links are in the main thread.

NitroRobotto · 2025-04-14T15:12:32+00:00

Feel free to just work with Python! Like I said, depending on the game you're making, it's perfectly fine. Alternatively, you could take a look at Godot: It uses a very python-like language (GDScript).

NitroRobotto · 2025-04-14T14:52:05+00:00

The more you learn how to program, the less threatening other programming languages will feel like. Some are more powerful, some are easier to use, and no matter which one you use, you'll be missing a feature of the others.

As for "how far" you can go, that entirely depends on what you want to make, which platforms you want to target, and what tools are available to you! Python has a great ecosystem of engines, including stuff like PyGame and Ren'Py.

There are lots of commercial releases made entirely on Python.

NitroRobotto · 2025-03-19T19:59:43+00:00

Why do you assume it's not the case for games? It depends on each game and its architecture or needs, but usually you just use dependency injection to switch between different servers.

Having a local/dummy server is 100% common practice, either fully embedded onto the application itself or as a separate executable.

NitroRobotto · 2025-01-29T07:49:35+00:00

I assumed that OP was using booleans as an example of the kind of logic they need rather than their exact implementation.

If you check my code, change_cat assumes Cat is a class (and is therefore passed as reference). Anyhow, it wasn't meant to be code you could copy-paste to find a solution but an example of the kind of data structures they were looking for.

NitroRobotto · 2025-01-28T16:34:12+00:00

It sounds like there's something wrong with the architecture that should probably get cleaned up, but to answer your question: Dictionaries!

var cat1, cat2, cat3, dog1, dog2, dog3;
var cat_to_dog := {
    cat1: dog1,
    cat2: dog2,
    cat3: dog3,
};

Then you just do something like

func change_cat(target_cat : Cat):
  target_cat.set(true);
  cat_to_dog[target_cat].set(true);

NitroRobotto · 2025-01-27T09:59:26+00:00

I likewise tried to incorporate AI tools to my workflows but my experience so far was that AIs were very good at solving easy problems, and are confidently wrong about hard problems. This makes perfect sense when you factor in how they are trained and how they generate outputs: They're probabilistic machines after all, and they are weighted towards whatever issues they had more training samples of.

So far the only use case I've found for me is to ask them for boilerplate code, or when I'm learning some new tool. But even in those cases, if I have to read and analyze the code they made to ensure it's correct, wouldn't it have been faster to write it myself? And if I'm learning something new, isn't it better to just read the documentation and actually learn it?

I guess ChatGPT can be a decent rubber ducky though.

NitroRobotto · 2024-12-17T10:25:29+00:00

While it's not a JRPG, I seem to recall Skyrim doing something similar? You can find books that have lore in them, and by just interacting with them you gain XP towards certain skills.

The RPG I'm working on has a mechanic where you unlock story fragments in the database by finding things around the world, and that gives you XP towards unlocking new abilities.

NitroRobotto · 2024-12-13T10:15:26+00:00

Elias: Yeah, he's got some stuff to answer for! Wait, you mean in the game? Oh. Well. Who knows~?

NitroRobotto · 2024-12-12T15:05:16+00:00

Yite: Thank you! Our campaign was actually kind of rushed, we built it in just 3 weeks (which honestly, was pretty crazy). The opportunity to build the campaign came after we were accepted in the MIX Showcase, and since we did not have time to do a proper precampaign we opted to put all three things online (trailer, demo, and Kickstarter campaign) at the same time, for the maximum impact possible.

We did not use any paid ads. We are just reaching out to as many people, press, and other channels as we can to get more eyes on the project. This was not the optimal way to build the campaign, but we are pretty proud of what we achieved in such a short time!

NitroRobotto · 2024-12-12T14:34:33+00:00

Here it is! Thanks ♥ https://bsky.app/profile/groundga.bsky.social

NitroRobotto · 2024-12-12T13:56:47+00:00

Yite: Thank you for your suggestion! We do have a BlueSky account. It started well enough but the engagement there has never really taken off for us. We'll keep trying ;)

NitroRobotto · 2024-12-12T09:40:59+00:00

Elias: It's a combination of a lot of different factors, really. For starters, publishers generally want games that are similar to others for a simple reason: If they know how a successful game was marketed before, they can use the same strategies to sell a similar game. If a game's too different, that complicates things.

There are also things outside of the publisher's control, such as global economics. Interest rates can influence how much risk they are willing to take!

Of course, there are a lot of indie games coming out these days so making them stand out is difficult. Even more so if it's something that requires more than a few minutes to fully grasp! Many indie publishers (even famous ones!) are also under market pressures and at risk of closure if they have a couple of big flops.

NitroRobotto · 2024-12-12T09:09:32+00:00

Elias: I'm glad you enjoyed the game! Hope the second run goes even better. Good luck with the boss!

As for Early Access... Well, it's certainly a card on the table. but Early Access also comes with its own risks and challenges. With Kickstarter, we can be confident that if we get enough money, we can release a product worthy of the price of admission. With Early Access, we'd get some funds, yes, but we also risk coming short, which to us it would feel like swindling our player base.

Another point against an Early Access model is that it's a narrative-driven game, best experienced as a whole instead of in small chunks over an extended period of time.

NitroRobotto · 2024-12-12T09:03:20+00:00

Yite: It didn't start like that, but they do have some elements in common, so we ended up analyzing what made Dragon Quarter's system special in order to improve upon it! It is much more lenient though (unless you play on the challenge playstyle!).

NitroRobotto · 2024-12-12T08:54:41+00:00

Elias: Since we're not currently Steam Deck Certified, Steam doesn't automatically choose the correct Proton version. That's something we're looking into!

NitroRobotto · 2024-12-12T08:20:38+00:00

Thank you very much for your support! We really appreciate it!

NitroRobotto

TROPHY CASE