AHLL requirements
Anders Petersson
bineng@bespin.dhs.org
Wed, 29 Sep 1999 23:57:27 +0200
Requirements for AHLL to do it's job (in no particular order):
* Must be a HLL
Low-level issues such as memory managment is not relevant inside the game,
and could even threaten the security of the server. There's more arguments,
I guess, but I don't think I have to convince anybody on this point.
* Access to types as objects
For the ability to handle whole aspects, generalize things to eg. dimensions.
* Security thru "positive access grantings"
You can't access what isn't explicitly granted you. Partly same reason as
previous item, partly to enforce a security police (the only thinkable, I
believe).
* A handle to an object is necessary to do anything with it
To create some kind of "physical barrier", plus security. (You can't reach
for something in the other corner of the world)
* Safe pointers
'Pointers' to make it possible to reference existing objects (like what
places are connected to each other), 'safe' to avoid user-caused bugs.
* Nested objects
To enable compound data types. (Like a place or a physical 'thing' with
attributes like weight, etc.)
* Typed language
To enforce necessary restrictions. Without this, more or less anything
would be possible and the world would collapse to a soup of elementary
particles, so to speak.
* Represent code as data, and have a way to execute the same
This is necessary to enable code to exist inside the system, to at all
enable any wider flexibility.
* A way to "simulate" objects, and control them from the outside
Instances of basic data types (eg. integers) ought not be represented
inside the system (imagine 2^32 integer objects...). To do the same with
elementary functions is impossible. In addition, events must have a way to
flow between the game and the users.
* Visible namespaces
To let players see their choices, generally seen. (This is on a low level.
For example, there must be a way to see what one is carrying.)
* Persistant objects
Obvious reasons; who'd like the world to disappear when you turn away?
* Object cloning
If types are objects, you simply *need* cloning to instantiate objects.
----
This is what I've come up with so far. There are probably more items to add.
Let's hear what we can agree about these very basic requirements. If our
opinions differ much on this, there's more than the language on stake; this
is about the AKOS vision.
binEng