# RPG Engine Design Using Component Entity Subsystems

This topic is 3991 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

0  1  2  3
4  5  6  7
8  9  10 11
12 13 14 15

We would then define a zone for each region. For example:
Zone  Includes regions
0     0,1,4,5
1     0,1,2,4,5,6
9     4,5,6,8,9,10,12,13,14


##### Share on other sites
Hi Brendon, since nobody else is responding I'll have a go.

Component/entity systems

I think you've picked a system that isn't well documented. I doubt you're going to find much beyond the links you've shown above, because this approach is by no means a standard and implementation details can vary wildly. Any time you ask about "overall architecture" you're entering a realm where there are few standards and little agreement.

Component entity systems are quite popular on these boards recently, as you may have seen from recent posts. However there seem to be 101 different ways of getting different components to work together, how to organise them in structures, and so on.

Incidentally I don't agree that "Entity Systems are the future of MMO development" as I don't think there's anything specific about 'entity systems' (a term that's too vague anyway) and MMO games. The problems they solve are pretty much the same problems everybody faces - how to generate large quantities of content efficiently. There's nothing new here - people have been saying "prefer composition over inheritance where possible" for ages. It's just that it's taken a while for other people to listen. Sometimes the composition is built into a master object, other times the composition is more abstract (eg. any component with a property of "actor" and a value of "354" is part of the Jim the Goblin actor), but it's essentially the same thing.

Quote:
 The problem i see comes with RPG's etc where there is a large continuous world through which the user may walk and only a number of "regions" in the world are active and loaded into memory at a point in time. In this case i dont think it is possible to have all the world entities loaded into ram (Minus their meshes etc) and being updated. It would just be too much data...

But the situation here is no different to any other system - if you have too much data, you need to get rid of some and just keep what's important. It's not unique to component based systems. Having said that, you're probably overestimating how much memory it all costs. It may not be something you ever need to worry about, or it may be something you can easily solve just by storing your components more effectively.

But, should you find that memory is a problem, paging things in and out based on distance is a perfectly workable approach. If you find it easier to do it by zones as you've specified, feel free, but essentially it just comes down to "only deal with entities that are nearby". I think you're overcomplicating the system somewhat below - what's wrong with simply saying "activate objects in the current region and any adjacent regions"? As for how to handle objects that may have moved when they didn't exist, so to speak, you can give them some sort of schedule and place them at wherever you'd expect them to be at the time when they're woken up, so to speak. But, it's probably easier to keep them in memory at all times, and merely spread out the updates in this manner, so that distant NPCs are only updated infrequently.

Story FSMs

I think a finite state machine is not a great way to depict a linear story. The use of FSM implies recurring events which is presumably not what you want. A more traditional flow chart approach is better here (or one of the similar UML diagrams for plotting activity).

I prefer to think of these things as logical constructs. To win the game, you must meet one or more prerequisites. They in turn are made possible by meeting their own prerequisites, and so on down to a trivial level. Each prerequisite can be considered a boolean flag, and actions taken in your game are checked to see if they set a given flag, and if so, dependent flags can be checked to see if they are now met, etc. When you meet one, there may need to be some code executed to open up new paths, create new objects, etc. But essentially I think it can be distilled down to events that set flags, routines for checking flags based on boolean expressions of other flags, and code that runs as a side-effect of setting such flags.

Seperation of Game Story from Implementation details

If you've done your components properly, or indeed done your design properly whether you use components or not, this Should Just Happen™. Your story system should be able to say "Move 'Horse10' to location(10,45)", and at no point does it care about whether there's a model attached, or whether it has animations or sound effects, or anything. Those are problems for the renderer and sound engines, who will look up model and sound components associated with "Horse10" when doing their job.

Now, when you're talking about how to communicate the appearance of Horse10 to your art team, I think that should just be done separately. That's more about documentation than game design as such. Plan out the NPCs (or buildings, or terrain, whatever) you'll need as part of the design, and then communicate that data to your artists separately. If there's some sort of formal database or checklist everybody can refer to, that's great. Don't overcomplicate it though - it's just a case of doing a bit of planning and a bit of communicating, and then since everybody's using the same entity names it should work ok.

##### Share on other sites
Thanks for the information. I am thinking of doing a simple prototype using Crystal Entity Layer. I think i might do as you suggested and just keep all entities in memory, actually I may make a small example and estimate how the memory usage will scale to a full sized game.

I really dont like optimising too early, but something like this may be a large change to make at a later point in time. I will consider the idea of keeping all entities in RAM and see where it gets me. Its a whole lot simpler.

It is a good point on the FSM's too. I think i might go away and have a play with these ideas for a while.

Thanks,
Brendon.

##### Share on other sites
If you want to experiment with paging inactive entities out to disk, and re-creating them by loading when necessary, then feel free. Just be sure to think about the pitfalls, such as what you're going to do if the player teleports half-way around the world and you suddenly need to load hundreds of NPCs, what to do if you need to query information from an entity that is currently paged out, how to handle NPCs that would travel from an inactive zone to an active zone as part of their AI (but can't, because they're inactive), and so on.

##### Share on other sites
Quote:
 Original post by KylotanIncidentally I don't agree that "Entity Systems are the future of MMO development" as I don't think there's anything specific about 'entity systems' (a term that's too vague anyway) and MMO games. The problems they solve are pretty much the same problems everybody faces - how to generate large quantities of content efficiently. There's nothing new here - people have been saying "prefer composition over inheritance where possible" for ages. It's just that it's taken a while for other people to listen. Sometimes the composition is built into a master object, other times the composition is more abstract (eg. any component with a property of "actor" and a value of "354" is part of the Jim the Goblin actor), but it's essentially the same thing.

Why not? IMHO MMO's are purely about data manipulation, and entity systems (or component systems?) are about encoding logic as data, so the two go rather well together.

##### Share on other sites
Quote:
 Original post by redmilamberWhy not? IMHO MMO's are purely about data manipulation

Because I disagree with that. All computer programs are 'about data manipulation'. There's nothing about MMOs that makes them more or less so than any other program.

##### Share on other sites
Quote:
Original post by Kylotan
Quote:
 Original post by redmilamberWhy not? IMHO MMO's are purely about data manipulation

Because I disagree with that. All computer programs are 'about data manipulation'. There's nothing about MMOs that makes them more or less so than any other program.

Theoreticaly speaking, yes - of course they are. But only at a very abstract level (at that same level, all programming languages are identical, and the only language we actually "need" is the lambda calculus; but practically, they're all very different, and we "need" a wide variety of them).

But in practical terms, there is a huge difference between a typical enterprise "business system" written with JavaBeans, where 99% of the code is of the form:

Take data
Simple conversion of that data from one format to another
Simple algebraic check
Update a flag somewhere

and a typical videogame, where the code is much more evenly divided between:

low-level I/O
complex algorithms to achieve specific effects

##### Share on other sites
Quote:

I'll assume that last line is the main point you're getting at. The thing is, large scale batched loading of data is trivial. 95% of what you load in will come in either standard formats, or optimised formats you made yourself.

The quantity of other data for an MMO is often not really any bigger than a typical single player game, partly because it has to perform like a single-player game on the client, and also because you're trying to minimise CPU usage on the server. Some of it will work well as part of a component scheme, but it will work just as well under any number of other well-explored schemes.

MMOs have several major issues; managing entity data is really not a significant one of them. Component based systems can be useful, but the problem they solve is not one either specific to MMOs or even prevalent in MMOs.

##### Share on other sites
Quote:
Original post by Kylotan
Quote:

I'll assume that last line is the main point you're getting at. The thing is, large scale batched loading of data is trivial. 95% of what you load in will come in either standard formats, or optimised formats you made yourself.

Nope.

Here's a simple statistic to give an idea of what I'm getting at: the typical successful MMO generates somewhere in the region of 100Gb of data every 24 hours: combats, deaths, trades, quest actions, NPC interactions, respawn locations, inventory updates, private messages, ... etc etc etc.

(I can't remember who (if anyone) has publically declared the actual number for their game, but you can approximate it for yourself fairly easily, especially given that with many games it's very easy to see data they MUST be keeping simply to implement various of their in-game systems, and on top of that several developers have declared what data they're data-mining)

Somewhere between 10% and 100% of that data needs to be kept forever, AND it's generating that much EVERY 24 hours.

So, you know, data is pretty central to MMOs, on a scale that simply doesn't apply in normal games. IMHO.

##### Share on other sites
That's flat statistical data. There is no "batched loading of data" in this case because you write it out to disk, or a database, and pull back just what you need, when you need it. It's a completely different area to what is referred to when discussing component/entity systems, which is interchangeable components that build up composite entities.

1. 1
Rutin
29
2. 2
3. 3
4. 4
5. 5

• 13
• 13
• 11
• 10
• 13
• ### Forum Statistics

• Total Topics
632959
• Total Posts
3009461
• ### Who's Online (See full list)

There are no registered users currently online

×