G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

I don't usually use auto-scum because it's so slow, so having
it switched on in the Steamband competition was my first real
experience of it.

Thinking about auto-scum in all variants, it seems really
weird to implement it by generating hundreds of levels,
testing them and throwing them away. When you have a
guaranteed good object in a vault you don't generate that by
rolling thousands of weapons until one of them just happens
to have the right flag!

Instead of simulating stair-scumming, why doesn't the
auto-scum feature simply start off by deciding that there's
going to be *something* special on *every* level and then
roll a series of tables to find out what it is? So maybe to
start off with there's a 5% chance of an extremely good
feeling, 10% chance of a very good feeling, 20% chance of a
fairly good feeling, etc. And then you roll on a random
table to decide whether it's going to be four minor objects
(or monsters), three deeper ones, etc., or one really out of
depth thing. And then you generate it (and all its contents
if it's a vault or a pit, or more than one) and place it
randomly somewhere on the level.

And then you create the rest of the level as normal. I
suppose if it just happens to create *another* good object (or
more than one) randomly during the creation process maybe
this ought to affect the pre-rolled level feeling too, so it
shows as higher than originally set.


I assume there's some reason why this wouldn't work or people
would be doing it already, it seems much more efficient.

--
Harriet Bazley == Loyaulte me lie ==

If it's not broken, don't fix it.
 

valis

Distinguished
Mar 24, 2005
380
0
18,780
Archived from groups: rec.games.roguelike.angband (More info?)

In article <91d563504d.admin@freeuk.com>,
Harriet Bazley <bazley@feathermail.co.uk> wrote:

> I don't usually use auto-scum because it's so slow, so having
> it switched on in the Steamband competition was my first real
> experience of it.

Just FYI, the autoscum in Steamband is slow because with Autoscum *OFF*
it defaults to the # of level generations that [V] uses with Autoscum
*ON* and with Steamband Autoscum *ON* it generates 1000x more levels
than [V] autoscum.
-Campbell
 

replicant

Distinguished
Oct 9, 2003
20
0
18,510
Archived from groups: rec.games.roguelike.angband (More info?)

Harriet Bazley wrote:
> I don't usually use auto-scum because it's so slow, so having
> it switched on in the Steamband competition was my first real
> experience of it.
>
> Thinking about auto-scum in all variants, it seems really
> weird to implement it by generating hundreds of levels,
> testing them and throwing them away. When you have a
> guaranteed good object in a vault you don't generate that by
> rolling thousands of weapons until one of them just happens
> to have the right flag!
>
> Instead of simulating stair-scumming, why doesn't the
> auto-scum feature simply start off by deciding that there's
> going to be *something* special on *every* level and then
> roll a series of tables to find out what it is? So maybe to
> start off with there's a 5% chance of an extremely good
> feeling, 10% chance of a very good feeling, 20% chance of a
> fairly good feeling, etc. And then you roll on a random
> table to decide whether it's going to be four minor objects
> (or monsters), three deeper ones, etc., or one really out of
> depth thing. And then you generate it (and all its contents
> if it's a vault or a pit, or more than one) and place it
> randomly somewhere on the level.
>
> And then you create the rest of the level as normal. I
> suppose if it just happens to create *another* good object (or
> more than one) randomly during the creation process maybe
> this ought to affect the pre-rolled level feeling too, so it
> shows as higher than originally set.
>
>
> I assume there's some reason why this wouldn't work or people
> would be doing it already, it seems much more efficient.

The problem here is that it's very hard to make sure that the
'interesting' things show up proportionately. For example, some levels
are interesting because they contain monsters, and other levels are
interesting because they contain objects. What's the ratio between
monster-interesting and object-interesting? Well, that depends on a
lot of things - the average level contains some average number of
objects, and some average number of monsters - but what is that
average? Does it change over time? Late levels tend to be crowded.
There's a certain chance that monsters will be generated deep - but how
much does the average deep monster add to the feeling? There's some
randomness to how deep it's going to be. Some monsters appear with
groups, and the escorts also affect the level feeling. There's a
certain chance that objects will be generated deep - but how much does
the average deep object add to the feeling? These, too, might depend
on the depth - if you're at level 98, everything is in depth anyway.
At some depths, artifacts won't contribute to the level feeling because
no artifacts will be in depth. And, of course, vaults and pits not
only add to the level feeling, by containing some average number of
monsters and objects, they also modify the level feeling in that way.

Why does all that matter? The level generation routine follows a set
of rules to generate a level. If we want to 'force' the issue and
generate a particular kind of level, we would want to make sure the
forced level follows more or less the same set of rules in general.
Unfortunately, the rules are extremely complex and depend on a lot of
variables. Maybe about 50% of all level feelings come from tough
monsters, but we mess up and think it ought to be 70%. Then, by trying
to plan out a level according to those numbers, we might introduce some
kind of bias to the generation, so that an auto-scummed level would
contain more (pick - artifacts, vaults, pits, items, unique monsters,
etc.) than a normally-generated level. We might create a level that is
extremely unlikely or even impossible under regular rules. That might
make playing with auto-scum too easy, too hard, or too boring,
depending on exactly what happens. Even if we plan very careful, all
the calculations depend on variables that might be changed in
subsequent versions; we frequently want to add or subtract monsters,
fiddle with how good artifacts are, change the rarity of certain items,
or tweak how often a vault or pit appears. If those affect how often
things happen that change level feeling, the auto-scum code would have
to take that into account.

The current method of generating thousands of levels and picking one
dodges all of this. Because, under the hood, auto-scum uses exactly
the same generation routine as normal play, we don't need to worry
about separate implementations. Auto-scum's results only depend on (a)
the way level feelings are calculated and (b) how auto-scum picks a
high-feeling level. If we change any other part of Angband, we don't
have to rewrite auto-scum to make sure it 'matches up' - it already
matches up because it uses the same code as the rest of the game.
Changes elsewhere don't affect auto-scum. It always works as
advertized - like regular Angband, except with higher level feelings.

In programming, this idea is called 'encapsulation' - you write code so
that when you change a value or function in one place, it doesn't screw
up code elsewhere as long as the new value or function works as
expected.

So - the way auto-scum currently works is inefficient *in CPU cycles*.
It uses up a lot of effort to calculate a good level. However,
auto-scum is extremely efficient *in programming time*. Maintainers
don't have to worry about auto-scum unless they have specifically
decided to change it. Furthermore, it's a simple implementation, and
it's obvious that it works like it's supposed to; it doesn't need to be
debugged or written, since it's already there and works. In a fairly
large, messy, and complicated program like Angband, everything you
don't have to worry about is a blessing. With modern computers,
processing power is cheap; programmers' time and patience, however,
remain limited.

There probably is a faster way to run auto-scum correctly and with
encapsulation, but I'm not sure it's worth the trouble. Most variant
maintainers would rather add exciting new features than mess with a
system that already exists and works, and I agree with them.
 

replicant

Distinguished
Oct 9, 2003
20
0
18,510
Archived from groups: rec.games.roguelike.angband (More info?)

Bah! It's a relative term, and he isn't dead.

....but compared to some modern styles / languages for programming, yes,
Angband is messy. Think of a Colt 6-shooter - elegant and effective
compared to its ancestors, but outdated when put beside the modern
contraptions. Ben deserves plenty of credit for accomplishing a real
feat of programming, but computer technology moves fast, and
programming methods have developed beyond where Angband currently is.
 
G

Guest

Guest
Archived from groups: rec.games.roguelike.angband (More info?)

Replicant wrote:
> In a fairly large, messy, and complicated program like Angband

Messy?!

No, I didn't just cast earthquake in the town -- that rumbling you hear
and the ground shaking is Ben Harrison spinning in his grave. :p

--
http://www.gnu.org/philosophy/right-to-read.html
Palladium? Trusted Computing? DRM? Microsoft? Sauron.
"One ring to rule them all, one ring to find them
One ring to bring them all, and in the darkness bind them."