Slashdot Mirror

I would think they would be using LambdaMOO database software.

Yes, it does appear that you (Blizzard) have made a conscious decision to go for slick playability over user-designed content. Can you confirm this, or would you like to see more player cities and the like? This is something that does seem to be hugely lacking in MMORPGs compared to text MOOs. Given various speculations about the "wikification" of games, how long do you think the top-down content model can thrive?

As far as I know, there is no non-free networked object-oriented database. Relational databases are nice, flat files have their place, but OO databases are quite useful too; I've built a few webapps using this. Thanks, Pavel Curtis!

Several programming languages exist only in a free version, or the non-free versions are derivatives. Scheme, Squeak (Smalltalk based), Python, and Perl are just a few that come to mind. Perhaps this clown would say that these are all derivative works from Fortran, or somesuch, but it's a stretch.

True, but LambdaMOO's server code is now hosted on SourceForge. I think they require some sort of open source license for all hosted projects.

The LambdaMOO admins occasionally make dumps of the live Lambda database and give away the core bits.

With regards to MUDs, I can heartily recommend LambdaMOO. It has a very simple object-oriented programming language, and unlike many MUDs, it's all interpreted, so you can program new stuff live with the server running. The server also automatically parses player commands with English-like syntax (direct objects, prepositions, and indirect objects) and passes them to the verbs (functions).

The downside compared to MUDs is that LambdaMOO is designed primarily as an educational/social environment, so any RPG functionality will have to be coded from scratch, although there are some ready-made RPG systems available on the web.

Something else to consider is shareware RPGs that allow user-designed scenarios. Blades of Exile, written by Jeff Vogel and available for Mac and Windows is a classic 2D tile-based RPG with a very simple graphical editor that allows you to create new scenarios. The author is also working on a sequel, which will use a newer isometric engine and feature a C-like scripting language for greater flexibility. Ambrosia Software publishes Escape Velocity, a 2D space trading game with a modular plug-in system that allows users to expand or modify the game universe or build a total conversion from scratch. These games were originally written for the Mac, where plug-ins are made very easily using ResEdit; the third game has recently been ported to Windows, and I'm not sure how plug-ins are made on the PC.

At any rate, this all depends on whether the kid in question is more interested in the technical challenge of programming a game and getting it to work, or in the design of challenging battles, puzzles, or whatever. I imagine someone who wanted to experiment with different level designs, enemies, weapons, and how they balance would get discouraged pretty quickly if they had to first spend days writing and debugging the basic engine behind it, and vice versa.

This purpose has been adequately served for several companies I'm involved with by using a MOO or other MU*s. My bias may be revealed by the fact that one of those corporations is in fact dedicated to running a particular MOO.

However, I have to say that it satisfies all of your requirements and provides a great deal of flexibility for the future as well. It has its own internal programming language (affectionately but not officially known as C&) which allows you to modify basically everything without requiring a restart. It has full support for TCP/IP and file IO, and though the binary support leaves something to be desired, it is quite possible to write a fully functional HTTP server for example.

Warning: Shameless plugs ahead. Disclaimer: I don't make any money from my pimping of MOO.

Although I don't know of something that does specifically for what you're asking for, in my experience a MOO makes a good platform for conducting official meetings. Everyone logs in, you can talk to one another (privately if you wish), and logging is easy.

Plus, it's decently easy through the MOO's C-like internal programming language to code up a motion/voting system in a certain room so that everyone can head in there for a meeting and have everything handled and logged correctly.

More info about MOOs can be found here and documentation is plentiful on the web. Additionally, I could probably even give you some pointers if you were to drop by my MOO.

but MOO is a great language!

What about Lambda?

Anyway, this is the first truly novel application of the peer-2-peer networking philosophy, albeit via a centralized server - and as such it is not very ... interesting. Now, if only more people would try and do something more ambitious, in this kind of general direction.... - this kind of thing could be used for many more things apart from merely chatting and wandering around some simplistic graphics.

Perhaps the answer lies with the addition of a MOO-like language, (perhaps Java?) - where each object in each person's 'home' would have some embedded code and thus could be interacted with in a meaningful way. There could also be repositories of commonly used objects, that would NOT rely on the distribution of a new src/exe of the main application for this type of p2p. (yeah, I guess kind of having the app update/recompile itself ala emacs style) - but that is off the mark:

What a real distributed server/computing application would enable people to do, is to collaborate on projects without relying on each one of the involved parties to have the software that would be necessary for the collaboration. The software iteself could work on a distributed level. Hm.

The is no clear separation between the environment and the program.

There is a confusion between a pointer and the object itself.

There is no finalaization (destruction)

There is a single memory model for instances (heap) versus, for instance, C++es minimum of 4 (heap, stack, static, member-of-another-object)

Why do you want multiple programmer-visible allocation models?

There is a single model of memory management (garbage collection over ALL objects - lose them and the memory eventually returns - sometimes after a sudden "freeze" of the program). It is automatic and can't be replaced with improved handling of special cases.

IMO one of the best multiple model systems I've used is in Modula-3, where normally all references are "traced"---automatically managed. But modules marked unsafe could manipulate untraced references and do all that pointer arithmetic that C jocks think they can't live without. Of course, there was a lot of peer pressure not to mark your modules unsafe unless there was a good reason, which made people carefully consider whether they really had to do risky things to get their part of the job done to the required performance standards.

Let's get to particulars. Squeak's collector is generational. Object memory is divided into "young" and "old" objects. Since the vast majority of objects are used once and forgotten, we don't need to scan "ALL" the objects to do most collections. Eventually, yes, we need to do a full collect, but this is fairly rare. You're right that this is problematic for realtime apps, and I don't know what people do about it. But given the frequency my Linux and W2k boxes decide to go thrash a little due to background tasks, I suspect it's acceptable for other apps.

Btw, the GC stats from the random image I pulled up claim 6507 minor GCs at average 9ms, and one full GC (which I explictly triggered) at 627.0ms.

I don't really feel like getting into the whole "GC is good/bad" flamewar; there are a lot of subtle issues on both sides, and I don't think I can argue either side with authority.

There is no strong typing.

You're right, in that there are not tools commonly in use to allow programmers to specify that arguments must conform to particular protocols. (You don't want to say "is an instance of class Collection" because subclassing is not subtyping; you want to say "must support the add: and remove: protocol"). That being said there are various type inference systems people are playing with.

The environment is hostile to multi-programmer cooperation.

Smalltalk's changeset tools are better than nothing, I guess. Other people in the thread have mentioned various multiprogrammer tools for Smalltalk, like ENVY; I haven't used any of them, but I think they're the rough equiv of CVS. That's not good enough.

Extreme Programming originated as a methodology for supporting multiprogrammer collaborative projects in Smalltalk, so it's not like the environment keeps you from doing this, especially if you have decent policies in place.

Once the Squeak people come up with a good module system, I suspect the collaboration issue will significantly improve.

As far as language-level support for multiple programmers goes, the best examples are mud implementation languages; I work on MOO, which might be a good place to mine for ideas.

The language design allows incomplete programs to appear to run, encouraging the release of incomplete and buggy programs.

The Squeak environment will complain loudly at you if you compile code that references method names that aren't defined anywhere.

Those two paragraphs are just a flail at what I'm guessing you mean there. With such a vague condemnation of Smalltalk systems and the people who use them, I don't know how to respond to particulars. If you meant something else, please follow up.

Methods (member functions) of subclasses (derived classes) are executed during construction of the superclasses (base class), invalidating the debugging of the superclass (base class) constructor.

IMO there aren't any entirely satisfactory constructor systems in any language I know; I've been bitten by them all. C++ goes to great lengths to try to address these issues, and as a result ends up with a great deal of conceptual complexity, and that cure sometimes feels worse than the disease.

I could go on.

Smalltalk is useful for throwing together a program to run once to get an answer to a question or sometimes to test an idea. It is totally unsuitable for the construction of mission-critical or commercial-grade applications.

Since the problem here is to create an environment for writing code you want to DISTRIBUTE to a large number of people who will use them without being inside their development, it's an amazingly wrong language choice.

I'm on vacation from Squeak. I got burned out banging my head against some of the modularity issues, and frustrated by how hard it was to build "conventional" user interfaces in it. I can zap out a simple button/entry/list/dialog box UI in Lua FLTK much faster than in either of Squeak's two UI systems. I'll probably return though. There's something really attractive about Squeak's environment, goals, and its incredible development community.

i've been noticing in this forum a lot of "i feel your pain" and "it's just that way, deal with it" kind of comments. for background, i'm a 19-year-old co-op (kind of an intern thing, and the differences don't matter for this discussion) at MITRE, a company that's been around for some time. i mean, our department secratary was hired the same year my mother was born. yeesh.
well anyway, i'd like to add that it really is a personal thing. some people have it ingrained in their heads that young whipper-snappers don't know anything. unfortunately we young whipper-snappers often don't respect the vast experience of those older than us, just because we may know some new technologies and tricks and such.
i came into my company with the respect of some of my colleagues because they had seen the work i had done on a project. management tends to be a bit harder to win over. many are under the impression that people as young as myself are expendable and unreliable. there is also a prevailing opinion that we're just workmonkeys and the *real* hard stuff should go to those with a few more years under their belts. this does change, unfortunately with time. i fear that the atmosphere is still one in which one has to prove himself consistently before people wake up and think "hey, this guy doesn't suck". after nearly a year with this company, i still get my ideas nixed simply because someone "higher up" wanted it done another way
so what is the point of this comment? i'm not sure. but give people- all people- the respect they deserve. and don't be a know-it-all-31337-h4x0r-dewd, either. let people know that you know how to do things, and do them well, but don't be surprised or offended when there are conflicting views.
finally, as you go through your technical career, treat those younger than you with the respect you ask for now. nothing at all against the current generation of programmers, but perhaps technical culture can be changed.
-----

Cool :)
---

Lots of stuff works on the devices. tclsh was an easy port, but awfully large to just have around without a good reason. I ran the LambdaMOO server using JHCore. Robert Coie actually built a self-hosting gcc.

Of course, without any CF access yet, anything that won't fit on the 4M ramdisk is run over the 115kbps SLIP/PPP link on NFS...not the speediest disk you've ever used.

> and they are working on getting the GUI running (it seems to be already running on at least one of the developers' machines).

The demo works on my E-15 too. It's pretty much stock microwindows, with new touchpanel calibration code.