Internet Operations Management

December 11, 1997
by Steve Kury

This article is the first of a series in the interest of wide-spread propagation of object-oriented methodologies into Lingo programming and project development with Macromedia Director. Object-oriented programming, OOP, is one of the most sophisticated forms of programming, and it makes projects easier to engineer if incorporated.

A common mistake made when using Director is not respecting it as a software development tool. Those developers who treat Director simply as an off-the-shelf multimedia visual content development program, and not as a software development environment for the purpose of creating content driven software, are not using it to capacity and can easily do themselves a disservice in the long run of the project.

One way that they do this is by not placing enough significance on the engineering and programming of the project. They sometimes bring in the programmer in the end of the project, instead of in the design phase when he/she needs to make the engineering input. It can be quite frustrating to have to interrupt the programming while designers and producers have to redesign parts of the project because they weren't thought out ahead of time and thus conflict with each other. Object-oriented design enables clearer conceptualization of project so that this can be avoided.

Another way is by not hiring programmers of requisite skill and experience level for the project. There are many ways to save money when running a multimedia project, hiring cheap programmers is not one of them. By bringing in qualified people, and that means paying for them, you save money in the long run because they eliminate most of their mistakes in the engineering, they don't paint themselves into holes that they can't get out of in the final stages of the project, and for the most part they just do it well the first time through.

Hiring the right people for the job, especially programmers, saves unnecessary headache and frustration for all involved. (This carries over to artists also, for instance an artist who doesn't cut and format the art due to his/her carelessness and lack of foresight for the programmer's needs adds to the programmer's frustrations and time involved. But this is another story for another time). It will make it a much more enjoyable process for all as it goes along smoothly. Quality performance under deadlines does not come cheap. After all, multimedia is not rocket science but it is expensive and highly technical. OOP gives enables greater structural flexibility in the later stages projects, and this helps them run smoothly.

Enough with my industry gripe, on with the OOP demo. The point is that object-oriented programming allows you to conceptualize the project from a high level and think of everything in terms of building blocks and units of building blocks which can be recycled. (It also increases your value as a programmer to any producer and technical director that understands it. The tangible motivation, hint, hint...)

What I am going to do here is build and implement a simple object for managing internet-related operations. What it will do is constantly monitor a text file, located on a distant server via the WWW, for a piece of information that changes randomly. This could be useful for any number of purposes. For example, a multi-player Shockwave game that is controlled by a central server. The game conditions, i.e. level, player statuses, "random decisions of the Imperial Overlord," etc... are placed in that text file by the moderater and/or CGI calls from other clients in the system. By constantly monitoring it the application can always be up-to-date on the latest game developments involving the other players. (This is not the most interesting example, but it illustrates the point.)

1. In the first of the two frame segment, the setup frame, instantiate the object in the frame script. This is where the object is actually created and stored in a global variable. It contains the object's properties, internal variables and states, and methods. The URL to the text file is being passed in as an argument. Things to understand about this are:

Once the object is instantiated the script is no longer referenced. The properties and methods are stored in the object, not referred to from the script.
If later on in the project, say near the final stages, it is decided that you need to monitor a second server-based text file, all that you have to do is:
1. Instantiate it in the setup frame script, passing in the second URL as the argument, and store it in a second global variable.
2. In the action frame script place a second thread method, which has the same name, and have it refer to the second NetMan object instead of the first.

This saves much time and effort because you do not have to create a second set of variables and methods for the second object. The information within the object class script is generic, working identically for each instantiation of the object. Any information specific to the instantiation of the object is passed in during instantiation. You only type three lines of code for it, the instantiation, the global variable declaration, and the thread. (For the first instantiation you write the class script, global declaration, instantiation, and thread. Now you reuse the class script and only write the other three lines of code.)

Object orientation allows you to make additions like this simply and with minimal effort. Having written the object class, if you wish to use it again in another application you simply paste the script into the cast, instantiate the object, and place the thread appropriately. Hardcoding the URL into the class prevents you from using it over again for another text file. Write it once and use it over and over. Once you get to a point where you have amassed a library/collection of various objects classes you can engineer complex projects relatively fast and efficiently.

2. In the second of the two frame segment, the action frame that repeats continuously, you place the thread for the object in the frame script. The thread is merely a method that is called every time the frame is cycled through. Things to understand about this are:

You do not need to redeclare the global variable containing the object in this, or any other, script. When you call one of an object's methods you are telling the method which object to refer to, you are not passing it in. If you have multiple objects based on the same class you call the same method for each and specify which object you are referring to, as mentioned above.
As the frame is cycled through it will be perceived that the thread's activity is happening non-stop. In this case it is because as soon as the thread completes its course of action the frame repeats and does it again. When you have several threads in the action frame script, they get cycled through so fast that they are perceived to running simultaneously, when they are really carrying out their individual activities one at a time. (This is how you get several actions to appear to happen "simultaneously.")
"Repeat while..." loops, i.e. "repeat while the mouseDown" and "repeat while the ticks is less than...," tie up the processor and interrupt the threading process. Avoid these as much as possible if you want your threads to function well. For example, a "repeat while mouseDown..." loop lasting 30 seconds would interrupt the functionality of our object(s) which need(s) to be working continuously. If information on the server's text file(s) get updated every 5 seconds you would have missed 6 updates. That is a lot of time and potentially significant information in gameplay.
Because Director automatically updates the stage on enterFrame, your need for updateStage commands is drastically diminished. Depending on how you do a single-frame animation, for example a character dancing across the stage , it may not require even a single updateStage command. (I will cover time controlled single-frame animation objects in the next article.)

3. Most of the netManager class, class is the computer science term equivalent of parent script, should be straight forward programming. I won't go into most of it. The manageNetOps method is the thread, the method that is called every time the frame is cycled through. Do note that:

getNetText, netDone, and netTextResult are all functions. Make sure that you place parentheses around their respective arguments. Parentheses around the argument of a method signify that it is a function, and thus is to return a piece of information.
I am using messageFlag, paralleling the messageID, to determine whether or not to set the messageID or check for netDone. I think that is cleaner and more organized than testing the property in question to see if it should be changed. It is also a question of style, you could do without it in this demo. It may be useful to set it now for when the thread gets complicated.
If the contents of the message property is to be placed into a text field, only put it into the field after it changes, not every time you retrieve it. (Don't tax the processor unnecessarily.)

The aforementioned example (HQX or ZIP) is very simple for the purpose of illustrating the concepts of object creation and threading as clearly as possible. In the coming articles of this series I will create a single-frame animation object and combine it with this net management object for the purpose of building a multi-threaded application.

Steven Kury is an interactive media developer living in the SF Bay area. He has worked on several integrated CD-ROM/internet/backend systems and has good breadth of experience in interactive media, including a stint as a QA engineer on the Director engineering team at Macromedia. He can be contacted at skury@primenet.com.