Skip to content

Commit

Permalink
Rewrite rest of html files to use same format as index
Browse files Browse the repository at this point in the history
  • Loading branch information
@seankelly
seankelly committed Jun 8, 2009
1 parent 0e1433d commit 3b2553d
Show file tree
Hide file tree
Showing 3 changed files with 200 additions and 152 deletions.
106 changes: 61 additions & 45 deletions bugs.html
View file
Expand Up @@ -4,62 +4,78 @@

<head>
<title>TAEB - Bugs and Limitations</title>
<link rel="stylesheet" type="text/css" href="style/main.css" />
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
</head>

<body>
<h1>TAEB - Bugs and Limitations</h1>
<div id="main">
<h1>TAEB - Bugs and Limitations</h1>

<p>
It's too big. Expect about 100-200 MB of RAM usage for a
fully-instantiated main dungeon, double that if it manages to
instantiate Gehennom. Sometimes it uses much more for poorly
understood reasons.
</p>
<p>
It's too big. Expect about 100-200 MB of RAM usage for a
fully-instantiated main dungeon, double that if it manages to
instantiate Gehennom. Sometimes it uses much more for poorly
understood reasons.
</p>

<p>
It's too slow. Depending on number of changed tiles, amount
of monsters, etc, it can be as much as about 1 second to
process input and 4 more for the default AI to decide on a
move (on sorear's 2GHz P4). Admittedly, it's hard to critique
bot performance much faster than that, but it does make
debugging late game issues harder, and is a blocker for
<a href="future.html#ih3">Interhack 3</a>.
</p>
<p>
It's too slow. Depending on number of changed tiles, amount
of monsters, etc, it can be as much as about 1 second to
process input and 4 more for the default AI to decide on a
move (on sorear's 2GHz P4). Admittedly, it's hard to critique
bot performance much faster than that, but it does make
debugging late game issues harder, and is a blocker for
<a href="future.html#ih3">Interhack 3</a>.
</p>

<p>
The mechanisms used to synchronize with NetHack are all a bit
fragile and occasionally (1 in 10<sup>5</sup> level) report
end of output prematurely. Not enough to motivate serious
improvement efforts, but enough to produce the occasional
unreproducable glitch.
</p>
<p>
The mechanisms used to synchronize with NetHack are all a bit
fragile and occasionally (1 in 10<sup>5</sup> level) report
end of output prematurely. Not enough to motivate serious
improvement efforts, but enough to produce the occasional
unreproducable glitch.
</p>

<p>
Teleportitis causes item data to be incorrectly updated if it
triggers during item actions (eating, pickup). Auto-recovers
on sight, but still warning spam.
</p>
<p>
Teleportitis causes item data to be incorrectly updated if it
triggers during item actions (eating, pickup). Auto-recovers
on sight, but still warning spam.
</p>

<p>
Group combat code is still pretty lousy in Behavioral, it has
to rely on Elbereth far too often, and it doesn't even abuse
it properly. Tends to die to captains and the like a lot for
obvious reasons. Priorities are a little tricky near trolls,
it prefers resting over dealing with the corpse, but there's
no obvious safe way to fix this.
</p>
<p>
Group combat code is still pretty lousy in Behavioral, it has
to rely on Elbereth far too often, and it doesn't even abuse
it properly. Tends to die to captains and the like a lot for
obvious reasons. Priorities are a little tricky near trolls,
it prefers resting over dealing with the corpse, but there's
no obvious safe way to fix this.
</p>

<p>
Behavioral tends to oscillate in situations where a desired
action is impossible, or becomes harder to see as it gets
closer; the standard example of this is a monster in a
corridor, Behavioral approaches at an angle for safety, loses
sight to the monster, forgets that it is there, goes back to
do something else, and repeats indefinitely.
</p>
<p>
Behavioral tends to oscillate in situations where a desired
action is impossible, or becomes harder to see as it gets
closer; the standard example of this is a monster in a
corridor, Behavioral approaches at an angle for safety, loses
sight to the monster, forgets that it is there, goes back to
do something else, and repeats indefinitely.
</p>

<p><a href="index.html">Back to TAEB Main</a></p>
<p><a href="index.html">Back to TAEB Main</a></p>
</div>

<div id="sidebar">
<div id="nav">
<ul>
<li><a href="http://taeb-blog.sartak.org">Design and development blog</a></li>
<li><a href="history.html">History</a></li>
<li><a href="design.html">Design</a></li>
<li><a href="future.html">Future directions</a></li>
<li><a href="bugs.html">Bugs and limitations</a></li>
<li><a href="http://sartak.org/code/TAEB/">Browse source</a></li>
</ul>
</div>
</div>
</body>
</html>
<!-- vim: set tw=70 si: -->
152 changes: 84 additions & 68 deletions future.html
View file
Expand Up @@ -4,83 +4,99 @@

<head>
<title>TAEB - Future Directions</title>
<link rel="stylesheet" type="text/css" href="style/main.css" />
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
</head>

<body>
<h1>TAEB - Future Directions</h1>
<div id="main">
<h1>TAEB - Future Directions</h1>

<h2><a name="announce">Announcements</a></h2>
<p>
</p>
<h2><a name="announce">Announcements</a></h2>
<p>
</p>

<h2><a name="monster-tracking">Monster Tracking</a></h2>
<p>
Currently, TAEB completely forgets about monsters when they
are not visible. It rediscovers them on the next turn and
generally acts correctly, but not being able to track monster
state from turn to turn puts annoying limitations on our
tactics. If we could somehow track monsters the way we track
items, TAEB would potentially be a much better fighter.
</p>
<p>
Most significantly, it is impossible for TAEB to know if a
monster is awake; since it never remembers seeing monsters
before, it is forced to conservatively assume the monster is
asleep. If a monster is potentially asleep, we can't use
combat tactics like waiting in a corridor - we would wait
forever! This is an especially annoying problem because
valkyries start with Stealth, so zoo monsters are very often
asleep.
</p>
<p>
Unfortunately, monster tracking is hard. Monsters move around
much more than items, so in general it's impossible to know
<i>which</i> monsters are the same as monsters on the previous
turn, especially in pack situations. We really want to
support tracking packs, because pack monsters are a major TAEB
killer. Also, monsters have many hidden variables, and
testing in combat doesn't work very well.
</p>
<p>
The best candidate solutions are based on variations of
<a href="http://en.wikipedia.com/wiki/Bayesian_inference">
Bayesian inference</a>, deciding for each monster a
conditional probability of being something we care about.
This is a fair amount of work, though, and little progress has
been made.
</p>
<h2><a name="monster-tracking">Monster Tracking</a></h2>
<p>
Currently, TAEB completely forgets about monsters when they
are not visible. It rediscovers them on the next turn and
generally acts correctly, but not being able to track monster
state from turn to turn puts annoying limitations on our
tactics. If we could somehow track monsters the way we track
items, TAEB would potentially be a much better fighter.
</p>
<p>
Most significantly, it is impossible for TAEB to know if a
monster is awake; since it never remembers seeing monsters
before, it is forced to conservatively assume the monster is
asleep. If a monster is potentially asleep, we can't use
combat tactics like waiting in a corridor - we would wait
forever! This is an especially annoying problem because
valkyries start with Stealth, so zoo monsters are very often
asleep.
</p>
<p>
Unfortunately, monster tracking is hard. Monsters move around
much more than items, so in general it's impossible to know
<i>which</i> monsters are the same as monsters on the previous
turn, especially in pack situations. We really want to
support tracking packs, because pack monsters are a major TAEB
killer. Also, monsters have many hidden variables, and
testing in combat doesn't work very well.
</p>
<p>
The best candidate solutions are based on variations of
<a href="http://en.wikipedia.com/wiki/Bayesian_inference">
Bayesian inference</a>, deciding for each monster a
conditional probability of being something we care about.
This is a fair amount of work, though, and little progress has
been made.
</p>

<h2><a name="newais">New AIs</a></h2>
<p>
Behavioral, time-tested as it is, is starting to show signs of
having reached the limits of its extensibility. Each new
behavior added slows down the bot additively, and in
interesting environments like quest levels we may take several
seconds to decide on each move. Can Behavioral be saved or
will a new, more stateful AI like <a
href="planar.html">Planar</a> take the torch?
</p>
<h2><a name="newais">New AIs</a></h2>
<p>
Behavioral, time-tested as it is, is starting to show signs of
having reached the limits of its extensibility. Each new
behavior added slows down the bot additively, and in
interesting environments like quest levels we may take several
seconds to decide on each move. Can Behavioral be saved or
will a new, more stateful AI like <a
href="planar.html">Planar</a> take the torch?
</p>

<h2><a name="ih3">Interhack III</a></h2>
<p>
One long-term idea for the TAEB core is to use it to power the
next-generation of <a
href="http://interhack.us/">Interhack</a>. This would
result in an Interhack with ability to semi-automate arbitrary
tasks, extremely flexible Perl scriptability, and a queriable
model of the entire dungeon, enabling an interface to rival
Crawl. There are two main blockers for this. First, TAEB has
to support all NetHack commands and game mechanics. While old
Interhack could get away with simply passing through
unrecognized commands and output (nearly all of it), that
would wreak havoc with TAEB's world model. Second, TAEB needs
to become much faster; on a good day, TAEB processing lag is
on the order of a third of a second, more than twice the
network lag from San Diego to Helsinki.
</p>
<h2><a name="ih3">Interhack III</a></h2>
<p>
One long-term idea for the TAEB core is to use it to power the
next-generation of <a
href="http://interhack.us/">Interhack</a>. This would
result in an Interhack with ability to semi-automate arbitrary
tasks, extremely flexible Perl scriptability, and a queriable
model of the entire dungeon, enabling an interface to rival
Crawl. There are two main blockers for this. First, TAEB has
to support all NetHack commands and game mechanics. While old
Interhack could get away with simply passing through
unrecognized commands and output (nearly all of it), that
would wreak havoc with TAEB's world model. Second, TAEB needs
to become much faster; on a good day, TAEB processing lag is
on the order of a third of a second, more than twice the
network lag from San Diego to Helsinki.
</p>

<p><a href="index.html">Back to TAEB Main</a></p>
<p><a href="index.html">Back to TAEB Main</a></p>
</div>

<div id="sidebar">
<div id="nav">
<ul>
<li><a href="http://taeb-blog.sartak.org">Design and development blog</a></li>
<li><a href="history.html">History</a></li>
<li><a href="design.html">Design</a></li>
<li><a href="future.html">Future directions</a></li>
<li><a href="bugs.html">Bugs and limitations</a></li>
<li><a href="http://sartak.org/code/TAEB/">Browse source</a></li>
</ul>
</div>
</div>
</body>
</html>
<!-- vim: set tw=70 si: -->

0 comments on commit 3b2553d

Please sign in to comment.