Mechanic #020 - Control Panel|
Build a robot from spare parts, then connect each part to a self-designed control panel.
The Composition Grid series is a group of gameplay mechanics that revolve around customization of one's game or abilities by placing objects at specific places on a grid. Where these objects are on the grid, as well as where they are in relation to each other, makes as much of a difference as what those objects are in the first place.
This entry isn't so much a full mechanic as it is the idea for a direction of a mechanic. The premise is that you build a control panel by finding different controllers and placing them on a grid. There's a number of different controllers: buttons, levers, switches, gauges, steering wheels, or even digital monitors. How you lay out your control panel is up to you. Then you use the mouse (or perhaps a stylus) to manually manipulate the controls to give it a real hands on feel. Something like the two DS screens plus a stylus would be great if the touch screen were dedicated to your control panel grid.
So how does creating a control panel work? Well, at the simplest implementation, it's simple a decorative option. Each controllable object may have a specific type of widget that controls it, so you just select the one you want according to taste and place it on the grid where you'd feel most comfortable with it. That would make a small, but welcome bit of customization to many types of games. But you can go further and introduce a "tinker" element.
We go to the whole model-view-controller pattern, where the object being controlled is the model, the control panel widgets the view, and the controller being a black box that exists somewhere inbetween. A bunch of inputs and outputs extend from both the model and the view into that black box, allowing the two to interact intelligently. Perhaps a visual demonstration is in order.
Let's say you have a crane. It can on extend or retract the line and open or close the claw. So, from the crane, we have:
- Line Velocity (negative retracts crane, positive extends it)
- Claw Input (1 = open claw, 0 = close claw)
Taking to the output, we can easily see how such numbers could be represented any number of ways. By feeding that number into one of the gauges, it will reflect it. A progress bar might fill up a certain percentage while a digital monitor will print out the output in textual form. While the digital monitor might be able to print out any recognizable number, the progress bar and gauge may only accept an input of 0 - 100. That's where the controller comes in. The black box converts one number (0-1000) into another (0-100).
- Length of line currently extended ( 0 - 1000 ft )
- Whether claw is open (1 = open, 0 = closed)
For the input, a similar adjustment takes place. For opening or closing the claw, a simple flip switch would work without translation. However, if you were to use a slider, the controller would need to translate the slider's position (0-100) into a binary number (0 or 1) - should be easy, just break it at the halfway point.
The line velocity is a bit more tricky. You could use a simple three-way switch and just translate the ON+, OFF, and ON- into a static velocity. Or you could use a slider and translate it's position into a variable velocity (like say, a slider at 0 is stopped, at slider at 25 is half the possible negative velocity). But you could take it one step further.
With a proper controller, you could hook both the inputs and outputs of the crane into it, and the input from the controller, and create a value for the line length based on the slider. The slider is all the way down, the crane is complete extended, while halfway up would have the crane halfway extended. The controller would use the output (where the line currently is) and calculate a proper velocity based on the slider's position.
If designed correctly, a system like this could be a tinker's paradise. One could create complex control schemes that give perfect direct control, or simple control schemes which give indirect control. A very large part of the process would be hooking up inputs and outputs to the right places, but also in designing and coding the different controllers (assuming there aren't plenty provided). I could see such tinkering welcome in something like a mech design and combat game, where how you design the controls could be just as important as which types of arms and legs you equip on the robot.