Protocol Contexts

From WorldForgeWiki
Jump to: navigation, search

Initial notes by zzorn.


In different situations when using a server and in-game, there are different actions and perceptions available for the player / client.

For example, before logging in, there are just login to existing account and create new account actions available.

When logged into an account, there are out of game chat available, as well as the ability to create a new character, or take a character into use.

When in the game, some in-game items, spells, vehicles, places, etc. can offer additional functions and perceptions. E.g. a car can be driven around, and can report the current speed, a compass can report the current heading, a notebook can provide a way to read and write notes, and a building designer can provide ways to design buildings.


To manage these actions and perception streams that are available at different times and in different situations, a context could be introduced.

  1. The context provides a set of actions that the agent controlling the context can do.
  2. It also can provide perception streams (e.g. chat messages to different channels, or move operations for objects in three dimensions, or updates to the properties of some object).
  3. A client can have several contexts available at the same time. The server should notify the client when a new context becomes available, or when a context dissappears. When a context is available, the actions and perceptions provided for it could be either sent to the client, or queried from the server.
  4. It might be possible to separately activate or deactivate listening to specific perception streams (e.g. a text-only client would not be very interested in 3D position updates, and would save bandwidth by not getting them).
  5. Several agents might have access to the same context (e.g. like co-operative control in TA-Spring, where both players control the same avatars)
  6. The available actions and properties and perceptions in a context should be possible to be changed at any time by the server.

Properties in Contexts

Often a context wants to offer the agent a read-only property. It can be actually implemented as a perception stream, that tells the agent of the existence of different properties, and tells the agent when they change. When initially connected to the context, the perception stream should tell about all the available properties, and their current value.

Examples of properties are hitpoints, mana, velocity, lag, friends list with online status, etc..

Even things like chat messages, or objects positioned on a landscape could be sent as a property perception stream, provided that the properties can have have nested maps and lists and such. This could allow a generic approach to keeping data structures up to date on the client side, but has the disadvantage that the server would dictate the internal storage structure of a client. The client will probably want to store things like entities in quadtrees and more efficient datastructures.

Nesting Contexts?

NOTE: These ideas are still not completely clear, and I'd appreciate thoughts and input on them. The goal is a simple, efficient, but generically powerful system.

Nested contexts might be needed to manage colliding contexts - e.g. if are driving a vehicle in-game, it will have it's own context for navigation - but so would your normal character that is driving the car. Or if you are remote controlling a space droid, that is repairing your spacecraft from the outside, you don't want your character to try repairing it himself when you issue the repair command.

So these situations could look something like this:

accountContextForPlayer("Hummin").characterContextForCharacter("Igor").contextForVehicle("hayWagon-8943").moveForward(10 meters)



If we have all contexts in the same namespace, we will get collisions between actions and perceptions with the same name.

If we have all contexts in own namespaces, but not nested, we will have potential ambiguity situations where the same context is available through two or more ways.

Although, if contexts have unique identifiers, then nesting would only be needed when first accessing or being presented with a context..


  • An usage scenario for contexts is also to introduce new game functionality using them - e.g. a magic system could give all characters a 'Magic' context, with properties such as mana, and actions such as 'cast spell(spell)' (which might not be available if the character did not have any magic abilities)
  • And items could also provide contexts - not just things like vehicles, but anything that provides interaction or advanced status display - e.g. a portable mini-radar, or an encyclopedia, or a crystal ball..
  • In-game mini-games would also have their own contexts - e.g. a go or chess board
  • Sometimes a context controls an object, but it can also be more abstract. e.g. an Admin context could provide server shutdown or logging controls
  • The client logic itself can also be implemented as a very basic context viewer and interactor, with plugins that provide different contexts. e.g. one plugin could provide a server selection context, and actions to connect to different servers. It would then forward any contexts provided by the connected to game server(s) (no reason you couldn't connect to many game servers or accounts at once) to the context renderer. There could also be simple plugins for measuring lag, quitting the client application, and configuring options like sound volume or resolution.

Client Implementation Ideas

<zzorn> One of my ideas is to allow the users / developers to modify the UI of the client on demand, so if they see that they now have a property called "vehicle.speed" available, they could create a HUD item for displaying it and place it on the screen, and next time the property is available it is shown again.

The interfaces for common contexts could of course also be created by the game developers using the same system, and there would be a generic 'context browser', that'd work on any context, just showing the available actions and properties in a tree list or such.


There could be different view components, specialized for showing some type of perception stream, e.g.:

  • Event log view
  • Console (event log input row)
  • Chat view (tabbed panel with event logs input row)
  • 3D view, with subviews for terrain height, atmosphere