We basically reviewed the concepts in the "Problem Solving, Programming Languages" and "Programming Tools" readings. I have broken out the definitions, described how I see it all fit together, and highlighted what I feel are the key points of the reading. The readings are more thorough, however, and should also be reviewed with these notes.
program - a sequence of instructions that tell a computer what to do
algorithm - a complete step-by-step list procedure for solving a problem or accomplishing a task (in the real world as well as in programming)
programming - is the ART of CREATING sequences of instructions that tell a computer to carry out a task. Many of the programmers I know were musicians, writers and artists before they became programmers.
programming language - a set of written symbols that instruct computer hardware to perform specific operations
syntax - a set of rules for a programming language, equivalent to grammar rules in English or Spanish or French or Polish or Swahili or Japanese or . . .
flowchart - a graphical method used for planning out a program. It includes special geometric symbols that depict the type of activity at each step (circles for start & end, parallelograms for for input & output, rectangles for instructions, diamonds for decisions) including a phrase defining the specific activity, connected by flowlines that show the order of the progression of steps.
pseudocode - a program planning tool that uses everyday language to prepare a brief set of instructions in the order in which they will appear in the finished program.
low-level languages- a language in which the instructions are written in binary code (machine languages) or a shorthand that is easily translated into binary code (assembly languages)
machine language - binary code, made up of 0s and 1s, that is the only language that a computer can understand. They have the fastest execution speeds, but require an intimate knowledge of how computers work and take the longest to write
assembly language - a language which uses abbreviations to represent machine language instructions. They require an assembler to run.
assembler - the program that converts the assembly language into machine language
high-level languages - a language with instructions that closely resemble human language and mathematical notation
compiler - one of two high-level language translator programs. Compilers translates the entire program into source code all at once, before the program is executed (run).
interpreter - one of two high-level language translator programs. Interpreters translate the program into machine language one line at a time.
object-oriented programming (OOP) languages - languages which model real-world objects with software counterparts. These languages consist of objects (combinations of data and procedures that are stored together as a reusable unit) and messages (procedures that are sent between these reusable units).
You write a program because you have a problem to solve. This problem is the generating idea and all that you write should move you towards solving the problem. You often find that you have to solve several sub-problems along the way in order to solve the problem. Some of these sub-problems are part of the problem itself, many of them come from limitations of quirks in the programming language.
Few programmers can sit down and just write a tight, efficient, bug-free program without any forethought. There are two major tools for organizing you ideas to facilitate writing a program. They are analogous to an outline and a sentence outline that you would write to organize your ideas before sitting down to write a term paper or essay (you DO write an outline first don't you?).
The first tool is a GRAPHICAL tool, so you artistic folks should be at home with that. It is called a flowchart. In one class we created a flowchart to solve the problem of getting someone out of the house in the morning, in which we found the sub-problem of creating an alarm clock that would only turn of when the shower was turned on, and would get progressively louder if the shower wasn't turned on, which would make the neighbors complain and the police come and take you away. In another class we planned out a little squaring program for sixth graders, that would take a user input and output the square in Director. There are several flowchart examples in the online programming readings.
The second tool is a word tool, akin to the sentence outline. It is called pseudocode--which is "sort of, but really fake" code. You write out, in everyday language, the sequence of instructions. This makes the actual programming more of a translation exercise from everyday language to the specific syntax of the programming language. We took our flowchart problems and turned them into pseudocode. There is a pseudocode example in the online programming readings also.
The next step is the translation into a programming language. The ease of that translation depends on the nature of the programming language. The hardest languages to write programs in are low-level languages. If you think of the computer itself as the floor, low level languages are on the steps closest to the floor. The computer only knows off and on, 0 and 1, called binary code, reminiscent of the vacuum tubes used in the first computers. The lowest of the low languages is machine language, in which programmers turns the words into 0s and 1s themselves. In that case, the programmer is the pre-processor of the code. The next lowest languages are assembly languages, which are like shorthand. Assembly languages take two processors, the first, again, is the programmer, who has to translate normal language into the shorthand, the second is a software program called an assembler, that translates the assembly languages into binary code.
Even programmers grew tired of translating into binary code and assembly languages, so they created high-level languages, languages that closely resemble human language and familiar mathematical notations. These languages also depend on a program to process them that is built into the language. There are two types of software program processors. Interpreters translate the lines into binary code one by one. Compilers take the entire program and then translate it. Examples of the third generation languages include BASIC, FORTRAN, Pascal, C, C++, Java, and Lingo. C, C++, and Lingo use compilers. The Lingo compiler runs whenever a script window is closed, or whenever the program is run (even if the script window hasn't been closed). You know a compiler (or an interpreter) is at work because it will spit out error messages at you if your syntax is wrong. (As you'll learn, sometimes the messages maker perfect sense, often they tell you you've made a different mistake than the one you actually made. This is because, like in sill word-processing programs, it assumes you were trying to do something different that you were actually trying to do.)
The next generation of high-level languages has fewer statements and employ visual tools. Lingo can also fall under this category because you are actually writing many short sub-programs and functions, not one long one. You then "drag" or "attach" those programs onto a graphical element like a sprite or a frame or a cast member, and Director writes the remaining necessary code that you don't see. If we were doing the same thing in C++, we'd be writing many times more code, and we couldn't easily and quickly see what we were creating.
Another high-level language type is object oriented programming languages. These languages use code that is close to human language also, but structures the programming differently. They try use software to model real life objects (like a car) that have properties (make, model, size, color, weight, number of doors, type of engine, number of cylinders in the engine, power windows, CD player, leather seats . . . ) and behaviors (it moves forward and backward, it turns, it starts, it stops, it speeds up, it slows down, if it's in a James Bond movie it floats and flies and self-destructs . . .).
The goal of object oriented program is to create reusable units that make writing programs quick and efficient. To do this we try to make code as generic as possible--creating objects whose properties we can set as we want to instead of creating code for every instance of an object. For example, when we create the sprites in a game, we'd create an object that has properties of point value and movement direction and movement speed and number of hits it takes to claim it or kill it, then we'd create "instances" of that object and put in the values we need for each one. That way we write the code once, and fill in the details (parameters in programming language) as needed.
Objects in Director/Lingo include cast members (that have names, height, width, scale, maybe text, foreground and background color . . . ), frames (that have numbers), sprites (that have scale, rotation, locations (horizontal and vertical), channel numbers, . . . )the stage (that has height, width, background color, . . .). All of these things can have behaviors "attached" to them that affect how they behave when they receive certain messages (mouseEnter, mouseUp, exitFrame, beginSprite, or user-defined functions). We'll review messages and hierarchy in week four, and properties of these objects in later weeks as we use them.
We created an example in Director of the squaring program. We created scripts that made a field editable (so that a user could type in it), took and stored user input from one field, performed the calculation when a "Calculate" button was pressed, and displayed the answer in another field. I will upload that to the server as soon as I can. I'll also upload a calculator program that I created that is inspired by the class example as soon as I write comments on it to help you see what I was doing.
Animation in Director® can be done with both the score and Lingo.
Horizontal, vertical and diagonal movement, rotation, scaling, and skewing can be done both with Lingo and the score. Your midterm and final projects in this class will use Lingo for most animations. For example,
we move a sprite 5 pixels to the right using the code
sprite(x).locH = sprite(x).locH + 5
or to the left with
sprite(x).locH = sprite(x).locH - 5
or up with
sprite(x).locH = sprite(x).locH - 5
or rotate 5 degrees with
sprite(x).rotation = sprite(x).rotation + 5
or scale (shrinking 5% each time) with
sprite(x).scale= sprite(x).scale * .95
We'll go over more about animation with Lingo soon.
Sometimes Lingo isn't the best choice for animation--especially if it's a really involved path or transformation. In those cases, we'd use one of several options. These are described in Chapter 2 of your Director 8 Demystified book.
Cell animation -- traditional animation in which a series of cast members are placed on the stage, each slightly different from each other. (remember the Swifty example in class). There are two ways of doing cell animation in Director. You can move each cast member, one at a time, to successive frames on the stage. If your cast members are all in the order you want them, select the first cast member you need, then Shift-select the last cast member you want and make sure all of the ones in between are highlighted. The choose "Modify/Cast to Time") and they will all be placed in order in separate frames. DON'T select them all and then drag them to the score. If you do that, they will instead be placed in the same frame in separate channels.
Tweening -- tweening requires setting at least two "keyframes," which designate the starting and ending points of a sprite. Director will then fill in the "in-betweens," thus "tweening" the animation. Popular uses of tweening are for moving sprites, fading sprites in and out, scaling, and shape transformation. (remember how we moved Swifty around the stage). To use Director's tweening, select the channel and the frame you want to start the animation in. Choose "Insert/Keyframe". There will be a dot in that frame in that channel. Select that one frame (not the entire sprite) and position the sprite where you want it on the stage. Select your next position point (same channel, different frame) and again choose "Insert/Keyframe." Select that single frame of the sprite and move the sprite where you want it. You can also rotate or scale it. You will see a beginning and ending dot (green and blue) and a white trail with a lot of little dots on it (these represent all of the frames in between). If you don’t see those dots and trails, you didn't have the single frame selected before you moved the sprite. Keep doing this as often as you like!
Real time recording--allows you to directly "record" the movement of a sprite on the stage while manually dragging the sprite around the stage. Choose "Control/Real Time Recording" and you'll see a red dot in the sprite channel you are moving. Move the sprite around the stage and press stop on the Control Panel when you're done. Director will write all the key frames.
Step recording--modified version of Real Time Recording in which you set up the recording attributes first and then move the playback head one frame at a time, moving the sprite a little on each frame. Choose "Control/Step Recording" and you'll see a red arrow in the sprite channel you are moving. Open the Control Panel and use the arrow to move forward one frame and then move the sprite to the next position you want on the stage. Press stop on the Control Panel when you're done. Director will write all the key frames.
Loops--once you have created an animation on the score you can save the entire animation as a loop, which allow you to move the moving animation around the stage further. For example, we created a loop of Swifty walking and then tweened the loop across the stage so it appears that he is walking across the stage. To create a loop, lay out the cast members in the sprites as you want them. There are two very important things to know about loops:
Online readings on programming (1 , 2), Animation discussion and tutorials in Chapter 2 of Director 8 Demystified.