Archived from groups: rec.games.roguelike.angband (More info?)
Briefly:
The code that translates monster energy to movement was modified some
time ago to address the movement clumping issue. The problem has not
disappeared in the latest version of Angband. This post talks about
movement clumping and testing for it, and then proposes a solution.
Movement clumping:
- Movement clumping occurs when a monster gets more or fewer moves
between one character move and the next than it would if speed
translated perfectly to movement. This can lead to insta-deaths as a
dragon or Morgoth gets an extra chance to do Something Nasty, despite
the player's best calculations of relative speed.
- Not all variants believe that movement clumping is really a problem.
Hengband deliberately randomizes monster movement so you can never be
sure exactly when any of your opponents will take another turn.
- This posts assumes that movement clumping, Hengband or no Hengband, is
a problem, and needs to be fixed. This opinion applies with double
force to variants using any version of 4GAI or the "spellpower" system.
Testing for movement clumping:
- It is not easy to definitively test for movement clumping by just
playing the game, because a variety of factors complexify the results.
Therefore, when I finally decided to tackle monster movement, I cobbled
up some testing code for Sangband that output messages when movement
clumping occured in turns where neither the character nor the particular
monster had any speed changes applied to them. This code (and an Excel
spreadsheet that helped me work the math) is available on request.
What testing indicates:
- The modern Angband method, as found in Angband itself and most
variants, fails in the case of a monster getting an exact multiple of
character energy, and the character not moving at exactly +0, +10, etc.
speed. Because of slowdown with heavy packs and randomized monster
speeds, this situation is not uncommon. The Angband method is also
exremely CPU-intensive; profiling implies that it causes more game
slow-down than any other single code block, including monster flow
(which is saying something).
- The Oangband system, as found in Oangband and Sangband, was not tested
(because I was planning to replace it regardless of results).
Current state of my own code:
- Sangband first went back to the Angband 2.8.3 system, modified by the
Oangband code to handle monster regeneration and add energy to monsters
within the "process_monsters()" loop. However, unlike in Oangband and
like in Angband, I apply energy after monster moves, same as with the
character.
- Instead of calling "process_monsters()" a second time just before
character moves, I added code within the "process_monsters()" loop
(right after adding energy) to allow monsters with high energy (at least
equal to the maximum of 100 and character energy) to move again. This
acomplishes the same thing and saves a great deal of CPU time better
used for more interesting things.
- I then forbade a second move for monsters that get an exact multiple
of the energy that the character gets (22 energy against 11, for
example).
Final comments:
- This is certain to not be the last word on the matter. My current
code has yet to be extensively tested, and may well change again before
release. It is therefore not available yet. What /is/ certain is that
putting in some serious scaffolding to test the code made all the
difference for me. I would never have been able to figure out exactly
how monster and character energies interact without both being able to
read energy data on-screen and then massage the numbers in Excel.
Briefly:
The code that translates monster energy to movement was modified some
time ago to address the movement clumping issue. The problem has not
disappeared in the latest version of Angband. This post talks about
movement clumping and testing for it, and then proposes a solution.
Movement clumping:
- Movement clumping occurs when a monster gets more or fewer moves
between one character move and the next than it would if speed
translated perfectly to movement. This can lead to insta-deaths as a
dragon or Morgoth gets an extra chance to do Something Nasty, despite
the player's best calculations of relative speed.
- Not all variants believe that movement clumping is really a problem.
Hengband deliberately randomizes monster movement so you can never be
sure exactly when any of your opponents will take another turn.
- This posts assumes that movement clumping, Hengband or no Hengband, is
a problem, and needs to be fixed. This opinion applies with double
force to variants using any version of 4GAI or the "spellpower" system.
Testing for movement clumping:
- It is not easy to definitively test for movement clumping by just
playing the game, because a variety of factors complexify the results.
Therefore, when I finally decided to tackle monster movement, I cobbled
up some testing code for Sangband that output messages when movement
clumping occured in turns where neither the character nor the particular
monster had any speed changes applied to them. This code (and an Excel
spreadsheet that helped me work the math) is available on request.
What testing indicates:
- The modern Angband method, as found in Angband itself and most
variants, fails in the case of a monster getting an exact multiple of
character energy, and the character not moving at exactly +0, +10, etc.
speed. Because of slowdown with heavy packs and randomized monster
speeds, this situation is not uncommon. The Angband method is also
exremely CPU-intensive; profiling implies that it causes more game
slow-down than any other single code block, including monster flow
(which is saying something).
- The Oangband system, as found in Oangband and Sangband, was not tested
(because I was planning to replace it regardless of results).
Current state of my own code:
- Sangband first went back to the Angband 2.8.3 system, modified by the
Oangband code to handle monster regeneration and add energy to monsters
within the "process_monsters()" loop. However, unlike in Oangband and
like in Angband, I apply energy after monster moves, same as with the
character.
- Instead of calling "process_monsters()" a second time just before
character moves, I added code within the "process_monsters()" loop
(right after adding energy) to allow monsters with high energy (at least
equal to the maximum of 100 and character energy) to move again. This
acomplishes the same thing and saves a great deal of CPU time better
used for more interesting things.
- I then forbade a second move for monsters that get an exact multiple
of the energy that the character gets (22 energy against 11, for
example).
Final comments:
- This is certain to not be the last word on the matter. My current
code has yet to be extensively tested, and may well change again before
release. It is therefore not available yet. What /is/ certain is that
putting in some serious scaffolding to test the code made all the
difference for me. I would never have been able to figure out exactly
how monster and character energies interact without both being able to
read energy data on-screen and then massage the numbers in Excel.
Facebook
Twitter
Instagram