• Advertisement
Sign in to follow this  

RPG Engine Design Using Component Entity Subsystems

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all, I have recently been thinking about how RPG's manage game entities and am looking for some advice on how others do this. Also where could I look for information on the internet and in books about this topic? On the whole i am looking for information about "overall architecture" for RPG game engine design that makes use of component entity systems. I.e. how do we create/manage/control the game entities? Most of the documents and books i have read look at individual components of game development but i am having difficulty finding any useful resources on the overall system design. Below i have tried to structure some questions/ideas of the game management ideas i have had which others might be able to help me understand if there are better or more tested way of doing these things. I have provided what my current thoughts are on the topics and asked questions relevant to them. Sorry if this is a long post, I hope others may be able to get something out of this as well as myself. ---- Context : Component entity systems ---- I have looked at a few sources about game object structuring. As such I have been looking a lot at component Entity systems and some implementations of them. Below is a short list of some resources i have read through: Entity Systems are the future of MMO develpoment Evolve Your Heirarchy CEL Design Mangalore Game Entity Open Game Engine I think these systems can be quite simple (relatively speaking) to implement and define worlds in when designing level based games like FPS's. In these situations much of the game design can be off-loaded into the level design where entities and the properties that define them can be "part of the level" as data, along with behaviour scripts etc. One example of such is Crystal Core: Crystal Core This makes use of a small program called celstart which contains the code, and crystal core along with a number of other celstart games are defined entirely as game data. From my reading this is a good principle to follow if possible. ---- Dynamically Adding/Removing entities from a RPG ---- 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... So this would introduce the idea of entities being dynamically added/removed to/from the active world as the player moves throughout it. Now i have some thoughts on how i would achieve this but was wondering if others know of information on tried patterns/ideas on how to achieve this? From what i understand based on the Crystal Entity Layer implementation (Not exactly it is my understanding of how they would do this but i have not looked at the code yet), the world could be broken into what i will call regions and zones. Each region has a corresponding zone, and each zone contains a group of regions. For example: Say we have a square 4x4 world where each number below identifies a region:
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
You would define the list for all zones: 0 - 15. The above is just an example of a few. If the player is located in region 0, then that makes zone 0 active. So all entities that are in this zone (I.e. entities located in regions: 0,1,4,5) are made "active". So as the player transitions from one zone to another some entities are made active and others are made inactive. A number of entities do not just stand still in the game. So this would require that each entity contain a list of regions in which they MAY be in at any given point in time. This information is stored in a database of some kind along with other entity details. If an entities list of possible regions includes any regions that are active, then the entity is loaded from the database and updated every frame using the standard event processing loop. If for example we have a horse entity that travels from regions 0 - 3 in a straight line once every game day and say the player is in region 7 thus activating zone 7 (Including regions: 2,3,6,7,10,11). Then we would create in memory an entity instance for that horse and ask the horse entity where its location is. If its entity is in any of the active regions,then its 3D mesh and other data is loaded and it is added to the players viewable world. Otherwise the entity just remains in memory being queried every now and then weher it is until it is actually located in the players active zone or none of its list of regions it can "possibly" be are active any more. I guess that is how i would approach the activation and loading/saving of entities dynamically. Does this sound suitable? ---- RPG Stories implemented as FSM's ---- The other thing i would like to ask about is how do people usually implement the story based Finite State Machines (FSM's) in these kind of systems? Crystal Entity Layer, has a simple FSM(quest) property that can be added to individual entities. However to me this seems more suitable to "small" quests and manipulation of behaviours. Not for implementing the main story line and entities over a world scale. It would be difficult to manage a decent story using small FSM's for each entity as there is just so much that could go wrong in the design of the FSM's and how these "autonomous" FSM's interact to produce a coherent game. Is this low level FSM type system how most RPG's will implement their story? I was looking at the Adonthell plot design guidelines document: Adonthell Plot Design This basically describes how to draw up a FSM for a plot in their RPG. I was looking at this and thinking well what they really need is a Story FSM design tool that shows their nice graphs, but also has the low level data that is used for directly modifying the entities in the game world. Again, the dialogue design is the same sort of thing. Do there exist FSM design tools that are used for implementing the plot and dialogue and also for documenting it in formats like this? When i was thinking of an entity manager, i was thinking it would have a database defining the entity types and also in the database would be a set of FSM's that define the story of the game and how to manipulate the entities. So going on from the dynamic loading example above. Lets say we have a basic story: * Horse-thief in region 12 is having trouble finding horses and cant move anywhere so the players task is to send any horses they find to him in sector 12. * Player meets horse somewhere in regions: 1,2, or 3 * Player throws a rock at horse * Horse runs home (region 0) and now changes the route it usually follows to now go on a path through regions: 0,4,8,12. This is in order to avoid the place where the nasty man threw a rock at it. * Player is given key by horse-thief for next stage of story This could be implemented using a number of smaller FSM's for each entity. So the horse entity has a FSM that is simple: * start state: Behaviour - follow path from region 0 to 3 each day The Horse thief entity has a FSM: * If not seen horse give spiel to player * If seen horse and player asks give him key The rock entity does not have a FSM, it is simply manipulated by other entities (The player), just like the key. Now, this will work fine for a small story like the above, but is this suitable for the larger story (Especially if an entity has multiple parts to play in the game)? ---- Seperation of Game Story from Implementation details ---- One final section i was wishing to discuss was wether it is feasible to separate the story/FSM's from the implementation details such as the artwork, sounds, graphics/sound/physics engine used etc? I am interested in trying to design a RPG Story engine that manipulates entities using string identifiers. So the engine would know that there exists a visual component called "horse_visual" but it honestly does not care if that is a 3D mesh or a 2D sprite or a description displayed in a text only game. So the database defining the entities would just identify items using strings and not actually reference the type of data other than say: attach "horse_visual" to entity horse and locate horse entity at position: "horses_start_pos" giving the entity behaviour: "horse_follow_path_0_1_2_3" These "string identifiers" could also have development information that describes the identifier stored in a development database like. horse_visual: "Is a horse of 10 hands in height of XXX breed is a brownish colour..." For NPC's this could be used to define their history, visual appearance, character etc that could be used by the art team for creating the mesh or sprite and audio data, animations etc. However this actual data which is specific to whether it is a 2D or 3D engine can be stored elsewhere in a different database. It is not really a part of the story itself and not required by the story FSM's. Seperation like this would allow development of the story to run parallel/separate to the development of the art etc. I can foresee a number of difficulties to this approach, but i was wondering of anyone has any experience with such a thing? Anyhow, I hope this post was not too long. I am very curious to see how others would approach these problems and the overall game management. Especially if you have experience writing any RPG's or have found some good resources on these topics. Thanks, Brendon. [Edited by - bcosta on November 3, 2007 5:33:35 AM]

Share this post


Link to post
Share on other sites
Advertisement
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by Kylotan
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.


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 this post


Link to post
Share on other sites
Quote:
Original post by redmilamber
Why 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 this post


Link to post
Share on other sites
Quote:
Original post by Kylotan
Quote:
Original post by redmilamber
Why 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
high-level task scheduling
complex algorithms to achieve specific effects
large-scale batched loading of data (e.g. level-loading)

Share this post


Link to post
Share on other sites
Quote:
Original post by redmilamber
large-scale batched loading of data (e.g. level-loading)


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 this post


Link to post
Share on other sites
Quote:
Original post by Kylotan
Quote:
Original post by redmilamber
large-scale batched loading of data (e.g. level-loading)


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 this post


Link to post
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement