Students will learn the art and design of interactive media, as we survey existing approaches and attempt to integrate them in unique ways. They will work with a shared information space, which contains select topics in ancient Egyptian history and art-history. This knowledge base will be fully online and expressed as: spatialized virtual environments, multimedia, video, bibliographic access to certain library collections and live interaction (remote vision and voice) with Egyptologists.
Physical interfaces include standard desktop computers, a large panoramic theater and a fully immersive virtual reality theater. Parallel to other classroom activities, students will learn and interact within this information space via online chat, electronic bulletin boards, networked virtual reality, and distance learning technologies. The provided software attempts to combine these approaches to present a multi-faceted interface to the knowledge base.
The students will use this software as a workbench for learning exercises and personal experiments, while the class as a whole begins to develop it into a coherent software application. The course is offered as an interdisciplinary research course by the College of Fine Arts and the History Department. No prerequisites. All majors are welcome.
06 December 2001
The next class meeting will be on December 12th at 5:30 in the CBPD.
You have three assignments for the rest of the term:
Cleanup and debug your projects, so they can be ready for the (academic) public. Due December 12th.
Come up with your own, personal, self-evaluation scheme, as described below. Be ready to discuss it on the 12th.
Writeup some documentation pages for your project, as described below. Each team does one writeup. Due December 19th.
Self Evaluation
You need to develop some rationale for evaluating yourself in the context of this class. You will tell us, in class, what the rationale is and the results it gives you. As with projects great and small, this one has requirements. The evaluation rationale must be:
USEFUL Your evaluation scheme must be of some benefit to you. Maybe it will help you identify your strengths and weaknessed. Maybe it will give you information to be a better decision-maker. Maybe its a way to measure your skills in certain areas. Whatever, it's not just busywork.
POSITIVE Do not use this as an opportunity just to externalize feelings of inadequacy or low self-esteem. Lots of easier ways to do that--away from us.
YOU WIN Keep it simple, keep it sane, and make sure you write a test for yourself you will pass. ;-) In life, you have to decide what is important to you and how to check your own progress. Might was well get started, now.
Attendence and attentiveness.
Goals. Did you achieve your goals? Were your goals realistic or relevant. Were you smart about changing your goals when you needed to.
How much did you learn?
Did you work hard enough?
Were you motivated?
Did you play well with others?
Was your work efficient? Was you work effective. Efficient and effective are different. They are not even opposites, but merely unrelated.
Did you make any money?
did you gain weight
This list could be endless. The point is to select dimensions which are relevant to who you are and what you want to know about yourself.
Project Documentation
Each team will produce a short introctory page containing:
Name of the thing/project.
What it is and what its for. Usually a few sentences are enough.
Hyperlink to the project itself.
List of the harware and software needed to run it. (PC, IE, etc.)
Credits and acknowledgements
Create another web page with:
Write 500 to 1000 word page for the readers who wish to do research with your project or build upon it. It should say something about the context and rationale for the project to get them going in a reasonable direction.
A list of the files and other components of which your project is made. Try to annotate or label the in such a way that reader can guess what each one is for. You might write a few sentences about the project structure, if you think it helpful.
A list of source materials. A bibliography, really. Keep it short and just stick to the main sources.
A list of all the useful components of your project, which you never integrated. Put them all in a "goodies" folder for future builders to use on thier own projects.
It would be nice (where possible) if this information were acessable from inside your project, if that makes sense. You never know how anyone else is going to link to your project, and they may skip the introductory page.
The MUDD is expanding, getting more interesting. We encourage you to visit via the "telnet usl.sis.pitt.edu 2000" command, from any DOS or UNIX shell.
October 2001
Please check the general forum and the forum for your team. People have made useful and important postings to both.
Your assignments for this week:
Complete your Project Designs and upload them to your "workspace" areas. There should be a copy in *.pdf format for viewing on the web, and the original in whatever word processor format you used. I encourage you to post it early, so Lynn, Lowry and I can comment.
Create a dumb, simple, example or mock-up of your project. Just enough to get the idea across.
The cosmology and timeline groups are now merged into the new "timeline" group.
Please welcome Colin Lauver to our extended family. He's the fellow converting the Temple of Horus to Unreal Tournament format, so we can show it in the Earth Theater at the Carnegie. You can see snapshots, and download his "rough draft" temple at: hemef.cfa.cmu.edu/egypt/workspace/unreal/
26 September 2001
Each project team must present their project design to the class. See Assignments for instructions.
We now have a bunch of dlists and forums for the course. To access both by hyperlink, go to the List of Everybody on this page.
Students are required to use the electronic forums, or at least try them. They have a significant advantage over e-mail in that messages posted there, stay there. See "Online Forums" for instructions.
Read, read, read your Egyptology! Read the readings Lynn Xeroxed, especially the chapter intended for your team. Check out Bella's Bella's bibliography for books at the Hunt and other resources. Look at Lynn's cyberlinks. The more of the right information you have, the easier your project will be.
The online CD materials on Hemef just got expanded Have a look.
19 September 2001
As you can see, I have rewritten the course info page, which subsumes the old announcement page. Please look it over and send me your suggestions. General news:
Student assignments, due 9/26/01, are described below.
A bunch of new CD materials have been translated from and uploaded to http://hemef.cfa.cmu.edu/egypt/cd/ The changes are not immediately apparent, it's just that a lot more links work, now, and lead to interesting things.
The MUDD is working most of the time--Herb has to occasionally take it offline to make changes. You can connect by opening a telnet session in DOS or UNIX by typing: "telnet usl.sis.pitt.edu 2000" and follow the instructions. The MUDD will move to Hemef, as soon as it's ready. Refer to the MUDD's building guide.
The system software map handout, and three new maps are listed below. Please have a look, especially if you missed class on 09/12/01
Below is a list of the software licenses we have, which you are unlikely to find in the clusters. They are available for use in course projects.
Colin Lauver, at the University of Michigan, has completed an Unreal Tournament version of the Temple of Horus. It still needs some bugs worked out, but those of you familiar with UT may wish to play with it.
I have installed several instances of Perlboard, which is a freeware electronic bulletin board written by Jessica Blank. I chose it over many other more featurefull systems, because it's basic functions are very easy to use. (More on this, later.) Eventually, we may upgrade, but for now it's plenty.
To find the other forums, look at the List of Everybody.
To get acquainted with how perboard works, you can play with the Practice Board. To reach it, just click the hyperlink in the previous sentence or type in its URL which is
http://hemef.cfa.cmu.edu/perlboard/It is important that you put the slash at the end of this URL.
You will see a numbered list of messages. Click the "Enter a New Post" message. A dialogue will pop up asking you to log in, or create a new account. Click on the create account button/text.
Another dialogue will pop up, which will ask you to fill out a "user profile" form. You will need to make up a name, a password and give it your e-mail address. We have about six different forums, so please use the same name for all of them. Yes, you will have to create a new profile for each one, sorry. Make your password very simple, if you like. We don't really care if anyone hacks into the Bulliten, we just want to make sure there is some guarantee that posts in your name really *are* from you!
When you finish, it will show you the screen for making a new post. Fill in the title and type a few words in the big window for the body of your message. Feel free to click one of the tiny icons to indicate the mood of your message. Now, click the "submit" button.
The next page to pop up will show you your message, as it will appear on the forum. Along the bottom are buttons, which allow you to cancel the message, go back to editing it or "Post" it to the bulletin board. If you press "Post", the message will go to the main board.
Click on "Return to Message Listings" on the next page to see your handiwork. To read it (or any other posting), double click on the message title.
On the main message list, just double click on the title of the message you want
Double click on the title of the message you want to specifically reply to. The page you use to read messages has a reply button, which you press to start writing your reply. When you are done, your reply will be indented under the message you responded to in the man list
Just highlight text from anywhere and paste it into the text window on your message editing page. You can clip text this way from a web page, but it will show up as text and not HTML.
In your favorite work processor write your big message, then copy it and past it into the text window in the new message main text window. If there is a size limit, it's large!
If you know HTML, you can just type it into the main text window for the new message, and your note will appear as it should in a web browser.
In your web browser, use the "view source" option for the web page you want to copy. When the source pops up in its little window, highlight all of it, copy it, and past it into your message text window. When you press "submit", you should see the copied page looking much like it would in a web browser.
HOWEVER, most web links from the page will probably be broken, because they are usually relative to the location of the html page on the web server. Absolute links, those of the form "http://www...etc...html", will work fine. Also, all sorts of fancy java stuff will break too. Stick to simple HTML for the forum.
All you need is to write or somehow create an HTML page, with your image(s) in it, and copy it into your message. Make sure the href to the image is absolute. For example it could be "/home/goshen/fool.jpg", which will work just because this user account is on the same machine as the perlboard. A safer way is to put in a regular web URL, like "http://hemef.cfa.cmu.edu/images/front-page.jpg"
By mutual agreement the class has divided itself into four teams. Each team will add a new way to interact with our cyberspace and/or new places to go within it. The following descriptions are preliminary, and will improve as the projects themselves become better defined. In random orders, they are:
Depict the changes that occur during the Egyptian year. Allow the user to move from one season (month? day?) to another using some control device.
Depict the four different cosmologies evident in Egyptian religious tradition. Give the user a way to move from one to another.
Create a game of some sort, which takes place in our cyberspace.
Perfect the MUDD->Java control pipeline, Create the Java->MUDD pipeline. Train everyone on how to use the MUDD. (This team is basically Herb and Jason)
DLIST for Everyone Online General Forum
| Games Project | DLIST FORUM |
| Jonathan D. Bradbury | jdb2@andrew.cmu.edu |
| Sriram Gollapalli | sriram@cmu.edu |
| Sabrina Haskell | shaskell+@andrew.cmu.edu |
| Jennifer Smith | krchicken@cmu.edu |
| Samantha Olschan | solschan@andrew.cmu.edu |
| Jill Palermo | jpalermo@andrew.cmu.edu |
| Timeline Project | DLIST FORUM |
| Philippe Monin | pmonin@cmu.edu |
| Anat Pollack | apollack@andrew.cmu.edu |
| Zak | zak@dvdempire.com |
| Huntington Howe | hhowe@cmu.edu |
| Micah Naeser | mnaeser@andrew.cmu.edu |
| Jonathan Amakawa | jamakawa@andrew.cmu.edu |
| Cheryl Platz | cnp@andrew.cmu.edu |
| Instructors | DLIST FORUM |
| Lynn Holden (content) | lholden@starmail.com |
| Lowry Burgess (synthesis) | lb30@andrew.cmu.edu |
| Jeffrey Jacobson (tech) | goshen@sis.pitt.edu |
| Collaborators | DLIST FORUM |
| Colin Lauver (Unreal Tournment) | colin_lauver@hotmail.com |
| Jason Yates (Tech) | sistence@telerama.com |
| Herb Gilliland (MUDD) | heg@andrew.cmu.edu |
| Sheila Halter (Archive) | shalter@pghmail.com |
| David White (Flash) | knave@sgi.net |
| Bella Girlich (Hunt) | bg2r@andrew.cmu.edu |
| Jane Vadnal | medart@pitt.edu |
The short answer is to startup your web browser and go to
http://hemef.cfa.cmu.edu/egypt/To access Interactive Ancient Egypt properly, your computer must have moderately strong graphics capability. A standard iMAC, MAC G3, or any PIII PC with a $50+ game card should be adequate. You will need a web browser with Java enables and a VRML browser plug-in from Cosmo. Cortona and Blaxxun work too, but are not guaranteed. All are free, and work with either Internet Explorer (IE) or Netscape. You may have trouble with IE on the MAC, however. If you need help please contact Mr. Jacobson.
An informal mirror of this site maintained at:
http://usl.sis.pitt.edu/egypt/Members of the class use this machine to engage in development efforts that may be disruptive. Once projects developed on "USL" are stable, they are moved over to "Hemef". For example, the MUDD->Java control mechanism is currently available only at http://usl.sis.pitt.edu/egypt/mud/
Everything we post on the web is open source and freely available to the public for non-commercial purposes. Enjoy.
Get ready to present a detailed design of your project for class on Wednesday, and hand in a written design document. The written part can be anywhere from about six to sixteen pages, depending on how your team lays out the information. The real measure of whether the document can convince yourselves and the instructors that you can use this as a roadmap to get a useful project done. The design should contain:
Summary with diagrams of your system component, which you basically already have.
Very detailed description of how your application behaves. The timeline and cosmogeny groups will need to carefully map out how their component responds to input and what its outputs are. Flow charts work well, but are not the only way. The games group will also have to create an input/output map, but most of their project will be described in something like a multi-threaded storyboard, showing the available plot developments.
A careful description of how your application connects to the rest of the system and the larger internet. What are the main hyperlinks lead into or out of your application? What other means of communication link it to other parts of the system?
List what you expect the components of app will be. Make a diagram if appropriate. You can identify anywhere from 4 to 40 separate elements.
Describe how you intend to build your app and what tools you intend to use. Identify the tasks you will need to perform and how long you think each one will take. It's painful, but you must assign a number of hours for each task. Whatever you put down will be wrong, but it is important you though the process.
Estimate the amount of work you will have to do for your project. It's painful, but try to assign a number of hours for each task.
Create a project design, as described in the Project Design Instructions.
Read Chapter Three from "The Fourth Dimension" by Rudy Rucker
One person in each team must check out or buy a copy of "Envisioning Information" by Tufte, and begin reading it. Let the other team members know what you find, and let it inform your design discussions.
Fill out your mind-map or die!
Read: "The Visual Display of Qualitative Information", by Tufte. The whole book. Don't worry, because it's mostly pictures.
Read: Pages 1-30 in "History of ancient Egypt : an Introduction" by Erik Hornug
Read: Pages 20-40 in Kemp.
Teams: Think about how the class should be broken up into teams. Remember: we are NOT in production mode! You are coming into the middle of this project, which is just now entering the integration phase.
Read chapters One and Two in "The Fourth Dimension" by Rudy Rucker.
Explore the website.
The following software packages are available for coursework.
The powerful and complex animation and modeling tool. Don't use it unless you already know how or you are willing to spend some time learning it.
3D model translation program. Very useful if you are going to use existing 3D content. Converts models to and from: Maya, Mirai, Renderman, SoftImage, trueSpace, 3DS MAX, AutoCAD, Cinema-4D, Creator2, Lightwave, VRML, DXF and others.
A very useful tool for editing HTML, JAVA and VRML all at the same time. Good for web pages which coordinate all three.
The following maps illustrate various aspects of the Interactive Ancient Egypt system hosted on hemef.
This assignment is due on 09/29/01. Also, an sketchy version must be sent to us by Monday noon, 09/27/01, so we can see if you are generally on the right track.
By the next class, each team must produce a simple and clear definition of what exactly they intend to add to the existing system. This can be upgrading the existing system in some way, like smoothing the interaction design, or adding a new element like another room or an interactive story. Your design must include a clear description of:
The "look and feel" of your new component. What does the user see and/or hear, when these things happen, and in response to what. Alternatively, how does your project influence user interaction with the existing system?
The components, the nuts and bolts, needed to make your modification happen. Identify the needed artwork, software, narratives, sound, test specifications, etc. needed.
The tools you intend to use, meaning the software packages to produce or convert artwork, compilers used for code, code languages used, etc.
What it plugs into. If this is a new component, what parts of the system does it communicate with? How does the look-and-feel mesh with the other parts of the system? If it is a modification, then how are these modifications reconciled with what the system is and what we want it to be. Describe all this thematically, artistically and technically.
Dependencies: What is dependent on this modification and what depends on it?
Scalability: How your modification can be done at different levels of effort and payoff. Think up the most disgustingly simple and easy hack you could shamelessly produce. Think of how you realistically hope to do it, and finally how you wish you could do it. You can describe how to scale your project in a variety of ways-there is no wrong way as long as it is intelligible.
Create your design, as a team, physically together until it is done. You cannot do this kind of work effectively by e-mail or any other long-range medium.
Produce two to four pages of diagrams and/or words to describe your project. By Monday the 24th, you must "hand in" a rough draft, so we can tell if you are generally on track. Mail it as an enclosure to all three instructors.
Speak each other's languages. Programmers, it is up to you to explain to the artists what the software does and does not do and why it is that way. Use analogy and metaphor and drawings as needed. They cannot meet you halfway. Artists, you have the same imperative. You must explain to everyone, including the programmers, why a certain plotline makes sense or why something or another must be a certain color, etc.
Do not produce any actual work. NO PROGRAMMING! You can draw diagrams or simple storyboards, make quick sketches and try out certain software tools. You could even write a tiny piece of code to answer some important question, but NO PROGRAMMING on any part of the final product.
Do not be embarrassed about doing things the easy way.
Follow these exciting steps when you get together to work. Feel free to repeat as needed.
Get comfortable. Have some food or drink or cavort in the park. Fling out ideas and write them all down as they come to you. No idea is to silly, nothing too fanciful to be rejected. Do not: Say, "It cannot be done." This is the time to fantasize!
Take the list you produced from the brainstorming, and throw out everything that cannot be done. It is up to everyone to set limits. The programmers need to think about what software solutions they feel very confident with. The artists need to nix anything that doesn't make sense, doesn't fit with the rest of the system or might misbehave. Everyone must explain to everyone else why this or that won't work.
Decide what you want your product to be. Set the general goal, then figure out how it scale. As described above, figure out different levels of effort and effect. You must also prioritize the different elements of your modification to the system. If, for example, you want to create three stories, which one is most important?
And give to us.
Life is not fair. Make that work for you. There is no virtue in suffering. Pay your dues promptly, but make sure you are paying the right dues. We do our best work while at play. The things that come easily to you probably exercise your particular talents. The things you find most fun will ultimately be easiest for you.