WorldForge Community

In python scripts, any method called foo_operation is a handler for an event that occurs in the server. All entities are sent a setup operation event just after they are created. Things should be done in the setup handler rather than in a constructor if they need to be done after the entity has been added correctly into the world model.

The only way currently for structures to get working collision detection is for them to create this kind of wall entity, but it is very painstaking to set up, and is a hack. We should come up with a much better way.

THe coordinate system for WorldForge does not really have world coordinates. All coordinates are local to a reference entity. There is a top level reference entity which we might sometimes refer to as the world, though this is a bad idea as the protocol does not require that this top level entity is a world, and it is explicitly defined in the protocol that the client may only be able to see a subset of the entity hierarchy such that the top level entity it can see is not the top level entity in the hierarchy.

There is no existing mechanism for floors and ceilings. Sorry.

Also, a note on the setup_operation() calls: it's not that bad of a hack! It wouldn't be too hard to automate the creation of setup_operation() scripts, so that people buildings structures would get the appropriate collision detection.

It could be less hacky to put collision information in the ruleset.xml file, or separate server-side model files, but the nice thing about setup_operation() is that it makes runtime specification of surfaces possible.

The main issue with the setup_operation way of handling this is that it does not scale well. If we have to write script code like this every time an entity needs to create other entities implicitly, then it makes it harder to add other cases to the setup_operation handler. The number of scripts required to handle a complex world design becomes very large and keeping track of everything becomes almost impossible.

It is much more desirable to be able to modify the behavior of an entity by assigning standard properties to that entity which are defined by the server as having the required effect.

In this case, there should be a class property which allows the world designer to define purely in XML that when a given entity class is instanced, a number of other entities should be instances at the same time.

"alriddoch" said:

In this case, there should be a class property which allows the world designer to define purely in XML that when a given entity class is instanced, a number of other entities should be instances at the same time.

Though should that really be on the server? I think it would be more flexible to keep that on the client as much as possible (as I was thinking of for Ember).

I agree. I was thinking that for entities such as the different characters (settler, butcher, merchant etc.) now that we've moved away from using different subclasses for each and instead try to use a single class ("human" or "character" perhaps) we need some way for the world creators to create these different types from prototypes. Since cyclient is a client just like Sear and Ember it could also use a the same prototype system as those clients.

I'd like to keep it as data driven as possible, but I think we do need to have some sort of scripting support anyway, else it would be too restrictive.

I have some experience with (full 3D) collision-detection code. Even on the server (or especially on the server), I'm guessing there should be a high-level breakdown of objects and things into a set of nodes, each node constrained to some 3D volume and aware of what other nodes are potentially visible from that node.

Also called potentially visible sets, see: http://www.google.com/search?q=potentially+visible+set

It would be the responsibility of the world creator (person or script) to break down the static world objects into separate PVS nodes.

Within each node (or PVS), all objects are broken down by an octree or Binary Space Partition tree. This means location-based lookups are O(logN) or better.

Even for very large sets of objects, collision detection only takes place locally to the moving object, and even within that neighborhood there should be ways to use space partitioning to keep the lookup performance sub-linear.

This also allows the server to tell the client only about those objects that are potentially visible to the observer.

Using full 3D collision detection, supporting ceilings, floors, ramps, bridges, etc. is pretty straightforward: all surfaces, whether floors or walls, are handled the same. With 3D collision detection and some basic physics rules you get the ability to walk around multiple-level structures etc.

"tomva" said:

Regarding 3D models and collision detection: I think there is a fairly clear pattern that has been established for creating objects:

1) Specify the object in a way that the server knows how to deal with it, and
2) Specify the object in a way that the client knows how to render it

Yes

"tomva" said:

(For people reading this that aren't Erik or Alriddoch, see http://wiki.worldforge.org/wiki/WorldCreation#Deep_Dive:_Wolf for a specific walkthrough)

I think collision detection is exclusively the responsibility of the server. So if I create a 3D object, part of my server specification will include telling cyphesis how to perform collision detection. The collision detection may be wildly different from the rendered model. For instance, a series of steps (as rendered on the client) may actually just be a smooth ramp for the purposes of collision detection. Likewise, a single flat wall as rendered on the client may contain multiple openings to represent secret doors or portals.

The client should have enough information to be able to accurately predict when a collision will be detected by the server, so as to provide the smoothest lag free experience possible to the player. A good MMO architecture allows for considerable difference between world state on client and server while trying to keep glitches in the user experience to a minimum. Corrections to client state should be done quickly but smoothly, and server side events should be anticipated where possible. In the case of secret entrances and invisible barriers it is obviously necessary for the client to be kept in the dark about the true nature of the world, but in this case the glitching that you will should fit with the surprise the character would experience on coming across something like that.

"tomva" said:

I agree that forcing this collision detection specification to occur in setup_operation is a bit painful. It would be more natural for the collision detection components to be placed in a separate file. Much like ember has a mapping to lookup 3D models based on entity type, so cyphesis could have a mapping to look up collision detection information based on entity type.

Far from moving it into a separate file, I am strongly in favor of moving everything that defines an entity into a single place, in the XML class definition. Only the most unusual types of behavior should require a type specific script class.

Sure, sounds like a great idea! If nothing else, it can start some discussions.

I've put up some preliminary notes (with an outline of a proposed design) up at the wiki: http://wiki.worldforge.org/wiki/Collisi ... tionEngine

I've posted a question in the General Programming forum about how launchpad.net should be used. I suspect I'll just create a blueprint entry there that references the wiki.