🚀 go-pugleaf

Amit Jayant Patel (amitp@owlnet.rice.edu) wrote:
: In article <Bw1M74.1o7@agora.rain.com>, donp@agora.rain.com (Don Park) writes:
: |> I think you have some good ideas as to how to make objects interact
: |> with the world. My problem is how to effectiveely save their state
: |> on a moments notice and reload to where the program left off and
: |> restore the state of all objects.
: |> 
: 
: Can't we just save the binary to disk?  Oops, almost... let's see, with
: C++, we can be nasty and do this:
: 
: 	void * vtbl_lookup[100];
: 
: Then for each type of object, assign it an 'object number' and put its
: vtbl pointer (yes, yes, it's very unportable) into the array; then save
: its object number and the chunk of memory assigned to the object (other
: than the vtable pointer) to disk.  
: 
: To restore, look at the object number, create a new object of the proper
: type, and pluck the disk image for the object and put it into memory
: (past the vtable pointer).  
: 
: Yes, it's evil & unportable ... :(

  [ lots of code deleted ]
 
: I don't think Turbo Pascal w/objects or C++ is very well suited for
: this game.  Here's what I want to see in the game language:

No kidding. :)

: [ lots of "ambtious" ideas :) deleted ]

Laugh. Ok. Let me talk about the system I am writing.
 
: zzzz
: <wake up>
: What was I thinking?  There's no way we could do that... or is
: there?

Grin.
: Something like TADS/ADVSYS, except for object-oriented ultima-style
: games?
: 	:) :)
: 
: 			Amit

OK. On and off for the last 3 months I have been writing a MUD driver.
For those that don't know MUD's, it is sort of like a multi-player
text adventure. All the following is built for text only. It could be
very easily adapted for graphical if you take as a given that the
majority of CPU is used for graphics..



I am writing a distributed, multitasking, OO, persistent Mud driver.
Very ambitious, but I have been encouraged by the success so far.

My solution to a LOT of problems is to make it interpreted. Argh! you
say! The speed loss!!!! argh!!!

Well, to be true it is slower. On my 486/33 (running linux), it clocks
about 800,000 instructions per second. Doesn't quite compare with C. 
It actually interprets a stack language. The source code (written in
an OO language made up on the spot, and extended as I want) is
compiled to this stack language, which then gets interpreted.

Because it is interpreted, I can VERY easily and cheaply multitask. I
need to stack only trivial context (basically, the 'self' object, a
stack, and an IP). This all goes in a struct that I hold a pointer to.
A context switch is a matter of pointing to a different struct.

Everything is an object. Object consist of a struct looking like...
	struct object {
		int class;
		struct object *a[0]; 	
		}

Where the size of 'a' depends on the class of the object. My system
currently uses reference counting for garbage collection. I am looking
for better ideas on this.

As all my pointers are to structs, they are all aligned to 4 bytes
boundaries, so I use the lower 2 bits to hold flags. In particular, 01
indicates that the object it is pointing to is actually on disk. If a
pointer to an 'on-disk' object is followed, it is automatically
brought into memory. There is a process that runs in idle time that
uses a clock algorithm to swap objects back out to disk.

My 'everything is an object' philosophy means that int, strings,
booleans et al are all objects too, so some code can get compiled very
cleanly. The compiler (currently in the process of being re-written)
compiles code like..
	while (j)
		j = j -1;
to something like.
	push j
	nif +3  /* if the value on the stack is false jump forward 4*/
	push lvalue j /* push address of j */
	dec	/* the C -- operator. Treats value on stack as an */
	 	/* lvalue , and subtracts one */
		/* leaves new value of lvalue on stack */
	if -1   /* if value on stack is true jump 1 back */
Where possible method calls on objects are staticly bound. This means
that the address of the method is compiled into the code. Otherwise
the name of the method is compiled in, and it is looked up at run
time.

The system supports re-compilation of code on the fly (a la LPmud).

The becomes applicable to a general game system when you realize that
the stack language can get VERY powerful. I.e. one of the 'basic'
instructions in the language runs a routines that traces every object
in the system checking the reference counts. Instructions to move a
sprite et would be trivial.

The basic point here is that a system like this is VERY easy to
program, and can be modified at RUN time. Class methods can be
added/subtracted, or just re-written (given some constraints to
ensure consistency). You can even have objects that re-write
themselves on the fly. These are all advantages of being interpreted.
The program that an object is running is another 'class' of object,
and can be manipulated on the fly.

Obviously I have left out a lot here. There are issues dealing with
concurrency, and distribution that are very messy to solve
(distribution probly isn't something you need to worry about for a
game, and that simplifies things a LOT).

For those interested in muds, the persistent systems means that a mud
like LPmud, that DOESN'T get reset when the server gets reset is a
possibly. If you damage a building, it stays damaged until someone,
or something fixes it. :)

Any comments, ideas, Q's etc post or mail me.

Michael.

Ps. The system as it currently stands is only barely started. It can
compile and run objects. It can multi-task them. Updating code in
classes isn't yet written. The distributed nature isn't even started.
Object swapping is worked out, and supported where it needs to be, but
not implemented. Basically is a currently a compiler, interpreter,
about 7 basic classes (Int, String, Bool, Iohandle, Class, Object, and
some internal ones). The multi-tasking is sketched in (enough for
proof of concept :), and thats about it. With exams looming, not much
work will be done on it for a month or so.