How to Talk to an AI: The Art of Prompting ========================================== How I turned an old computer into a virtual horror movie production studio by giving an AI a job description. ------------------------------------------------------------------------ A NITETIME.NET guide to understanding AI, prompting, and why the way you ask matters. There is something happening in computing right now that I think a lot of people are missing. Most people have experienced artificial intelligence by typing a question into ChatGPT and getting an answer. Maybe you've asked it to write an email, explain something complicated, generate a picture, or help settle an argument. That's all fine, but it's a little like buying a brand-new computer and only using the calculator. The really interesting stuff begins when you stop treating AI like a question-and-answer machine and start treating it like a capable assistant that can participate in actual projects. And the secret to getting started isn't learning a programming language. It's learning how to explain what you want. That's called prompting. I'm going to show you a real example from something I'm building at NITETIME.NET. It's a particularly ridiculous project, which makes it a perfect demonstration. I'm attempting to produce a nine-episode horror television series called CONTAGIOUS FEAR. The entire show takes place from the perspective of someone riding through a haunted amusement park attraction that gradually descends into an impossible nightmare. Picture an old-fashioned haunted-house ride. You're sitting in a little car, rolling past cardboard skeletons and mechanical monsters while spooky organ music plays. Except the ride starts doing things it shouldn't. The mechanical figures begin watching you. The rooms stop making architectural sense. The attraction becomes increasingly disturbing, until you begin to suspect that the ride itself is alive. We're not building an actual amusement park ride. We're going to make a computer-generated movie showing what the passenger would see. And rather than sit down and manually create every element of this production, I'm using AI to help build the tools necessary to make it. I recently gave one of my computers a lengthy set of instructions to begin that process. Let's take that prompt apart and explain why I wrote it the way I did. ------------------------------------------------------------------------ First, what exactly is a prompt? -------------------------------- A prompt is simply the instructions you give an artificial intelligence system. That's it. There's no magic programming language involved. You don't have to learn special commands or understand the mathematics behind neural networks. You communicate using ordinary language. For example, a basic prompt might be: > Write a scary story about a haunted amusement park. The AI will probably produce a scary story. But it has to invent nearly everything about your request. How long should the story be? Is it funny or serious? Who is the audience? Does it take place in the present? Is it a short story, a screenplay, or a television episode? You left those decisions to the computer. Now consider this: > Write a five-minute horror story told entirely from the perspective of > a passenger riding through an old-fashioned amusement park haunted > house. Begin with cheerful organ music and mechanical skeletons. > Gradually introduce impossible events until the passenger realizes the > attraction is alive. Avoid dialogue and tell the story through > scenery, movement, lighting, and sound. That's a much better prompt. You haven't written any computer code. You've simply explained what you're trying to accomplish. You've provided context, requirements, limitations, and a desired result. The more clearly you communicate your intentions, the less the AI has to guess. That doesn't mean longer prompts are automatically better. It means useful details produce more predictable results. And that's where things get interesting. 1. Give the AI a job -------------------- My actual prompt begins like this: > PROJECT: CONTAGIOUS FEAR > NITETIME.NET ORIGINAL PRODUCTION > BOXEY -- AI DEVELOPMENT AND VIRTUAL RIDE PRODUCTION > > You are BOXEY, a dedicated production and AI processing node within > the NITETIME.NET computing infrastructure. This does something important. I'm establishing the AI's role. I have several computers doing different things around here. One handles broadcasting. Another hosts services. This particular machine is an older Dell workstation that I've named BOXEY. Instead of telling the AI to generally help with a horror movie, I'm giving it a specific responsibility within a larger operation. BOXEY is going to become our production machine. Its assignment is to investigate artificial intelligence software, build computer-generated environments, animate cameras, render video, and prepare footage for eventual broadcast. Think of this as hiring someone and explaining their position in the company. You wouldn't hire a new employee, point toward the building, and say, "Do some business." You'd explain their job. That's what we're doing here. Prompting principle #1: Give the AI a clear role and responsibility. One important distinction: saying "You are BOXEY" doesn't magically transform the AI into a different system. It's a way of establishing the role it should follow. The AI still needs actual software tools and permissions to interact with the computer. 2. Explain the mission, not just the immediate task --------------------------------------------------- Next comes the mission statement: > Build the technical and creative foundation for CONTAGIOUS FEAR, a > nine-episode virtual horror dark-ride television series. > > This is an actual production assignment, not merely a research > exercise. That second sentence is especially important. AI assistants can be very good at discussing how to accomplish something without ever accomplishing it. Ask one how to make a movie, and you might receive an excellent essay about filmmaking. Wonderful. But I don't need an essay about making a movie. I need to make a movie. So I explicitly tell the AI that the assignment involves producing working software, writing scripts, creating animation, and rendering actual test footage. Later in the prompt, I reinforce this with another instruction: > Do not stop at documentation. Create an actual working Blender > prototype. That's intentional. I'm defining what success looks like. A finished research document might be useful, but it doesn't constitute success for this assignment. I want files, software, animation, and eventually something I can watch. Prompting principle #2: Describe the outcome you want, not merely the subject you want to discuss. 3. Tell the AI what it has to work with --------------------------------------- Here's where my prompt starts looking a little technical. I identify the computer: > Machine: Dell Precision Tower 7810 > Processors: Dual Intel Xeon E5-2630 v3 > CPU: 16 physical cores, 32 logical threads > RAM: Approximately 30 GiB > GPU: NVIDIA Quadro K4200, 4 GB > Operating System: Ubuntu 26.04.1 LTS You don't need to understand all those specifications to understand why they're included. Imagine hiring someone to build a backyard deck. You explain that you have a circular saw, a drill, a pile of lumber, and a truck. That's important information. If your contractor assumes you own a bulldozer and an industrial crane, their construction plan probably isn't going to be particularly useful. The same applies to computers. BOXEY is an older workstation. It has a respectable amount of processing power, but its graphics card is ancient by modern AI standards. If I don't mention that, the AI might recommend software that requires a $2,000 graphics card. So I add: > Do not assume it supports modern CUDA AI workloads. > > Prefer CPU-based inference and rendering unless you establish a > genuinely working and compatible GPU acceleration method. In ordinary English, I'm saying: Don't assume my equipment can do something just because a newer computer can. Check first. This is called providing context. Context is one of the most powerful ingredients in effective prompting. The AI can make better decisions when it understands the environment in which those decisions must work. Prompting principle #3: Explain your available resources and limitations. 4. Establish boundaries before giving the AI freedom ---------------------------------------------------- Now we arrive at something I consider extremely important. My instructions include: > Do not modify the existing Windows NTFS volume. That computer still has a Windows drive containing existing files. I absolutely do not want my enthusiastic new AI production assistant deciding that the best way to make room for a movie studio is to erase Windows. I also tell it: > Do not expose unauthenticated AI APIs to the public internet. And: > Do not install incompatible NVIDIA drivers. And: > Work autonomously on reversible local tasks. These aren't creative instructions. They're boundaries. I'm defining what the AI is allowed to do, what it should avoid, and where it needs to exercise caution. Think about a contractor remodeling your kitchen. You might give them considerable freedom to accomplish the job, but you'd still explain that they cannot knock down a load-bearing wall without approval. That's exactly the relationship I'm trying to establish here. I want BOXEY to investigate, install appropriate software, create project files, and experiment. I don't want it destroying existing data or exposing my home network to the internet. There's an important technical caveat: a written instruction is not a security system. Real protection comes from operating-system permissions, backups, restricted access, and the safeguards built into the tools. The prompt helps guide behavior. Actual security controls limit what can happen if the AI makes a mistake. Prompting principle #4: Explain what the AI must not do, especially when it can change real things. 5. Break a gigantic project into smaller assignments ---------------------------------------------------- My original prompt has 16 numbered sections. That might seem excessive, but consider the project. We're attempting to create a television production system from an older computer. The work includes installing software, investigating animation techniques, developing a story, writing scripts, generating three-dimensional scenery, building a virtual camera, synchronizing music, rendering video, and coordinating with another computer. That's a lot. If I simply said: > Make me a nine-episode animated horror series. I'd be asking the AI to make hundreds of decisions without any guidance. Instead, I divide the assignment into individual areas. One section is about establishing local AI. Another covers technical research. Another describes the fictional world. Another concerns music. Several deal with animation, camera movement, and video rendering. And near the end, I specify exactly what should be completed first. This is similar to handing a construction crew architectural plans rather than a napkin with a drawing of a house. The big idea is still the house. But the plans explain how the work fits together. For a project this large, I expect the AI to work through the assignment over multiple sessions. A long prompt does not mean an AI has unlimited time, memory, or computing resources. The numbered sections help it prioritize and preserve the overall direction. Prompting principle #5: Break complicated goals into manageable tasks that contribute to the same outcome. 6. Give it the creative vision ------------------------------ Now we get to the fun part. Here's a section of the prompt: > The viewer enters what initially appears to be an ordinary amusement > park haunted-house attraction. > > The experience begins with the comfortable artificiality of an > old-fashioned dark ride. > > There are painted walls, mechanical monsters, theatrical lighting, > creaking doors, organ music, and cheap scares. > > However, something is profoundly wrong. Notice what I'm doing. I'm not telling the AI where to place every skeleton or what color to paint every wall. I'm establishing a creative direction. The attraction should begin with an intentionally artificial, almost charming atmosphere. It should resemble those old mechanical haunted houses where a painted plywood vampire springs out of a coffin while an organ plays something spooky. But as the episodes continue, the illusion begins falling apart. The scenery becomes more realistic. Architecture becomes impossible. Things that should be mechanical begin acting alive. Eventually, the attraction itself becomes the monster. This is the kind of information a film director gives a production team. It's not a blueprint for one particular scene. It's an explanation of the emotional experience the entire production should create. That distinction matters. Prompting principle #6: Explain the feeling and purpose behind your creative choices, not just the objects you want. 7. Use references to explain what you're imagining -------------------------------------------------- In the prompt, I mention classic haunted-house rides, carnival ghost trains, gothic horror, mechanical theater, psychological thrillers, and cosmic horror. I also reference the escalating psychological intensity of a film like Se7en. Why? Because those references communicate a tremendous amount of information very quickly. If I say "old-fashioned amusement park haunted house," you can probably imagine the general environment immediately. If I say "expressionist horror," someone familiar with the style might imagine distorted architecture, unnatural shadows, and exaggerated theatrical environments. References help communicate ideas. But there's a difference between taking inspiration from something and copying it. That's why the prompt explicitly says: > Do not copy copyrighted stories, characters, scenes, dialogue, or > distinctive visual designs. > > Create an original mythology for CONTAGIOUS FEAR. I'm using existing works to communicate the desired atmosphere, not requesting reproductions. You can do the same thing with practically any creative project. You might ask an AI to write something with the warmth of a small-town newspaper, the excitement of an old radio commercial, or the atmosphere of a 1950s science-fiction program. Those references establish direction. The actual work should still be original. Prompting principle #7: Use familiar comparisons to communicate style, while being clear about what must be original. 8. Give the AI room to solve problems ------------------------------------- Here's one of my favorite parts of the prompt: > Do not assume that a photorealistic rendering engine is necessarily > the best choice. > > Our objective is maximum visual impact per hour of rendering. This is a very important instruction. I don't particularly care whether BOXEY creates its scenery using advanced 3D models, painted backgrounds, clever lighting tricks, or a combination of techniques. I care whether the result looks good. Remember, we're simulating an old haunted-house ride. That environment is already supposed to contain artificial scenery, painted surfaces, theatrical lighting, and mechanical figures. We might be able to make something visually spectacular without creating photorealistic monsters containing millions of tiny details. In fact, trying to make everything photorealistic might ruin the charm. The AI is instructed to investigate several different approaches and determine which are practical. This is a crucial difference between giving someone a task and micromanaging every decision. I'm defining the objective while allowing the AI to investigate possible solutions. Prompting principle #8: Be specific about the result, but flexible about how to achieve it. 9. Explain how you want the AI to think about trade-offs -------------------------------------------------------- A recurring theme in my instructions is that BOXEY has limited hardware. So I tell it: > If a rendering feature is too expensive for this hardware, implement a > cheaper approximation. And: > Do not initiate hours-long renders without first measuring performance > on short samples. These instructions establish priorities. For example, imagine BOXEY discovers two ways to create a spooky hallway. Method A looks absolutely magnificent but requires six hours to generate ten seconds of footage. Method B looks nearly as good and requires fifteen minutes. For a nine-episode series, Method B might be the obvious winner. Rather than ordering the computer to use one specific method, I'm giving it a standard by which to evaluate its options. This is extremely useful when prompting AI. You don't necessarily need to know the answer yourself. But you should explain how you want the answer evaluated. For example: "Choose the least expensive option that is still reliable." "Favor simple solutions that are easy to repair." "Prioritize accuracy over speed." "Keep the result understandable to someone without technical experience." Those are all valuable instructions because they guide decisions. Prompting principle #9: Tell the AI how to choose between competing solutions. 10. Give it an example of the finished work ------------------------------------------- One section of my prompt asks for detailed episode scripts. But I don't merely say "write a script." I provide a specific example: > SCENE 1.03 -- THE PORTRAIT GALLERY > > The ride vehicle enters a narrow hallway. > > The camera travels forward at walking speed. > > Six portraits line the walls. > > The organ plays a cheerful minor-key melody. > > As the camera passes the third portrait, the figure inside turns its > head toward the rider. > > The camera does not stop. > > At the end of the corridor, the organ loses one note. > > The final portrait is blank. > > As the vehicle turns the corner, a faint scraping sound comes from > behind. This example accomplishes several things. First, it demonstrates the style of storytelling. Second, it shows the level of detail expected. Third, it illustrates how scenery, movement, music, and sound should work together. And finally, it provides a model the AI can follow when writing additional scenes. This is sometimes called few-shot prompting when you're providing one or more examples of the kind of output you want. You don't need to know that term. Just remember that showing an example is often more effective than explaining a format in abstract terms. It's the difference between telling someone to make you a sandwich and showing them the sandwich you want. Prompting principle #10: When possible, demonstrate the kind of answer or result you're expecting. 11. Tell the AI to verify its own work -------------------------------------- This part is particularly important when you're asking AI to do technical work. I instruct BOXEY to measure things such as processing speed, memory consumption, and video rendering time. I also include: > Do not fabricate research results or benchmarks. Why would I need to say that? Because AI language models generate responses based on patterns learned during training and the information available in the conversation. They can produce convincing explanations even when the underlying facts have not been verified. An AI might confidently estimate that a particular computer can render a certain animation in twenty minutes. But unless it actually measures performance, that's just an estimate. And estimates can be wildly wrong. So I require testing. If BOXEY says it installed software, I want it to verify that the software actually runs. If it says it created an animation, I want a rendered video file. If it recommends a technique, I want the recommendation grounded in reliable information or an experiment. This illustrates an important difference between asking AI for advice and asking AI to perform work. Prompting principle #11: Ask for evidence, tests, and verification rather than accepting confident claims. 12. Explain how the AI should handle failures --------------------------------------------- Real projects don't go perfectly. Software installations fail. Hardware turns out to be incompatible. Programs crash. A rendering technique that sounded wonderful might take days to process. Rather than expect everything to work, I include instructions for dealing with obstacles. For example: > If local AI is slow, continue development using Codex rather than > allowing AI performance to block the project. And: > If a rendering feature is too expensive for this hardware, implement a > cheaper approximation. This gives the AI permission to adapt. There's an important distinction here. I'm not telling it to ignore failures. I'm telling it not to let a nonessential failure stop the entire project. If the old graphics card can't run a modern AI model, use the processors instead. If a complicated lighting effect takes too long, find a simpler way to achieve the same appearance. If the computer can't render a twenty-minute episode efficiently, start by producing fifteen seconds. That's how practical development works. Prompting principle #12: Tell the AI what to do when its first approach doesn't work. 13. Give it a way to communicate with the rest of the team ---------------------------------------------------------- My prompt references something called NITETIME-RAM. That's a shared project-memory system I've been setting up between my computers. Think of it as a communal notebook. One machine can record what it's working on, what it has discovered, and what help it needs. Other participating machines can consult those records. In this particular assignment, BOXEY handles the production side. Another machine, WORKSTATION, remains responsible for broadcasting and publishing. So my instructions explain that division of labor: > BOXEY is responsible for local AI inference, technical research, > procedural scene generation, CPU rendering, video encoding, and > production tooling. > > WORKSTATION retains broadcast scheduling, publishing, final creative > approval, and integration into NITETIME.NET programming. This prevents two machines from assuming they own the same responsibilities. It also helps preserve continuity. If BOXEY gets restarted tomorrow, the goal is for the next AI session to consult the project records and understand what has already happened. Of course, this only works if the underlying memory system is actually configured and accessible. Writing "remember everything" in a prompt doesn't automatically give an AI permanent memory. But when an AI has access to real files and a functioning coordination system, the prompt can tell it how to use them. Prompting principle #13: For ongoing projects, establish where progress and decisions should be recorded. 14. Demand a useful report when the work is finished ---------------------------------------------------- Toward the end of my prompt, I specify exactly how BOXEY should report its results. I want to know: - What software was installed. - What files were created. - What was tested and actually works. - What failed and where the project stands. - What needs to happen next. That last part is especially useful. A good AI work session should leave you knowing what was accomplished and what remains. The report should distinguish between something that has been planned, something that has been attempted, and something that has actually been completed. Those are three very different things. I don't want BOXEY telling me we've created a virtual horror attraction simply because it wrote a beautiful description of one. I want to know whether the camera moves, whether the scene renders, and whether the resulting video plays. Prompting principle #14: Define how success will be demonstrated and reported. ------------------------------------------------------------------------ So what happens when I hit Enter? --------------------------------- This is where we need to make an important distinction. There are different kinds of AI systems. If you paste my entire prompt into an ordinary chatbot without access to a computer, the chatbot can discuss the project, write scripts, explain technical concepts, and generate programming code. But it cannot necessarily install Blender, examine BOXEY's hardware, or render video on my workstation. For that, I'm using Codex, an AI coding assistant that can work with files and execute commands in a computer environment when it has the appropriate access. That gives the prompt a different meaning. Instead of simply asking an AI to describe a production system, I'm asking an AI with access to development tools to begin building one. In simplified terms, the process works like this: I provide the objective. The AI reads my instructions and determines which tasks to attempt. The AI examines the environment. Using its available tools, it can inspect files, software, and hardware to understand the computer it's working on. The AI develops a plan. It identifies the necessary components, dependencies, and practical first steps. The AI takes actions. Depending on its permissions, it can create directories, write programs, install software, and run tests. The computer produces results. Blender creates animation, rendering software generates images, and video software assembles those images into movies. The AI evaluates the results. It can check for errors, inspect logs, adjust programs, and try again. This can form a repeated cycle: INSTRUCTIONS -> ACTION -> TEST -> FEEDBACK -> REVISION That's the really interesting part. We're no longer limited to AI producing an answer. We're using AI to help produce and test working systems. However, Codex is not magically unlimited or infallible. It can misunderstand instructions, make programming mistakes, encounter permission problems, or get stuck. It also operates within the limits of its tools, available time, and working context. That's why the testing, boundaries, checkpoints, and reporting instructions are such an important part of the prompt. How much of that giant prompt is actually necessary? ---------------------------------------------------- Now, here's something I want to make clear. You do not need to write a sixteen-section document to get useful results from AI. My prompt is long because my project is complicated. In fact, overly long prompts can become counterproductive. They can contain contradictory instructions, bury the important details, or encourage an AI to spend more time planning than doing. That's why I included a priority list and told BOXEY to begin producing actual work rather than endlessly researching possibilities. Most everyday tasks need only a few sentences. Imagine you want to organize fifty years of family photographs. A perfectly reasonable prompt would be: > I have several thousand family photographs scattered across folders on > my computer. I want to organize them by date, identify duplicates, and > create a searchable collection. I don't know how to program. Help me > figure out how to do this using free software. Do not delete or modify > my original photographs. Start with a small test folder before making > changes to the entire collection. Look at how much information that communicates. It identifies the problem, the desired outcome, the person's technical experience, the budget, a critical safety rule, and a practical starting point. No specialized AI vocabulary required. Or suppose you own a small business. You could write: > I run a small woodworking business. I want a website where I can > photograph a finished project with my phone, type a few sentences > about it, and have that information turned into a professional-looking > website post. I'd eventually like the same information shared on > social media. I have a limited budget and would prefer free software. > Help me design the simplest reliable system, and explain each step in > language I can understand. That's a pretty substantial assignment. And it begins with ordinary English. You don't need to understand databases, web servers, APIs, or programming frameworks to explain the business problem you're trying to solve. The AI can help investigate those technical details. You still need to make decisions, check the results, and approve actions that affect real systems. But you no longer have to know every implementation detail before you can begin. The biggest misconception about prompting ----------------------------------------- I think many people approach AI believing there's some secret combination of words that unlocks its capabilities. They imagine professional AI users typing strange commands or complicated formulas. There are certainly techniques that improve results, and understanding how AI systems operate is useful. But the fundamental skill is much more familiar. It's the ability to clearly communicate an idea. Think about what makes a good manager, teacher, director, or project leader. They explain the objective. They provide necessary background. They communicate expectations. They establish boundaries. They give examples. They allow room for creative problem-solving. And they evaluate the work. Those are almost exactly the same skills involved in writing an effective prompt. The difference is that instead of communicating those instructions to a human being, you're communicating them to a computer system that can interpret language and, when connected to the appropriate tools, assist in carrying out the work. That doesn't mean the computer understands everything perfectly. It certainly doesn't mean that every idea can be accomplished. But it dramatically changes who can participate in the process of creating software, media, and other complicated projects. There's another trick: You don't have to write the perfect prompt yourself ------------------------------------------------------------------------ This might be the most useful advice in this entire article. You can ask AI to help you write the prompt. Seriously. You can start with something as informal as: > I've got this crazy idea for a horror show where the audience is > riding through a haunted amusement park attraction. I want to make it > using 3D animation on an old computer. I don't know the best way to do > it. Ask me questions about what I'm imagining, then help me write > instructions for an AI coding assistant to start building it. Now you've turned prompting into a conversation. The AI can ask about the type of horror you're imagining, the equipment you have, the length of the episodes, the music, and how realistic you want the scenery to appear. You answer in your own words. It helps organize those answers into a structured assignment. You review the instructions and make corrections. And when you're satisfied, you give the finished prompt to the AI system that will perform the work. In fact, that's one of the ways I've been developing projects for NITETIME.NET. I have conversations about ideas, explore the possibilities, make creative decisions, and then turn those discussions into detailed production instructions. The prompt isn't necessarily where the thinking begins. Sometimes it's the document that captures the thinking we've already done. ------------------------------------------------------------------------ The future of computing might involve a lot more conversation ------------------------------------------------------------- I've been developing websites and working with computers since the early days of the commercial internet. I've watched the industry move through all sorts of technological changes. We went from manually writing HTML pages to elaborate frameworks, databases, content management systems, APIs, and massive software ecosystems. For most of that history, if you wanted a computer to do something new, somebody had to understand how to program that behavior. The interface between a person's idea and the computer's execution was traditionally a programming language. And those languages weren't designed for ordinary people. They required specialized knowledge, precise syntax, and years of experience to master. AI coding tools are beginning to change that relationship. They provide a way for people to describe their intentions in natural language and have software created to help carry them out. That doesn't eliminate the need for engineering expertise. Complex systems still need careful design, testing, security, maintenance, and human judgment. But it potentially lowers the barrier between having an idea and creating a working prototype. And that's enormously significant. Consider what I'm doing with CONTAGIOUS FEAR. I have an aging Dell workstation, an old graphics card, some available processing power, a homemade broadcasting operation, a Lowrey organ, and a completely unreasonable idea for a nine-episode horror series. A few years ago, I would have looked at the project and started calculating how many months I'd need to spend learning animation software and writing production tools. Today, I can begin by describing the production to an AI coding assistant and asking it to help establish the technical foundation. I can direct the project without personally writing every line of the software involved. Does that guarantee I'll end up with nine finished episodes? Absolutely not. We still have to find out what the hardware can accomplish, whether the animation looks convincing, and whether the production process is practical. The project is an experiment, not a finished accomplishment. But the experiment itself illustrates something remarkable. The starting point is no longer necessarily knowing how to build the thing. It can be knowing how to describe the thing you want to build. And once you understand that, you begin looking at computers a little differently. You stop asking only, "What software can I buy that does this?" You start asking, "Could I have software made specifically to do what I want?" That is a very different way of thinking. The takeaway ------------ If you've never seriously experimented with AI, here's my suggestion. Don't start by learning complicated prompting terminology. Start with something you genuinely want to accomplish. Explain what you're trying to do. Explain why. Describe what you have available. State what you don't want to happen. Give examples of the results you're imagining. Then have a conversation. Ask the AI what information it's missing. Ask it to help organize the project. Ask it to explain the technical details in plain English. And if you're using an AI system that can actually operate software, begin with something small and reversible. Give it a test project and see what it can really accomplish. You don't have to start with a nine-episode horror series. Although, apparently, I do. Because somewhere in my house, there's a twenty-something-year-old idea of what a powerful computer should look like, sitting in a Dell tower, being given instructions to construct a nightmare. And I think that's pretty damn cool. Welcome to the age of conversational computing. The computer still does the computing. But increasingly, we get to explain what we want in our own words. ------------------------------------------------------------------------ NITETIME.NET A drop of ink in a binary ocean. CONTAGIOUS FEAR -- A NITETIME.NET Original Production The viewer is the passenger. The camera is the vehicle. The environment is the storyteller. The organ is the heartbeat. And the attraction itself is the monster.