I'm really, truly sorry I haven't commented on this yet. I had intended to, but then it slipped my mind. Now, I've got a midterm in a few hours, but I'm going to comment now anyways, because I know if I don't it'll slip my mind again. 
First, a comment on TheOneTrueGod's comments:
TheOneTrueGod wrote:
-First thing I see: exporting variables. You shouldn't do this... All the variables should be managed inside the class. If you absolutely must get the value from inside the class, make a function called "Get*****" (Where ***** is the name of whatever you want to 'get'). If you have a lot of variables that you plan on exporting this way, I generally make a "GetVar (s : string)" type of funciton, and the parameter is which one I want to 'get'.
Exporting variables is essentially the same as creating reader methods for them. In a good language, the shortcut used would be fine. Turing, however, has an inconsistency in that exporting a variable in read-only scope doesn't actually prevent one from getting write access to that variable. Rather, Turing will complain (give a warning) if you try to write to a "read only variable", but it will do it. So, in the case of Turing, writing your own getVar type functions would be good.
I would highly recommend you stay away from a generic getVar(s : string) type function, though. The reason being that this function contains within it the code that determines which variables are made accessable. Then how would you document it? We should know exactly which properties of our objects are readable from the outside world, and this approach to creating reader-methods undermines that because it is hard to document. On the other hand, we don't even need any documentation if you use methods like getX and getHealth. Another bonus is that some languages (Ruby, for example) provide a method that will return an array of all the methods associated with an object. This would allow us to see all the getX, getHealth type methods, and we don't even need to go to the documentation at all!
Now, here's something in your code to clean up: Look at the Non_Mage_Enemy and Mage_Enemy classes (that right there is an issue, actually: you should follow a consistant style within your code. You've got some classes in lower case with underscores, some with first letter of each word in upper case with underscores... I suggest DoingAllClassNamesLikeThis, method_names_like_this, vars_like_this, CONSTANTS_LIKE_THIS). Anyways, looking at the Non_Mage_Enemy and Mage_Enemy classes, you've got a level_up procedure that looks mighty similar. It looks the same, to me. The only way the level ups could differ is with different values for the variables skill_chance, speed_chance, etc. But you can change those variables' values for each object. Take this example:
| code: |
class Foo
export yar
var bar := 5
proc yar
put bar + 1
end yar
end Foo
class Bar
inherit Foo
bar := 3
end Bar
var p : ^Bar
new Bar, p
p -> yar % outputs 4
|
In this code, Foo is your Enemy class, and Bar is a Mage_Enemy. So you can see that changing the variables value within a child object will indeed modify the behaviour of that object's methods. And so it should.
As already mentioned, the inventory system needs some work. That checking the 0..3 slots is a problem. Hardcoding is bad, for many reasons. One such reason is because I, the reader of your code, don't immediately know if you even are checking all the slots, or if there are more slots you aren't checking there. |
so here it is: have fun! (I hope your reading this Cervantes)
.