The thread started off fine, but as often happens on internet forums, spiraled off-topic rather quickly.

ES designs seem to be very popular in game design at the moment, however I have usually seen them used in the context of a GRAPHIC game with many, many, MANY entities that need to be managed (think particle systems!) where performance can be a real problem when using standard OOP practices.

For an excellent discussion of ES in detail, see the excellent series of articles at T=Machine:

These Entity Systems are basically DATA. You have rows of data in a DB (SQL or otherwise) that are joined by an EntityID - The entity itself HAS NO DATA. The entity and components have no code either. All code is contained within systems that operate on the data. All data is shared within a system. A System accesses only the components that it needs. For example a Movement system would access CLocation, CTargetLocation, CAttrMovementPoints, CCharacterEncumberance, etc. It would not care about CName or CAttrHealth unless those were needed to move the character from one location to another.

In practice, the entity can sometimes be an OOP object, but this object would never change any of the Game Data that is associated with it, it would only have meta methods that make coding easier.

Now for the part I am really interested in - How would something like this be applicable for a MUD? The basic idea seems to be sound - What you deal with, mostly, in a MMO (be it a MUD or a Graphical MMO) is data. In a graphical game, it is often needed to perform a set of operations to large amounts data VERY often - i.e. Rendering sprites, transforming graphics, tracking projectiles or particles in an explosion, etc. These operations can occur every frame, that is, 30-60 times a second. MUDs, on the other hand, are much MUCH slower due to the nature of the interface. I can think of some situations where semi-global oprerations much occur on chunks of 'entities' - Weather, day/night changes, area effects, mob movements, resets, etc. Even so, the volumes we are talking about here are paltry compared to the games that usually employ this kind of ES.

What I find very attractive about Entity systems:

1.) Easy serialization (if everything is just data, you are pretty much done before you start!)

2.) Flexibility. Every object is an entity (basically an ID number) and associated components (data members!) and entities are defined by their components. Thus, to create a room, we have an entity with (roughly) a CRoomDescription component, a CZone zomponent (if the room is located within a larger, ZONE area), a CTerrain component, etc. If you want to create a vehicle, for example, you could take a Room entity aggregation (like a meta-class that collects the components that would define an entity's room-ness) and copy it, adding a CLocation component. then save that aggregation as a 'vehicle'. This is rough and off the top of my head.

What I don't like:

1.) It it HARD to get over OOP. I have a really hard time reconciling with the isea of these monolithic opaque systems that contain all of the code - It just offends my senses as a programmer.

2.) There is a lot of stuff in a MUD that only occurs to one or 2 entities at a time, and this counters some of the benefits of an ES. I am not convinced that this alone makes it unsuitable however.

Now, what do you all think? Is this a worthwhile design strategy for MUD development or do the differences between MUDs and their graphical brethren such that it is a poor fit? Personally, I believe that it can be done, and that it would make it simpler to do something like add graphics to a mud at a later point. I also believe that the answer may lie somewhere in-between - An Entity system (RDBMS based) with a very light and shallow oop system surrounding it to make code easier to write and maintain.

I've been playing around with this. It's nowhere near done, but already some differences between muds and graphical mmo's have come to light which make it less exciting.

First off, MUD's typically don't do very much transformation of objects. Objects in muds tend to stay pretty static until a player or script interacts with them. Given that, it's hard to justify breaking objects up into components to parallelize their processing, because what exactly are you processing? I saw that you mentionned this.

Building a system like this gives you the option of doing some neat calculations over large numbers of objects, but you almost need to come up with things to calculate before you launch into doing it. For example, you could build a MUD that involves large, large numbers of zombie mobiles which all need to be coordinated. But for the typical hack and slash MUD, there just aren't enough objects with variables that you *want* to keep track of in real time. It would be a case of the engine motivating the game, rather then the game motivating the engine.

I guess it's the same with anything. Find a use case, a reason for needing easy parallelization, easy serialization, and objects that are inherently component based rather then inheritance based. The current batch of MUD's don't need it, and wouldn't really be improved by having it, but I think it would be possible to make something much, much more complex. Hopefully, then, it's also more fun :P.

It should be mentioned that graphical things done on the client side like particle engine rendering is irrelevant what the work done on the server side. In actuality, you may have less resources available to you if you're having to do things that typically the client could. In other words, I wouldn't be so quick to say a mud requires less.

Of course, it depends on the specs of the MUD/MMO. But in general (of course, just from my experiences) MUDs tend to perform less intensive tasks. With the graphics, it's not that a graphical MUD is doing more calculations on the back end to show the graphics (that's done on the client side), it's just that the representations are more complex, because a lot more information can be displayed at once.

If you have a graphical space battle MMO, you might be expected to keep track of missiles flying (possibly with their own tracking AI), every ship, asteroids, etc, and the interactions between them, so that they can be shown on the screen to a player flying through space. In a MUD, you could simulate all that, but most of the time you'll just say "oh, flying north through an asteroid field. 50% chance of asteroid impact. It seems you were hit, subtract health". This is obviously lighter on calculation then a trajectory calculation, and makes more sense with a text based interface, because otherwise you'd have to send tons of "Asteroid is X miles from you" messages to give the player a chance to respond.

Edit: I should clarify, I agree with you, and it's certainly possible that a MUD could use something like this, I just don't see the need often in practice

These things could also be implemented by iterating over lists or by using scheduled events. The question I guess is do these (and other similar use cases) justify using an ECS?

Regarding world building tools…I envision a web-based tool hooked into the world db where you can add, remove, modify entities by using components like lego blocks. Rooms, mobs, exits, scripted triggers, etc can all be entities that can be built up. Using templates you can quickly select groups of components to build up whatever it is you need quickly and easily.

Tools can make or break a game, IMO.

I realize that something like this can also become a nightmare of maintenance if the tools are not up to par and that is why I am focusing so much on that aspect.

I think the main issue with ES and other paradigms of this sort is that often they're a solution looking for a problem.

First define your problem. ES came about because people recognized certain problems with more hierarchical inheritance-based systems (not that you can't have hierarchies with ES of course) and an ES is a way to address that. But if you use an ES just because you read about it somewhere and thought it was cool, you're not really making your system any simpler or easier to understand.

I think the LARGEST aspect of this that we as MUD developers can take home is the idea of having everything be composed of Components to ease the design, creation and maintenance of the game.

You would think that, but objects typically aren't composed of much in a MUD, and the benefit from having an ES is structured processing, not the structure itself. Objects in MUDs typically are component based, it's just that the components are usually simple variables (strings, numbers, flags), and they aren't updated frequently.

There are some use cases when you would need to iterate over entities of a particular type where having the monolithic systems would help:- Non-gameplay commands like who, etc.- Saving state- Complex weather systems (as I mentioned before)- Tracking systems (decaying tracks, etc.)- Mob control (Large groups of coordinated mobs.)- World building tools (This is a BIG BIG one!)

These things could also be implemented by iterating over lists or by using scheduled events. The question I guess is do these (and other similar use cases) justify using an ECS?

Apart from building (which isn't really a big issue, building is already pretty easy in most MUDs), most of those systems would be good candidates for an ES on their own, without the rest of the MUD necessarily being aware of it. This comes with the caveat that these systems actually require a lot of calculation, and are used often. If every MOB in your world has a scent and can be tracked, it might be worthwhile. If it's limited to the forest of unusual scents, not so much.

Edit:Another idea for an ES supported system:-Implement a more realistic economy. Give merchants in the game a location component (based on the city they're based in), a list of goods they need, they money they have and the price they'll pay. Use a system to calculate the actual market value of everything in the game, continuously. You can also add in merchant caravans, who can be raided and thus would need to increase their entourage and the prices they charge to merchants. If you want, you can extend the system to any NPC that would reasonably make purchases, by also giving them a list of goods they want, the money they have and the price they'll pay.

It seems to me that there is some conflation of attributes and components here. I'd not consider "location" to be a component. The distinction typically drawn is that an attribute is data whereas a component has functionality.

How is that a component, though? Surely a component is defined by more than simply "this thing has a position attribute". For example, it might define interaction with things that can contain things, or things that can see things in places, etc. Is your XY position truly absolutely nothing more than a data point? If so, then how is it actually fitting into your component system? How do other components interact with it? How is it different from an actual attribute?

By 'actual attribute' I'm guessing you mean of an object. The important thing to realize however is that a component system doesn't need to presume an object at all. The entity is the collection of its components. When you make that leap is when components really shine.

OK, then let me ask you this – in the component systems you've written, do you instantiate an object and add components to it? Or do you create a collection of components (leaving aside for the moment that the collection itself may be an object depending on the implementation)? In the former case I see what you're saying about attributes, but in the latter case the difference is moot.

What difference are you establishing between an object that has components and an object that is a collection of components? Are you saying that in the latter you would have something that is truly nothing but a collection, whereas in the former, you have some attributes, and then some components?

For me objects might or might not have attributes, depending on what is necessary, and then will also potentially have additional components. Regarding location, the choice depends on what else that location might mean. Typically I would have location be an attribute of a component, unless it makes sense for all game entities to have some notion of location.

The point for me of components is to be able to mix and match behavior, not to make absolutely everything into a component. So I'd not make an X/Y coordinate a component just for the sake of it. As I said before, a component (to me at least) is functionality.

In an ES (as described in the articles posted at the start), components are entirely non-functional, so I think you're talking about something different. In an ES, all of the functionality is implemented as systems, which take a vector of components and crunch on it. The system doesn't care about what the component belongs to, just that it has the data that the system needs to do its calculations.

As an example, suppose your game needs lots of pathfinding. You might give your entities a position component and an destination component (or a component that includes both, if that's more convenient). Then you have your system run over all of the pairs of position and destination present in the game, and return a path between them (if they differ). The system doesn't what is pathfinding, it ONLY loads the position, the destination, and the graph. This means that the system can be split off to a separate process, or even run on a different computer. It also means that the process is as memory efficient as it can be, since it only loads what it needs to complete the job. This, compared to a normal object system where you might need to keep a whole deer in memory just to find out where the deer is going to and coming from (because position and destination are a component of a deer, or some superclass).

It gets hairy when you try to talk about objects, because the object in an ES is only ever re-associated when it needs to be. It's not even a collection of components, really, since in memory, your object would be an ID (just an id). If a player wants to see it's description, you look up the description in the database for that ID and return it. If the player wants the position, you look up the position component for that ID in the database and return it. You never hold a complete object in memory unless you have to or want to (for caching or convenience purposes).

The key part of an entity system, though, is that you can easily separate parts of the object from the whole in order to perform calculations.

In this way, an ES isn't really a component system, it's a way of structuring your objects so that mass rapid parallel processing is possible. Is it overkill for a MUD? Absolutely. I don't know of a single MUD that has reached the complexity and popularity where something like this would be of use. Component systems, like you describe, are much more general and flexible, and might actually be usable for a MUD.

Edit: I should mention, if it's not already clear, that probably the most natural home for an ES would be in a relational database. The entity is an id. You might want a table of these and what they're supposed to represent, but it's not vital to the concept. A component is a mapping between an id and some data. All a system does is query some n components, perform a calculation, and update some m components which may or may not be the original components.

You can also model it as a set of hashmaps, one for each component. The keys to the hashmaps are entities, and systems work the same except querying becomes difficult.

That's all and ES needs to work, anything else is just convenience for the programmer. You could write a wrapper which grabs all the data for a particular object so that you can work on the whole thing instead of just parts, but that's above and beyond what an ES is.

Fair enough. I'd lost that original context in my first reply; my bad.

I agree that this isn't really a component system so much as a storage layout. Components to me, at least as they apply in a MUD environment, would be less for storing data (although obviously data is often needed) and more for indicating interaction. For example, an entity might have a "weapon" component indicating that you can wield it and bonk people with it. An entity might have a "container" component indicating you can put things in it, look inside it, etc.

How you actually store this is a separate question to me; you could store them in a list of components, do something like what you describe where everything is fully "exploded" (for want of a better term), etc.

I agree that you can probably implement a more traditional component system over an ES, and you might want to, but as always the question is why do you have an ES in the first place. If the answer is "I want to split pathfinding to a separate server because I have too many npc's and users who are making it lag, and I only want to transfer the pathfinding data, not the whole object, and it would be really nice if getting that data was easy", then you're getting close to an actual use case. Again, for most MUDs, that isn't their primary concern.

I'm not sure that you'd need an ES as you describe for that either, to be honest. You could transmit the coordinates from the node that has the object, not the whole object. Of course the receiving end needs to know about the world graph one way or another, but I don't feel that full decoupling of object and object attributes is necessary for the particular example of pathfinding. I agree with your general point though.

I think that's true, but only if you have easy access to nodes. If you have to loop over the objects to find their locations (or the nodes to find the objects), then you haven't really gained anything. In an ES, it would be easy, because you would maintain a list of (id, pos, dest) at all times that can instantly be serialized and sent to the pathfinding server.

You don't need to of course, and I wouldn't implement an ES that can only do this. Ideally you have many systems which have to perform fairly involved calculations on a large sets of contiguous data. It's kind of hard to find problems which fit this model that aren't contrived, especially when talking about MUDs.

It's kind of hard to find problems which fit this model that aren't contrived, especially when talking about MUDs.

Well, I certainly agree with that re: MUDs. :tongue:

One thing I like about MUDs is that they're a great testbed for very complicated algorithms, because you have a relatively simple world to work with without needing to make graphics for things etc., even if the algorithms are completely inappropriate for the particular MUD.