There are several basic elements to my approach. I don't use all of them all of the time, but they all get frequent play.
Plan Hierarchically
Build Iteratively
Work in Pieces
Test Constantly
Integrate Frequently
Include Failure in your build cycle
Plan Hierarchically
It is important to have a plan. But it is equally important not to plan too much too early. Don't get bogged down in details to where you can't see the overall picture.
What you want is to leverage tools like Fermi Estimation; instead of trying to make up a detailed list of parts and what they cost, do a detailed analysis of a representative slice then extrapolate. You want to have an idea how much time, how much cost, whether you can handle the size of the thing or the work methods in your available space, but you need to do this without actually knowing in detail how you intend to build it!
Be always aware of the box. All the way through the project, don't let a problem be insurmountable because you are trying to solve it within assumed and invisible constraints. You can't get a circuit to work? Maybe there already exists a commercial substitute. You can't smooth a surface the way you want it? Perhaps it doesn't need to be smooth, because it is going to be hidden under later details.
As an example, the Jedi Holocron I am building is too elaborate for the task. If my project brief said "Assemble Holocron kit and add a light inside" then most of what I'm doing is not necessary.
The actual project brief is, however, "Use a Jedi Holocron build as a test platform to learn laser engraving and cutting, and to experiment with neopixel lighting elements."
This is being aware of the box.
And this is also how you plan heirarchically. You do not want your brief to be, "Build a prop blaster using a resin cast plus a machined nozzle with the fins on quarter inch spacing from 2011 T3 even though 6063 is stronger because anodizing and...."
Your brief needs to be written at the highest level you can imagine. Take it as abstracted as you can, until it includes as alternatives, "Buy a better one pre-made" or "Don't even bother, I've got a better idea."
Only when you have a mission statement that can fit in a single sentence without too many comma splices, breathe, do you move on to make a more detailed spec.
And even then, spec in terms of how much time you are reserving, deadlines if any, estimated cost and other budget issues, general plan of attack. Don't get bogged down in details, again, because -- you don't know all of the details yet.
Which brings us to:
Build Iteratively
The plan may not work. The material might not work. The concept might not work. Instead of starting out all at once with the final materials and working for days to get the final polished finish only to find out it is too big to fit your hand, start with mock-ups. Start with massing studies. Start with practice shots on the desired material. Start with little bits you can try out molding or machining or soldering on.
There will always be a gotcha you didn't see coming. But as much as possible, solve the large problems early. Solve issues of scale as early as you can, so you are working in finer detail later.
For a prop? Start with mock-ups. Make something you can hold, and see if the basic size and shape is right. It is a lot better to waste a chunk of foam than it is to waste carefully scrollsaw'd MDF.
For electronics, use proof-of-concept and breadboard and perf to work out the bugs before you go spending money on a PCB.
Basically, whenever there is a way of mocking up or substituting part or all of the build with cardboard and duct tape, flashlights and safety pins, boiler-plate code and rehearsal cubes, do it.
And keep this going throughout the project.
This of course blends almost imperceptibly with;
Work in Pieces
As Volpin said recently over at Tested, don't try to sculpt a Halo Reach Needler. Sculpt the parts of a Halo Reach Needler.
Engineers call this Divide and Conquer.
Look for parts. Look for sub-assemblies. Look for modules.
You want to be working with smaller pieces of the whole whenever possible. Smaller pieces are easier to comprehend, smaller pieces are less scary (building an Iron Man helmet is a lot less scary a project than building an Iron Man suit!) and failure is localized, too; instead of the entire project going up in a puff of magic smoke, you only lose the LED and regulator you were working on at that moment.
Smaller parts take up less workshop space and are easier to manipulate. When you have smaller parts, you can be painting on one while the paint is drying on another. You can be soldering on one while the parts are on back order for another.
And most importantly, when you are working on a single element -- a sub-routine of code, a sleeve, a carved foregrip -- when something goes wrong you can test just that element, instead of trying to track down an error somewhere in the entire five hundred lines of C++.
Which brings us to;
Test Constantly
Just like the massing tests and the Fermi Estimates mentioned earlier, any time you can test an idea or an element, do so.
When I'm setting up a sound system, the first thing I do is plug in a laptop (or, more often, my scanner) and play a little music. This is like a dummy check; before I go around looking for shorts in every single mic cable, I'm going to confirm the system actually turns on and sound comes through.
When you are coding, set flags and debug branches and so forth for your functions, and see if they do what you actually expected them to do when called.
When you work in pieces, you very often have pieces that can function on their own in some limited way. So wire them up. Say you are building a ukulele amp with onboard effects. Leave the pre-amp and pickup in their boxes, leave the amp in its box, and test just the effects unit; surrounding it with known working elements. Send it signal by plugging it into a laptop and running iTunes. Confirm the signal is going through by attaching headphones with a jumper cable. It doesn't matter how squirrelly the improvisations are; the important thing is that you are isolating so the only thing that is being tested is the piece you are working on.
When you know every sub-assembly works as designed, you can have more confidence in knowing the whole thing will work as designed. But there is a big caveat:
Integrate Frequently
There are entire classes of problems that only happen when you bring everything together. Hetrodyne effects, interference. But also physical fit, relative massing, visual appeal, even color and surface texture.
Try to find these problems before you have wasted weeks on a spiffy paint job.
Test-fit. Mock up. It doesn't matter if you have to use double-stick tape, alligator clips, rubber bands, etc., but remember to stop at frequent intervals in the project to take all the separate pieces out of their separate worlds and make sure they really do fit together.
You won't do this nearly as often as you test individual units, but you need to do it.
Also, these tests become basic benchmarks of the project. And they play back into the hierarchical design process; at each integration, you learn how the total project conforms to the original plan, and you learn how you need to modify your estimate of remaining time, budget, the need for special tools or materials, etc.
Different projects have different benchmarks, but here's some loose ideas of major integration stages:
Massing Study: This is when you get a general sense for how big something is, the proportional balance. In 3d, a massing study is done with primitives; stack up cylinders and blocks to get a basic sense of the shape of the thing.
Mock-Up: this is a more elaborate massing study; for a prop, this is something you can actually hold (whether it is rough-cut from foam or taped together from tin cans and gun parts). The mock-up for my Hogleg Maverick would probably be the PhotoShop image I created that showed the basic shape, aesthetic balance, color balance, etc.
Proof of Concept: particularly in electronics, this is the first circuit that actually does something, even if it barely works at all. The idea is a step in the build where you can actually turn it on and something happens. In prop-making, the proof of concept may be more a successful trial with a new material or technique.
Signal Test: get the entire thing up to the point where an input will show up at an output. Particularly important in both sound design and programming. The point, again, is not to worry about whether the program spits out the right answer, or the sound from the speakers is any good. The test is there merely to show that all the essential elements of the chain functioned well enough to pass on a signal.
Sanity Check: the first moment during a build when you can look at how much material you ordered, how long it took to actually machine the first of ten emitters, how much molding compound is left in the can after the first pull. It is the moment when you stack up all the unfinished pieces, or all the sketches, or all the components you've ordered, and look at the total mass and go, "Oh, wow." When you look at the total like this, it will tell you things you might not have remembered to estimate. Like, "With this many slashes in the doublet, I'm going to run out of bias tape soon."
Trial Fit: really important for props and costumes, especially the former if electronics are involved. See if the parts you are building are going to fit together. See if there is really going to be as much room inside as you expected.
Muslin: For costumes, before you cut into $16 a yard brocade, build the bodice out of muslin and fit it. This is incremental build at its finest; make the mistakes on cheaper fabric. But there are muslin approximations for many expensive materials, or extensive processes.
Line Check: this is a term from sound engineering. Before you tape down cable runs, and before you start worrying about dialing in the right sound for everything, make sure every mic is getting a signal back to the board, and they are showing up on the right channels. For electronics, make sure every part lights up/turns on/does something.
Remember, at every one of these integration tests you are going back to work on a piece-by-piece level. And you are taking what you learned in the integration test to modify your hierarchical project plan.
Scale Check: this is from my own work in Poser; at some point I bring the prop into Poser and import some random figure into the workspace. When you've been staring at bolt heads and panel lines for days, you lose perspective on just what the thing looks like in context. Putting a human figure in lets you grasp overall scale and level of detail again.
All-Up Test: This is when every bit of active electronics is connected together for the first time.
Plugs-out Test: This is when you remove all external components so the thing is running on internal batteries, no extra jumpers or external keyboards or whatever.
In-Situ Test: This is when you bring it to the theater (or whatever the intended operating environment is) to see if it functions under the actual conditions. Especially important for testing range, brightness, loudness; try it in the actual room. This test does not assume under actual running conditions; just that you are testing in the intended environment.
And, well, that's plenty enough for one entry!
No comments:
Post a Comment