I couldn't agree more, which is why I'm persisting with this even though it obviously is way, way too much.

Sorry for the double post, I just thought I should mention this, because I wasn't aware of it before.

On the wiki, there's an approach that puts the code in the components and uses message passing to communicate between them, which seems like it's much closer what David Haley was talking about. I feel concerned about the performance of such a system, though, depending on how far the messages propagate. I might have to write a POC to see if it's a reasonable approach or not. It certainly seems like it would be easier to implement then splitting a MUD into series of systems.

I think that the performance there depends on the intelligence of the message dispatching. My understanding of EVE Online's implementation is that it's a massive system of message passing along channels, and it seems to do alright in terms of managing load etc. :smile: But yes, I agree with you, a straightforward, "overly literal" implementation of this could get pretty gnarly and bog you down in message passing rather than message processing.

Eve also has a huge cluster to process all the messages :biggrin:. Not to say that they haven't done it intelligently. Eve's system is pretty impressive.

Yes indeed. So I wonder what would happen if you took a game that scaled to thousands and thousands of players, and brought it down to a more typical MUD load of a hundred or so at most. The issue with message systems, I've found at least, is that the performance needs aren't always linear; if you double the messages you're handling you're not necessarily doubling the processing time, you could be increasing it more than that. But it's pretty hard to put hard numbers on this when just guesstimating… still, it would be interesting to see.

Stackless Python channels pass a python object reference from the sender to the receiver - message passing this is not. This is the problem with trying to understand a game system which you only hear about, you have to fill in the gaps yourself with your imagination - much like reading the text in a MUD :wink:

Passing an object is not the same as passing a message? Is not messaging a channel, err, sending a message?
I guess I'm not sure what distinction you're drawing there. Passing a message is just sending information. Whether that information is sent as a big encoded byte stream, an object reference, or a zeta-gamma space ray is immaterial – you're still dealing with a bunch of things that are communicating with each other and where said communication drives the logic of your application.

Isn't message passing the term for communication via unshared data? i.e. sending it would pass a copy. Erlang I think is defined by this mechanism.

http://en.wikipedia.org/wiki/Message_pas...

"Message passing […]. In this model, processes or objects can send and receive messages (comprising zero or more bytes, complex data structures, or even segments of code) to other processes. "

I think the shared status is irrelevant.

You might be right, but that Wikipedia page seems pretty unclear to me.




No wonder people say don't cite wikipedia :rolleyes:

The Objective C designers would be unhappy to hear that their message passing system, used for calling methods and distributing the calls to other objects if the callee doesn't implement that method, is invalid.

Citing wikipedia has to be a step up from citing…nothing?

Well, some people might use message passing to mean strictly the communication of shared resources. I believe that the more common definition is that it's just invoking some process on a thing that can receive communication. If you look at a bunch of OO texts, for example, the terms "invoking an object method" and "sending the object a message" are used interchangeably. Quix gave a good example with Objective C which takes from SmallTalk. There are plenty of other examples where the main performance bottleneck in an OO system is "message dispatching", i.e. figuring out which block of code to invoke based on the various objects involved.

And the Wikipedia definition you cited, while fairly confusing and misleading, can still be interpreted to accept either a copy of data or a shared reference. Copying a reference is basically sharing the memory, after all. (I.e., pass an object by reference by passing the pointer by value.)

But ultimately it doesn't really matter. We can agree on some definition of terms; the point I was making is that this process of sending all these messages around (or whatever you want to call them) is where performance can get tricky.

I was trying to sort out where this argument is coming from, and I found this handy link (which is a wiki, so ymmv): Message Passing.

A component system could reasonably be implemented in either case, though I had an async version in mind, since most OO languages implement the smalltalk version of message passing, and it isn't as interesting to talk about.

The author seems to have great difficulty in explaining the concepts.
It's terminological gobbledy-gook.

The Artemis implementation doesn't appear to back it up either.
See Entity.java

private int id;
	private long uniqueId;
	private long typeBits;
	private long systemBits;
	
	private World world;
	private EntityManager entityManager;

Seriously, this is a Flyweight object?!

The main problem with the article, I think, is that he avoids using metaphors that make sense, because they come with baggage from other languages. For example, a template is a perfectly good way of describing a collection of components, but he calls it an assemblage to avoid confusing it with C++ templates. It makes the whole article pretty unreadable until you get used to the weird terminology he's using.

I admit it took a few readings to get a good idea of what this was, and what it's for.

The Artemis framework does seems to have some questionable design decisions. I just gave it a cursory glance, so I might have missed something, but it doesn't seem to implement any of the optimisations that an entity system should make possible (Systems running in parallel, only processing entities that a system cares about). It looks like the "flyweight" (lol) entity is just for convenience, as the code the framework is based off of has removed it in the latest version (using just an int). I don't think it's required. The other fields are there to avoid using a database - they're implementation specific.

Care to tell us why?

No. I kindof did already, but I"ll expand…

In a "traditional" language like C, code is executed in sequence. You write code, the compiler generates assembly, assembles it into object code, and the linker produces an executable/shared-library. Your code starts at a "well-known" entry point and does what you told it to do, basically by moving the program counter around and shuffling data between CPU registers and memory locations.

In a "message passing" language, like Objective C or Smalltalk, this still happens but rather than your code explicitly calling exact functions in specific objects, you can think of a function call as more of a request to have this code executed. The message is the function and arguments that are to be run along with the originating object, and it is delivered to the object referenced in code. That object can either execute a matching method in itself OR choose to delegate that message to other objects which it knows might be able to handle it.

Since Objective C relies on this system of message passing to handle inheritance and polymorphism, the language designers would probably feel a bit miffed to learn that they system they designed and refer to as message passing is, in fact, not valid by the definition being tossed around above, since the entire object is NOT passed around in total.

I agree with the sentiment that tools are very important and have invested a significant amount of time in developing those. In retrospect, a lot of my efforts (e. g. porting all save states to write to a standalone MySQL server, developing a web-based world builder UI, etc) seem to have been moving the game as a whole down the "component model" path.

One thing I want to point out (and I think you can already see it coming) is that you don't have to rewrite your game server to make it a component within a larger structure, open to other components or custom interfaces. By adding a standalone database (if you don't already use one), you are equipping it with the ability to read to and from an online "message board" to which you can plug other components, e. g. the game website, tools to help players, builders, etc. I've written quite a few of those already, and they have been well-received.

To sum up, while I'm not sure that writing the server code itself in a modular way would be all that beneficial, I do think that there is a lot to gain from treating your existing server as a component in a larger system.

Why wouldn't writing server code in a modular way be beneficial? There's legitimate places for highly coupled code…but a modular approach for a mud server sounds like the sweet spot of the bat.