With an emphasis on the "combat."
Just for a lark I started a new game of Bioshock just to see what you could do with the Research Camera.
The game is pretty well balanced, and pretty well organized where you usually need a combination of approaches to get through all the various obstacles. But still, a few combinations are so powerful you can get through ninety percent of the game with them. What a lot of players like is the Electroshock/Wrench combination. You can switch (equipped) plasmid and (equipped) weapon very quickly, usually by tapping the right mouse button. For the above combination, you stun enemies (or cameras, for that matter) with the plasmid then close in to melee range with the wrench.
(It is also a nice combination if you've been hacking turrets, particularly flying turrets. Just stun the enemy and let the turret finish them off.)
There are a half-dozen buffs for the wrench anyhow (various tonics you stumble upon at various points in the game -- no, using the wrench more doesn't increase the probability of these items being made available). I can't think off-hand of any corresponding buffs for the various ranged weapons options, other than the "Power to the People" weapons upgrade stations.
So the trick to using the Research Camera fully was to equip a plasmid that was a primary weapon. And Telekinesis was it. It is also spoken of as, really, the most powerful plasmid in the game. You practically never run out of ammunition if you are using it in combat, and the EVE cost is so low you can use it for hours without needing to find more EVE to recharge.
The first time I tried this combo, I was searching a room when a Spider Splicer ran in after me. I took her picture, then caught one of her spider claws in mid-air and threw it back at her. She yelped, and ran back out to use the nearby First Aid Station -- which I'd hacked on the way in! And I was sold.
So I went through the game with the camera at the ready. Everything that attacked -- and several things that didn't -- I took pictures of. Only when I'd finished, or when I was really pressed, I'd switch to telekinesis.
And boy is the Research Camera powerful!
You almost immediately start collecting damage bonuses. It also starts dropping tonics on you. Within the first few dozen pictures of Splicers leaping at me, I had upgraded to Static Discharge 2. Which meant any Splicer closing to melee range would be thrown back violently by my natural electric shield, and with my other damage bonuses often killed outright. Then I'd pick up the Splicer's body with telekinesis and use it to mow down the others.
The only downside is I'd also been letting the Big Daddies be, so I quickly ran out of fresh slots for all my nifty new tonics.
Makes me wonder what other under-emphasized gameplay mechanics in the game might be similarly powerful if utilized correctly...
Sunday, December 28, 2014
Friday, December 26, 2014
Blue Light Special
Building a dozen stage marker lights this weekend (assuming the parts arrive today or tomorrow).
The client wanted them in a variety of different colors, including blue. I told him the latter might be difficult.
At a first approximation, blue LEDs typically list a forward voltage of 3.3 volts, and a pair of AAA cells (at 1.5 volts ea) sums to 3.0 volts.
At a second, better approximation, the voltage range (depending on formulation) is all the way from 2.48 to 3.7 volts. As opposed to, say, red or yellow, which list between 1.7 up to around 2.3 volts.
And this is another one of those wonderful places where what looks like an arbitrary number is actually a window into the physics of the universe. At the simplest level, an LED's forward voltage is defined by the band gap. And the frequency of the photon emitted is a direct product of that band gap. Blue LEDs typically require more voltage because the light they emit is of a higher frequency.
But only at a first approximation. LED physics is a lot more complicated than that. In any case, because this is a photonic effect (as well as a diode junction), an LED isn't like an incandescent bulb. They either light, or they don't. There's no equivalent of the barely-seen glow of a filament on the last dregs of a discharged battery.
Nor is battery chemistry as simple as that. 1.5 volts is the equivalent chemically-defined energy level in the older Alkaline formulas. Rechargeable batteries are typically less; assume 1.4 volts per cell. And unlike LEDs, batteries are not consistent in voltage across their draw. As a battery discharges, the voltage also lowers.
So this is the long answer of why a blue LED would make a poor match-up with a pair of AAA cells; theory says the cells would just barely provide the necessary voltage to make the light turn on, and a bare fraction into their lifetime, that voltage would drop too low to work any more.
There is enough wiggle room in these numbers, however, to make experiment worthwhile. I stuck a blue LED in my bench rig (a pair of AAA batteries in a holder and a couple lengths of jumper wire). And four days later, it is still shining.
Why? Well, one factor may be that I'm using rechargeable batteries. They start with a lower voltage, remember, but at least in the Sony "Eneloop" series, they maintain that voltage for a much greater part of their discharge curve. The voltage does not droop significantly until they've reached a good 70% of the total capacity.
Note in passing that the capacity of batteries also changes over discharge rate. When you state a battery has "1500 mAh" you have to specify the typical amperage of the draw. For AAA batteries, that stated amperage is 15ma. Which, fortunately, is within the range of what a single high-brightness LED imposes.
(Incidentally, I just realized I could have made these things with Pirahnha RGB's, and changed color with just a jumper).
Still, the red LED in the prototype is now on six days of continuous use, and showing no signs of dimming either.
At a first approximation, blue LEDs typically list a forward voltage of 3.3 volts, and a pair of AAA cells (at 1.5 volts ea) sums to 3.0 volts.
At a second, better approximation, the voltage range (depending on formulation) is all the way from 2.48 to 3.7 volts. As opposed to, say, red or yellow, which list between 1.7 up to around 2.3 volts.
And this is another one of those wonderful places where what looks like an arbitrary number is actually a window into the physics of the universe. At the simplest level, an LED's forward voltage is defined by the band gap. And the frequency of the photon emitted is a direct product of that band gap. Blue LEDs typically require more voltage because the light they emit is of a higher frequency.
But only at a first approximation. LED physics is a lot more complicated than that. In any case, because this is a photonic effect (as well as a diode junction), an LED isn't like an incandescent bulb. They either light, or they don't. There's no equivalent of the barely-seen glow of a filament on the last dregs of a discharged battery.
So this is the long answer of why a blue LED would make a poor match-up with a pair of AAA cells; theory says the cells would just barely provide the necessary voltage to make the light turn on, and a bare fraction into their lifetime, that voltage would drop too low to work any more.
There is enough wiggle room in these numbers, however, to make experiment worthwhile. I stuck a blue LED in my bench rig (a pair of AAA batteries in a holder and a couple lengths of jumper wire). And four days later, it is still shining.
Why? Well, one factor may be that I'm using rechargeable batteries. They start with a lower voltage, remember, but at least in the Sony "Eneloop" series, they maintain that voltage for a much greater part of their discharge curve. The voltage does not droop significantly until they've reached a good 70% of the total capacity.
Note in passing that the capacity of batteries also changes over discharge rate. When you state a battery has "1500 mAh" you have to specify the typical amperage of the draw. For AAA batteries, that stated amperage is 15ma. Which, fortunately, is within the range of what a single high-brightness LED imposes.
(Incidentally, I just realized I could have made these things with Pirahnha RGB's, and changed color with just a jumper).
Still, the red LED in the prototype is now on six days of continuous use, and showing no signs of dimming either.
Thursday, December 25, 2014
A Man, a Plan, an...Underwater City Based on Objectivist Principles: Bioshock!
Another wandering review of an ancient game (well, 2007 release...)
It is tempting to approach Bioshock with hindsight, forgetting just how many innovations it introduced to a wider audience. The combination of first-person-shooter gunplay and survival-game ambience was relatively new. The world-building was exceptional not just for a new level of technical achievement, but for an integrated and cohesive vision that made internal sense (instead of being just a series of spectacular backdrops). Even Crafting -- present in nascent form -- was essentially new.
However, the game survives well. Like the Lord of the Rings, it may have been followed by enough others to lend a certain jaded familiarity with the ideas, but it still holds up as doing a good job with them.
But let's just take this as established and move on; it was a very good game and deserved its acclaim then, and it is quite playable and does not feel in the least bit retro or awkward now. Whatever you can say on the technical side -- low-poly models, simplistic AI, canned and repetitive dialog -- the game recognized these technical limitations and constructed story and level and character design and gameplay to make the best possible use of them.
In short, it largely avoids the uncanny valley problem by choosing characters that are already firmly deep in the trench. The splicer's rote behavior becomes not emblematic of poor coding, but of their own befuddled brains. Similar can be said of the physical design of Rapture itself. Draw distance and skybox are hardly an issue when you are in a narrow corridor deep under the sea.
With that said, the rest of this essay is going to be about some of those elements of gameplay and design choices and what they say about evolving game design in general.
First off, and sharing a problem Tomb Raider 2013 had much, much worse, Bioshock may have too much in the box. It seems the accepted design that when you put RPG elements into an FPS (err..Role Playing Game elements into a First-Person Shooter -- I'm going to try to stay away from the technical and the acronyms but this is going to slide away from general readership regardless), you end up with multiple streams of weapon-and-health support.
As in every FPS from Doom on, you can pick up ammunition from enemy drops. You can find it just lying around the landscape (at least Bioshock is restrained in this -- in many games the random ammunition boxes become almost as ludicrous as the frequent health packs). You can also purchase it (a nice Bioshock innovation is that, contextually, vending machines for ammunition make sense in that universe.) And you can craft it.
Which is my first complaint, really. Crafting is cute, but when you get right down to it, it is a different vending machine. Or a different weapons drop. I have yet to see a Crafting system that let you make something truly unique (I can't really imagine how you could code it up!) So instead, this is just "expensive" ammunition. Which technically is not available to anyone else in the game world, except that they can and do use the same Crafting machines you do, plus -- to Craft, you need raw supplies, and you find those on enemy dead or in the usual supply cabinets.
So when you get right down to it, Crafting is just like purchasing ammunition with money you found on a body or hidden in a crate, only it is barter goods instead of cash. It is slightly more limited, but at the same time you don't get any real choice as to what you collect. You can't go out to the Rubber Hose Tree because you have everything else but that to make new RPG rounds.
At least they've avoided the extremes of Fallout 3, where you are carrying so many scraps of rusted metal and stale bread you have to rent a storage locker to put them in. Or the opposite extreme of Tomb Raider 2013, in which the open pool of "salvage" begins to suggest that the materials for strengthening a home-made stick bow are equally appropriate to bore-sight a 1940's machine gun.
But, in the end of it, you have three distinct streams of ammunition re-supply, and this starts to feel a lot less like gameplay and a lot more like a transparent effort to stretch the running time.
Bioshock has the sometimes-reviled "Vita-Chambers." Which are an in-game hand-wave towards how your character is able to restore from a save point. I don't have problem with them per se, except to say they don't get you anything. The in-universe explanation is ludicrous and you never see anyone else using them, nor does anyone in game seem to recognize that they are being used. Now, if Splicers camped the nearest Vita-Chamber, that might make a little more sense. But, really, you've just replaced one lack of explanation for an equal lack of explanation. Only one that is wearing a large blue-glowing lampshade.
Save points are an essential problem in game design. You achieve desired difficulty through there being a real chance of failure. But failure can not be punished too excessively or the player stops playing. I've had a least one game that required you restart and re-load a saved game, and that was so onerous the game lost all fun.
On the other hand, something like Tomb Raider: Legends, where you almost-instantly reset to a convenient place (with all health restored), makes death such a revolving door suicide becomes a viable gameplay option.
Bioshock started to carry through something with the Vita-Chambers in that they restore you with marginal health and Eve. The old space game Escape Velocity escape pod option plays out similarly; you lose your current ship and at least some of your reputation. In at least one version of the game, if you lost a battle to pirates you would have cargo and money stolen then be left drifting without power for the further ignominy of having to plead with passing ships for a little help.
I could sort of see this being carried through in an FPS, where making a mistake and getting shot means you are shown in cut-scene somehow finding cover to crawl into -- or being rescued by locals -- and then restart play with most of your weapons gone and your health hanging by a thread, with your first task being re-supply.
Except there's that old punishment problem again. If the player avatar gets killed/incapacitated often, then the penalty can't be too large or take too long or the player will quit in disgust after the third or fourth time of going through it. And when you make the drawbacks of resurrection too low and/or the process too fast and painless, you take the bite out of death and take the challenge out of playing.
I played Bioshock through to the end of Arcadia on "Medium" difficulty, but the big set-piece battle in the labs I ended up hitting the Vita-Chamber every few minutes. I literally would run out of the Vita-Chamber, attack the remaining Splicers with whatever weapon happened to be equipped at the moment, kill one, die, be sent back to the Vita-Chamber. Lather, rinse, repeat until all the Splicers were finally dead. It really took the thrill out.
At least a proper save point means you face the same challenge and have to get through it at least once from the top. You can't just chip away at it. (But then, this is the theory behind why some games limit the number of save points -- to keep you from save-scrumming through a really tough section. Me, I think the choice should be made by the player. You should be able to balance perceived risk and rewards, weighing whether to spend the time saving the game versus the pain of having to go back to the previous save point.)
Really, this is an extension of the Health Pack problem. At least, in the Bioshock universe it makes in-game sense why Health Packs work. And why guns are relatively weak; everyone is all Adam'd up to be much less vulnerable. And this is why rocket-propelled grenades and flame throwers are in the vending machines -- and they kill just about as effectively as they do in the real world. Being able to shrug off a couple 38 slugs does not translate into resisting two pounds of explosive warhead!
Bioshock also partly answers the Hero Success problem. Although it seems to you that you are pretty much a beginning Splicer -- literally just off the boat, access to the same weapons and Eve that they have -- you can believe you are doing well even early on because you aren't, at least, batshit insane. The Splicers are so easily distracted, prone to fratricide, and otherwise just as likely to get themselves killed as to successfully attack you, it is not entirely unbelievable you make it through them alive.
Later on, of course, you realize you are Jack Ryan, and the turrets are shooting at you less, the cameras take longer to find you, and every safe, door, and vending machine is easier for you to hack than it is for anyone else other than you or dear old dad.
Still, it does beg the question of if the Splicers are so into trying every plasmid they can inject, why so many of them shoot at you with guns, and why even the ones with plasmid-based attacks specialize in only one (and aren't even that good at it). Again; they've all got rubber hose and distilled water in their pockets; why aren't they are the Maker-Space-o-Matic making their own frag grenades?
For some reason, stealth and environmental kills feel more "realistic" in these sorts of ordinary-man-fights-off-skilled-ninjas situations. Even in the movies it seems to work. Put the hero in a "Draw, pardner" situation and it feels unlikely that they win the shootout. But let them come up with some stupid contrivance with a cart, a robe, and some straw and it feels reasonable. Relatively speaking.
Tomb Raider 2013 would have felt a lot better if that sort of thing had been made the rule. And they had the space for it; Lara shows an aptitude towards climbing and she's small enough to get into spaces the Solarii can't. It is established in several places in the game that the mooks simply don't expect someone to be able to approach from a certain direction, and otherwise have their guard down.
But then the game throws it all away by letting you, often forcing you, and apparently expecting you to do stand-up gun brawls with upwards of a dozen mooks firing automatic weapons. And you hose them down with an identical weapon and no explanation of your superior standing. Half-life got the same way, but at least had the hand-wave of the HEV suit. That, and the contrived circumstances that let Gordon constantly appear in the least expected place.
Bioshock nearly falls in the same direction, particularly after Jack downs so many plasmids he can take out a Big Daddy with a monkey wrench. Fontaine should be nearly unstoppable. Instead he's a typical boss fight, and easily taken down with a few grenades.
That said, Bioshock takes the hyperspace arsenal problem and doubles it. I found it frustrating and difficult even after some creative keyboard re-mapping to be able to actually reach the right combinations of weapons and plasmids amid the tumult of a battle.
The game gives you too many choices. It seems to expect you to be using them, too. Adding to the various tonics, the plasmids, the ammunition choices, the various strategies of distance, melee, fratricide via plasmid, trap-laying, and hacking, it also has an entire side mechanic of Researching.
At some point in the middle of combat while watching your three and nine for flankers, keeping an eye on Eve and Ammo (the game handles depletion badly and inconsistently. When you run low on Eve, you will re-inject in a time-consuming animation that can get you killed if you were just about to swing a wrench in a close-in melee. But if you run low on a speciality ammunition, no reload occurs until you page through all your ammunition types to find one you still have in stock), and of course trying to get the right weapons selected, you are expected to whip out a camera and take a nicely framed picture of your attacker, which after you've taken enough will tell you which kind of ammunition does them the most damage.
And, yes, Splicers do have typical video-game sound signatures. So, technically, you could hear a Splicer singing to themselves from around the corner, select and load up the optimum weapon combination, then jump at them.
In practice, if you do so you'll find yourself staring at a security camera that you need to rapidly switch weapons and/or plasmids in order to deal with, and the Splicers travel in mixed packs anyhow. Which is why most players seem to settle on one or two weapons and just use those.
Which in turn means that all that foofraw with U-Invent stations and weapon drops and cash drops and so forth is just annoyance, because you can never seem to be able to find ammunition for the weapon you've decided to settle on. You don't need more variety, and you don't need upgrade for the weapons you never use. You just want a way to reload the one you are comfortable with.
The much-touted "Moral Choice" is hardly that. It is presented pretty clearly from the first moment as "be relatively nice" or "eat kittens." The closest it comes to nuance is you only earn the good ending if you avoid eating even a single one.
I differ from other reviewers, however, in saying that there is no ludonarrative dissonance here. I think Jack is faced with essentially the same choice the player is faced with. The attraction of new plasmids against the moral repugnance of harming the Little Sisters.
I think the closest this comes to being true is that it is expected the player wants to fight Big Daddies. They can't resist the challenge. Internally, it is a lot less justified for Jack to tangle with them. Me, I think Jack and I pretty much agreed on the big guys. In this nightmarish world full of mad Splicers killing everything that moved, they were the only thing that didn't mess with me. They just tromped around, groaning, minding their own business. Sometimes Splicers would take them on, and they'd put a stop to that. Which I was also totally in favor of. And there's a moment in the animation where the Little Sister says "Come along, slowpoke," and the Big Daddy groans and adjusts it's heavy tank and regulator before lumbering after her. I can totally sympathize.
Given the choice, I'd leave them alone. Sure, Tennenbaum wants you to "rescue" the Little Sisters, but from where I stand, they seem happy enough and are pretty well adjusted to living in this freaky place. Being a little girl without spooky powers and a giant robotic-appearing guardian does not seem to have good long-term prospects in Rapture.
The reasoning to do otherwise is in-game, at least. Jack is put in position of "the only person who can save us" and has to selfishly chose to gather Adam in order to be be able to take on Fontaine. And that means attacking the Big Daddies, no matter how much that makes the Little Sisters cry. But at least you can still chose to rescue them instead of "harvesting" them.
(To add insult to the simplicity of the false moral choice, you only get half the Adam if you refrain from killing the little girls. And if you refrain twice, Tennenbaum shows up with a magical teddy bear containing more Adam than any three. So it isn't a moral choice, as much as it is a test for how stupid immorality can make you. One way or another, you'll have more plasmids than you know what to do with before the middle of the game).
This is also a complaint about the RPG element. Like at least one other game I've been naming a lot recently, Bioshock apparently gives you options to specialize your character growth, but practically speaking you'll end up with all the slots filled soon enough regardless on the order you chose to fill them.
I chose to specialize in hacking, but there are a lot of tonics you find if you explore (especially in the earlier levels, it is well worth checking out every nook and cranny. And after you get telekinesis, is worth keeping an eye open for extra ammo and Eve vials that are half-hidden on remote ledges or behind grates). Basically, you fill up your slots with random stuff long before you can make reasoned choices as to purchases.
And even then, hacking is almost entirely engineering tonics, so those slots would go unused if you didn't buff the hacking skills -- there's no trade-off involved, no loss you are taking to push those skills. So not really RPG in that way.
With that all said, the elements basically work. They are all defensible within-game, making a nice change from, say, games where clips of ammo seem to be lying around the halls at random, and stale food and old potions found on the damp and dirty floor of a dungeon are perfectly safe and indeed urgent to imbibe immediately.
The hacking mini-game is innocuous enough and it is a lot of fun to hack not just turrets but first aid stations and let Splicers blow themselves up. The ammunition choices don't seem to make a critical difference and there are far too many weapons, but even though only a small number of plasmids are worth keeping at the ready, it is awful fun to mess around a little and use some of the more outrageous powers to give a Splicer a bad day (the game thoughtfully gives you an episode in which your genetic code is going amuck and you basically get handed a random plasmid to experiment with every minute or so.)
The atmospherics are wonderful, early stages of the game are quite spooky and the extended episode with the mad artist fellow bring that spookiness right back up. And for those that empathize with the Big Daddies, there's a point late in the game where you can really indulge that feeling. The various oral diaries are a hoot and even the Splicers are fun to listen to (for at least a little).
And the ending is moving, and sufficient. I'd like it if it cut to titles instead of dropping you back to the main loading screen, though; that moment really needs a quiet time to follow to let it sink in a little and move through the catharsis.
Family, indeed. Another good thought for the holidays. Even if you do spend some of it behind a computer...and under the sea.
It is tempting to approach Bioshock with hindsight, forgetting just how many innovations it introduced to a wider audience. The combination of first-person-shooter gunplay and survival-game ambience was relatively new. The world-building was exceptional not just for a new level of technical achievement, but for an integrated and cohesive vision that made internal sense (instead of being just a series of spectacular backdrops). Even Crafting -- present in nascent form -- was essentially new.
However, the game survives well. Like the Lord of the Rings, it may have been followed by enough others to lend a certain jaded familiarity with the ideas, but it still holds up as doing a good job with them.
But let's just take this as established and move on; it was a very good game and deserved its acclaim then, and it is quite playable and does not feel in the least bit retro or awkward now. Whatever you can say on the technical side -- low-poly models, simplistic AI, canned and repetitive dialog -- the game recognized these technical limitations and constructed story and level and character design and gameplay to make the best possible use of them.
In short, it largely avoids the uncanny valley problem by choosing characters that are already firmly deep in the trench. The splicer's rote behavior becomes not emblematic of poor coding, but of their own befuddled brains. Similar can be said of the physical design of Rapture itself. Draw distance and skybox are hardly an issue when you are in a narrow corridor deep under the sea.
With that said, the rest of this essay is going to be about some of those elements of gameplay and design choices and what they say about evolving game design in general.
First off, and sharing a problem Tomb Raider 2013 had much, much worse, Bioshock may have too much in the box. It seems the accepted design that when you put RPG elements into an FPS (err..Role Playing Game elements into a First-Person Shooter -- I'm going to try to stay away from the technical and the acronyms but this is going to slide away from general readership regardless), you end up with multiple streams of weapon-and-health support.
As in every FPS from Doom on, you can pick up ammunition from enemy drops. You can find it just lying around the landscape (at least Bioshock is restrained in this -- in many games the random ammunition boxes become almost as ludicrous as the frequent health packs). You can also purchase it (a nice Bioshock innovation is that, contextually, vending machines for ammunition make sense in that universe.) And you can craft it.
Which is my first complaint, really. Crafting is cute, but when you get right down to it, it is a different vending machine. Or a different weapons drop. I have yet to see a Crafting system that let you make something truly unique (I can't really imagine how you could code it up!) So instead, this is just "expensive" ammunition. Which technically is not available to anyone else in the game world, except that they can and do use the same Crafting machines you do, plus -- to Craft, you need raw supplies, and you find those on enemy dead or in the usual supply cabinets.
So when you get right down to it, Crafting is just like purchasing ammunition with money you found on a body or hidden in a crate, only it is barter goods instead of cash. It is slightly more limited, but at the same time you don't get any real choice as to what you collect. You can't go out to the Rubber Hose Tree because you have everything else but that to make new RPG rounds.
At least they've avoided the extremes of Fallout 3, where you are carrying so many scraps of rusted metal and stale bread you have to rent a storage locker to put them in. Or the opposite extreme of Tomb Raider 2013, in which the open pool of "salvage" begins to suggest that the materials for strengthening a home-made stick bow are equally appropriate to bore-sight a 1940's machine gun.
But, in the end of it, you have three distinct streams of ammunition re-supply, and this starts to feel a lot less like gameplay and a lot more like a transparent effort to stretch the running time.
Bioshock has the sometimes-reviled "Vita-Chambers." Which are an in-game hand-wave towards how your character is able to restore from a save point. I don't have problem with them per se, except to say they don't get you anything. The in-universe explanation is ludicrous and you never see anyone else using them, nor does anyone in game seem to recognize that they are being used. Now, if Splicers camped the nearest Vita-Chamber, that might make a little more sense. But, really, you've just replaced one lack of explanation for an equal lack of explanation. Only one that is wearing a large blue-glowing lampshade.
Save points are an essential problem in game design. You achieve desired difficulty through there being a real chance of failure. But failure can not be punished too excessively or the player stops playing. I've had a least one game that required you restart and re-load a saved game, and that was so onerous the game lost all fun.
On the other hand, something like Tomb Raider: Legends, where you almost-instantly reset to a convenient place (with all health restored), makes death such a revolving door suicide becomes a viable gameplay option.
Bioshock started to carry through something with the Vita-Chambers in that they restore you with marginal health and Eve. The old space game Escape Velocity escape pod option plays out similarly; you lose your current ship and at least some of your reputation. In at least one version of the game, if you lost a battle to pirates you would have cargo and money stolen then be left drifting without power for the further ignominy of having to plead with passing ships for a little help.
I could sort of see this being carried through in an FPS, where making a mistake and getting shot means you are shown in cut-scene somehow finding cover to crawl into -- or being rescued by locals -- and then restart play with most of your weapons gone and your health hanging by a thread, with your first task being re-supply.
Except there's that old punishment problem again. If the player avatar gets killed/incapacitated often, then the penalty can't be too large or take too long or the player will quit in disgust after the third or fourth time of going through it. And when you make the drawbacks of resurrection too low and/or the process too fast and painless, you take the bite out of death and take the challenge out of playing.
I played Bioshock through to the end of Arcadia on "Medium" difficulty, but the big set-piece battle in the labs I ended up hitting the Vita-Chamber every few minutes. I literally would run out of the Vita-Chamber, attack the remaining Splicers with whatever weapon happened to be equipped at the moment, kill one, die, be sent back to the Vita-Chamber. Lather, rinse, repeat until all the Splicers were finally dead. It really took the thrill out.
At least a proper save point means you face the same challenge and have to get through it at least once from the top. You can't just chip away at it. (But then, this is the theory behind why some games limit the number of save points -- to keep you from save-scrumming through a really tough section. Me, I think the choice should be made by the player. You should be able to balance perceived risk and rewards, weighing whether to spend the time saving the game versus the pain of having to go back to the previous save point.)
Really, this is an extension of the Health Pack problem. At least, in the Bioshock universe it makes in-game sense why Health Packs work. And why guns are relatively weak; everyone is all Adam'd up to be much less vulnerable. And this is why rocket-propelled grenades and flame throwers are in the vending machines -- and they kill just about as effectively as they do in the real world. Being able to shrug off a couple 38 slugs does not translate into resisting two pounds of explosive warhead!
Bioshock also partly answers the Hero Success problem. Although it seems to you that you are pretty much a beginning Splicer -- literally just off the boat, access to the same weapons and Eve that they have -- you can believe you are doing well even early on because you aren't, at least, batshit insane. The Splicers are so easily distracted, prone to fratricide, and otherwise just as likely to get themselves killed as to successfully attack you, it is not entirely unbelievable you make it through them alive.
Later on, of course, you realize you are Jack Ryan, and the turrets are shooting at you less, the cameras take longer to find you, and every safe, door, and vending machine is easier for you to hack than it is for anyone else other than you or dear old dad.
Still, it does beg the question of if the Splicers are so into trying every plasmid they can inject, why so many of them shoot at you with guns, and why even the ones with plasmid-based attacks specialize in only one (and aren't even that good at it). Again; they've all got rubber hose and distilled water in their pockets; why aren't they are the Maker-Space-o-Matic making their own frag grenades?
For some reason, stealth and environmental kills feel more "realistic" in these sorts of ordinary-man-fights-off-skilled-ninjas situations. Even in the movies it seems to work. Put the hero in a "Draw, pardner" situation and it feels unlikely that they win the shootout. But let them come up with some stupid contrivance with a cart, a robe, and some straw and it feels reasonable. Relatively speaking.
Tomb Raider 2013 would have felt a lot better if that sort of thing had been made the rule. And they had the space for it; Lara shows an aptitude towards climbing and she's small enough to get into spaces the Solarii can't. It is established in several places in the game that the mooks simply don't expect someone to be able to approach from a certain direction, and otherwise have their guard down.
But then the game throws it all away by letting you, often forcing you, and apparently expecting you to do stand-up gun brawls with upwards of a dozen mooks firing automatic weapons. And you hose them down with an identical weapon and no explanation of your superior standing. Half-life got the same way, but at least had the hand-wave of the HEV suit. That, and the contrived circumstances that let Gordon constantly appear in the least expected place.
Bioshock nearly falls in the same direction, particularly after Jack downs so many plasmids he can take out a Big Daddy with a monkey wrench. Fontaine should be nearly unstoppable. Instead he's a typical boss fight, and easily taken down with a few grenades.
That said, Bioshock takes the hyperspace arsenal problem and doubles it. I found it frustrating and difficult even after some creative keyboard re-mapping to be able to actually reach the right combinations of weapons and plasmids amid the tumult of a battle.
The game gives you too many choices. It seems to expect you to be using them, too. Adding to the various tonics, the plasmids, the ammunition choices, the various strategies of distance, melee, fratricide via plasmid, trap-laying, and hacking, it also has an entire side mechanic of Researching.
At some point in the middle of combat while watching your three and nine for flankers, keeping an eye on Eve and Ammo (the game handles depletion badly and inconsistently. When you run low on Eve, you will re-inject in a time-consuming animation that can get you killed if you were just about to swing a wrench in a close-in melee. But if you run low on a speciality ammunition, no reload occurs until you page through all your ammunition types to find one you still have in stock), and of course trying to get the right weapons selected, you are expected to whip out a camera and take a nicely framed picture of your attacker, which after you've taken enough will tell you which kind of ammunition does them the most damage.
And, yes, Splicers do have typical video-game sound signatures. So, technically, you could hear a Splicer singing to themselves from around the corner, select and load up the optimum weapon combination, then jump at them.
In practice, if you do so you'll find yourself staring at a security camera that you need to rapidly switch weapons and/or plasmids in order to deal with, and the Splicers travel in mixed packs anyhow. Which is why most players seem to settle on one or two weapons and just use those.
Which in turn means that all that foofraw with U-Invent stations and weapon drops and cash drops and so forth is just annoyance, because you can never seem to be able to find ammunition for the weapon you've decided to settle on. You don't need more variety, and you don't need upgrade for the weapons you never use. You just want a way to reload the one you are comfortable with.
The much-touted "Moral Choice" is hardly that. It is presented pretty clearly from the first moment as "be relatively nice" or "eat kittens." The closest it comes to nuance is you only earn the good ending if you avoid eating even a single one.
I differ from other reviewers, however, in saying that there is no ludonarrative dissonance here. I think Jack is faced with essentially the same choice the player is faced with. The attraction of new plasmids against the moral repugnance of harming the Little Sisters.
I think the closest this comes to being true is that it is expected the player wants to fight Big Daddies. They can't resist the challenge. Internally, it is a lot less justified for Jack to tangle with them. Me, I think Jack and I pretty much agreed on the big guys. In this nightmarish world full of mad Splicers killing everything that moved, they were the only thing that didn't mess with me. They just tromped around, groaning, minding their own business. Sometimes Splicers would take them on, and they'd put a stop to that. Which I was also totally in favor of. And there's a moment in the animation where the Little Sister says "Come along, slowpoke," and the Big Daddy groans and adjusts it's heavy tank and regulator before lumbering after her. I can totally sympathize.
Given the choice, I'd leave them alone. Sure, Tennenbaum wants you to "rescue" the Little Sisters, but from where I stand, they seem happy enough and are pretty well adjusted to living in this freaky place. Being a little girl without spooky powers and a giant robotic-appearing guardian does not seem to have good long-term prospects in Rapture.
The reasoning to do otherwise is in-game, at least. Jack is put in position of "the only person who can save us" and has to selfishly chose to gather Adam in order to be be able to take on Fontaine. And that means attacking the Big Daddies, no matter how much that makes the Little Sisters cry. But at least you can still chose to rescue them instead of "harvesting" them.
(To add insult to the simplicity of the false moral choice, you only get half the Adam if you refrain from killing the little girls. And if you refrain twice, Tennenbaum shows up with a magical teddy bear containing more Adam than any three. So it isn't a moral choice, as much as it is a test for how stupid immorality can make you. One way or another, you'll have more plasmids than you know what to do with before the middle of the game).
This is also a complaint about the RPG element. Like at least one other game I've been naming a lot recently, Bioshock apparently gives you options to specialize your character growth, but practically speaking you'll end up with all the slots filled soon enough regardless on the order you chose to fill them.
I chose to specialize in hacking, but there are a lot of tonics you find if you explore (especially in the earlier levels, it is well worth checking out every nook and cranny. And after you get telekinesis, is worth keeping an eye open for extra ammo and Eve vials that are half-hidden on remote ledges or behind grates). Basically, you fill up your slots with random stuff long before you can make reasoned choices as to purchases.
And even then, hacking is almost entirely engineering tonics, so those slots would go unused if you didn't buff the hacking skills -- there's no trade-off involved, no loss you are taking to push those skills. So not really RPG in that way.
With that all said, the elements basically work. They are all defensible within-game, making a nice change from, say, games where clips of ammo seem to be lying around the halls at random, and stale food and old potions found on the damp and dirty floor of a dungeon are perfectly safe and indeed urgent to imbibe immediately.
The hacking mini-game is innocuous enough and it is a lot of fun to hack not just turrets but first aid stations and let Splicers blow themselves up. The ammunition choices don't seem to make a critical difference and there are far too many weapons, but even though only a small number of plasmids are worth keeping at the ready, it is awful fun to mess around a little and use some of the more outrageous powers to give a Splicer a bad day (the game thoughtfully gives you an episode in which your genetic code is going amuck and you basically get handed a random plasmid to experiment with every minute or so.)
The atmospherics are wonderful, early stages of the game are quite spooky and the extended episode with the mad artist fellow bring that spookiness right back up. And for those that empathize with the Big Daddies, there's a point late in the game where you can really indulge that feeling. The various oral diaries are a hoot and even the Splicers are fun to listen to (for at least a little).
And the ending is moving, and sufficient. I'd like it if it cut to titles instead of dropping you back to the main loading screen, though; that moment really needs a quiet time to follow to let it sink in a little and move through the catharsis.
Family, indeed. Another good thought for the holidays. Even if you do spend some of it behind a computer...and under the sea.
The Fundamental Attribution Error
Many people don't code. According to some academic studies, a significant number can't code; there is some essential conceptual block they have yet to hurdle. Of course this is controversial, and complex, and much-discussed.
I was just browsing the usual blogs on this cold morning and The Daily WTF had dug up the old fizzbuzz problem sometimes given as an interview question for new software developer hires. And an intriguing statement came out of one of the following links; that poor programmers didn't stumble on just the big, complicated problems, but on little problems as well. The problem seems to be with what some of us used to call thinking like the computer (the oft-repeated "it does what you said, not what you meant" problem).
And I can't help thinking that there may be links to the tech/non-tech dichotomy as well, plus could throw in the oft-observed (but less well studied) apparent statistical correlation between programmers and people on the autistic spectrum.
One of the articles I've looked at suggests that the problem may lie in modeling. That non-programmers attempt to map the behavior of a system to their existing internal models of the world, but programmers are willing to accept and work within the constraints of the machine's unique (and often counter-intuitive) internal model instead.
This seems to me to have some application to mathematics, and even a few soft sciences as well (ethnomusicology leaps to mind -- a difficult field to write academically in because you simultaneously have to work within a culture's unique mapping of the sound space, but document what they produce within the not-always-perfect mapping of the shared language of western tradition.)
The other thought that springs out is that rules-based behavior -- which I have noticed among non-technical people and commented on before -- makes sense within this mapping problem. In a rules-based system, you only have your internal model of the larger universe. Instead of abstracting and intuiting the internal state of a device or system, you establish a narrow, filtered connection to it.
Rules-based behavior -- what I also call magical thinking -- is a list of empirical solutions. I'm going to go back again to a simple system I observed at an old workplace. There were work lights in the wing that needed to be turned off during the play. Since the room could be approached from two directions, the original electricians had put in a two-way switch; you could switch on or off from either end of the room.
The tech approach is to model the system. Usually by direct experimentation (aka, flip the switches, figure out how it works). Or, more importantly, figure out an internal model; the truth table of that set of switches. Rules-based behavior wants to map a single action, (press this switch) to a desired result (turn the lights off). The user of a rules-based system needs to have made available a system that can be abstracted and limited to this simplicity.
The first attempt at documenting the rule was to label the switch. "Up" was equivalent to lights "On." The map matched the territory -- until the next time someone flipped the switch at the other end of the room. Now the map didn't match the territory. The solution? Re-label the switch, and tape over the other switch.
As a sound engineer or as a general stage technician one sees this sort of thing all the time. The usual wave-off is you are working with people who don't have the time or the interest to learn how the gadget they are abusing actually works. So we put up with equipment that breaks at inconvenient times (like in the middle of the show). But I've got a growing belief that this isn't a good picture -- that our model is incorrect.
Because we don't require the musicians on stage or the stage manager fumbling with a headset to understand the internal electronics of the gear. Sure, that may be the framework the technician used to arrive at their understanding. But it isn't necessary to get through a couple of years of technical eduction and basic electronics to construct a proper model of the underlying system.
What we may be dealing with, in short, is that same non-programmer problem; people who are unable to make the mental leap to modeling a system as it is, instead of trying to cram its behavior into their established system of beliefs.
I've often noticed and remarked on the difference in behavior between the tech and non-tech, the Morlock and Eloi of our overly-stretched and far-too-contrasty comparison here. Confronted with a new piece of technical equipment, the Morlock plays with it. The Eloi approaches tentatively, and only presses a control when they are assured that is the right button to press. When questioned, they may say they are "afraid of breaking something."
The Morlock scoffs that gear is harder to break than that. But that ignores two very important caveats behind their approach. The first is a robust general model formed from similar pieces of gear that informs them of the safe envelope for experimentation. They may flip all the switches on the surface of a new mixer safe in the knowledge that they probably can't break anything, but they know better than to fiddle with the small black switch cryptically labeled "120/240" on the back of the thing!
Plus, the Morlock knows that if they break it, they can probably fix it, and if it was that easy to break in the first place it probably needed to be replaced anyhow.
The Fundamental Attribution Error in psychology is, basically, attributing the behavior of others to internal factors ("He is such a rude person") whereas one's own behavior is seen as driven by external factors ("Sure I hung up on him, but he asked for it.")
Assignment is a fundamental error in programming (and in C-like typography, an error that everyone makes on a regular basis without requiring the influence of a poor mental model). The same interviewers who were startled at how many would-be programmers could not formulate an approach to a test problem in the fizzbuzz class were not particularly surprised by educators who found up to eighty percent of the students in first-year comp sci could not correctly answer;
a = 10;
b = 20;
a = b;
if (a < b) {
///does this line run?
}
(The more usual form of this mistake for most of us is "If (a = b){..." aka; typing "=" or assignment when we meant to type "==" or equivalence. Fortunately, the compiler tends to catch this kind of error!)
Apparently, though, and according to at least a small number of academic studies, the error of the students is not typographically based but stems from an incorrect or entirely missing internal model of how attribution works.
And as for fizzbuzz? I left it to the last, because it is also a truism that if you bring up fizzbuzz around any group of programmers discussion will instantly devolve into better (or, at least, more unique and esoteric) ways of programming it. There is something in the programmer that can not resist the urge to solve the problem -- well over the urge to discuss the context of solving the problem.
Yes, I immediately thought of my own. Using modulus, of course. But even if I had tackled it five years ago, before I realized the sheer power of "If (a % 5 == 0){", I could still have come up with a solution. It is a matter of matching the problem space with the space of the tools at hand. If nothing else, "If (a == 3 || a == 6 || a == 9..." would do the job, even if frighteningly brute-force. (Or for the true glutton, a "switch/case" stack 100 items long...)
And I don't know if this idea of being unable to adopt the internal model of the machine is a reasonable explanation for why some people don't seem to have the tech gene. I do know that trying to apply a (small) set of rules is not going to get you through a fizzbuzz problem.
Which may be the simplest way of looking at a thing that may be over-stated and over-complexed; that the Eloi problem is, in short, trying to simplify a complicated world into too small a set of rules.
Meanwhile, I'm spending Christmas morning sitting at home alone thinking about conceptual problems in computer programming. And if that isn't suggestive of a position somewhere on the high-functioning end of the spectrum, I don't know what is!
(Truth is -- I'm listening to Christmas-themed jazz tunes, the sun is coming through my window, I just got off the phone with Mom and I'm thinking about re-heating that pumpkin pie, and I'd say that life is pretty durn good.)
I was just browsing the usual blogs on this cold morning and The Daily WTF had dug up the old fizzbuzz problem sometimes given as an interview question for new software developer hires. And an intriguing statement came out of one of the following links; that poor programmers didn't stumble on just the big, complicated problems, but on little problems as well. The problem seems to be with what some of us used to call thinking like the computer (the oft-repeated "it does what you said, not what you meant" problem).
And I can't help thinking that there may be links to the tech/non-tech dichotomy as well, plus could throw in the oft-observed (but less well studied) apparent statistical correlation between programmers and people on the autistic spectrum.
One of the articles I've looked at suggests that the problem may lie in modeling. That non-programmers attempt to map the behavior of a system to their existing internal models of the world, but programmers are willing to accept and work within the constraints of the machine's unique (and often counter-intuitive) internal model instead.
This seems to me to have some application to mathematics, and even a few soft sciences as well (ethnomusicology leaps to mind -- a difficult field to write academically in because you simultaneously have to work within a culture's unique mapping of the sound space, but document what they produce within the not-always-perfect mapping of the shared language of western tradition.)
The other thought that springs out is that rules-based behavior -- which I have noticed among non-technical people and commented on before -- makes sense within this mapping problem. In a rules-based system, you only have your internal model of the larger universe. Instead of abstracting and intuiting the internal state of a device or system, you establish a narrow, filtered connection to it.
Rules-based behavior -- what I also call magical thinking -- is a list of empirical solutions. I'm going to go back again to a simple system I observed at an old workplace. There were work lights in the wing that needed to be turned off during the play. Since the room could be approached from two directions, the original electricians had put in a two-way switch; you could switch on or off from either end of the room.
The tech approach is to model the system. Usually by direct experimentation (aka, flip the switches, figure out how it works). Or, more importantly, figure out an internal model; the truth table of that set of switches. Rules-based behavior wants to map a single action, (press this switch) to a desired result (turn the lights off). The user of a rules-based system needs to have made available a system that can be abstracted and limited to this simplicity.
The first attempt at documenting the rule was to label the switch. "Up" was equivalent to lights "On." The map matched the territory -- until the next time someone flipped the switch at the other end of the room. Now the map didn't match the territory. The solution? Re-label the switch, and tape over the other switch.
As a sound engineer or as a general stage technician one sees this sort of thing all the time. The usual wave-off is you are working with people who don't have the time or the interest to learn how the gadget they are abusing actually works. So we put up with equipment that breaks at inconvenient times (like in the middle of the show). But I've got a growing belief that this isn't a good picture -- that our model is incorrect.
Because we don't require the musicians on stage or the stage manager fumbling with a headset to understand the internal electronics of the gear. Sure, that may be the framework the technician used to arrive at their understanding. But it isn't necessary to get through a couple of years of technical eduction and basic electronics to construct a proper model of the underlying system.
What we may be dealing with, in short, is that same non-programmer problem; people who are unable to make the mental leap to modeling a system as it is, instead of trying to cram its behavior into their established system of beliefs.
I've often noticed and remarked on the difference in behavior between the tech and non-tech, the Morlock and Eloi of our overly-stretched and far-too-contrasty comparison here. Confronted with a new piece of technical equipment, the Morlock plays with it. The Eloi approaches tentatively, and only presses a control when they are assured that is the right button to press. When questioned, they may say they are "afraid of breaking something."
The Morlock scoffs that gear is harder to break than that. But that ignores two very important caveats behind their approach. The first is a robust general model formed from similar pieces of gear that informs them of the safe envelope for experimentation. They may flip all the switches on the surface of a new mixer safe in the knowledge that they probably can't break anything, but they know better than to fiddle with the small black switch cryptically labeled "120/240" on the back of the thing!
Plus, the Morlock knows that if they break it, they can probably fix it, and if it was that easy to break in the first place it probably needed to be replaced anyhow.
The Fundamental Attribution Error in psychology is, basically, attributing the behavior of others to internal factors ("He is such a rude person") whereas one's own behavior is seen as driven by external factors ("Sure I hung up on him, but he asked for it.")
Assignment is a fundamental error in programming (and in C-like typography, an error that everyone makes on a regular basis without requiring the influence of a poor mental model). The same interviewers who were startled at how many would-be programmers could not formulate an approach to a test problem in the fizzbuzz class were not particularly surprised by educators who found up to eighty percent of the students in first-year comp sci could not correctly answer;
a = 10;
b = 20;
a = b;
if (a < b) {
///does this line run?
}
(The more usual form of this mistake for most of us is "If (a = b){..." aka; typing "=" or assignment when we meant to type "==" or equivalence. Fortunately, the compiler tends to catch this kind of error!)
Apparently, though, and according to at least a small number of academic studies, the error of the students is not typographically based but stems from an incorrect or entirely missing internal model of how attribution works.
And as for fizzbuzz? I left it to the last, because it is also a truism that if you bring up fizzbuzz around any group of programmers discussion will instantly devolve into better (or, at least, more unique and esoteric) ways of programming it. There is something in the programmer that can not resist the urge to solve the problem -- well over the urge to discuss the context of solving the problem.
Yes, I immediately thought of my own. Using modulus, of course. But even if I had tackled it five years ago, before I realized the sheer power of "If (a % 5 == 0){", I could still have come up with a solution. It is a matter of matching the problem space with the space of the tools at hand. If nothing else, "If (a == 3 || a == 6 || a == 9..." would do the job, even if frighteningly brute-force. (Or for the true glutton, a "switch/case" stack 100 items long...)
And I don't know if this idea of being unable to adopt the internal model of the machine is a reasonable explanation for why some people don't seem to have the tech gene. I do know that trying to apply a (small) set of rules is not going to get you through a fizzbuzz problem.
Which may be the simplest way of looking at a thing that may be over-stated and over-complexed; that the Eloi problem is, in short, trying to simplify a complicated world into too small a set of rules.
Meanwhile, I'm spending Christmas morning sitting at home alone thinking about conceptual problems in computer programming. And if that isn't suggestive of a position somewhere on the high-functioning end of the spectrum, I don't know what is!
(Truth is -- I'm listening to Christmas-themed jazz tunes, the sun is coming through my window, I just got off the phone with Mom and I'm thinking about re-heating that pumpkin pie, and I'd say that life is pretty durn good.)
Saturday, December 20, 2014
...Shining at the Frankenstein Place
My design goals were in error, and most of the math was thus based on the wrong assumptions. The revised target was for a light that would be visible primarily during black-outs.
Which is perhaps calculable, but if you tried to point Wolfram-Alpha at figuring the threshold of detection from an actor who is within a handful of seconds from having been exposed to full stage lighting...well, I think it would spit up.
In any case, a 20ma LED, even run down at around 6-7ma, is plenty bright enough. 20 degrees is a bit too narrow for the expected off-axis viewing and 40-60 is better.
Also, even more importantly, I "wasted" several hours drawing up plans for laser-cut acrylic when it turns out there are battery boxes available for about a buck fifty each. "Wasted," because I was at rehearsal anyhow and getting paid for that.
In any case, the project is spec'd, tested, and documented.
Working within parts available at the local Radio Shack (which, despite boarded-up windows appears to still be in business) the unit cost is about $2.50. Purchasing in bulk through DigiKey, I can get it down to $1.75 each. And build time is minimal.
As with most of my work, this is open hardware. The full Instructable is up, of course; at
http://www.instructables.com/id/Build-a-Stage-Marker-Light
Which is perhaps calculable, but if you tried to point Wolfram-Alpha at figuring the threshold of detection from an actor who is within a handful of seconds from having been exposed to full stage lighting...well, I think it would spit up.In any case, a 20ma LED, even run down at around 6-7ma, is plenty bright enough. 20 degrees is a bit too narrow for the expected off-axis viewing and 40-60 is better.
Also, even more importantly, I "wasted" several hours drawing up plans for laser-cut acrylic when it turns out there are battery boxes available for about a buck fifty each. "Wasted," because I was at rehearsal anyhow and getting paid for that.
In any case, the project is spec'd, tested, and documented.
Working within parts available at the local Radio Shack (which, despite boarded-up windows appears to still be in business) the unit cost is about $2.50. Purchasing in bulk through DigiKey, I can get it down to $1.75 each. And build time is minimal.
As with most of my work, this is open hardware. The full Instructable is up, of course; at
http://www.instructables.com/id/Build-a-Stage-Marker-Light
Wednesday, December 17, 2014
Lux Life
I just got a priority project dumped on me. I'm trying to figure out if I can build a better stage edge light.
The client goal was to break the existing price point and deliver something cheaper. Unfortunately, that price point is $11 and I'm not sure I can get significantly cheaper.
The one thing I can do is provide a lot better performance at that price point.
The existing commercial product is dead-simple; a 9v battery clip modified to hold a naked 4ma LED. Very simple, small, easy to maintain...but that's the best of it. Undirected and extremely lossy, as 9v "transistor" batteries are much more expensive than AA cells, and since LED forward voltage is under 3v, most of that extra voltage is being wasted as heat in the regulator.
So it is obvious to design around AA/AAA, especially as those already exist in profusion in the theater world, and are better-established in the rechargeable options as well (why I opted for 3xAAA as the standard for my DuckLight).
The LED is a little more of a question. 20ma is easily available in that size, but what is the actual desired intensity? After trying several different estimation models, including illumination, visual astronomy, and f-stop estimation, I've zeroed in to assuming the LED will be behind a diffusor that in turn is tucked into a hood (or otherwise is blocked from direct audience view.
Using a whole bunch of loose assumptions, such as calling typical lux at the front edge of the stage 400-600, calling the albedo of dance marly .1 and ignoring the anisotropic shading model (which will come back to bite me, I know) I end up with a desired lux of around 100 before the self-illuminated surface can be clearly discerned from the background illumination.
So the smaller the surface, the better, right? Well, now we switch to the angular resolution of the human eye, which works out to about half a centimeter from the back of the stage. Except that resolution is actually all over the map when comparing relative magnitudes -- we can see stars, after all, and we don't have the optical power to resolve those.
Still, the numbers are converging around a 1cm^2 diffusor driven by 5-20ma as being "probably" visible from on stage. Omitting glare, of course. Plus the actor or dancer is facing right at sources (the face light) that are several magnitudes greater, and the instantaneous magnitude range of the human eye is only 3-4 f-stops.
This is going to have to be calculated when I work on making a light that can be seen against the glare of the shin-busters to allow a dancer to run off stage. (Well, since they normally navigate by the shin-busters, the real calculation is how much their eye will dark-adapt during the brief moments of a black-out as they race towards a red blinking safety light in the wings).
Unfortunately the battery numbers are not coming out where I'd like them. The competition boasts 125 hours (my calculation confirms this is possible for their setup) and that won't last the week. Running full-out with 20ma, even with the much greater capacity of "penlight" cells I can't stretch to the length of a run.
So the optimal design appears to be 2xAA, which has a slightly larger profile than 2xAAA but will last for ten days. That means the user places fresh cells in during prep for the weekend's performances, and leaves them on over the weekend. That is the best option for mechanical simplicity, cost, and limiting the failure modes (both mechanical and human error).
(I may still go for AAA, which gives a theoretical life at max output of four days. The 4x battery performance I'm getting out of penlight batteries is balanced by the 4x output power I'm aiming for in the design).
For simplicity, the diffusion may be simple cavity reflection; the "hood" is also the diffusor. Which does bring to question, however, if I want to design a tilting head so the same unit could be used for side lights. Actually, though...there's no reason it has to be designed with the light output axial with the batteries. It could be orthogonal to their long axis. This isn't a flashlight, after all!
My best guess at this point is a laser-cut acrylic "housing." The quotes are there because I don't need to close off the battery compartment. I just need to keep the batteries in place. So an open framework with a flat bottom makes the most sense (the flat bottom designed for double-stick tape, screws, or magnets to fasten it in place...provide pockets for supermagnets in the design.)
To get a true picture of the cost, then, I have to upload files to Ponoko. Even if I do intend to laser them myself at TechShop, I am entering into this on a non-profit, open-hardware basis.
Now what I really need is a name (so I can refer to it in project notes and folder names more efficiently). "mouseLight" works for me. Especially since I am working out the details for this over a production of "Nutcracker."
The client goal was to break the existing price point and deliver something cheaper. Unfortunately, that price point is $11 and I'm not sure I can get significantly cheaper.
The one thing I can do is provide a lot better performance at that price point.
The existing commercial product is dead-simple; a 9v battery clip modified to hold a naked 4ma LED. Very simple, small, easy to maintain...but that's the best of it. Undirected and extremely lossy, as 9v "transistor" batteries are much more expensive than AA cells, and since LED forward voltage is under 3v, most of that extra voltage is being wasted as heat in the regulator.
So it is obvious to design around AA/AAA, especially as those already exist in profusion in the theater world, and are better-established in the rechargeable options as well (why I opted for 3xAAA as the standard for my DuckLight).
The LED is a little more of a question. 20ma is easily available in that size, but what is the actual desired intensity? After trying several different estimation models, including illumination, visual astronomy, and f-stop estimation, I've zeroed in to assuming the LED will be behind a diffusor that in turn is tucked into a hood (or otherwise is blocked from direct audience view.
Using a whole bunch of loose assumptions, such as calling typical lux at the front edge of the stage 400-600, calling the albedo of dance marly .1 and ignoring the anisotropic shading model (which will come back to bite me, I know) I end up with a desired lux of around 100 before the self-illuminated surface can be clearly discerned from the background illumination.
So the smaller the surface, the better, right? Well, now we switch to the angular resolution of the human eye, which works out to about half a centimeter from the back of the stage. Except that resolution is actually all over the map when comparing relative magnitudes -- we can see stars, after all, and we don't have the optical power to resolve those.
Still, the numbers are converging around a 1cm^2 diffusor driven by 5-20ma as being "probably" visible from on stage. Omitting glare, of course. Plus the actor or dancer is facing right at sources (the face light) that are several magnitudes greater, and the instantaneous magnitude range of the human eye is only 3-4 f-stops.
This is going to have to be calculated when I work on making a light that can be seen against the glare of the shin-busters to allow a dancer to run off stage. (Well, since they normally navigate by the shin-busters, the real calculation is how much their eye will dark-adapt during the brief moments of a black-out as they race towards a red blinking safety light in the wings).
Unfortunately the battery numbers are not coming out where I'd like them. The competition boasts 125 hours (my calculation confirms this is possible for their setup) and that won't last the week. Running full-out with 20ma, even with the much greater capacity of "penlight" cells I can't stretch to the length of a run.
So the optimal design appears to be 2xAA, which has a slightly larger profile than 2xAAA but will last for ten days. That means the user places fresh cells in during prep for the weekend's performances, and leaves them on over the weekend. That is the best option for mechanical simplicity, cost, and limiting the failure modes (both mechanical and human error).
(I may still go for AAA, which gives a theoretical life at max output of four days. The 4x battery performance I'm getting out of penlight batteries is balanced by the 4x output power I'm aiming for in the design).
For simplicity, the diffusion may be simple cavity reflection; the "hood" is also the diffusor. Which does bring to question, however, if I want to design a tilting head so the same unit could be used for side lights. Actually, though...there's no reason it has to be designed with the light output axial with the batteries. It could be orthogonal to their long axis. This isn't a flashlight, after all!
My best guess at this point is a laser-cut acrylic "housing." The quotes are there because I don't need to close off the battery compartment. I just need to keep the batteries in place. So an open framework with a flat bottom makes the most sense (the flat bottom designed for double-stick tape, screws, or magnets to fasten it in place...provide pockets for supermagnets in the design.)
To get a true picture of the cost, then, I have to upload files to Ponoko. Even if I do intend to laser them myself at TechShop, I am entering into this on a non-profit, open-hardware basis.
Now what I really need is a name (so I can refer to it in project notes and folder names more efficiently). "mouseLight" works for me. Especially since I am working out the details for this over a production of "Nutcracker."
Monday, December 15, 2014
Flash! Aaaaah....!
Between shifts over the run of Nutcracker I've been getting a lot of work done on my RGB light. Finally tracked down a constant-current driver that seems nearly perfect; the AMC7135.
Back up a hair. LEDs are current devices. Once forward voltage is achieved, current flow will increase near-logarithmically over only small increases in voltage; a runaway process leading to overheating and breakdown. Thus current limiters are needed.
The most basic is a series resistor. Basically, the resistor is chosen so that the current across it (calculated assuming the voltage drop across the LED is constant), is the same as that desired for the LED. Pick the right resistor, the loop current remains under the limit. The problems are two; all the voltage above the necessary forward voltage of the LED is transformed to heat in the resistor, and, the resistor is only of the correct value when the voltage is stable.
The better regulation is essentially a transistor that uses the current flow in a feedback loop, thus holding the current at a desired point. With the right components, these circuits will compensate for a range of voltages and, as well, react thermally in the correct direction to compensate for the changing behavior of LED and circuit as it warms up.
However, the typical packages I was finding were a couple bucks each and required up to a dozen external discrete components; capacitors, resistors, signal diodes, zener diodes, even inductors. Which was a lot of parts to be adding to a small board especially when I wanted to control three channels or more of LED.
But the AMC7135 is the ticket. Unlike many current limiters, it is preset internally to 350ma. It requires essentially no external components. And it may be a usage that's out of spec, but it can be successfully PWM'd. There are in fact high-end flashlights that use this exact circuit.
Again to step back; LEDs require a minimum voltage, and when this voltage is achieved will consume as much current as you let them. This makes them poor candidates for resistance dimming. The best way to control their intensity is to turn them on and off quite rapidly. By varying the ratio of time on to time off, you achieve a nice control of intensity.
Do this to red, green, and blue LEDs and you can achieve a decent range of colors as well.
Which is what I've been trying to do for over a year; to create an extremely cheap, small, high-power colored light that can be used inside props, on costumes, and in other theatrical applications. There are a lot of commercial packages that are similar, but few offer two of the things I find important for this application; tight control, and battery power.
Control turns out to be the sticky issue. What I really don't want is all those cheap LED toys; things you have to hold down a button and scroll through different colors to get to the one you want. This is non-optimal for theatrical use. It should be able to be set so when the actor (or the light board operator) hits a switch it lights up the right way the first time.
Proof-of-concept; ATtiny controlling two channels of a 3W LED via darlington transistors, on a 4xAAA battery pack. When you hold down the button it does a candle flicker.
There are also commercial products that allow you to dial up a preset -- from infrared controllers to full DMX-512 wireless solutions to the pretty-durn-close BlinkM. Where all but the BlinkM fail for me is that they are fiddly (or expensive). We don't want a lighting controller gaff-taped to a nearby wall with sticky tape pointing at the right preset. That's just another kind of over-complicated work around. Again, we want a user-programmed preset. After the light is set, it just plain turns on.
The only real failings of the BlinkM for me is lack of power for theatrical use, and some lack of flexibility in the existing controller software. Which might just be a conflicting paradigm thing (they went with a drum machine model for animations, I went for a flexible event-based system for mine).
The BlinkM from ThinkM.
So...I've had the high-power, hard-programmed RGB working. I had it on a costume in a show, and over the show it did exactly as required. The problem is, setting the desired look was a programming task. It was done with the skills, the knowledge of the circuit's behavior, and the programming tools I own.
The "Wiz" jacket, switching between free-running light animations when commanded remotely from the simple GUI shown on the laptop beside it.
What I want is for anyone to be able to purchase a kit or make the open-hardware light, set it to a theatrically useful look (oil lamp, say), and be done with it. But I am having no luck making the power I desire accessible to the end-user I envision.
Also, on the hardware side, if I make each individual light capable of simple stand-alone programming, it increases the unit cost. It makes too much sense to offload as much as the hardware as possible even if that does mean the end-user needs a minimum of two things to get started instead of one.
Hardware USB is the most transparent option. To put it on each individual light, though, increases their cost excessively. Plus the varied solutions are non-optimal in different ways. USB is a complex protocol, and there are no all-platform open definitions for producing a virtual COM port from it -- which is what is needed to allow one to write a nice user-friendly front-end (or even to surf in to the device via Terminal and program it on a command-line basis).
The older Arduinos used a translator chip from FTDI to handle interface to the user's USB port -- which also required a driver to be installed to show up on some platforms. There are AVR chips that are USB-native, but like the FTDI they are surface-mount devices and add considerably to the cost and effort of putting together each light.
HID is actually a lot easier; you can get a class-compliant HID with out-of-spec modeling of proper USB behavior, and it will still be recognized by most computers as a keyboard. There is even a clever hack that translates extra characters on this virtual keyboard into a fake serial port. But it requires multiple pieces of helper software and probably doesn't work on Mac yet.
Clever Arduino compatibles like the Trinket get by because the programming port used by avrdude is not per se a serial port. Basically, you can program an AVR using another non-USB compliant AVR (or even program itself with a clever enough bootloader) but it can't be made to show up as a serial port.
So, unless I want to write a wrapper for avrdude that presents a simplified GUI to the end-user but invokes the avrgcc toolchain behind the screen (too many pitfalls there I'm afraid), the best option is to move the expense of this USB-to-serial translation off the light and into a second board.
The BlinkM does it quite cleverly. It is programmed via a I2C connection, which is done using the soft serial code on an Arduino. Simply put, you plug the header of the BlinkM into matching pins on an Arduino header, run the provided Arduino sketch to turn the Arduino into a I2C to USB translator, then run the BlinkM programming software.
Somewhat similarly, you can once you have the complete Arduino software up and running, use an Arduino (with or without invoking soft serial -- in the old days it was done just by prying the ATmega itself out of the socket) to patch you though to the AVR you want to program. You could even use the Arduino IDE to write and upload the program.
And that's what I'm going to do. Only with an additional wrinkle. The power user can and should write their own software into the light. But for someone who just needs to specify the exact color it boots up into, or how long it takes to fade out when turned off, I am going to provide a space for user presets in non-volatile memory. So the end-user will use either FTDI cable (which are widely available in Arduino circles), or an Arduino with the appropriate software, to plug into the light node. They will try out different looks and then commit the look of their choice to one of the slots of user memory.
If and when I get that far, I can wrap this in a proper GUI. But before then, this behavior of going direct to looks or presets and setting the boot preset is also exactly what I want for inter-node communication.
Because the other thing I want to put on these lights that doesn't exist in any cheap, easy-to-use, prop-and-theater-friendly option is remote control.
The proof-of-concept for a accelerometer-based effect; this combined accelerometer, XBee module, and AAA battery pack to detect a throwing gesture and play a sound effect from a remote receiver.
At the base of it is a protocol to let each node communicate bidirectionally. I'm doing it this way, instead of using existing buses like I2C, for transparency as I program. The BAUD rate I envision may be low, but I can still afford to send ASCII nouns rather than cryptic hexadecimal sequences.
I envision a complex prop that might have several lighting nodes each playing canned animations in free-running mode, and a single controller just telling them when to switch on and off. This is also how we will interact wirelessly; you won't control a candle flicker in real time, you will command it to light, then blow out.
A sticking point at the moment is the RF option itself. I'd like to provision each lighting node with the basic circuitry, omitting only the expensive transceiver. But between level shifting and LDO and of course a couple status lights, it may add too much to the individual cost and complexity.
This is worse when considering the transceiver options. Now, there are a lot of cheap, off-the-shelf 434 kHz, Bluetooth, etc. options. But all of them are inadequate for theater. They offer fifty feet of transmission in line-of-sight. Theater requires shooting two hundred and fifty feet through set walls and a fifty-member dance ensemble.
The leading options I have now are the Hope RF chips -- particularly the RFM69W and HW chips -- and the XBee series.
Trouble is, the Hope chips appear to require four digital pins to communicate with them properly, and the code to navigate their communications protocol eats up a full 8K of program memory. Which makes them pretty much impossible to run from an ATtiny, and pushes them up into "requires a late-model Arduino to operate" territory.
The XBees are simple and transparent and I've been using them in actual theater situations. Their major drawbacks are frequency and price. They are 2.5 GHz devices, and shorter wavelength radio has poor penetration of obstacles. The "Pro" models, which have the necessary power to punch from light booth to backstage, are upwards of forty bucks each.
So down the road, I hope to get the Hope chips working for me, but for now I'm going to have to hope that only a few of the more expensive transceivers are needed by the typical end-user.
And as for interfacing with the worlds of DMX-512 and MIDI; I'm holding off there. I see this as happening via software (aka a laptop with a DMX-512 dongle) even though it would be a lot more turn-key if it was a single stand-alone DMX-512 module. But getting one of those up to spec and robust, it would end up costing pretty close to the commercial models that are already available. So not really something I need to explore at the moment.
But, at last, I'm nailing down the specs on the basic light module. I should be able to get the first order out to the fab house for printed-circuit boards this week. Maybe even assemble one in time for my coming lighting design.
Here's the major parts. Power supply 3.7V to 5v; aka lithium poly, 5v wall wart, or 3x "penlight" batteries (AA or AAA). The latter is my preferred choice for theater due to the ease of swapping in freshly-charged cells (rechargeable or otherwise).
I have a bunch of 3W RGB's to start with, but I've found RGBW's available for about twice the price and those will provide a much nicer mix for typical theater applications (candles, lanterns, headlights...) Unfortunately RBGA or RGB+ "Warm" White (4,000 K) are harder to come by at budget prices.
The buck driver on the right there is there to illustrate mostly the SOT-89 surface-mount footprint of the AMC7135's, of which I'll be provisioning four of. A nice additional quality of these things; you can run them in parallel to drive higher wattage LEDs.
The controller chip looks at this point to be an ATtiny 20-pin, probably the attiny861A because of its 8K of program memory. I do love the 25/45/85, but there just aren't enough pins. Even the ATtiny84 is pushing it for sufficient pins -- and doesn't have the nice UART of the larger, more expensive chip. The various chips to the lower left are standing in for that footprint. I'm going through-hole and socket for ease in assembly and replacement.
I haven't decided on the header; whether to go with the 2x3 ICSP type or the 6-inline format shared by the FTDI cable and other similar devices. And I'm still pondering whether the XBee will be on the main board or have a daughterboard (for which the Adafruit board at the top right is standing in). The trade-off, as always, is between a compact footprint and lots of out-of-the-box functionality, versus price per item. Because I have to anticipate situations in which you'd want a dozen of these things scattered around as part of a more complicated lighting effect, and that would be a lot easier if I could keep them under $10 each.
Back up a hair. LEDs are current devices. Once forward voltage is achieved, current flow will increase near-logarithmically over only small increases in voltage; a runaway process leading to overheating and breakdown. Thus current limiters are needed.
The better regulation is essentially a transistor that uses the current flow in a feedback loop, thus holding the current at a desired point. With the right components, these circuits will compensate for a range of voltages and, as well, react thermally in the correct direction to compensate for the changing behavior of LED and circuit as it warms up.
However, the typical packages I was finding were a couple bucks each and required up to a dozen external discrete components; capacitors, resistors, signal diodes, zener diodes, even inductors. Which was a lot of parts to be adding to a small board especially when I wanted to control three channels or more of LED.
But the AMC7135 is the ticket. Unlike many current limiters, it is preset internally to 350ma. It requires essentially no external components. And it may be a usage that's out of spec, but it can be successfully PWM'd. There are in fact high-end flashlights that use this exact circuit.
Again to step back; LEDs require a minimum voltage, and when this voltage is achieved will consume as much current as you let them. This makes them poor candidates for resistance dimming. The best way to control their intensity is to turn them on and off quite rapidly. By varying the ratio of time on to time off, you achieve a nice control of intensity.
Do this to red, green, and blue LEDs and you can achieve a decent range of colors as well.
Which is what I've been trying to do for over a year; to create an extremely cheap, small, high-power colored light that can be used inside props, on costumes, and in other theatrical applications. There are a lot of commercial packages that are similar, but few offer two of the things I find important for this application; tight control, and battery power.
Proof-of-concept; ATtiny controlling two channels of a 3W LED via darlington transistors, on a 4xAAA battery pack. When you hold down the button it does a candle flicker.
There are also commercial products that allow you to dial up a preset -- from infrared controllers to full DMX-512 wireless solutions to the pretty-durn-close BlinkM. Where all but the BlinkM fail for me is that they are fiddly (or expensive). We don't want a lighting controller gaff-taped to a nearby wall with sticky tape pointing at the right preset. That's just another kind of over-complicated work around. Again, we want a user-programmed preset. After the light is set, it just plain turns on.
The BlinkM from ThinkM.
So...I've had the high-power, hard-programmed RGB working. I had it on a costume in a show, and over the show it did exactly as required. The problem is, setting the desired look was a programming task. It was done with the skills, the knowledge of the circuit's behavior, and the programming tools I own.
What I want is for anyone to be able to purchase a kit or make the open-hardware light, set it to a theatrically useful look (oil lamp, say), and be done with it. But I am having no luck making the power I desire accessible to the end-user I envision.
Also, on the hardware side, if I make each individual light capable of simple stand-alone programming, it increases the unit cost. It makes too much sense to offload as much as the hardware as possible even if that does mean the end-user needs a minimum of two things to get started instead of one.
Hardware USB is the most transparent option. To put it on each individual light, though, increases their cost excessively. Plus the varied solutions are non-optimal in different ways. USB is a complex protocol, and there are no all-platform open definitions for producing a virtual COM port from it -- which is what is needed to allow one to write a nice user-friendly front-end (or even to surf in to the device via Terminal and program it on a command-line basis).
The older Arduinos used a translator chip from FTDI to handle interface to the user's USB port -- which also required a driver to be installed to show up on some platforms. There are AVR chips that are USB-native, but like the FTDI they are surface-mount devices and add considerably to the cost and effort of putting together each light.
HID is actually a lot easier; you can get a class-compliant HID with out-of-spec modeling of proper USB behavior, and it will still be recognized by most computers as a keyboard. There is even a clever hack that translates extra characters on this virtual keyboard into a fake serial port. But it requires multiple pieces of helper software and probably doesn't work on Mac yet.
Clever Arduino compatibles like the Trinket get by because the programming port used by avrdude is not per se a serial port. Basically, you can program an AVR using another non-USB compliant AVR (or even program itself with a clever enough bootloader) but it can't be made to show up as a serial port.
So, unless I want to write a wrapper for avrdude that presents a simplified GUI to the end-user but invokes the avrgcc toolchain behind the screen (too many pitfalls there I'm afraid), the best option is to move the expense of this USB-to-serial translation off the light and into a second board.
The BlinkM does it quite cleverly. It is programmed via a I2C connection, which is done using the soft serial code on an Arduino. Simply put, you plug the header of the BlinkM into matching pins on an Arduino header, run the provided Arduino sketch to turn the Arduino into a I2C to USB translator, then run the BlinkM programming software.
Somewhat similarly, you can once you have the complete Arduino software up and running, use an Arduino (with or without invoking soft serial -- in the old days it was done just by prying the ATmega itself out of the socket) to patch you though to the AVR you want to program. You could even use the Arduino IDE to write and upload the program.
And that's what I'm going to do. Only with an additional wrinkle. The power user can and should write their own software into the light. But for someone who just needs to specify the exact color it boots up into, or how long it takes to fade out when turned off, I am going to provide a space for user presets in non-volatile memory. So the end-user will use either FTDI cable (which are widely available in Arduino circles), or an Arduino with the appropriate software, to plug into the light node. They will try out different looks and then commit the look of their choice to one of the slots of user memory.
If and when I get that far, I can wrap this in a proper GUI. But before then, this behavior of going direct to looks or presets and setting the boot preset is also exactly what I want for inter-node communication.
The proof-of-concept for a accelerometer-based effect; this combined accelerometer, XBee module, and AAA battery pack to detect a throwing gesture and play a sound effect from a remote receiver.
At the base of it is a protocol to let each node communicate bidirectionally. I'm doing it this way, instead of using existing buses like I2C, for transparency as I program. The BAUD rate I envision may be low, but I can still afford to send ASCII nouns rather than cryptic hexadecimal sequences.
I envision a complex prop that might have several lighting nodes each playing canned animations in free-running mode, and a single controller just telling them when to switch on and off. This is also how we will interact wirelessly; you won't control a candle flicker in real time, you will command it to light, then blow out.
A sticking point at the moment is the RF option itself. I'd like to provision each lighting node with the basic circuitry, omitting only the expensive transceiver. But between level shifting and LDO and of course a couple status lights, it may add too much to the individual cost and complexity.
This is worse when considering the transceiver options. Now, there are a lot of cheap, off-the-shelf 434 kHz, Bluetooth, etc. options. But all of them are inadequate for theater. They offer fifty feet of transmission in line-of-sight. Theater requires shooting two hundred and fifty feet through set walls and a fifty-member dance ensemble.
The leading options I have now are the Hope RF chips -- particularly the RFM69W and HW chips -- and the XBee series.
Trouble is, the Hope chips appear to require four digital pins to communicate with them properly, and the code to navigate their communications protocol eats up a full 8K of program memory. Which makes them pretty much impossible to run from an ATtiny, and pushes them up into "requires a late-model Arduino to operate" territory.
The XBees are simple and transparent and I've been using them in actual theater situations. Their major drawbacks are frequency and price. They are 2.5 GHz devices, and shorter wavelength radio has poor penetration of obstacles. The "Pro" models, which have the necessary power to punch from light booth to backstage, are upwards of forty bucks each.
So down the road, I hope to get the Hope chips working for me, but for now I'm going to have to hope that only a few of the more expensive transceivers are needed by the typical end-user.
And as for interfacing with the worlds of DMX-512 and MIDI; I'm holding off there. I see this as happening via software (aka a laptop with a DMX-512 dongle) even though it would be a lot more turn-key if it was a single stand-alone DMX-512 module. But getting one of those up to spec and robust, it would end up costing pretty close to the commercial models that are already available. So not really something I need to explore at the moment.
But, at last, I'm nailing down the specs on the basic light module. I should be able to get the first order out to the fab house for printed-circuit boards this week. Maybe even assemble one in time for my coming lighting design.Here's the major parts. Power supply 3.7V to 5v; aka lithium poly, 5v wall wart, or 3x "penlight" batteries (AA or AAA). The latter is my preferred choice for theater due to the ease of swapping in freshly-charged cells (rechargeable or otherwise).
I have a bunch of 3W RGB's to start with, but I've found RGBW's available for about twice the price and those will provide a much nicer mix for typical theater applications (candles, lanterns, headlights...) Unfortunately RBGA or RGB+ "Warm" White (4,000 K) are harder to come by at budget prices.
The buck driver on the right there is there to illustrate mostly the SOT-89 surface-mount footprint of the AMC7135's, of which I'll be provisioning four of. A nice additional quality of these things; you can run them in parallel to drive higher wattage LEDs.
The controller chip looks at this point to be an ATtiny 20-pin, probably the attiny861A because of its 8K of program memory. I do love the 25/45/85, but there just aren't enough pins. Even the ATtiny84 is pushing it for sufficient pins -- and doesn't have the nice UART of the larger, more expensive chip. The various chips to the lower left are standing in for that footprint. I'm going through-hole and socket for ease in assembly and replacement.
I haven't decided on the header; whether to go with the 2x3 ICSP type or the 6-inline format shared by the FTDI cable and other similar devices. And I'm still pondering whether the XBee will be on the main board or have a daughterboard (for which the Adafruit board at the top right is standing in). The trade-off, as always, is between a compact footprint and lots of out-of-the-box functionality, versus price per item. Because I have to anticipate situations in which you'd want a dozen of these things scattered around as part of a more complicated lighting effect, and that would be a lot easier if I could keep them under $10 each.
Thursday, December 11, 2014
It Ain't the Heat, it's the Humidity
Actually, it is both.
A very simple bit of physics. The speed of sound changes due to the density of the air. Which means altitude, temperature, and humidity.
The absorption of sound by air (that is, the way acoustic energy falls off with distance in addition to the geometry of inverse-square dispersion), also changes with humidity, and this is frequency-dependent.
But let's take the first. Assume you EQ'd your house until the speaker response was nice and flat. Well, when the audience walks in, you've got a problem.
What is room EQ? Two things, primarily. There's the response curve of the speakers and amps. And there's the response of the room. This latter is due largely to multipath reflection. Sound comes from a speaker. It travels across the audience, hits the back wall, reflects back over that same audience. Where the two paths meet, parts of the waveform will be in phase and combine, others will be out of phase and destructively interfere. Thus, peaks and valleys in the response -- the most prominent of which can be related directly back to the dimensions of the room itself.
So what happens if the speed of sound changes? The two paths increase or decrease in time. But they do so as a proportion, as a percentage, of their previous time. Which means the phase relationship changes. Which means the peaks and valleys are not in the same place.
Which means that 2 kHz peak you notched out of the mains is no longer there, and you are taking a 2 kHz cut in the middle of the sound. And there's a new, uncorrected peak at 2.5 kHz. Or maybe 1.5 kHz -- depending on how the speed of sound changes, and how it relates mathematically to the critical dimensions of the room.
Oh, yes. And the temperature and humidity does change. Not only does each human body in the audience pump 100 watts of heat into the air, each gives off water vapor, raising the humidity. And that's not the worst of it. The graph changes radically between 10% and 30% humidity. Which means starting with a dry room and introducing warm sweaty bodies will have a much greater effect on the speed of sound in your venue than you might expect.
And that's before we even get to considering the frequency-dependent attenuation that also takes place over that critical humidity curve. Which -- just to put icing on the cake -- is most prominent at 12.5 kHz; right in the middle of our frequencies of interest.
A very simple bit of physics. The speed of sound changes due to the density of the air. Which means altitude, temperature, and humidity.
The absorption of sound by air (that is, the way acoustic energy falls off with distance in addition to the geometry of inverse-square dispersion), also changes with humidity, and this is frequency-dependent.
But let's take the first. Assume you EQ'd your house until the speaker response was nice and flat. Well, when the audience walks in, you've got a problem.
What is room EQ? Two things, primarily. There's the response curve of the speakers and amps. And there's the response of the room. This latter is due largely to multipath reflection. Sound comes from a speaker. It travels across the audience, hits the back wall, reflects back over that same audience. Where the two paths meet, parts of the waveform will be in phase and combine, others will be out of phase and destructively interfere. Thus, peaks and valleys in the response -- the most prominent of which can be related directly back to the dimensions of the room itself.
So what happens if the speed of sound changes? The two paths increase or decrease in time. But they do so as a proportion, as a percentage, of their previous time. Which means the phase relationship changes. Which means the peaks and valleys are not in the same place.
Which means that 2 kHz peak you notched out of the mains is no longer there, and you are taking a 2 kHz cut in the middle of the sound. And there's a new, uncorrected peak at 2.5 kHz. Or maybe 1.5 kHz -- depending on how the speed of sound changes, and how it relates mathematically to the critical dimensions of the room.
Oh, yes. And the temperature and humidity does change. Not only does each human body in the audience pump 100 watts of heat into the air, each gives off water vapor, raising the humidity. And that's not the worst of it. The graph changes radically between 10% and 30% humidity. Which means starting with a dry room and introducing warm sweaty bodies will have a much greater effect on the speed of sound in your venue than you might expect.
And that's before we even get to considering the frequency-dependent attenuation that also takes place over that critical humidity curve. Which -- just to put icing on the cake -- is most prominent at 12.5 kHz; right in the middle of our frequencies of interest.
A Perfect Storm
There's a renter that comes into my usual theater space every December. We typically have 3-5 technicians on our overhire list, so we split up the shifts to cover the gig. This year, there's just me, and I've got the entire thing. My hours from Sunday were 14, 13, 12...and then a mere 6 (plus two hours in a meeting across town on another show).
Over the same period that protests have been marching through town tying up traffic, breaking windows, setting fires, and attracting news helicopters that sit over our apartment loudly clattering away until the wee hours of the morning.
The protests finally stopped...as a record-breaking storm moved in, rattling windows all night, knocking down power lines, and flooding half the streets.
That's a twelve-hour shift of climbing ladders, by the by, with maybe fifteen minutes to grab a bite (no lunch or dinner break). And then little sleep due to riots and weather. And little food due to being almost broke.
And you know what? I feel great.
Over the same period that protests have been marching through town tying up traffic, breaking windows, setting fires, and attracting news helicopters that sit over our apartment loudly clattering away until the wee hours of the morning.
The protests finally stopped...as a record-breaking storm moved in, rattling windows all night, knocking down power lines, and flooding half the streets.
That's a twelve-hour shift of climbing ladders, by the by, with maybe fifteen minutes to grab a bite (no lunch or dinner break). And then little sleep due to riots and weather. And little food due to being almost broke.
And you know what? I feel great.
Pan With a Real Handle
...which was a mildly clever pitch I heard some years ago from a pan-handler in The Haight, near the "pan handle" of Golden Gate Park.
Anyhow, I'm getting into a lighting design now. Nice little space, about twenty dimmers to play with (but some LED pars that should take up some of the slack).
And once again, I learn more about the goals for a circuit I'm designing when an actual application comes along. There's an old-style radio in the show and the dialog makes a point of that nice tube glow.
Seems like a good application for the Duck Light; dial up a good "glowing tube" red-amber, rig it to a button....wait. The current version is color-programmed off-line. There's no provision for real-time adjustment of the color.
Right. So I really do need to set up a software chain that, at the least, allows real-time dialing of a color selection and pushing that into permanent flash memory.
And in the nature of this play, I'd really want the effect to be both remotely controlled, and DMX controlled. I had envisioned running complex effects off a laptop, but for this show, it would be nice to have a modular, turn-key, DMX-512 solution instead.
So this is once again something the BlinkM already does, and one better; it has a primitive sequencer built in, and uploads fresh code via its own custom GUI-based IDE. It makes it nearly trivial for the end-user to select color and simple animations the will operate in free-running mode.
I'm still caught on how to offer programming flexibility without the overhead of FTDI or other USB toolchain -- since I'm not really up for adapting any of the open-source serial-over-USB code bases myself!
Anyhow, I'm getting into a lighting design now. Nice little space, about twenty dimmers to play with (but some LED pars that should take up some of the slack).
And once again, I learn more about the goals for a circuit I'm designing when an actual application comes along. There's an old-style radio in the show and the dialog makes a point of that nice tube glow.
Seems like a good application for the Duck Light; dial up a good "glowing tube" red-amber, rig it to a button....wait. The current version is color-programmed off-line. There's no provision for real-time adjustment of the color.
Right. So I really do need to set up a software chain that, at the least, allows real-time dialing of a color selection and pushing that into permanent flash memory.
And in the nature of this play, I'd really want the effect to be both remotely controlled, and DMX controlled. I had envisioned running complex effects off a laptop, but for this show, it would be nice to have a modular, turn-key, DMX-512 solution instead.
So this is once again something the BlinkM already does, and one better; it has a primitive sequencer built in, and uploads fresh code via its own custom GUI-based IDE. It makes it nearly trivial for the end-user to select color and simple animations the will operate in free-running mode.
I'm still caught on how to offer programming flexibility without the overhead of FTDI or other USB toolchain -- since I'm not really up for adapting any of the open-source serial-over-USB code bases myself!
Thursday, December 4, 2014
KP Duty
Spent a full day at TechShop milling, grinding, and most especially filing. It looks like all the parts from the parts kit will more-or-less fit:
The shroud retaining lever fits, but the shaft was sheered near where the nut would be. Right now it is a tight friction fit but if I want to be really nice, I need to cut off the shaft, press-fit a new one, and thread that for a new retaining nut.
The magazine catch release appears to fit in the existing slot, with the pin being press-fit. At the very least I have to re-drill the holes, as one got slagged over.
The charging handle appears to be assembled through the gun, with the bolt catcher also pinned on. Sounds very fiddly to do! (I don't even know how you can press the -- missing -- pin in once the side rails are welded on).
I just figured it out. There's a hole in the side plates that is drilled slightly larger than the retaining pin. Trouble is, this requires moving the bolt back slightly from out of battery -- something no longer possible since I welded it in. But I should be able to just mill the slot a bit further and make it work.
The sight was wrenched off but even straightened, the remains of the rivets do not appear to be located properly. So I'll need to grind those off, possibly re-mill the slot a little to achieve a proper fit, then drill new holes. Which I might want to tap, or use soft brass on, so the next person along doesn't have to lever the sight assembly off.
The trigger assembly is held at the front by a block with a notch in it; only the stub of this block remains as the rest was in the direct path of the cut. So I have a few hours yet -- among other things, cleaning off the cosmoleum or whatever it is on the remaining original parts so they fit and move properly.
On the receiver itself: it is never going to look pristine, and I spent all morning with diamond bit and small hand files just re-shaping the barrel lugs after my last attempt to fill some of the remaining voids. But at the same time, it is starting to look decent and it might just be worth trying to fill the two worst gaps; the remaining slot in the side plates, and the small gaps to either side of the end cap. The latter are visible when the weapon is assembled.
To do the latter, I'll want to lathe up a new backing plug from the last of my 1-1/4" aluminium rod. Although since the bolt is now a permanent part of the rebuilt receiver, there's no good reason to keep any more of the rear clear than is needed for the rod that is part of the end cap. The big downside is I'm sure to damage the threads again, and have to grind and file those some more.
The side plates are a bit more troublesome. I had a long and difficult time trimming weld metal that made it past the end of my last set of backing plates, so I'm leery of welding near the tube. But pretty much, would be milling a chunk of aluminium plate to stand in for the trigger group. And probably milling into the existing side plates to provide a slot for fresh pieces of steel. The MIG will fill a lot, but even with a backing plate, where I fill is where I'm going to have to go back with mill and grinding bits to clean out the slot again.
I'm reading up on prep for gun bluing now. I have both brown and blue and should be able to get a nice aged patina out of them. I suspect very strongly I'm going to have to spend 10-20 hours continuing to file things smoother and smoother, then graduate to finer and finer emery papers, then finally to steel wool and wire brushes. So there's a bit of labor involved, still!
The shroud retaining lever fits, but the shaft was sheered near where the nut would be. Right now it is a tight friction fit but if I want to be really nice, I need to cut off the shaft, press-fit a new one, and thread that for a new retaining nut.
The magazine catch release appears to fit in the existing slot, with the pin being press-fit. At the very least I have to re-drill the holes, as one got slagged over.
The charging handle appears to be assembled through the gun, with the bolt catcher also pinned on. Sounds very fiddly to do! (I don't even know how you can press the -- missing -- pin in once the side rails are welded on).
I just figured it out. There's a hole in the side plates that is drilled slightly larger than the retaining pin. Trouble is, this requires moving the bolt back slightly from out of battery -- something no longer possible since I welded it in. But I should be able to just mill the slot a bit further and make it work.
The sight was wrenched off but even straightened, the remains of the rivets do not appear to be located properly. So I'll need to grind those off, possibly re-mill the slot a little to achieve a proper fit, then drill new holes. Which I might want to tap, or use soft brass on, so the next person along doesn't have to lever the sight assembly off.
The trigger assembly is held at the front by a block with a notch in it; only the stub of this block remains as the rest was in the direct path of the cut. So I have a few hours yet -- among other things, cleaning off the cosmoleum or whatever it is on the remaining original parts so they fit and move properly.
On the receiver itself: it is never going to look pristine, and I spent all morning with diamond bit and small hand files just re-shaping the barrel lugs after my last attempt to fill some of the remaining voids. But at the same time, it is starting to look decent and it might just be worth trying to fill the two worst gaps; the remaining slot in the side plates, and the small gaps to either side of the end cap. The latter are visible when the weapon is assembled.
To do the latter, I'll want to lathe up a new backing plug from the last of my 1-1/4" aluminium rod. Although since the bolt is now a permanent part of the rebuilt receiver, there's no good reason to keep any more of the rear clear than is needed for the rod that is part of the end cap. The big downside is I'm sure to damage the threads again, and have to grind and file those some more.
The side plates are a bit more troublesome. I had a long and difficult time trimming weld metal that made it past the end of my last set of backing plates, so I'm leery of welding near the tube. But pretty much, would be milling a chunk of aluminium plate to stand in for the trigger group. And probably milling into the existing side plates to provide a slot for fresh pieces of steel. The MIG will fill a lot, but even with a backing plate, where I fill is where I'm going to have to go back with mill and grinding bits to clean out the slot again.
I'm reading up on prep for gun bluing now. I have both brown and blue and should be able to get a nice aged patina out of them. I suspect very strongly I'm going to have to spend 10-20 hours continuing to file things smoother and smoother, then graduate to finer and finer emery papers, then finally to steel wool and wire brushes. So there's a bit of labor involved, still!
Tuesday, December 2, 2014
One-Piece
I welded today.
Took the SBU (Safety and Basic Use class) for the MIG welder last week. Went in today and pulled a bunch of scrap (mostly battered welding chits from previous classes) from the bin and tried to remember what I'd learned in class. I'd had a lot of trouble in class for some reason. I think because previous experience in stick welding had me used to eyeballing the arc, and the bulk of the MIG electrode holder means you really can't do it that way. So fifteen years of muscle memory was in my way.
I messed with the dial settings and made lots of nasty spots and sputters for about an hour, then it started to click. The "bacon" sound came almost immediately upon achieving a good spark coil sound (the two sounds are superimposed; you can hear when you are getting a good weld). And once I found that groove, I could pretty arbitrarily change the electrode distance and travel speed, pretty much adjusting one to the other.
It is a whole dance when you are doing it right; maintaining the arc, building and pushing the puddle, achieving the right blend of penetration and fill, controlling the heat build-up. All through constant movement whilst maintaining the correct distance and travel.
Put rougher scrap on the table and started at welding into corners and filling voids. And it was going well enough I jumped right up to working on the Suomi again.
It is nice to finally have the receiver in one piece. There's a lot of grinding and filing before I can be sure I got the measurements right, though. And I haven't decided on the best way to tackle that hole behind the magazine well. I could mill a backing plate out of aluminium plate and fill the remaining void with weld metal. Or I could cut a slot and put in new steel. Or perhaps I can mill down the stubs of the side rails enough to where I can slot in new chunks of plate steel -- probably again with a backing plate of aluminium.
I also think I have to lathe another "fake bolt" to use as a backing plate to put a little more metal at the end of the tube; the cap screws down only so far and the gaps I have would be visible in the assembled weapon. The original fake bolt I machined is of course welded permanently inside the tube at this point, and I intend to take further steps to ensure it remains so.
There's still several smaller gaps. I tried flowing solder into some of the smallest holes but my iron hasn't got the power to push heat into five pounds of steel. There's also an epoxy-based filler designed for this, but it doesn't take bluing well. I have a small brazing kit, too, but unless I get in on the TIG class some time real soon I'm looking at basically throwing big blobs of metal from the oversized wire we have and then grinding them back down again. And it may take multiple passes before I'm satisfied with it.
In any case, TechShop was very much the way to go. Sturdy steel tables, lots of clamping options, a full-sized MIG of course, and lots of bandsaws and grinders and whatnot right there to create filler with. Much more comfortable than the plywood propped up on sawhorses out in a parking lot that I started with!
It is nice to finally have the receiver in one piece. There's a lot of grinding and filing before I can be sure I got the measurements right, though. And I haven't decided on the best way to tackle that hole behind the magazine well. I could mill a backing plate out of aluminium plate and fill the remaining void with weld metal. Or I could cut a slot and put in new steel. Or perhaps I can mill down the stubs of the side rails enough to where I can slot in new chunks of plate steel -- probably again with a backing plate of aluminium.
I also think I have to lathe another "fake bolt" to use as a backing plate to put a little more metal at the end of the tube; the cap screws down only so far and the gaps I have would be visible in the assembled weapon. The original fake bolt I machined is of course welded permanently inside the tube at this point, and I intend to take further steps to ensure it remains so.
There's still several smaller gaps. I tried flowing solder into some of the smallest holes but my iron hasn't got the power to push heat into five pounds of steel. There's also an epoxy-based filler designed for this, but it doesn't take bluing well. I have a small brazing kit, too, but unless I get in on the TIG class some time real soon I'm looking at basically throwing big blobs of metal from the oversized wire we have and then grinding them back down again. And it may take multiple passes before I'm satisfied with it.
In any case, TechShop was very much the way to go. Sturdy steel tables, lots of clamping options, a full-sized MIG of course, and lots of bandsaws and grinders and whatnot right there to create filler with. Much more comfortable than the plywood propped up on sawhorses out in a parking lot that I started with!
Came home, and my laptop was showing that it was on battery. With the charger plugged in. Oops. Looked at the charger, and there was a nasty charred spot in the cord where somehow it had cracked or been caught (or nibbled?) and tore the outer wrap-around conductor. Which apparently is not a ground/shield; there's power running through it. Hrm. Anyhow, was able to work a length of desoldering braid into the frayed ends and restore continuity. Good thing, too, since closing weekend is almost on us and all my sound cues and keyboard patches and house music are on this machine!
To finish up the day, plugged the UMX-610 into a Reaper file I keep for that purpose and did a little piano practice. But what did I say about muscle memory? Maybe welding all day tuned my hands to the wrong expectations. I was fumbling a lot of notes. But oh well. I do far too many things to even hope to do all of them well.
Tuesday, November 25, 2014
Bypass Operation
Yes, it is another Tomb Raider 2013 rant. I wouldn't be doing this, really, if there wasn't so much to like about the game...
Anyhow, responding to the complaint of a strong ludonarrative dissonance, one of the developers retorted that you didn't have to kill every Solarii you encountered. You could "just bypass them."
So can you? Playing up through the Radio Tower, the totals were roughly one live body left behind for every person Lara was forced to kill. Discounting the large set-piece battles/ambushes, where it was necessary to kill everyone in order for the game to advance.
1) Deer. You have to kill a deer to trigger the "go back to the campsite with meat and get a radio call from Roth" event. I shot a couple rabbits and a crow, but no, has to be a deer. However, you can leave all of Bambi's little friends unharmed (really, one deer carcass should feed her for the rest of her island stay!) 0/0
2) Wolves. After Mathias leaves with Sam, you get stuck in a bear trap. Three wolves will charge and the only way through the semi-quicktime is to kill all three. 0/0 humans, 3/3 wolves.
3) More wolves. The game really thinks you will fight them. It puts you on a bridge with clear lanes of fire and three more bundles of fresh arrows at your feet. Instead I scramble-ran all the way up the hillside to trigger the cutscene with Whitman. Got bit a couple times but super-healing power, right? 0/0 humans, 3/5 wolves (counting only combat encounters).
4) Vladimir. Killed in a quicktime. You kill him or get killed. That's your only bullet, so bypassing the other Solarii in the scene is not a moral choice. 1/1
5) Two guys in front of a door. This is the scene I thought I could win. You are trapped in a courtyard between a fire that springs up the moment you enter, and a door that requires you pry at it with your hand axe. And...no go. The guys discover you in cutscene so you must fight them. I tried pushing them over. Tried shooting them in the knee. But no matter what I tried, the moment I started prying at the door someone would shoot a flaming arrow into it and Lara would drop the axe. 3/3
Yeah, the game is making a big point here with you getting over your first kill, being totally cornered, and choosing to fight back. So it is not a ludonarrative disconnect per se...although it is a little odd that exactly two minutes after throwing up, you are gritting your teeth and shooting people again. Plus, both headshots and finishing moves are already active by this point.
6) The Silent Kill. The game really, really, really wants you to stealth kill this one guy. It gives you fresh arrows and a cart to hide behind. And guess what? Movement keys are locked. Weapon switch is locked. It's pretty much another damned QTE; all you can do is track and fire. And if you shoot at so much as his big toe, he falls over dead. 4/4
7) Two more guys at foot of cliff. They spend a while facing each other, then one walks over towards you and will discover you. And even if you ran past them -- the rope ladder that gets you up the cliff isn't unrolled until you start shooting. If you stealth kill (what the game wants) the rope ladder guy comes down for the hell of it anyway. Regardless, you can't climb the ladder until they stop shooting at you, meaning once again, TPK. 7/7
8) The not-fireproof hut. The game has decided you are okay with shooting people in the back with a bow and wants to teach you a new trick now; to do it up close and personal. There are two bad guys with their backs to you and the game flashes up instructions on how to garrote them with your bow. Then you are supposed to get discovered by four other guys including a molotov-thrower who will set fire to the building you are fighting in. (The same move, a little later in the game, you upgrade to burying your ice axe in the back of their neck). Well, I was having none of that. I jumped over the first guy, scramble-dodged the second, took a couple flaming arrows in the butt scrambling up to the next level, scramble-ran across that while everyone was yelling and shooting, and hopped on the zipline out of there. Success! (Assuming you don't count own-goals from Mr. Firebug.) 7/13
9) Wolf in cave. Killed in a QTE. Still 7/13, and wolves are 4/6.
10) Men at top of cliff. Well, what do you know? If you wait long enough, they say "Let's go inside out of the rain," and they do. And you can actually stroll right through the camp without them seeing you. (Not only that, but there's more conversation triggered if you do so; always a bonus with the clever writing and nice voice acting). Another four lives saved, and these ones didn't finish up the encounter setting fire to themselves. 7/16
11) Men on trail before Broken Tunnel. These ones are not designed to by bypassed. If you use the zipline, they trigger. If you chose to jump, you are injured but heal...and they trigger the moment you walk any closer. All three have cover and one of them is throwing molotovs to flush you out. Hell with it; I was on easy setting; I scramble-ran right up the trail, shoved them out of the way, got hit a few times with arrows and one axe but survived long enough to wriggle into the crack to the next level. And they VO's comment on this "That's too narrow for us...we'll have to go around." The developers think of everything! 7/20.
12) Broken Tunnel. The way this is staged, you are supposed to fight your way from cover to cover against the six mooks in the courtyard, under constant fire from the machine gun, then fight your way up the stairwell to take the gunner from behind. The smart way to do it is to snipe the gunner, then silent kill all the mooks on the ground one by one.
I took the third path: I ran like hell. Rolled a lot and zig-zagged from cover to cover right through the whole mess. Now, later in the game you have to do this against Dmitri, so you know it is possible. This early on, no-one is going to break cover under fire from six guys and a heavy machine gun. Went right up the stairs, pushed the two there out of my way, jumped to the tower and had to struggle in that narrow walkway to push the other two down just long enough to climb up the ledge. They kept shooting and shooting but scenery blocked their bullets. 7/31
But the developers are still lying here. I'm using the easy setting, abusing the dodge mechanic, and relying on AI stupidity to do things that also break the ludonarrative dissonance. Lara may be, at this point in the game, reluctant to kill, but that does not in any way translate to "Cheerful about running right at a heavy machine gun!" And, no...there is no alternate path, no climb high above their heads, no concealment you can use to make a long torturous sneak. There is either combat and kill, or take an insane risk.
13) Inside the bunker, two mooks are wrestling with a big drum painted bright red and anyone who ever played a game in their life knows what they are supposed to do here. After you've killed them, another will pop out of a ceiling hatch. Instead I run, run, run, shove shove shove run run run. 7/34
14) The gas trap. The only way to advance is to light off the gas. And that fatally injures the mook with the Type 100. You can mercy kill him if you like, but irregardless, you set off a gas explosion in his face. 8/35
15) Ambush! Here the numbers go bad. The game gave you a light machine gun. It auto-selects to force it into your hands, goes into slow-mo, and glues your feet to the ground while three guys close on you with axes. On any mode other than easy, you pull the trigger or you die. I was on easy mode. I waited until the slo-mo ended, then jumped up to the balcony. Someone was already up there shooting at me so I pushed him off. And he died. OSHA is right, apparently. You can jump up and down this balcony all day, but if they fall off it, they die. And, well, stymied.
The iron door to the next room is opened by the reinforcements, and reinforcements won't come until all but two of the mooks are dead. At least I could make a partial sop to my desire to not engage in combat with them; I ran around like mad, jumping up to the balcony, pushing people off it, jumping back to the floor when it got too busy up there. Actually managed to kill about six of them without firing a shot.
The door finally opened, but the next door had the same latch problem; if you approach the door to lever it open, someone sets fire to it and Lara drops the axe. Even if there is just one guy left, and he is disabled, a flaming arrow will appear. You have to kill every last one. The only possible sop to your conscious is a couple are bomb-throwers, and you can maneuver them into own-kills. Twelve more kills; 20/47
16) Guy on the bridge. Killed in a QTE. And, no, you can't climb over the truck or anything; the only path forward is through the cutscene. 21/48
17) The bunker in front of the tower is already alerted. Now, it is actually possible to run past all of them and into the second courtyard. But the doors won't open until they send the "big guy" out, and he won't come out until you are down to two or less alive in the entire freaking complex (minus the idiot who shows up with a molotov only after everyone else is dead. He is, at least, surprised to find you alive). I lost track a little at this point. There's two at the short tower, three or four in the tower filled with handy red drums of bang, another four that spring up after you've encountered the drum people, three or so snipers in the last building, plus the first of the guys who carries a safe door around with him all shift. I gave up and shot one of the drums, then ran around the courtyard like mad trying to taunt the big guy out. Shot people in the knees, but it was so crowded down there I accidentally triggered a finishing kill animation, and then we just said the heck with it. The only person Lara didn't kill was the idiot with the molotov. Call it 12 kills; 33/60
So, yes, by the time you've reached the radio tower, you've killed over half the people you've met. And those that survived are still shooting at you; there are a grand total of three Solarii still sitting comfortably in their huts at the top of a waterfall, out of the rain, unaware of how close they came to encountering Wolverine.
I tried to go a little further with this increasingly quixotic quest. I found one loophole; there's an ambush right after you get the flaming arrows and once again you are glued to the ground with an arrow notched and will die if you don't immolate three guys. But after that, you can actually run away from the entire ambush; they eventually say "Let the guys at the gate take care of her," or words to that effect.
So that's another twenty or so who you can spare, although the gate does not allow such mercy; twenty dead there. Then the tower Grim is holed up in; you must complete that fight and kill at least a dozen. And another dozen when you've fought your way around to take it from a different angle. There is about eight on the windmill you can bypass, though. Can't sneak past them; once again, the game triggers them automatically (in fact, the one time I crawled all the way around, they actually teleported in right in front of my eyes). You might confuse or reset them by going into the nearby tomb. But if you run around like a mad weasel long enough to confuse them properly, you can jump on to the tramway and leave them behind. Three or four machine gun bullets in the back are nothing to Lara -- not on easy mode, at least.
So for those next encounters, you are forced to kill roughly 3/5 of the people you encounter. And these are larger encounters, too; the blood on your hands is up over a hundred by the time you get out of the geothermal caverns. This isn't player choice; this is built into the level design.
(Yes...the Solarii revival meeting can almost be bypassed; stealth-kill two guards, run like hell to the gas valve, blow it up to open the next door...and the dozen or more you ran past die screaming in the resulting eruption and flames. Oh, well. At this point, one needs to take notice that since you set fire to their building, at least fifty die in the flames; you see some two dozen blasted by gouts of fire, crushed by flaming debris, or falling off a roof in flames. You hear a lot more voices screaming in the distance. Still, even counting only direct player kills, you leave over a hundred bodies in your wake.)
So, no. The ludonarrative dissonance is alive and well. Me, I have my own head-cannon. Especially since I have the out-of-game knowledge that the first tortured sacrifice you see strung up is another student, a member of your expedition, and a friend, I pretty much decided my Lara went straight from fear to murderous rage. The moment she got a weapon, she was happy to kill every single cultist on that island. With an axe. Close-up.
Anyhow, responding to the complaint of a strong ludonarrative dissonance, one of the developers retorted that you didn't have to kill every Solarii you encountered. You could "just bypass them."
So can you? Playing up through the Radio Tower, the totals were roughly one live body left behind for every person Lara was forced to kill. Discounting the large set-piece battles/ambushes, where it was necessary to kill everyone in order for the game to advance.
1) Deer. You have to kill a deer to trigger the "go back to the campsite with meat and get a radio call from Roth" event. I shot a couple rabbits and a crow, but no, has to be a deer. However, you can leave all of Bambi's little friends unharmed (really, one deer carcass should feed her for the rest of her island stay!) 0/0
2) Wolves. After Mathias leaves with Sam, you get stuck in a bear trap. Three wolves will charge and the only way through the semi-quicktime is to kill all three. 0/0 humans, 3/3 wolves.
3) More wolves. The game really thinks you will fight them. It puts you on a bridge with clear lanes of fire and three more bundles of fresh arrows at your feet. Instead I scramble-ran all the way up the hillside to trigger the cutscene with Whitman. Got bit a couple times but super-healing power, right? 0/0 humans, 3/5 wolves (counting only combat encounters).
4) Vladimir. Killed in a quicktime. You kill him or get killed. That's your only bullet, so bypassing the other Solarii in the scene is not a moral choice. 1/1
5) Two guys in front of a door. This is the scene I thought I could win. You are trapped in a courtyard between a fire that springs up the moment you enter, and a door that requires you pry at it with your hand axe. And...no go. The guys discover you in cutscene so you must fight them. I tried pushing them over. Tried shooting them in the knee. But no matter what I tried, the moment I started prying at the door someone would shoot a flaming arrow into it and Lara would drop the axe. 3/3
Yeah, the game is making a big point here with you getting over your first kill, being totally cornered, and choosing to fight back. So it is not a ludonarrative disconnect per se...although it is a little odd that exactly two minutes after throwing up, you are gritting your teeth and shooting people again. Plus, both headshots and finishing moves are already active by this point.
6) The Silent Kill. The game really, really, really wants you to stealth kill this one guy. It gives you fresh arrows and a cart to hide behind. And guess what? Movement keys are locked. Weapon switch is locked. It's pretty much another damned QTE; all you can do is track and fire. And if you shoot at so much as his big toe, he falls over dead. 4/4
7) Two more guys at foot of cliff. They spend a while facing each other, then one walks over towards you and will discover you. And even if you ran past them -- the rope ladder that gets you up the cliff isn't unrolled until you start shooting. If you stealth kill (what the game wants) the rope ladder guy comes down for the hell of it anyway. Regardless, you can't climb the ladder until they stop shooting at you, meaning once again, TPK. 7/7
8) The not-fireproof hut. The game has decided you are okay with shooting people in the back with a bow and wants to teach you a new trick now; to do it up close and personal. There are two bad guys with their backs to you and the game flashes up instructions on how to garrote them with your bow. Then you are supposed to get discovered by four other guys including a molotov-thrower who will set fire to the building you are fighting in. (The same move, a little later in the game, you upgrade to burying your ice axe in the back of their neck). Well, I was having none of that. I jumped over the first guy, scramble-dodged the second, took a couple flaming arrows in the butt scrambling up to the next level, scramble-ran across that while everyone was yelling and shooting, and hopped on the zipline out of there. Success! (Assuming you don't count own-goals from Mr. Firebug.) 7/13
9) Wolf in cave. Killed in a QTE. Still 7/13, and wolves are 4/6.
10) Men at top of cliff. Well, what do you know? If you wait long enough, they say "Let's go inside out of the rain," and they do. And you can actually stroll right through the camp without them seeing you. (Not only that, but there's more conversation triggered if you do so; always a bonus with the clever writing and nice voice acting). Another four lives saved, and these ones didn't finish up the encounter setting fire to themselves. 7/16
11) Men on trail before Broken Tunnel. These ones are not designed to by bypassed. If you use the zipline, they trigger. If you chose to jump, you are injured but heal...and they trigger the moment you walk any closer. All three have cover and one of them is throwing molotovs to flush you out. Hell with it; I was on easy setting; I scramble-ran right up the trail, shoved them out of the way, got hit a few times with arrows and one axe but survived long enough to wriggle into the crack to the next level. And they VO's comment on this "That's too narrow for us...we'll have to go around." The developers think of everything! 7/20.
12) Broken Tunnel. The way this is staged, you are supposed to fight your way from cover to cover against the six mooks in the courtyard, under constant fire from the machine gun, then fight your way up the stairwell to take the gunner from behind. The smart way to do it is to snipe the gunner, then silent kill all the mooks on the ground one by one.
I took the third path: I ran like hell. Rolled a lot and zig-zagged from cover to cover right through the whole mess. Now, later in the game you have to do this against Dmitri, so you know it is possible. This early on, no-one is going to break cover under fire from six guys and a heavy machine gun. Went right up the stairs, pushed the two there out of my way, jumped to the tower and had to struggle in that narrow walkway to push the other two down just long enough to climb up the ledge. They kept shooting and shooting but scenery blocked their bullets. 7/31
But the developers are still lying here. I'm using the easy setting, abusing the dodge mechanic, and relying on AI stupidity to do things that also break the ludonarrative dissonance. Lara may be, at this point in the game, reluctant to kill, but that does not in any way translate to "Cheerful about running right at a heavy machine gun!" And, no...there is no alternate path, no climb high above their heads, no concealment you can use to make a long torturous sneak. There is either combat and kill, or take an insane risk.
13) Inside the bunker, two mooks are wrestling with a big drum painted bright red and anyone who ever played a game in their life knows what they are supposed to do here. After you've killed them, another will pop out of a ceiling hatch. Instead I run, run, run, shove shove shove run run run. 7/34
14) The gas trap. The only way to advance is to light off the gas. And that fatally injures the mook with the Type 100. You can mercy kill him if you like, but irregardless, you set off a gas explosion in his face. 8/35
15) Ambush! Here the numbers go bad. The game gave you a light machine gun. It auto-selects to force it into your hands, goes into slow-mo, and glues your feet to the ground while three guys close on you with axes. On any mode other than easy, you pull the trigger or you die. I was on easy mode. I waited until the slo-mo ended, then jumped up to the balcony. Someone was already up there shooting at me so I pushed him off. And he died. OSHA is right, apparently. You can jump up and down this balcony all day, but if they fall off it, they die. And, well, stymied.
The iron door to the next room is opened by the reinforcements, and reinforcements won't come until all but two of the mooks are dead. At least I could make a partial sop to my desire to not engage in combat with them; I ran around like mad, jumping up to the balcony, pushing people off it, jumping back to the floor when it got too busy up there. Actually managed to kill about six of them without firing a shot.
The door finally opened, but the next door had the same latch problem; if you approach the door to lever it open, someone sets fire to it and Lara drops the axe. Even if there is just one guy left, and he is disabled, a flaming arrow will appear. You have to kill every last one. The only possible sop to your conscious is a couple are bomb-throwers, and you can maneuver them into own-kills. Twelve more kills; 20/47
16) Guy on the bridge. Killed in a QTE. And, no, you can't climb over the truck or anything; the only path forward is through the cutscene. 21/48
17) The bunker in front of the tower is already alerted. Now, it is actually possible to run past all of them and into the second courtyard. But the doors won't open until they send the "big guy" out, and he won't come out until you are down to two or less alive in the entire freaking complex (minus the idiot who shows up with a molotov only after everyone else is dead. He is, at least, surprised to find you alive). I lost track a little at this point. There's two at the short tower, three or four in the tower filled with handy red drums of bang, another four that spring up after you've encountered the drum people, three or so snipers in the last building, plus the first of the guys who carries a safe door around with him all shift. I gave up and shot one of the drums, then ran around the courtyard like mad trying to taunt the big guy out. Shot people in the knees, but it was so crowded down there I accidentally triggered a finishing kill animation, and then we just said the heck with it. The only person Lara didn't kill was the idiot with the molotov. Call it 12 kills; 33/60
So, yes, by the time you've reached the radio tower, you've killed over half the people you've met. And those that survived are still shooting at you; there are a grand total of three Solarii still sitting comfortably in their huts at the top of a waterfall, out of the rain, unaware of how close they came to encountering Wolverine.
I tried to go a little further with this increasingly quixotic quest. I found one loophole; there's an ambush right after you get the flaming arrows and once again you are glued to the ground with an arrow notched and will die if you don't immolate three guys. But after that, you can actually run away from the entire ambush; they eventually say "Let the guys at the gate take care of her," or words to that effect.
So that's another twenty or so who you can spare, although the gate does not allow such mercy; twenty dead there. Then the tower Grim is holed up in; you must complete that fight and kill at least a dozen. And another dozen when you've fought your way around to take it from a different angle. There is about eight on the windmill you can bypass, though. Can't sneak past them; once again, the game triggers them automatically (in fact, the one time I crawled all the way around, they actually teleported in right in front of my eyes). You might confuse or reset them by going into the nearby tomb. But if you run around like a mad weasel long enough to confuse them properly, you can jump on to the tramway and leave them behind. Three or four machine gun bullets in the back are nothing to Lara -- not on easy mode, at least.
So for those next encounters, you are forced to kill roughly 3/5 of the people you encounter. And these are larger encounters, too; the blood on your hands is up over a hundred by the time you get out of the geothermal caverns. This isn't player choice; this is built into the level design.
(Yes...the Solarii revival meeting can almost be bypassed; stealth-kill two guards, run like hell to the gas valve, blow it up to open the next door...and the dozen or more you ran past die screaming in the resulting eruption and flames. Oh, well. At this point, one needs to take notice that since you set fire to their building, at least fifty die in the flames; you see some two dozen blasted by gouts of fire, crushed by flaming debris, or falling off a roof in flames. You hear a lot more voices screaming in the distance. Still, even counting only direct player kills, you leave over a hundred bodies in your wake.)
So, no. The ludonarrative dissonance is alive and well. Me, I have my own head-cannon. Especially since I have the out-of-game knowledge that the first tortured sacrifice you see strung up is another student, a member of your expedition, and a friend, I pretty much decided my Lara went straight from fear to murderous rage. The moment she got a weapon, she was happy to kill every single cultist on that island. With an axe. Close-up.
Monday, November 24, 2014
The Reverberant Field
Graph the strength of your singers versus the volume in the orchestra pit. For any shared acoustic space, there is a point where your show becomes unmixable.
Which is to say, nothing you do with microphones and speakers will restore the proper balance. And it's worse than that. Sound reinforcement for music -- much less a musical -- is not about winning the volume wars, it is about achieving intelligibility. To follow the story, the audience must be able to understand the words. And that's much tougher to achieve.A large part of the reason is the reverberant field. When sound enters a space, it reflects. When it has reflected several times, over a period of up to several seconds, it becomes what we call the reverb tail. But there's several very interesting things about this tail. Since it has bounced back and forth from all available surfaces, it is essentially anisotropic and omnidirectional. Since it is composed of reflections from the last second or several of material, it contains no identifiable transients. And since high frequencies are more easily absorbed, it is weighted towards the low end.
What all this means is the acoustic remnant left after the vocal energy of singers, musical instruments, and sound reinforcement speakers has entered the space is a muddy, boomy, mush. Referencing only the reverberant field, a string bass is just "Ooommooommooom"; no pluck, no notes, no rhythm. For vocals, you are lucky to make out the basic vowels; consonants are lost.
And it gets worse.
As you add volume, whether directly from louder singers or instruments or by turning up microphones, you "pump" the space. The reverberant field becomes stronger in a non-linear way, becoming closer to a continuous wall of white noise. And certain frequencies are pumped as if in a laser cavity; room nodes emerge, standing waves, tones that are captured and amplified and sustained.
(There's a few other side effects; fixtures and architectural elements rattle, adding more noise, and the audience becomes noisier as well.)
Since the reverberant field is practically by definition at equal volume throughout the acoustic space, the direct sound forms a ratio with it. Put a singer at one end of the room. Close by the singer, their voice is louder. By the time you get to the back of the room, the reverberant sound dominates.
And this has huge implications for sound reinforcement.
FOH mixing in any space smaller than a stadium is all about selective reinforcement. Take a small-scale example; a recorder and trumpet duet. In a small space, you might put a mic on the recorder and feed it into the house system to help it match the trumpet's volume.
Problem is, your house speakers aren't on stage. So if you stand in front of a speaker, you get just recorder. Stand in front of the stage, you get just trumpet. Only a little ways back in the hall do you get equal amounts of trumpet and recorder.
Take another typical example; bass player with their own amp. From the audience, all they hear is "oomoomoom." So you take a DI off the bass and emphasize the attack a little. This means two streams have entered the acoustic space:
"Ooomooomooom"
"Tac! Dac! Dac!"
And at the proper distance, they blend into the proper "Toom doom da doom doom da doom." But anywhere other than down the alley where direct projection from stage is roughly matched to direct tweeter radiation from speakers, you get something other than a good bass sound.
Go back to the first. One alternative is to mic both instruments. So from anywhere within range of the speakers, you are hearing both amplified recorder and amplified trumpet. Plus the reverberant field. And therein lies the catch. If the trumpet player, freed from the responsibility of blending with the recorder, increases in volume, the reverberant field increases non-linearly. And as you increase the speaker volume to compensate, the reinforcement is also fighting its own reverberant field.
Why is it non-linear? Well, air has mass. It takes a certain amount of energy to overcome the inertia of the air and set up standing waves. On the listener end, perception starts being non-linear; it takes ten times the power to be perceived as twice the volume, but this is also frequency dependent and the frequency response changes at different volumes. At higher volumes, masking effects in the cochlea become more dominant, up through the onset of hearing fatigue; short-term hearing loss.
Which all work out to progressive loss of perception of the high frequency content. As you crank higher and higher, the desired sound; the harmonics that define the character and timbre, the higher-frequency sounds that define the attack transients, and of course the very transients themselves get lost in the smear of reflected, bottom-heavy, indistinct noise that makes up your reverberant field.
But good luck getting it fixed. If you ask for the trumpet to perhaps play a little softer, all you will get is well-meaning suggestions to turn his mic down. Which, of course, devolves us back to the first set-up; where the people directly in front of the speaker hear the recorder and only a couple of seats get a decent balance.
(Only you've lost that, too, since the reinforced recorder is now masking itself; the transients are lost in the echoes of the reverberant field, and the characteristic timbre is masked in the thrumming low end you've filled the hall with. And of course the trumpet is also lost in the reverberant field now, meaning you might as well have two fretless basses up there for all the character and melodic content that comes through).
Consider what selective reinforcement means for design of a musical. From the back of the house, the reverberant field overwhelms anything coming directly from the stage. From the back of the house, then, it becomes clear you need to roll off the low end and push the presence in the vocal microphones.
Which if done right can provide a pleasing voice in which it is generally possible to make out the words.
But move closer to the main speakers. If you stare down the throat of the speakers, you are getting just the reinforcement; an overly bright, tinny, compressed voice with lots of artifacts. Not pleasant to listen to!
In many seats towards the front of the listening space, some direct bleed comes off the stage and mixes with what's coming off the speakers, plus of course you have the reverberant field. So low end is filled in by the field, mid-range and localization cues come directly from the singer, and presence and definition and consonants are coming off the speakers. And if the speakers are time-aligned properly and not too far away in the horizontal plane (the human ear gives more of a pass to misalignment in the vertical plane) you get a pleasing voice.
Of course, the reverberant field is delayed. That's what it is; reflections from the distant walls. So that smears the lower end. And, yes, it is impossible to align your mains perfectly for all seats; a little geometry will demonstrate that! But here it gets even trickier; the human perceptual apparatus will bring in all the frequency data more-or-less without question, but it will provide perceptual focus based on location, time-of-arrival, and frequency content.
Which boils down to -- the total mix may or may not be pleasing, but it is nearly impossible for untrained ears to sort out which elements are contributing what to the total mix. The reverberant field, particularly, is generally unperceived. The influence that low end leakage has on the volume sensitivity and resulting frequency sensitivity curves in the listening ears will always be underestimated and overlooked.
As that reverberant field rises in ratio (whether due to sheer level, or to increasing distance of the listener from stage and/or speakers) the ability to sort out the desired musical information becomes less. It is like the dark matter of sound at that point; making voices sound muffled and inspiring lots of orders to "turn it up, turn it up!" when the problem is the unseen drag of low-frequency white noise.
And this means the correct emphasis to blend with the acoustic material in the space is different for each seat. And different for each voice. And changes there, too; the singer who needs a lot of help will be emphasized more in speakers, the singer with the strong voice will be almost non-existent in the speakers (depending on where you mix to, of course; whether you mix for the person standing in front of the speaker, the person in the back of the room, or try -- as most of us do -- to achieve a compromise that will work for as much of the audience as possible).
This means if Ethel Merman singes a duet with Little Suzy, the people near the speakers will complain all they hear is a child's screechy voice being amplified way too much, and the people everywhere else will hear nothing but Ethel Merman. This of course evens out the flatter your speaker coverage is!
And it gets subtler than this. Take two singers of similar vocal timbre but different strengths of production. As the reinforcement is balanced for tonal deficiency, they will sound the same in the sweet spot, but one will have an odd, artificial sounding microphone voice right next to the speakers. And that same one will be dull and muffled compared to his partner when listening from distant in the hall.
Or take either of those singers, and change the total volume of the song. At low volumes of reinforcement, the natural voice dominates in the front of the hall and the reverberant field dominates in the rear. At higher levels of reinforcement, the microphone sound dominates over greater and greater parts of the hall. And if the microphone sound is tailored to emphasize needed frequencies and otherwise selectively reinforce the voice, the amplified sound will pass through insufficient, to nicely blended, to artificial as you increase volume.
This is why reinforcement -- working around and supporting the natural acoustic sound from the stage and the orchestra -- is the most difficult kind of sound.
It is also why amplification -- powering over the direct sound with a fuller-range, more accurate picture -- only works within certain boundaries.
And in both cases, you remain at the mercy of backline leakage. No matter what the strategy you pick, if a band continues to turn up their instruments, there will come a point where there is no alternative left for mixing. The show is just going to have to suck.
In other news, I just finished the third weekend of mixing "Poppins."
Saturday, November 22, 2014
King of the Rocketmen
Finally got back to the CAD software:
This is a "flash hider" that sticks on a stock Luger pistol to make a "King of the Rocketmen" prop. When I've finished the model, it will be freely available to print at my Shapeways store...and I'll look at the numbers for lathing one out of aluminium.
And I really don't understand Fusion 360.
Okay, first off, I'm learning CAD. That's an expected learning curve. CAD is a different way of doing things, and I also have been emphasizing organic and poly modeling techniques in the past: CAD leans much more towards parametric methods.
But I'm having a lot of trouble understanding how Fusion 360 is organized. And I'm not alone in this. It seems to have a collection of semi-hierarchically related structures, among them bodies, patches, components, and parts. How they relate, which can contain which, which can be converted into which, is quite unclear. Furthermore, the possible operations change greatly depending on which one you are looking at; even if it is otherwise identical looking and created in an almost identical method.
The software is being rapidly revised, including even the names of parts and functions, and there exists nothing even slightly like a manual. There are videos, but they use terms and show a workspace which is several versions superseded and in many cases no longer applies.
Above that is a bigger question of; "What they heck is this software for?" I have my own suspicions. I think that Autodesk had a bunch of maverick programmers and marketing people; beanie-wearing, espresso-drinking hipsters who were a little too out there for the flagship products. So they put them in a room and told them to go wild with a sort of mad mix of trial balloons, concepts in search of an application, some solid code, and above all an urge to look as trendy as humanly possible.
This means not just the team, but most of the active user base, are people who have way too much experience with Inventor and so forth. Making the software accessible to outsiders doesn't seem like a priority, because they are working in a self-exclusionary echo chamber.
It is fairly telling that the top threads in their own forum are about how to include videos and personalized graphics in one's forum posts.
In a refreshing alternative to most 3d software, what they seem to think of as their selling points are not the modeling functionality, and certainly not gosh-wow render tricks or a suite of included-with-the-download DAZ dollies, but instead the concept of sharing and portability. They believe strongly in this idea, although the implementation seems nebulous (really, now; software that is buggy on a powerful desktop machine, with a graphics-heavy interface, is not going to translate well to a smart phone. And the cloud storage system they have already for file management is crawling-slow, heavy and unwieldy even on a decent work-based connection. Good luck shoving those files down the pipe you will get at a beach-house!)
As far as I can tell, in fact, all the vaunted "sharing via cloud" could be achieved just as well by throwing a save file at DropBox every now and then. But I could be missing the point. Right now whatever it is, it confuses the existing user base more than it accomplishes anything else (lots and lots of forum threads wondering how they can access their own files after a quit and restore!)
In any case, I struggled for days just to lathe the simple shape above. Practically every standard method I tried ended up with unselectable edges or grayed-out "OK" buttons, with no real explanation why. At least one of them crashed the application completely. And what I finally got, violates the spirit of parametric modeling completely in that it is not easily editable. Half the useful functions require turning history off, and the hierarchy of parts doesn't actually seem to go into a final form that includes sub-forms that can be edited.
Navigation is still broken, although I'm using third-party tools to remap and create a middle mouse button, which should help. (For me, 3d aps live or die on navigation. If I can't zip around an object to view it from different angles, I can't build it properly. But the vast majority of 3d aps start now as Windows native, and tend to take such things as three-button mice as standard. Even power Mac users don't get these easily -- nor do they play well with the rest of the Mac environment. But funny thing; an ap as otherwise ghastly as Carrara can implement a smooth 3d navigation and selection and even basic movement rotation and scaling tools with just a couple of control keys. So it isn't that F1-home key-scroll wheel is necessary to make 3d navigation work. It is just that many 3d ap programmers are, well, stupid.)
Oh, yeah. And sad thing is, the tool path tools are poor enough I'm going to end up exporting and generating tool path and so forth in a different ap anyhow. Which means that I might as well have built the thing in a poly modeler to begin with.
And I really don't understand Fusion 360.
Okay, first off, I'm learning CAD. That's an expected learning curve. CAD is a different way of doing things, and I also have been emphasizing organic and poly modeling techniques in the past: CAD leans much more towards parametric methods.
But I'm having a lot of trouble understanding how Fusion 360 is organized. And I'm not alone in this. It seems to have a collection of semi-hierarchically related structures, among them bodies, patches, components, and parts. How they relate, which can contain which, which can be converted into which, is quite unclear. Furthermore, the possible operations change greatly depending on which one you are looking at; even if it is otherwise identical looking and created in an almost identical method.
The software is being rapidly revised, including even the names of parts and functions, and there exists nothing even slightly like a manual. There are videos, but they use terms and show a workspace which is several versions superseded and in many cases no longer applies.
Above that is a bigger question of; "What they heck is this software for?" I have my own suspicions. I think that Autodesk had a bunch of maverick programmers and marketing people; beanie-wearing, espresso-drinking hipsters who were a little too out there for the flagship products. So they put them in a room and told them to go wild with a sort of mad mix of trial balloons, concepts in search of an application, some solid code, and above all an urge to look as trendy as humanly possible.
This means not just the team, but most of the active user base, are people who have way too much experience with Inventor and so forth. Making the software accessible to outsiders doesn't seem like a priority, because they are working in a self-exclusionary echo chamber.
It is fairly telling that the top threads in their own forum are about how to include videos and personalized graphics in one's forum posts.
In a refreshing alternative to most 3d software, what they seem to think of as their selling points are not the modeling functionality, and certainly not gosh-wow render tricks or a suite of included-with-the-download DAZ dollies, but instead the concept of sharing and portability. They believe strongly in this idea, although the implementation seems nebulous (really, now; software that is buggy on a powerful desktop machine, with a graphics-heavy interface, is not going to translate well to a smart phone. And the cloud storage system they have already for file management is crawling-slow, heavy and unwieldy even on a decent work-based connection. Good luck shoving those files down the pipe you will get at a beach-house!)
As far as I can tell, in fact, all the vaunted "sharing via cloud" could be achieved just as well by throwing a save file at DropBox every now and then. But I could be missing the point. Right now whatever it is, it confuses the existing user base more than it accomplishes anything else (lots and lots of forum threads wondering how they can access their own files after a quit and restore!)
In any case, I struggled for days just to lathe the simple shape above. Practically every standard method I tried ended up with unselectable edges or grayed-out "OK" buttons, with no real explanation why. At least one of them crashed the application completely. And what I finally got, violates the spirit of parametric modeling completely in that it is not easily editable. Half the useful functions require turning history off, and the hierarchy of parts doesn't actually seem to go into a final form that includes sub-forms that can be edited.
Navigation is still broken, although I'm using third-party tools to remap and create a middle mouse button, which should help. (For me, 3d aps live or die on navigation. If I can't zip around an object to view it from different angles, I can't build it properly. But the vast majority of 3d aps start now as Windows native, and tend to take such things as three-button mice as standard. Even power Mac users don't get these easily -- nor do they play well with the rest of the Mac environment. But funny thing; an ap as otherwise ghastly as Carrara can implement a smooth 3d navigation and selection and even basic movement rotation and scaling tools with just a couple of control keys. So it isn't that F1-home key-scroll wheel is necessary to make 3d navigation work. It is just that many 3d ap programmers are, well, stupid.)
Oh, yeah. And sad thing is, the tool path tools are poor enough I'm going to end up exporting and generating tool path and so forth in a different ap anyhow. Which means that I might as well have built the thing in a poly modeler to begin with.
Subscribe to:
Posts (Atom)