Hi!
Hi,
Whatever, in these kind of games, there's a virtual world, filled with
creatures and items, a hero has to explore and to interact with. It seems quite natural to model this world using an object-oriented paradigm. Yes, but the world is made of Objects it is not object-"oriented". Then is natural to use Smalltalk (an environment or objects).
However, everybody has different preferences
and the originator of the ORCS project, Fabio d'Allesi, started with the idea to create a whole new language. Smalltalk is not a language, it is an environment with objects. Then why to create a language if we want to have objects?
The system shall consist of a development environment and a runtime system.
In evolutionary systems, is important that evolution never ends... Then always the system can evolve (runtime = development, past < present).
Smalltalk, the syntax can be learn in one day,
but Smalltalk, the language and it's environment needs a long time to learn. The major problem IMHO is the fact that you cannot use Smalltalk (even for some very basic tasks) unless you've understood the whole idea behind it. I've been working with Smalltalk, and I have played Role games. Learn the basics to play role games is more difficult to learn that Smalltalk. The number of alternatives for a game like Runequest if very bigger that the number of classes in a commercial Smalltalk. With Smalltalk, we the Smalltalkers have the same problems with people that RolePlayers have. There are people that like role playing, and people that NOT. :-( The percent of people that don't like role playing is equivalent to the % of people that don't like Smalltalk. And I personally think, that the cause is the same. Most of the people are not prepared to work in a virtual world (with no real objects). Most of the people does not aggre to be sub-creators (as undestoood by J.R.R. Tolkien in "Tree and Leaf: including the poem <<Mythopoeia>>")
Basically, my idea
is to change the language to give the people something that looks more familiar to them and which still has the semantic of Smalltalk. Provably you must to build more "interesting" objects to role-playing builders.
This is a very important aspect of a language because the syntax
is the first thing new people have to interact with. And you always make the product for the customer. And in the case of the ORCS project, the typical customer is the spare-time programmer who'd never manage to create a whole game on its own but who has some very cool ideas, he'd like to add to the existing game. I have done (in 1990) a simulation system with components that must be built with a custon made GUI and behaviour of the component was specified by users (in Smalltalk). The components were connected to build a train locomotive. Each component was programmed and tested in a workbench. The users learn in a VERY short time the mesages they needs to use. They were "ocasional" users and they didn't know about objects. The only thing you must do to guaranty the exit is to build a good framework, not a powerfull language (build power objects, not power languages). Let the language be the language of any object (and evolve with them).
I'd like to reuse all development tools of Squeak without great changes
because this would give us a very powerful development environment for FREE. Please, don't work to have less. :-)
The language would need a parcel concept similar to VisualWorks. ASAIK
Squeak has still the old-fashioned monolithic image model. Is anybody working on this issue or at least can estimate the work needed to add this to Squeak? Andres Vallaud (sqrmax@cvtci.com.ar) and me (alereimondo@sugarweb.com) are working on it; but I don't know when we will have something ready to be publicated.
The language would also need namespaces (every modern language should have
them, IMHO), but that's easy to add while translating it to Smalltalk. I'd however like to see Smalltalk-based NS, too. Again the question... NameSpaces implemented only as a mechanism to hide objects is simple to implement (see ). But if you think in NamesSpaces as Spaces of diferent instantiations of the VM running with different GC Spaces, needs to reimplement a huge part of the VM.
Ale.