| 28.Aug.1998 |
Completed a part of the
entity handler. Now it handles
correctly atoms (integers, strings), objects
and methods. Still undone the code dealing with
arrays and cameras. Preliminary tests ran flawlessly, but I think the overall handler can be optimized. I will be thinking about this during this weekend. BTW, to perform more accurate and complex tests I need to code a few other parts of the kernel, so I think it's better to start working on the internal framework interface and the object manager before optimizing things. I will be working on these from next monday, and I should have *far* more things to say in a week or so. |
| 24.Aug.1998 |
The dynamic code linker is complete. Today I am going to perform some tests on the linker, then I will be moving on to coding the entity handler. The entity handler is another part of the ORCS! kernel which should handle the insertion/removal of entities into objects and classes. In ORCS!, an entity represents an incarnation of almost anything, ranging from objects, classes, single actions to arrays of data, keyed-arrays and more complex data/code sets. The way these entities are arranged should ensure some interesting features such as:
After all, being able to easily analyze and modify an ORCS! system while it's running it's one of the basic goal of my current ORCS! kernel design. |
| 19.Aug.1998 |
After weeks of planning, testing and preliminary writing
of small programs and sets of simplified routines to check the
real possibilities of such a complex system, today I started
the serious coding of the ORCS! kernel. First step: writing the dynamic code linker. This could take quite a while, but I expect to have a complete dynamic linker ready within the next week. For those who may be interested in this, the dynamic code linker is a fundamental section of the ORCS! framework kernel, and will handle the insertion/removal of microcode chunks into a running ORCS! environment (a game). Keep in mind that everything in ORCS!, from objects and classes, to events, actions, reactions and anything else always contain hybrid sets of data and active microcode. Dynamic code linking is done pre-compiling every active code segment into position-indepent microcode sets, and then creating libraries of code sets to be loaded & executed dynamically while the game takes place. Thanks to this feature, it is possible to modify, edit, recompile, extend and refresh single entities without having to recompile an ORCS! game (or even just quit and restart it). It all happens transparently and dynamically. Also, this will allow the construction of gaming environments where not only the data itself grow and evolve dynamically, but (most important) where also the active-code does. |
| 17.Aug.1998 |
Started the first tests on dynamic code loading, via
ELF/shared-object programming techniques. This reminds
me of techniques which I was using with the glorious
AmigaOS libraries more than 12 years ago. Testing hybrid data+PIC-code file load/link/exec routines, which should form the dynamic linker, which is a part of the ORCS! framework kernel. These routines will be used to load classes or objects, linking them to a running system. Every object will be a hybrid set of interchangeable data and functions, forming both the "interface" and the inner core of an object or class. By the way, I tested some key features to see if the idea can be set down in code, and the system *works* smoothly. |
| 15.Aug.1998 |
More planning on events: started working on a nice idea to handle
cascades of effects/events/actions and reactions in a nice way,
through what I called "cameras". Basically, you can build a sort of entity which is a "camera" making one object "look" to an other object or to a part of it. Once the target changes, a triggering message is sent to an event-handler, and this can start a chain of other triggering effects. Should be coding and testing this before the end of the month. More on the protogame: it *should* be something in the classical roguelike-style, ala Angband. Just, *extremely* more complex, where "complex" doesn't necessarily mean "more difficult" but likely "more intriguing". On the other hand, *extremely* really means something zillion of light-years away. |
| 08.Aug.1998 |
[by the way, my birthday, ohoo, I am 29 now. Ugh.] Started planning more complex issues (sets/subsets of objects, slots [general-purpose object handlers], action/reaction schemes, events). At the same time, started planning the first game prototype. I need it to actually test the maximum complexity a standard machine (say, a Pentium200 with 32M of RAM) can handle before seeing performance collapse. I will be working on the language, the ORCS! kernel and the protogame at the same time, but I will leave the actual compiler for later. So, it looks like the first game prototype will be out long BEFORE the ORCS! compiler. I will try to write the game in a mixed Orcol/C language, converting the non-C parts to C manually. The final ORCS! games will be written totally in Orcol, and the Orcol->C conversion will be done totally by the ORCS! compiler. |
| 04.Aug.1998 |
Finished writing a first, preliminary system of
routines able to create/destroy/handle classes,
objects, messages. The sources sum up to about 40k of ANSI/C files. Initial performance tests: the system can handle up to half a million of simple message delivery and handling cycles. Every cycle includes looking up a given target object, building up the stack of objects composing the message, passing the message to the target object, resolving the message, pushing a result object into a reply stack and passing the reply stack back to the message sender. |
| 26.Jul.1998 |
Finished planning the object-oriented framework and
some very basic features. Started coding some routines to handle classes/objects and messages, using ANSI-C. I am compiling the sources on more environments/systems, including:
|
| 12.Jul.1998 |
After about one year since its beginning, on August 1997,
the ORCS! project comes to a stop. Read the public announcement posted to the Roguelike News here. |
| 08.Jul.1998 |
Completed the initial design for the basic object-oriented
framework which should be the core of the
ORCS! kernel. Started planning how to build basic object-oriented features (object construction/destruction, object/class lookup, message handling, exception handling). |
| 04.Jul.1998 | Started working on a new set of specifications for the ORCS! object-oriented framework, taken the best ideas from the old ORCS! preliminary-specification-draft written last year. |
| 02.Jul.1998 | After many months of inactivity (both mine and of the developers mailing list), I started working on the ORCS! project, with the decision to stop talking about it and start coding it on my own. |