Security Cameras
I just spent a good chunk of my weekend working on security cameras. Or, rather, a kit allowing SL users to create their own camera systems. Those of you who who've checked out the Garage of DOOM know that there is a basic camera set built into the security desk at the entry area. Sit in the chairs, and your camera is automatically sent to one of eight preset views within the Garage. Nothing too fancy, just fixed viewpoints selected with arrow keys, but it provides an easy way to watch a game in progress.

Well, since the GoD interminable beta began a few months back, I've received numerous IMs asking about the system. My answer has always been the same: it's not overly complex, but it does require some scripting/building knowledge and a fair bit of tedious preparation. Each of the camera locations in the GoD's system must be programmed by hand, using preset coordinates for the camera's placement and focus positions. (Basically, "put the camera at position [A,B,C] and look at position [X,Y,Z].") Nothing terribly difficult, but a bit tedious and possibly too much to ask of a non-scripter. And, face it, if they were scripters, they wouldn't be asking me for copies of this comparatively straightforward application. They'd be writing their own. And probably doing so better than I could, come to that.

In any case, after the umpteenth inquiry, I finally decided to build a product that would automate the process, allowing non-programmers to build their own systems using (relatively) simple tools. The end result came in two parts: a camera position recording HUD and a camera-enabled poseball. The poseball turned out to be reasonably easy. It reads a notecard with camera settings and camera coordinates, and overrides the camera of anyone sitting on it. Naturally, it includes a basic sit animation script, as well. Just drop in the desired animation, and the poseball does the rest. A configuration notecard is included to change simple things like the floating text ("Watch Security Cameras" or the like) and text color, and the poseball can be modified as required for color, shape, linking to other furniture, and so on.

However, generating the camera coordinates notecard turned out to be the hitch. I started out with a simple, one-prim HUD for the process. Maneuver your camera into the desired position, and click on the HUD to record its coordinates. Then type "/1 send" to send the coordinates as a properly formatted e-mail. I thought long and hard about data transmission, in terms of e-mail vs. in-world comm channels. People are understandably leery of handing out their e-mail addresses, although it's likely that the purchase price of the HUD would dwarf any profits I could expect from scamming one e-mail address for a spammer. Putting aside my personal distaste for spam e-mails, there's just no profit in it with this model.

Unfortunately, given that there is no way to write to a notecard directly by script, I'm left with convoluted schemes like this. The other option was to have the device spew out the coordinates on a chat channel, and have the user copy and paste from his history. The Thinc printing press uses this scheme, and it works fine for that application. The main difference is the books effectively form their own backups. Miss the chat? Just run it again. Decide you want to change a page a few weeks down the line? Just swap out the image in the book template and run it again. That doesn't work so well here, however. There's no individual cameras to swap around like textures in an inventory. I suppose I could have come up with some complex system to store camera locations indefinitely in memory, swap them around, mix and match them, etc. But the e-mails are much cleaner. Once it's sent, the user can copy it as many times as he likes, and he can mix and match the lines as needed.

That, and it was easier for me to code. By this point in the project, I was ready to let that be a prime design criterion. I was never a big fan of having to either edit all the extraneous chat out of a card or move to an isolated location, anyway. Especially unworkable given the types of locations likely to use this device (casinos, clubs, etc).

Addendum, 4/2/07
Decided to ditch the e-mail system altogether. It worked great for me (I use e-mails to monitor all sorts of in-world events), but a couple of my beta testers were having problems with e-mails simply disappearing for one reason or another. Still not convinced the problem was insoluble, and the e-mail system was undeniably easier to use when it worked. But I could see support requests stretching out before me every time someone had their config data eaten by a spam filter, or lost for various other easily-solved-but-annoying reasons, and decided to drop it for something easier to deal with in all cases. And I think the results will work better for the average user in any case.

There are now two different types of cameras. One is still notecard programmable. This is the advanced option, allowing users to mix and match cameras and create custom names ("Entry Lobby" instead of the default "Camera 1" for example). But instead of sending the notecard data by e-mail, it is sent by OwnerSay and harvested from the chat history. Had to make the notecard reader a little more robust (better error checking, and the ability to deal with extraneous blank lines and such at the end of the notecard), but it seems to work better as a result.

The second camera is the quick one, and requires no user interaction. Just press the button on the HUD, and a camera ball is generated and programmed on the fly. The user can then just drop the poseball wherever he likes, or use the included configuration notecard to adjust poses, colors, text, and so on. Fewer configuration options, and no ability to merge or delete camera views (once the poseball is made- the HUD still allows that for cameras in memory), but considerably simpler to use.

In any case, the basic single-prim HUD worked well enough if things were optimal. Unfortunately, there are a few hitches with camera controls. The main one is that cameras are limited to within 50 meters of the user (unless you disable camera constraints). The natural tendency is to wander around your parcel, collecting camera spots, then go back to your security desk/chair/whatever and dump it all in... Only to find out that half of the cameras are out of range. That left me with a need for some form of audit system. This required going through each camera and checking range. And it required a somewhat more complicated HUD.


After much tinkering, this was the result. When "CHECK" is selected, the user is presented with the display at the left. From there, he can cycle through each of the stored cameras and delete any that don't fit his needs. It also checks for distance from the user to the camera, and warns him if the camera is over 50 meters away. Of course, this is only useful if the user is standing near the intended location of the poseball. (It occurs to me as I write this that I should put a similar check in the poseball as it's reading the notecard.) I also added buttons to clear the memory (triggering the confirmation box at right), send the coordinates e-mail, and record the camera locations. Oh, and I added a fair bit of superfluous shininess, just for my own amusement.

This works pretty well, all told. The configuration of the HUD came after an an "ah-ha!" moment for me. When the "CHECK" or "CLEAR" functions are selected, the entire HUD rotates 90 degrees in the appropriate direction to present the new display. I'm sure most experienced HUD designers came across this trick long ago, but it was a new one on me. It saves screen space, anyway, which is important given that the HUD must be relatively large for text to be read clearly on lower resolution clients displays. And it looks kind of nifty in operation, besides.

You can see the protrusions for the buttons on the edges of the HUD in each of the three angles. In future devices, I'll probably recess the buttons, to prevent them from being inadvertently pressed (discovered this on accident by pressing the edge of the "YES" button and deleting all of my stored cameras). It's easy enough to track the current HUD mode/orientation for now, though. And I like the industrial tool appearance, with the extraneous protrusions on the side. In any case, it's certainly sufficient for an extra tool to build another product from a kit. I don't see Ikea wasting a lot of time and money making their Allen wrenches and disposable screwdrivers look pretty. Functional is good enough.

I'm really kind of enjoying designing HUDs. And I think I'm getting a little better at it, too. I'm going to have to look into refurbishing some of my old products for HUD use.
Posted by Moriash Moreau at 12:06 PM