This article describes some core concepts in Ares code. It assumes you’ve already read about the Ares Architecture.
Table of Contents
When someone connects to the game with their MU client, Ares calls that connection a Client. The Client class provides information about the connection, like the IP address and idle time. It handles input from the MU client and turns it into a Command (explained below).
The Client class also provides utilities to easily send messages (emit) to the MU client. Throughout the Ares code, you’ll see things like:
client.emit_success message
The Client class provides five methods for sending output to the MU client:
emit
- A basic emit.emit_ooc
- OOC messages show up in light blue.emit_success
- Success notices show up in green.emit_failure
- Failure/error alerts show up in red.emit_raw
- A special emit that will not evaluate linebreaks or ansi codes.Once a player has logged in with their character name and password, their client now has a Character attached. You can access that by calling client.char
from a Client object.
You can use the character object to access all sorts of information about the character. For example, you can emit a personal greeting:
client.emit "Hello #{client.char.name}!"
The Ares Engine provides several other basic database models.
When a client sends some text to the game, it is converted into a Command object. The Command object breaks the text into its familiar MUSH components:
(prefix)root/switch args
For example: combat/join Faraday=123
would be broken up as:
prefix | root | switch | args |
---|---|---|---|
+ | combat | join | Faraday=123 |
Commands are routed through a central Dispatcher, which will go through the plugins trying to find one that wants the command. The dispatcher uses the EventMachine reactor library, which ensures that commands are handled one by one in an orderly queue.
In addition to commands, the game code can issue Events to notify plugins when noteworthy events have happened. Some common events include:
Events are also routed through the central Dispatcher. Unlike a command, which can only be handled by a single plugin, Events may be handled by multiple plugins. For example, when a character logs in you want to notify people in his room (Rooms plugin), notify the channels he’s on (Channels plugin), notify him of new mail or forum posts (Login plugin), and so on.
When a player does something on the Web Portal, it doesn’t come through as a Command, but as a Web Request. They’re similar in structure to Commands and also go through the Dispatcher; they’re just handled a little differently.