He speaks
The event handling in the Wombat Engine is designed to be easily extensible to new commands and new types of input devices. We make the assumption that we have 1 keyboard type device and 1 mouse like device. At he base level we have a set of classes that looks at an input device and determines the state of that device. For the keyboard, this is a simple on/off for each key. For the mouse, we also report the current position of the mouse cursor.
When we detect a mouse down, a key down, or some similar event we pass the event through something termed the "context checker." The context checker interprets the signal in relation to what is happenning onscreen. For example, the button for "open a menu" may become the button for "close a menu" once a menu is opened. This interpreted signal is now placed in a list to be processed.
Each frame the list of control signals is sent to our interpreter. When the intterpreter recieves the list of control signals it processes them and dispatches them to the object the control code is the targeted towards. For example, if the user pressed the button corresponding to "move forward," the interpreter forwards the mve forward message to the main character object, who will then act on the signal appropriatly.
Mouse movement works as follows: In both mouse movement modes, keyboard signals take precedence over mouse signals, but the mouse and keyboard can be used simultaneously. For example, one can use the keyboard to move forward and back and the mouse to turn. In both mouse movement modes, moving forward or back is a function of the mouse relative to the center point of the window. To move forward, the mouse cursor must be above the center of the window, with increased distance meaning increased speed.
In the first mouse control method, turning is similar to moving, based on the mouse position relative to the center of the screen. The second method uses a velocity based method for turning. (We refer to it as the "Doom Style" control scheme) Moving the mouse slightly to the left will turn the character slightly, while a fast long slide will turn the character much more. The effect is not residual; unlike the first mouse control method the static position of the cursor has no importance, only the movement of the cursor is important.
Hitting return once will put you in text sending mode. In this mode the character keys on the keyboard will no longer activate their usual functions. Instead what you type will appear in the bottom left corner of the window. When you hit enter again the message you typed appears as scolling text above your head for other players to read. (For now it appears on your screen as well as the other players') Players who are not the targets of the message will see the message as semi-transparent, to avoid clutter and to serve as a visual cue as to the importance of the message. In the executable availiable for download, all players are targeted by all messages. You can simulate the semi-transparent effect by pressing 'b' before you begin to type a message.
He speaks
As in all 3d environments we have a camera that renders the scene from the camera's position. The camera supports two modes of use:
The first sets the camera to look at a particular point. The camera can then zoom in and out and rotate around the point in 3d space, as well as rotate along it's own axis. In the second mode of use the camera is set to a position in space and given a vector direction to look in. While one of these modes can be used to duplicate the other, they represent two different ways of thinking about camera movement, hence the distinction. The camera class is fairly low level and meant to be modular; it relies on nothing in the rest of the Wombat Engine. The switches between first and third person mode, resetting to default camera views, etc, are all handled by the interface on a level higher than the base camera class. As of now no collision is performed on the camera or it's line of sight, so graphical screw-ups appear from time to time.
Zoomed
out shot
Right clicking the mouse will bring up a context sensitive hierarchical menu that the user can select items from with the left mouse button. The menu options are generated by the object the user clicked on. If the user clicks in space, a default menu is provided. If the user clicks on a particular object, that object generates a list of commands to go in it's menu. For example, clicking on a rock may bring up a menu with the options "Look At" and "Pick Up." When an item is selected, a control signal is generated and passed through the interpreter on to whichever object needs to act on that signal. (Usually the object that spawned the menu) At this point object selection with the mouse is non-existent, so only the default menu will ever appear. Other menus do work and can be hacked in (ie: open a certain menu when the mouse is clicked in a certain location) but they never appear in the downloadable executable.
Hierarchical
menus
When in third person modea semi-transparent circle will appear around the character's feet. This circle serves as a source of visual cues for the user. Strips of different colors appear on the circle to indicate the presence of different things of interest in that direction, with the size of the strip indicating distance. By default, a blueish strip appears on the circle towards the direction the mouse cursor is in. The strip can also indicate harmless items (green), potential danger (yellow) and immediate danger (red).