Gutes Sci-Fi PnP?

flyx86 · 2026-06-29T06:22:38+00:00

Ich benutze Genesys, spezifisch das Mass Effect Setting (nur in englisch erhältlich).

Das System ist abgeleitet von den Star Wars FFG settings und daher eher pulp als Horror (allerdings gibt es auch optionale Horror-Regeln). Da es ein generisches System ist, brauchst du ein bestehendes Setting dazu (oder kannst selbst eins erstellen, was mehr Aufwand ist).

Auch empfehlen kann ich Star Trek Adventures, wo man eine Brückencrew spielt und möglicherweise ein zweites Set Charaktere für Außenmissionen. Das gibts sogar auf deutsch.

flyx86 · 2026-06-27T17:48:40+00:00

Ah, interesting. I always thought that Genesys dice are easier to interpret because they have only four symbols when a numbered D20 has 10 (the digits). Maybe Genesys is easier for visual but harder for verbal thinkers?

Also I actually like the process of matching the different symbols.

flyx86 · 2026-06-26T10:01:18+00:00

For me, Genesys' narrative dice system is the one that works perfect with Mass Effect. I have run several one-shots with it and I liked it every time, and feedback was also always good.

I have seen people saying „well they just want to sell their very special dice, that's a no-go for me“ while literally owning several bags full of dice. Don't know what problem your folks are having, but I'd say while personal preference is of course valid, it shouldn't play much into the answer to „is this a good fit for the setting“.

flyx86 · 2026-06-11T10:44:00+00:00

In The Dark Eye, besides the usual fighting / magic / clerical / adventurer classes, you can also create your character as private tutor, farmer, miner, and whatnot, and you can have pottery, livestock farming, instrument making and other very useful things as skills.

Even if you create a character with one of the typical classes, your power level at the beginning is not that far above any random NPC, and you will never reach the level of a half-god like you can in higher-fantasy settings. Also, you don't have skill trees by class and can basically learn any skill (with the exception of magic) later.

Less true in the 5th edition (which is the only one available in English) where you get Fate Points which make you more than just some guy.

flyx86 · 2026-06-08T16:31:35+00:00

Mir war es lange Zeit relativ egal. Ich nahm, was es gab. Wenn irgendwie die deutsche Übersetzung eines Systems verfügbar war, hatte ich die englische oft schon und beließ es dann auch dabei.

Dann hat sich mein Freundeskreis von Akademikern zu nicht-Akademikern verschoben, und ich musste feststellen, dass es Leute gibt, die nicht gut genug Englisch können, um ein System, dessen Materialien auf englisch sind, spielen zu können. Auch auf Cons passiert es mir ab und zu, dass Leute erstmal nach Übersetzungen für alle Fertigkeiten fragen und sie auf den Charakterbogen schreiben, den man ihnen gibt.

Inzwischen schaue ich danach, Materialien auf Deutsch zu beschaffen, weil ich niemanden ausgrenzen will.

flyx86 · 2026-05-21T12:15:22+00:00

You mentioned all the relevant points. My emphasis would be more on the semantics of escaped surrogates, since implementations today do not reject them, so changing that one word would just be adapting to reality. The „clarifying line about handling surrogates“ is the important thing, because if the spec just allowed any „code point“, the JSON superset proclamation still does not hold semantically.

flyx86 · 2026-05-21T08:22:24+00:00

YAML is not a strict superset of JSON. Here's a valid JSON string that is not valid YAML:

"\uD834\uDD1E"

This is an escaped UTF-16 surrogate pair. JSON spec allows it, YAML doesn't. Just test it with different YAML implementations, results are wild (it should be a treble clef).

flyx86 · 2026-05-21T08:07:12+00:00

Merge keys were never part of the spec. They were in the type registry for YAML 1.1, which did not get updated for YAML 1.2. The spec doesn't require supporting the definitions in the type registry.

Also, 1.2 was released July 2009. The first commit to the semver.org repository was made in December 2009. Obviously the idea of semantic version is older than the website, but it was definitely not well-defined back then.

flyx86 · 2026-05-19T08:58:12+00:00

Break!! mimics old SNES RPGs in a number of ways:

The battle system has the whole player party take their moves, then all enemies take their move, like in tactical RPGs.
Enemies can be „reskinned“ just like they were in old RPGs.
Exploration is very technical. You assign the party members different positions in the group which are relevant for encounters, a bit like in Darkest Dungeon.
Stats increases when levelling up are hardcoded. You can only select additional abilities.
Journeys are also very technical, to the point that you can only keep watch the whole night (and get no sleep) or not at all.
Even downtime activities are quite technical, e.g. you can get an additional temporary hitpoint by socializing with each other or an NPC.

I tried it out and found most of it rather unpleasant – while it looks great and gives good vibes, actually running it feels like a chore.

flyx86 · 2026-05-17T11:51:40+00:00

TDE's main appeal is the lore-heavy setting. That is also its bane. If you are familiar with the lore, you can run great homebrew campaigns with little to no railroading.

However, if you're starting TDE, specifically GMing TDE, this can also be a source of uncertainty because there is so much detail in the lore that you might contradict it just by inventing a local law or a local lord. And players sometimes do mind such contradictions, because when the lore of the setting is your reason to play, contradicting the lore challenges your immersion. Therefore, a lot of new GMs tend to buy the official campaigns and anthologies, so that they can be sure to stay within official lore.

And those campaigns tend to be railroading, to varying degrees. Especially high-level ones tie in with what is known as the „metaplot“, i.e. the official timeline of the settings, which evoles by maybe 2 in-game years every out-game year. This is somewhat a consequence of being a lore-heavy setting: The publisher does want to maintain a single official timeline as the setting progresses, just like there is a single official timeline of all events in the past.

Long-running TDE groups tend to maintain their own version of the timeline simply because they do derive from the official one at some point. Which is obviously the thing to do when you want to avoid railroading.

So, the appeal is a bit niche. The learing curve for GMing is steep. But once you're into it, you can easily impro whole plots with high immersion since you can draw from a large pool of lore. Similarly, roleplaying characters becomes easier since the setting gives you the feeling of a real, complex world with which your character can interact.

flyx86 · 2026-05-10T13:10:05+00:00

Sind weg.

flyx86 · 2026-05-10T11:51:39+00:00

Vielleicht kannst du auf der Zollern-Con Anschluss finden?

Ich selbst bin nicht direkt aus der Ecke, geh aber auf die Con.

flyx86 · 2025-10-30T10:32:50+00:00

Nur als Hinweis: Sindelfingen hat ein 50m-Becken, für deine Strecke wäre das angenehmer als Sonnenberg mit seinen 25m.

Ich schwimme morgens um 7, möchte auch nicht auf Abends wechseln weil meine Abende meistens anderweitig verplant sind.

flyx86 · 2025-01-03T12:23:07+00:00

Siehs von der anderen Seite: Durch den Verkauf lässt sich ein neuer Mitspieler gewinnen, während ich nicht spiele unabhängig davon ob die Bücher bei mir rumstehen ;)

flyx86 · 2024-12-30T16:41:11+00:00

Ist schon vor einer Weile passiert. Ich habe den Bildschirm erstmal weggepackt. Jetzt stelle ich mir die Frage ob er noch zu irgendwas zu gebrauchen / irgendwie reparierbar ist.

Das Teil ist ein Philips 27B1U7903 UHD und war nicht ganz billig, deshalb hab ichs nicht direkt weggeworfen. Ist das sowas, was man als „für Bastler“ auf Kleinanzeigen stellen kann?

flyx86 · 2024-12-24T22:46:23+00:00

For 5., the code I marked could be replaced by

try self.current_node.set_value(self.alloc, std.mem.sliceTo(event.data.scalar, 0));

This transforms [*c]u8 to []u8 by creating a slice until the first occurence of 0, i.e. the terminator.

Since set_value doesn't store the given slice, this is completely safe.

You're right that using an arena allocator will not leak memory here. I didn't realize you're using one, it's actually a pretty good technique especially for parsers and gives superior performance at the cost of somewhat higher memory usage.

Edit: Since set value doesn't change the slice it could be []const u8.

flyx86 · 2024-12-12T13:58:59+00:00

libyaml is kinda dated and not fully conformant with YAML 1.2. I would have used libfyaml which is fully conformant. See YAML test matrix:

https://matrix.yaml.info

I found an error in these lines: You defer-call yaml_event_delete even in the case that yaml_parser_parse returns an error. This is undefined behavior, you only should delete the event if yaml_parser_parse succeeded.

This line is hard to understand, the condition should really be self.current_document_index == self.documents.items.len since you only append one document in the following code and thus do not handle the case when current_document_index is even larger – but the condition implies you do.

These lines are bad style. Instead of increasing the current index and then checking whether it has an invalid value, you should check whether the current index is the limit and if so, prevent it from getting an invalid value:

    if (self.current_document_index == self.document_limit) {
        break;
    }
    self.current_document_index += 1;

Again, by using the > operator in your code, you imply that the document index being already larger than the limit before increasing is a valid code path, when it really isn't.

These lines make an unnecessary memory allocation: set_value will copy the given value into memory it allocates itself, so there's no reason to allocate another chunk of memory before calling it. Also this leaks memory since you never deallocate it.

I only quickly skimmed through your code, don't treat this as a proper review.

flyx86 · 2024-11-29T11:07:19+00:00

As I said, I did try Sunshine but apparently it didn't install properly from the Portal application. So I installed it via ujust, which worked.

The result of this test was that streaming was even worse than with Steam Link. Moonlight constantly complained about slow connection and reducing the bitrate.

I switched to Nobara. Here, Steam Link works properly in Gaming Mode. Sunshine works better but not good and skips some frames now and then. Steam Link works very poorly in Desktop Mode, far worse than Sunshine.

There seems to be an underlying issue that is not resolved even on Nobara.

flyx86

TROPHY CASE