Sunday, March 30, 2014

Trinkets

I picked up a foot of 3/8" aluminium at the hardware store just so I could go in and lathe today. But I forgot to bring the unfinished grenade with me!


I spent the day making small mistakes anyhow, so it was worthwhile. Better to make mistakes on little parts, then on a nearly-finished prop.

And, yes, I will be selling a few. I've got a thread going at the RPF.



Meanwhile, I seem to have solved my Trinket issues. Somehow, when the bootloader went bad and I switched to ISP, I bollixed the fuses. Or so I assume; I got a "naked" ATtiny85 working with the neopixels via my old target board:


But it didn't talk to the pixels until I'd used the "burn bootloader" command in the Arduino 1.0.5 IDE to -- I assume! -- flash the fuses for 8MHz behavior.

In any case, after two days of struggling, I've control over the neopixels again. But I took apart the Holocron circuit board to get to this stage, and at this point it makes as much sense to go with a minimal ATtiny instead of "wasting" the Trinket on it.

(It also makes a lot of sense to continue with the ISP instead of trying to fix the Trinket's bootloader, because I can really use that 3K of program space!)

So with any luck the Holocron will get boxed up this week. I'll finish documenting the build here, and also in another Instructable. I have until the first of May to write as many "I Made it at TechShop" Instructables as I can manage...because after that I have to start paying full price for the classes I still want to take.




Health Packs

Just some random musing about game design.

The health packs, or miraculously curative items of quickly-digested food, that litter most FPS and similar games are a necessary corollary to the kind of combat presented. You are usually mowing your way through a lot of mooks. And often they have similar weapons, or at least comparable skills -- so it actually takes some effort to defeat them -- and it doesn't feel realistic if they don't score on you a bit. But because of the sheer number of enemies, to make it seem you are actually in contest and in combat you need to take multiple hits. To survive them, no single hit can be crippling...and healing can only be another room or two away.

Several unfortunate things happen because of this mechanic. A "charge right in" player style as often as not -- because it is safer to run to the next health pack, then to linger trying to take a smaller number of hits to begin with. And in those times the game actually puts pressure on you by withholding health packs, so accustomed are you to refreshing your health at frequent intervals, it doesn't feel like a challenge; it feels like an unfair imposition.

The older "recharge while resting" mechanism had its bonus, but then you either get the player feeling unfairly put upon because mooks keep re-spawning and spoiling their beauty sleep, or the game turns into "play for five seconds, retreat to recover hit points for twenty" and that is a boring way to play.

And those same FPS play a nasty game of "you can't take it with you" as well. Even though you have no problem carrying eighteen different weapons on your back, out of the room full of crates you just opened you can only remove and carry off ONE magazine. You can't stick the others in a pack (although I've spent a fair bit of effort in Half-Life2 throwing spare magazines and health packs in front of me down the corridors!)

Which means that even if you stumble into a medical dispensary, or a fully-staffed hospital, or have a "after three weeks of recuperation back at your base" cut scene, you can't get your base health any higher than the same number you achieve seconds after running through a machine-gun volley and then across a couple random health packs found lying in the street.



Well, I'd love to see an FPS game with hit points being roughly conserved for the length of an episode, chapter, mission. Like the old RPGs where you would have to rest up at the inn overnight in order to reset all your hit points and manna. Sure, there might be a bit of first aid, or special game mechanic like a healer character or something similarly magical, but basically, you'd start each "mission" or major chapter fresh.

And you'd get mostly cosmetic injuries if you were lucky.  If you were less lucky or careful, the injuries you'd take wouldn't be just numbers off a hit point total. They would reduce your effectiveness in various ways. But this wouldn't feel unfair because the level design would compensate; it wouldn't put the stuff where peak endurance was needed right at the end of the level, but instead play towards other strengths, ones that weren't effected quite so much by the accumulated injuries.

And a lot more of what you took would be portrayed as scrapes, bruises, cuts; John McClaine stuff. The old "bullet through the shoulder" would be rarer.

Which means that even though the mooks could be throwing the same weight of rounds at you -- suppressive fire is a thing real armies do -- you weather this not by taking five or ten hit points for every round that hits you, but by almost never getting hit in the first place.

Which is a problem. In real combat, suppressive fire works, and teamwork and flanking movement is usually necessary. When you are on your own, extensive use of cover (or if you can't get that, concealment). And stealth games are a thing, but we'd like to have a combat game too and doing it this way either requires way too much of our friendly AI's, or is too slow.

Of course, one of the reasons stealth and use of cover is so slow is, well, historical. Running across the battlefield guns akimbo is the default setting, and special enemies were introduced that required less-used mechanics...and all that boils down to making moving in a crouch slow and difficult.

Plus the basic ways of handling the game universe that are down behind the code treat your character as a bounding box. Crouching is implemented by making the box shorter. The engine may be able to draw a line of sight to an actual 3d model of your character, but collisions with scenery are usually handled with the bounding box. And there is no simple way to represent to the player the ways a physical body interacts with cluttered terrain; the scrambling, twisting, elbow-crawls and low rolls to get around and between objects while maintaining cover and concealment.

Still, I suppose you could rethink the movement paradigms. Just as "sprint" is a special key and often has conditionals (as in, you can only move faster than a walk for a short period of time), "crawl" could be treated not as it is currently -- having to hold down a crouch key and awkwardly press the movement keys at the same time -- but as an alternate, or even a default, movement mode while under fire.



But the biggest problem is that, really, you need to reduce the number of mooks. There isn't a good way of realistically dealing with hundreds of people shooting at you, and have it still fun to play. Well, other than the Pac Man arrangement of easy health and convenient ammo dumps we have now.

If you reduce the number of mooks, the biggest problem is that you reveal the shortfalls of the AI more. Which is another way of saying each mook needs a lot more scripting. And they are of course more dangerous now. Which really means that instead of hundreds of mooks, what we are fighting is a series of boss encounters.

Each soldier that is ahead of you is, not just a possible five or ten hit point penalty and a place to grab a fresh ten-round magazine, but an individual encounter. Set up the same way bunches of mooks are set up in many existing FPS; the group of soldiers right around a corner with a stack of barrels or a ventilator shaft that you can use to tackle them other than head-on. Or the squad that spawns right behind you in a dead-end hall forcing you to engage at point-blank range.

But this would still take longer in level design for the same amount of play. Because ten random mooks in a room will average out the flaws in the AI a little bit and they won't look completely asinine. But a single elite in the same room -- a boss mook -- needs to be much more carefully scripted to feel like a realistic encounter.

And because of the no-healing-until-end-of-episode arrangement, the level designer would also have to be more careful not to create situations where an injured player has no ability to complete, and their only chance is to retreat all the way to a much earlier saved position. And they would also have to work at making climactic challenges to each level that allowed for the range of injuries sustained to that point, without nerfing it for the more successful or careful player.



Tuesday, March 25, 2014

Holocron Hold-up

I got the code for the "quiet" mode working nicely at last. The best way I could figure out to impose a slow color shift on top of a (relatively) faster "sleep mode" pulse was to divide the red and green additive values by the value of the base blue. Which meant working in fractions, which meant I had to use float values, which meant I sucked up nearly all the program memory.

(Which meant the key command line became an unwieldy "strip.setPixelColor(whichPixel, gamma[int((redVal/100)*blueVal)], gamma[int((greenVal/100)*blueVal)], gamma[int(blueVal)]);")

But while I was attempting something a little more streamlined I managed to overwrite the bootloader (it's unfortunately easy to do on the Trinket, due to the ATtiny85 not having a protected memory partition).

So I need to attach a bunch of wires and go inside with my USBtiny ISP instead.


With luck, omitting the bootloader will spare me enough flash memory that I can do something nice for the "Jedi Detected" lighting routine. Seems a shame to have four digitally controlled RGB's and only drive them in unison. But it may have to be something simple when all is said and done. Subtle fades and bits of "analog" randomness really add a lot of extra lines to code.



Five people at the RPF have expressed interest in at least one M40 Grenade, so I'm preparing to go back to the lathe and run off three or four, then officially offer them for sale. The drilling part was painful enough I've got ahead and dropped a few bucks at McMaster-Carr -- heavy-duty chip-clearing high speed steel -- but I couldn't bring myself to spend for TiN coating, much less high carbon steel.



The Instructable for this fetched me a new class, at least. Which is good, because I used up my last free class and then some scheduling the Milling Machine SBU for this week.

The rest of the week is going to be installing speakers and inspecting cable at another theater. Oh; and I may change the light bulb in a lighthouse.

Monday, March 24, 2014

Code Drops

Show is closed. Parts are ordered and next week is install at another theater.

Started an interest thread at the RPF and enough people want a grenade I've gone ahead and ordered more metal. Not quite enough interest to justify a complete set of tooling, but I will splurge on some drill bits.


Ran into another small hurdle with the Holocron. I re-purposed my old Blink code and it ran fine, but as the neopixel literature warned, I also used up most of the available memory. Since I don't really need an RTOS -- or a flexible code structure -- I'm going for more of a traditional loop-based approach now. So far I've only saved about 20% of the program space, but it may be just enough to permit it all to stick on that ATtiny85 chip.


On the longer project list is finishing up some vacuform Lewis Gun magazines, rebuilding a Suomi, and on personal projects, wiring the kerosene lantern I bought with remote-controlled LED light.

Oh, and I scheduled a class on the milling machine.

Thursday, March 20, 2014

Zombie Ghoasts Leave This Place!

The LED sensor on the Holocron isn't working, and I just don't have the patience to problem-solve it within the context of this project. Somewhere down the road, I'll get an LED-as-sensor working on a breadboard, and then I'll be able to integrate it into new projects.

So that simplifies the programming. The Holocron will have three modes. First is off; when it is turned upside down, the power is cut off to the Trinket. Second mode is Ghost Light; this is some sort of gentle color-shift and perhaps a position-shift as well. I'll have to see if I can re-purpose some of my Blink code to do this. I'm using neo-pixels for this, so no PWM needed, but I still need to cross-fade from one color set to another.

Third mode would be "Jedi Detected." In the current code, the capacitance sensor object "yoda" stores a "midiclorian" value; when this passes threshold, the Holocron will do a brief fancier, brighter display. Maybe some swirling (I have four neo-pixels arranged in a square).

If I could have gotten the LED sensor to work, it would have triggered some sort of display change when the flash drive was in read/written.




Meanwhile, I'm stumbling around like a zombie myself, feeling probably the worst I have since December. But not as bad as in years past, still. Even if I did spend a couple days sitting on the couch seeing if the airboat from Half-Life 2 would drive down the corridors of the Aperture Science Enrichment Center.

Apropos of that, the gaming community has been reduced to noticing script pointers in the latest Steam SDK that appear to refer to maps that don't exist yet...but could possibly be part of Half-Life 3.

Given the insanely long delay, and the lack of any word from Valve, I'd say this particular piece of vapor-ware may be the real "zombie ghoast" in the room...

Saturday, March 15, 2014

Mercury Bubbles

Added a tilt switch to the Holocron so power to the LiPo could be physically disconnected without having to open the Holocron and fumble for a mini-toggle or something.

Except, RoHS has removed mercury-based tilt switches from stores in California. The alternatives are much more vibration-sensitive.

Fortunately, there's a cure for that, too; a 4700 uf electrolytic proves sufficient to keep the Trinket's power supply from browning out even with active shaking of the sensor. And it still cuts power quite effectively when the Holocron is turned upside down.


Unfortunately, I also found a board-mount USB-B jack at the same electronics store. I was going to hard-wire the USB tail and tuck it into the box when not in use, but perhaps I should cut a larger hole and mount a USB-B instead? Pity I already did the lasering (not to mention gluing all the pieces together already).



On the M40, slitting white electrician's tape to 1/8" looks decent (or at least, like the original prop) and a coat of Clear-Coat makes it durable enough, but I'm not sure I like the effect. I am tempted to lath a tight-fitting plug that I can use as a turning guide. I'm sure any lathe tools would snag, although sanding is possible. LDPE is also, however, laser-able -- and TechShop has a rotary attachment for the Epilogs I've been using.



I still don't know if I want to try to do a run on these. I think I'd want to do more than four and less than 100; enough to make it economically viable to purchase my own parting tools, and enough so it would be efficient to make templates or similar. But few enough so I don't get utterly bored with the prospect.

At my current skill level, probably one out of three would have problems. Which means instead of doing orders, I might do better offering a few up on a sliding scale.

Perhaps I'll start an interest thread at the RPF.


(Oh, yeah -- another of my low-light specials here. The blue light is from my Holocron in progress, the white base light is my (modified) Energizer headlamp, and that high orange key is from a butane fire starter.)

Friday, March 14, 2014

Venue Design

I'm trying to do some system upgrades at a local theater.



The main problem we are facing is that it is a multi-use, multi-user facility. And it has no resident engineer. So each individual designer or facility user has made changes, usually undocumented, sometimes stupid, to what has become an accreted pile of barely-works and what-is-this.

The current administrators are in complete agreement with me that we want a turn-key approach. Actually, a more nuanced view of it is a "venue" approach.

Out there in the bigger world of live sound, there is a permeable barrier between the house system, and the FOH console. The incoming act is always given permission to do whatever they need on the front end. But the system they patch into -- with the limiters, cross-overs, and other shaping tools -- they don't have blanket permission to muck with. Only if they can convince the venue engineer will they be allowed to adjust how the system itself is configured.

In this case, I want to set that barrier even a little further out. One of the users is a classroom setting where all they need is a talkback microphone and a way to play iPods through the system. For this, I do not want them to be even touching the FOH mixer.

We also have some inexperienced sound designers coming in. For them, I want them to be able to walk in to an FOH mixer that is already working, and a sound effects playback computer already hooked into the system. Because I don't want to make them think they have to go behind the rack and start yanking out cables just to get the sound for their show working.



This makes, however, for a potentially expensive, and very likely complex, system. What I'm trying to do is have hard-wired defaults, and offer flexibility within a parallel patch system; so whether you chose to patch directly into one of the surround speakers or not, it will remain part of the configured "mains" input.

This requires a bunch of summing mixers.

My best of all possible worlds would be a big line mixer mounted in the rack, with a custom acrylic shield locking out the majority of the knobs from the casual user.

But I can't seem to find one with enough inputs to handle the ability to route SFX playback to any of the speakers in the "mains" system. So my fallback there is very possibly going to be to hide a couple RDL (Radio Design Labs) "Stick-ons" inside the rack. This would allow me to have a firewire interface permanently wired into the house speaker system in such a way that cues can be played back into individual speakers or groups of speakers.

My vision of the "mains" processing, however, is that the front speakers have 31-band graphic, and the rear surround are on a delay. So the only place I really can patch in a direct-to-speaker would be post-processor anyhow. So maybe having an RDL stick-on as a line-level merger is the smartest way to add this option. Better yet, it is an option I don't have to include at this time.

A similar issue is the front-of-stage foldback speakers. They are sometimes used for sound effect playback, and sometimes used for foldback of band or pre-recorded music. They would also be handy for Stage Manager announcements during rehearsals, of course. This would be a lot of summing mixers to try to integrate all these different users, though.



On the "classes" end, I want them to be presented with a vanilla mixer that has nothing to do with whatever the main stage shows will be using. In fact, I think they don't need a mixer at all; they can adjust their playback volume via the iPod itself, and the talkback can be a preset. For this, I'm willing to assume having these components "permanently" wired -- with a switch on the talkback mic, of course -- and preset levels on the rack mixer, will suffice. If actual conditions during the class require they tweak their levels, it doesn't effect anything else.

Of course even soft-switching is not a panacea for idiots and live mics. So it would be very nice to have a limiter in circuit. The iPod, too -- I have yet to see any user, anywhere, mute the system before yanking the plug out of an iPod.

Another element for this is that the talkback might want to be sent to the dressing room monitors during main stage shows. It might be safer, however, to make only the Clear-Com headset capable of paging backstage -- because doing it the other way leads to the potential of dressing room announcements being sent to the audience during a main stage performance!



For classic reinforcement, I want the option to have the board either in the booth, or out in the house. What I want to do is run an audio snake out to the FOH position and leave it there. One way or another, this means they will be disconnecting the mixer itself and dragging it around. Since they have to patch into the line mixer to get access to their outputs anyhow, I am tempted to add a patch bay to the system. Or I could hard-wire the system end of two snakes (one for booth, one for FOH) and trust that it will never occur that both systems are in use simultaneously.



The last major system is the enhanced dressing room and booth monitors. For those, I'm using a simple zone system driven by one microphone. This is truly turn-key; the only thing the end user will ever do is turn up or down the level of one of the zones. Which in itself is dangerous enough (this is why you do not put volume controls on dressing room monitors. Because a random cast member will turn it down so they can listen to their tunes or talk on their phone, and never remember to turn it back up again, and no-one will realize the monitors are down until someone blows an entrance).

The main option I have is to add an input; either from the Stage Manager's headset, or from the talk-back mic, or even a dedicated booth-to-dressing-room annunciator. This, at least (even the option for automatic ducking!) is already included in the unit I've spec'd out.




All said and done, what I'm trying to achieve is a TNG system -- Star Trek, The Next Generation, that is. Which is to say; that it is clean and intuitive in the default state, but endlessly reconfigurable to almost every option imaginable should the need arise.