Bay 12 Games Forum

What i meant was that whose macros follow a fixed set of instructions. And should a gobloon dodge out of the way during the macro you'd be wasting time trying to disarm empty space. And more skilled players could get the same results using targeted attacks without the risk of losing track of their target.

Don't get me wrong, i like the idea of not having to go through endless menus during combat. But i don't think using macros would work throughout the entire learning cliff.
More detailed combat preferences would be much more useful IMO, since they would take the pressure off of the newer players while giving the veterans more control over the flow of combat.

This hotkey system seem too difficult to effectively set up for new players and veteran players can get the same results faster by using wrestling and targeted attacks.

What i'm getting at is that it'd take time for player to get used to it, only for them to abandon it once they get comfortable with the normal combat system.

Isn't booze explosive?

In Liamar's defense, EVERYTHING is planned.

I can get behind everything except this bit:

A procedurally generated race that survives a few(hundred) years into world gen but always dies out before the end date of history generation.

Because having them be part of history generation defeats the purpose of them being a precursor civilization.

I think all they should leave behind to the world are ruins spread everywhere, showing that they once ruled the world.
And those ruins should be made from slade, showing that they at one time had developed the means to mine and construct with slade. (And maybe they were the ones that constructed the Curious Underground Structure as a way to imprison the Clowns in their Circus.)

In general, such civilizations follow a few rules:
-They disappeared ages before the start of the story.
-They were the masters of their world.
-The knowledge they possessed at the height of their civilization could drive most younger civilizations to self-destruction.
-Despite their power and knowledge they were overcome by a more powerful enemy.
-And they leave behind tons of ruins and artifacts that no one can understand or sometimes even recognize.

I don't think it'd take up any CPU time during play, as everything happens right before embark and after the fortress fell. It certainly wouldn't take up as much time as the last 10 years of history generation.
In addition, both references can be written to a file as to not take up any more memory than necessary.

The biggest hurdle would be editing the fortress layout to appear more aged, right before subtracting it from an embark's blank reference at the start of a new game.

I was reading through some of my old threads and had an aha-erlebnis when reading this:

So, how about this: in the save folder there would be a new subfolder where player ruins would be stored. Around every ten years or at the moment of abandonment/retiring the game creates ruin template by simplifying/removing the engravings and smoothing excessive architectural details and places this template into aforementioned folder (or updates the one already present).
When a new world is created, the game looks into that folder and randomly places them around the world.
I doubt that layout of a couple fortress levels plus several engravings without links to history files would take up a lot of memory.
This way we'd get plausible ruins instead of another set of those fractal tombs.

I think this can be done in only a few steps.
-First a snapshot of the site is taken directly after embark (so we have a blank reference).
-Then, after the fortress is overrun or abandoned, another snapshot of the site is taken (a fortress reference).

Note that 'snapshot' in this method is a 3-dimensional picture of the entire embark site from the magma up to the surface, though the only information that needs to be stored is whether or not the tiles contain unmined stone. So it will be something like a 3-dimensional, binary map.

-Then, the fortress reference can be subtracted from the blank reference, and the result will be a negative fortress layout of everything that was excavated during play. And because the cave layers are present in both the blank- and fortress reference, they won't show up in the layout.

At this point both references could be deleted as they would no longer necessary be, and the fortress layout can be written to a file (probably somewhere in the /save/ folder, but outside the current /region/ folder) for future use.

Now imagine you do an embark in a new world and the game decides

hmm, this embark could use some more ruins

The game would snap the embark's blank reference,
access a randomly chosen fortress layout and edit it's z-levels so that it would appear somewhere underground,
subtract the fortress layout from the blank reference and
retake the blank reference (so that, if this new fortress would ever be chosen for ruins, you could excavate progressively deeper ruins)