RIM - The Basics

By Lee

RIM stands for Rule Implementation Module. As the name implies, they are used to implement rules (and some other things) in Stage. Stage has a goal to be modular, hence it can be the framework for many different games. Stage, itself, is made up of many core sub-systems. Some of these sub-systems are Thor, Mercury, Pegasus, Shepherd, Echo and Galileo. The RIMs provide a method that allows any client/server style game to be implemented using Stage and the various Worldforge clients.

It should be noted that the current RIM and Pegasus systems are subject to change as the rest of Stage develops and Lee learns new ways to handle things.

What is in RIM for me?

Many different developers will work on RIM modules. The role of each varies:

Game System Developers

RIM modules provide the building blocks for creating a game on the Stage server. Eventually, enough RIMs should exist that these developers should be able to pick and choose. Sometimes, if there is functionaltiy that suit a particular need of the game, a new RIM module will have to be made or adapted from an existing module.

Rule system developers

RIM provides a way of defining what an Atlas Operation does what to the world state.

World Developers

You are going to have it so easy. A standard set of world development RIMs will be created to interface with other Worldforge tools, like mapmakers, to allow the quick development of worlds and immediate viewing using standard WF clients.

RIM Developers

This system provides an easy way to define what happens to an Atlas Operation sent from the clients.

Stage Developers

Without this system (or something similar), Stage would be game-less ;-)

Ok, so what happens to an Atlas Operation?

The client sends an Atlas operation (from here on referred to as an op) to Stage, where Mercury receives it. If it is an In Game(IG) operation, Mercury passes it to Pegasus. If Out of Game(OOG), Mercury handles it. When a op arrive in Pegasus, it processes the op though RIMs. Pegasus gives the resulting operations back to Mercury, which are then sent to the clients appropriately.

The Pegasus processing step is the major part of RIM.

The following demonstrates what happens during processing:

  1. The op is checked for its type (create, talk, move, etc)
  2. A lookup is performed to find the RIM that can and wants to deal with that type of op.
  3. The Pre-processing method of the RIM is passed the op. The op is then evaluated and the method returns zero or more ops.
  4. The ops from the previous step, if any, are then passed to the process function of the RIMs in which they correspond. Again, more ops can be returned.
  5. Any ops from the processing step are now passes to the correct RIM(s) for the post-processing step.
  6. Ops coming from the post-processing step are put in the queue for Mercury to return to the clients.

Basically, there are three steps in a RIM: pre-process, process, and post-process. What happens in each step is up to the developer, but the there is a suggested use for each of the steps. Pre-process should be used to check the op for errors, preload any entities necessary and do a quick sanity check on the op. The post-processing step should change the perception of the actions which are happening In-Game. Processing is used to change the world state. Keep in mind that any returned ops from any of these functions may then again be passed to the same RIM.

So what is currently happening to RIM?

As of this writing, there is only one functioning RIM. It is called RimChat, and it is used to implement what is effectively a room based IRC. RimChat is slowly being moved towards a 3d, graphical world.

In RimChat, only two room exists and they are text only (like Out-Of-Game, it surpports talking, whispering, shouting and emotes). Movement between rooms should be implemented by the publishing of this paper. All RIMs have to be compiled in staticly (or as a shared library) at the moment as dynamic loading is being researched. The current plan for RIMs being developed is RimChat, Pong, and then some generic, non-monolithic RIMs.

Development of RIM seems slow. Why is that?

Good question. The two answers to this are: I've just started my second semester of university and have more assignments, and RIM is limited by what the rest of stage can do. For example, there isn't any real archetype system yet, so RimChat fakes it, and it's the same with containment (in a location, not position, sense). There is still quite a few things in Stage which have not been finalised yet, like how collisons will be handled, if OOG and admin will also be handled by Pegasus or a Pegasus-like system, etc.

The near future of RimChat

some of these might be put in a different RIM (with a copy of the rest), probably called RimTextRpg