Rune-based ID

[AnonymousHero]

especially gcu.

Kill GCU. Seriously, kill it. There's no rationalizaton for what GCU does. Kill it. KILL!

/stops channelling Bill Hicks.

(If T2 code is anything to go by there are loads of features of the Term interface struct which only exist to satistfy GCU... on platforms where you cannot move the cursor to "max (x,y)" because... reasons.)

[PowerWyrm]

Newly generated character with the latest build:
- there's a "mace of slay dragon" in the temple, although I've not seen the tail of a dragon yet
- hitting something makes you learn the "to damage" rune... but how are you supposed to learn the "to hit" rune (I was expecting by "missing" something, but it's not the case)?
- full dice/ac are automatically learned, so what's the point of the corresponding runes?

[Nick]

- there's a "mace of slay dragon" in the temple, although I've not seen the tail of a dragon yet

After some discussion, we decided to name ego items in stores, although (IIRC) you don't get the rune until you hit a dragon with it

- hitting something makes you learn the "to damage" rune... but how are you supposed to learn the "to hit" rune (I was expecting by "missing" something, but it's not the case)?

Um, generally just by hitting something

- full dice/ac are automatically learned, so what's the point of the corresponding runes?

These aren't runes any more.

[PowerWyrm]

Um, generally just by hitting something

I've hit a lot of somethings, still the rune isn't learned...

[Nick]

I've hit a lot of somethings, still the rune isn't learned...

If the weapon doesn't have a +to-hit, that would do it - otherwise it looks buggy.

[Nick]

After some discussion, we decided to name ego items in stores, although (IIRC) you don't get the rune until you hit a dragon with it

Looks like I recalled incorrectly - you do learn the rune. So buying ego items is a way of learning runes.

[Nivra]

There has been a bit of discussion on this, and I'm still unsure which way to go. As you say, this change would mean the player knows how many unknown runes there are (which might be seen as good or bad), and also requires some sort of names to be given to the runes (a bit like for scrolls).

I don't know - what do other people think?

I love the idea of showing runes using Runic Unicode

ᛈ ᛚ ᛖ ᛆ ᛊ ᛖ

[PowerWyrm]

If the weapon doesn't have a +to-hit, that would do it - otherwise it looks buggy.

Facepalm... Of course, that was the case (I was using the starting dagger enchanted to +1 to-dam with a scroll). Tested with a fully enchanted weapon, the to-hit was learned.

[PowerWyrm]

I understand that pseudo-id is gone... but why removing the ego quality squelching categories? Before, I could squelch slay dragon and such vs westernesse and such by choosing "excellent but not splendid" as a category. Now I have to select "non-artifact" and squelch all egos in the ego item ignore menu manually...

[Cold_Heart]

Kill GCU. Seriously, kill it. There's no rationalizaton for what GCU does. Kill it. KILL!

You can't be serious, can you.

If anything,

1) GCU is the main interface
2) any features that can not exist in GCU interface can go die in a fire

[AnonymousHero]

You can't be serious, can you.

If anything,

1) GCU is the main interface
2) any features that can not exist in GCU interface can go die in a fire

I am serious... and don't call me "can you".

Well, only semi-serious. I just think that GCU is not worth supporting because it's probably quite rarely used and it requires weird workarounds and special cases in code. Admittedly, I'm probably very biased because I'm 'maintaining' and/or 'ruining' ToME 2.x. Just to be clear: I'm not saying we shouldn't have ASCII (my preferred interface, in fact) -- I'm just saying that supporting playing inside a terminal window (as opposed to spawning a new window) doesn't seem worth the complexity to me.

[Cold_Heart]

The "playing inside a terminal window" thing provides actual signifincant benefits:

1) playing on a remote headless box via ssh/telnet/whathaveyou from whatever device that you can get an ssh client on (crapdroid? windows phone? a toaster? a potato?)

2) using whatever terminal emulator with whatever features you want

3) interoperation with whatever terminal tools you want (tmux? how about ttyrec? and take it a step further and termcast?)

And to me, a GCU frontend is a very, very large part of what makes a roguelike a roguelike.

[Derakon]

The "playing inside a terminal window" thing provides actual signifincant benefits:

<snip>

I'm not saying you're wrong or that these aren't benefits, but I would guess well in excess of 90% of the player base does not need or even notice these features. They shouldn't be thrown away for no reason, but supporting them does add cost to supporting the game in general.

It would be nice if there were a better general-purpose remote-play/record/playback functionality than using a terminal. Something smarter than full-screen recording but more flexible than terminals.

[Nick]

I'm not saying you're wrong or that these aren't benefits, but I would guess well in excess of 90% of the player base does not need or even notice these features. They shouldn't be thrown away for no reason, but supporting them does add cost to supporting the game in general.

Agreed, and I think you'd need an overwhelmingly compelling reason (like literally no-one used terminals any more).

It would be nice if there were a better general-purpose remote-play/record/playback functionality than using a terminal. Something smarter than full-screen recording but more flexible than terminals.

Yes, and really that shouldn't be too hard now.

I actually considered for a while the idea of replacing savefiles with a complete record of all game commands, and on reloading have the game just run through them up until the current point. This is in some ways the correct way to handle saving and reloading; the problem is that it is very fragile to code changes. But having this as a part of the savefile is perhaps a good option.

[Derakon]

I actually considered for a while the idea of replacing savefiles with a complete record of all game commands, and on reloading have the game just run through them up until the current point. This is in some ways the correct way to handle saving and reloading; the problem is that it is very fragile to code changes. But having this as a part of the savefile is perhaps a good option.

I don't think this is the correct way, exactly: they're two separate things. You want an encoding of the game state as a save file, because replaying the game each time you load could get prohibitively expensive even for a relatively simple game. But having the ability to record and replay your actions is also valuable.

If you do decide to look into this, you might want to take a look at what tool-assisted speedrunners do. They make speedruns of classic videogames using emulators that are coded to record their actions, and they make heavy use of frame-by-frame play and rewinding to make their speedruns "perfect" (effectively turning an action game into a puzzle game). The savestates (a.k.a. savefiles) they use encode not just the current emulator state, but also the steps taken to reach that state, so they can be used to replay the game from power-on, but usually you just imprint the emulator with the state encoded in the savestate instead.

Some emulators are prone to "desyncs", which means that the actions stored in the savestate do not reliably result in the correct game state. This is usually due to the emulator not being properly deterministic.