30 Nov, 2011, plamzi wrote in the 41st comment:
Votes: 0
Runter said:
Plamzi said:
while I'm not sure that writing the server code itself in a modular way would be all that beneficial


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.


It may very well be. I'm just not sure about it and I don't readily see the places where you'd reap benefits, so here's an opening for someone to cite specific examples (I think many of the ones provided thus far are not strictly enabled by a component model). I have written 4 apps in Objective-C and done a good bit of work with web services and interfaces talking, but I've got 0 hands-on experience with code that internally follows a component model so no wonder my imagination falls short. All I did was look at the picture below and tried to picture a MUD server written this way:



The only thing I could think of was that it may make "unplugging" and refreshing the world data component at run time easier. But then it occurred to me that if your world is in an external database, then you already have a world data component - you just have to decide how much to copy over vs. how much to request on demand, with obvious tradeoffs and benefits to either.
30 Nov, 2011, David Haley wrote in the 42nd comment:
Votes: 0
It should be obvious why you would want your code to be easy to refactor and decouple. You might decide to change something, and if everything is already clean and easily separated, you will have a lot less work than if everything is tightly integrated.

Are you likely to completely swap out subsystems on the fly? No, probably not, at least not like you might swap out a credit card service (but……..). Still, you might decide to expand your scripting system (or change it entirely, but let's just talk about expanding for now). If things are well-written, with appropriate abstractions, it's a whole heckuva lot easier. If you don't believe me, go try adding multi-parameter, actual functions to mudprog in Diku and then see how much you would have liked them to have written that code just a tiny bit more nicely. That's actually a great example of something that started out super simple, but was expanded to something more complicated but without any real thought, and it's not a giant mess of barnacles.
30 Nov, 2011, plamzi wrote in the 43rd comment:
Votes: 0
David Haley said:
It should be obvious why you would want your code to be easy to refactor and decouple. You might decide to change something, and if everything is already clean and easily separated, you will have a lot less work than if everything is tightly integrated..

…Still, you might decide to expand your scripting system (or change it entirely, but let's just talk about expanding for now). If things are well-written, with appropriate abstractions, it's a whole heckuva lot easier. If you don't believe me, go try adding multi-parameter, actual functions to mudprog in Diku and then see how much you would have liked them to have written that code just a tiny bit more nicely. That's actually a great example of something that started out super simple, but was expanded to something more complicated but without any real thought, and it's not a giant mess of barnacles.


Surely you're not saying that a component model is the only way to produce "clean and easily separated" code that anticipates expansion? If so, you're going to have to make your case to the thousands of people who have been writing clean, modular code since the dawn of programming.

I can see how staring at that diagram encourages a coder to think in a modular way but I don't see anything that compels them to. Any of those component blocks can be filled with code that is just as sloppy, opaque, and inflexible as anything ever produced by a human being…
30 Nov, 2011, Idealiad wrote in the 44th comment:
Votes: 0
Though plamzi said 'modular' up thread I think he basically meant 'component system'.
30 Nov, 2011, Nich wrote in the 45th comment:
Votes: 0
plamzi said:
I can see how staring at that diagram encourages a coder to think in a modular way but I don't see anything that compels them to. Any of those component blocks can be filled with code that is just as sloppy, opaque, and inflexible as anything ever produced by a human being…


It wouldn't matter about the contents of each component. It's the interface between them that matters. If you're already at the stage where you can remove one component and plug another in its place, then your code is pretty modular. It's inherently more modular, regardless of whether the contents are a mess or not, just for the fact that you could code another component to the same interface and replace the old one with the new one without breaking functionality. This as opposed to a spaghetti ball of code. There's definitely other ways of achieving the same goal. But I don't see how you can look at a diagram like you had, and claim that is isn't modular. It's almost the definition of modular.

Edit: Now, maintainable, that's another story, but at least you can just code a new component without worrying about breaking the rest of the system. You don't *have* to look inside any of them, just program to the spec/interface.
01 Dec, 2011, David Haley wrote in the 46th comment:
Votes: 0
plamzi said:
Surely you're not saying that a component model is the only way to produce "clean and easily separated" code that anticipates expansion?

I was responding to what you said, not what you meant. :smile: As Idealiad said, the word you used, and were replying to, was "modular".

plamzi said:
I can see how staring at that diagram encourages a coder to think in a modular way but I don't see anything that compels them to. Any of those component blocks can be filled with code that is just as sloppy, opaque, and inflexible as anything ever produced by a human being…

Well, sure. No design document or diagram will ever "compel" somebody to implement it nicely. (Of course, it's an exercise in silliness to spend time generating design documents for a clean system and then implement it completely differently.)
01 Dec, 2011, Ripley wrote in the 47th comment:
Votes: 0
Nice thread. Thank you everyone for your contributions!

Here is something I found that might spur some more discussion:

http://code.google.com/p/propcompentitys...

The project contains code for a MUD server as an example of a property-component-entity system (PCES).

A PCES is an interesting type of entity/component system and I think it could be applicable for this domain. Basically, entities have a 'property' container, I have also seen this described as a 'blackboard', where data to be shared within the entity is stored. Components can listen to that data and react when it changes - Classic observer stuff. The components ONLY contain code that works on this data and have no state themselves. It seems to me that this is really not radically different from the example I gave from T=Machine, just abstract the logical-collections of components out into systems that work on the entity's data. This particular implementation seems to be a bit easier to wrap one's brain around if you are used to standard OOP practices.

Of significant interest to me is the fact that the above example uses lua to implement the game code for the MUD, while the component engine is implemented in C++. This is the design I am working towards with the base I am working on so it is very nice to see a -real- example in the MUD domain.

What is also interesting is the way the author broke down components (although I don't necessarily agree!) Check out the Scripts directory in the code and you can see the lua code for the Head component for example, or the Hands component.

I also wanted to share this link: http://www.oddrosemedia.com/wiki/index.p...

This is another type of scripted ECS more like the one I posted from T=Machine utilizing scripting. However the link just provides an overview and many questions are still outstanding (like system communication!).

So far the google code site has the most complete and interesting example I have found of an entity system in action within the MUD domain.
02 Dec, 2011, Tyche wrote in the 48th comment:
Votes: 0
Nich said:
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.


I had a strong negative reaction to these articles. The articles are riddled with inconsistencies. However, I found the Scott Bilas slides here, which are well worth reading.
02 Dec, 2011, Idealiad wrote in the 49th comment:
Votes: 0
Ripley said:
Nice thread. Thank you everyone for your contributions!

Here is something I found that might spur some more discussion:

http://code.google.com/p/propcompentitys...


Did you get a sense of how he prioritizes components consuming events? Do events always fall through, is there some logic to stop event propagation based on the component, and so on?
02 Dec, 2011, Ripley wrote in the 50th comment:
Votes: 0
Idealiad said:
Did you get a sense of how he prioritizes components consuming events? Do events always fall through, is there some logic to stop event propagation based on the component, and so on?


Well he is using a framework called ClanLib - And it appears that it has 2 separate event handling systems. The one dealing with the properties uses signals/slots, and while he used ClanLib I would rather use something lighter like libsigc++. You can use accumulators within signals to stop event propagation based on the slot's return value - I am not exactly sure what you mean by 'events falling through'.

ClanLib's signals are not as sophisticated as libsigc++ - They can never have a return value other than void in the implementation I have looked at.
03 Dec, 2011, Tyche wrote in the 51st comment:
Votes: 0
The concept is a response to the problems of some class-oriented programming languages (Java and C++) with static typed, static inheritance implementations.
Object-oriented languages that implement run-time dynamic polymorphism have been created and largely solve parts of this problem, flexibility and rapid online programming.
They don't solve the performance problems that may exist with "massively-mulitplayer" games. I think they are quite workable for "medium-mutiplayer" games like many muds
(mMORPGS - just made that up ;-) ).

Bilas talk is about implementing the Composition pattern via aggregation under the covers, and designing a domain language which makes use of the component abstraction.
I've talked about here that in some programming languages the notion that "Inheritance is Composition" leads to an entirely different solution.
http://www.mudbytes.net/index.php?a=topi...

—–
Aside: At one point I had all the posts on this particular topic tagged, but unfortunately the tag system is broken.
40.0/51