-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathBUGS.TXT
114 lines (94 loc) · 5.58 KB
/
BUGS.TXT
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
KNOWN BUGS LIST
The following are bugs and discrepancies that still exist in
Archetype version 1.0 . The letter after each number indicates
what kind of problem it is:
I : A solution already exists but has not yet been implemented.
D : There are several solutions, but a best solution has not yet
been decided.
K : Knotty problem. An idea for a solution exists but it requires
sweeping changes to the design.
N : Not a problem. These were not part of the inital design for
Archetype and I am not in a hurry to rectify them; however,
someday it would be nice to add these features.
1. (I) You cannot use a verb as any part of a noun phrase or the parser
will get confused. For example, if you have an object named
"start button", a verb named "start" and a verb named "push",
the phrase "push the start button" will actually be collapsed
into <push start> <button> instead of <push> <start button>.
This is because the parser entirely ignores the words "the",
"an", and "a" at the present.
2. (D) Typing a verb all by itself when the verb requires a subject
and perhaps a direct object should result in the message
"I don't know what <verb> means all by itself." However, when
the player is in a hollow object or piece of furniture, the
verb is considered to apply to the object or furniture itself;
e.g. "leave" by itself when sitting on a couch means "leave
the couch".
3. (I) When saving a game state, the game's vocabulary is not saved.
If the game does not dynamically change the vocabulary (by
re-opening the parser) this is not a problem. However it does
limit the adventure writer's freedom if they wish to dynamically
change the vocabulary.
4. (K) The interpreter uses much more memory than it needs to; about three
times as much. This was done for speed and ease of coding. Even
a large adventure only uses about 200K, though, so I have been
wasteful just because I know I can get away with it.
5. (N) There are no such things as lists or arrays in Archetype. You can
make a linked list (in fact the interpreter does, for the BEFORE
and AFTER handlers) using the "create" and "destroy" statements,
but the language does not have any native vector type.
6. (N) There are no such things as arguments when sending messages. As
a result, useful recursion is limited. This was done on purpose,
a sort of experiment to see if a useful language could be written
with dataless messages. The answer is a qualified "yes", since
every method can tell who the sender was and what its attributes
are.
7. (D) There are no such things as real numbers. Integers only.
Like (6) above, this was done as an experiment. It can be
changed in the future, of course.
8. (K) You cannot have anything like a .o file, where the source is
unavailable but the intermediate binary can be linked with others
to make one executable. The most useful place for this is the
INTRPTR.ACH file. It's regrettable that it has to be recompiled
every single time you compile your adventure. Furthermore, with
.o files you could make and independently test an adventure in
sections.
9. (D) A nicer debugger than the existing one would be good; namely one
in which you can interactively view and change the contents of
attributes. You can't right now.
10. (I) Sadly, an expression such as
a +:= 2
is interpreted exactly the same as
a := a + 2
so that no time is saved with the first form.
However it is recommended that you use the first form because in
the future, it will be executed faster.
11. (N) An expression such as
s &:= expr
will leave s UNDEFINED if expr becomes UNDEFINED. This is often
not what the programmer expects, but it does make sense if you
think about it.
12. (D) Sometimes error messages pertaining to the first declaration of
an object or type will be flagged after the entire type or object
has been declared. Technically they should occur as soon as it
is possible to tell there has been an error.
13. (N) No such things as "local variables". Attributes kind of look like
it in terms of syntax, but they are global (anyone knowing your
name knows your attributes) and they are static.
14. (I) I/O is a good deal slower than it has to be. This is the
fault of the inefficient SAVELOAD.PAS module, which invokes
an I/O routine for each atomic piece of the adventure, rather
than caching them in a buffer and dumping them to disk all at
once. Since program writing and reading is done infrequently
compared to the other run-time operations, it was left unpolished.
15. (I) Include files may be only in the current directory or the
adventure file's directory.
16. (I) The automatic paging that Archetype does for screen output
assumes 24 lines (egads). Sorry.
17. (I) The word-wrap output engine does not recognize the
special "escape" characters such as \n yet, making them (sigh)
nearly worthless except as part of the prompt.
18. (I) The compiler does not prohibit declaring more than
one "main" object, nor declaring the same attribute
or method twice in an object. It ought to, as the
results may surprise the programmer.