Dec 6, 2007

Today is our last day so we'll wrap up the semester. I'll collect the Cell Phone papers, then I'll have just a few final words and take a few closing comments.

Then you're done!

Topics

Homework

Dec 4, 2007

Topics:

Homework:

Nov 29, 2007

Topics:

Homework:

Nov 27, 2007

Yet another brief day as all we have to do is see Luke's presentation from last week.

Topics:

Homework:

Nov 20, 2007

Today is a very brief day to let you start your Thanksgiving a bit early.

Topics:

Homework:

Nov 15, 2007

Topics

Homework

Nov 13, 2007

I don't think it's possible for the day to get any simpler.

Topics:

Scavenger Hunt:

Nov 08, 2007

Topics:

Homework:

Nov 06, 2007

Topics:

Homework:

Nov 01, 2007

Topics:

• Real Life Sim Presentation by Heather
• Discuss: Virtual Itza
• Discuss: Virtual World, Real Life Lawyers
• Discuss: Second Life Faces Mobile Death
• Discuss: Beijing Police Will Patrol Web Virtually
• Discuss: Real Hope in a Virtual World
• Discuss: Dennis Kucinich Opens Up Shop in Second Life
• Discuss: How a Computer Game Glitch Could Help to Fight Off a Global Pandemic

Homework:

Oct 30, 2007

Topics:

Homework:

Oct 25, 2007

Today we tackle the issues surrounding the second half of your "final" project. ...among other things...

Homework

Oct 23, 2007

Topics:

Homework:

Oct 18, 2007

No Class in the classroom today.

Please take this time to work on your Software Simulation Instructional Design packet. They're due next Thursday!

Oct 16, 2007

Topics:

Homework:

Oct 11, 2007

Topics:

Homework:

Oct 9, 2007

Topics:

Homework:

Oct 4, 2007

Three Real Life Sims: Bobby, Alex, & Brian

Topics:

• Oddware Presentations.

Homework:

Oct 2, 2007

No SL Presentations today.

Topics:

Homework:

Sep 27, 2007

Two Real Life Sim presentations. Bobby & Jesse

Topic:

Homework:

Sep 25, 2007

• The Crooked House
• Virtual Hallucinations
• Myst Online

Scavenger Hunt : A pet of some sort. We'll meet at the Beach House and show them off.

Sep 20, 2007

Real Life Simulation Presentation by: Bobby

Topics:

• Hardware Prototypes

Homework:

• Oddware

Sep 18, 2007

Second Life Sim: Mike

Other places by Damian

Homework

• Optional: Jewelry with "bling."

Sep 13, 2007

Real Life Sim: Jerilyn

Topics:

• My 4th Newspaper Interview about UB and Second Life.
• Four interesting Second Life books.
• Second Life Terrorism
• Second Life Punishment
• Reuters in Second Life
• Disaffected!

Homework

• Play Disaffected

 

Sep 11, 2007

Today we meet in Second Life at 11am.
Jesse will be presenting his first Second Life simulation.

Sep 6, 2007

Here are the topics we will be covering today:

• Ricky's Real Life Sim Presentation
• Non-Computer Platforms
• Computer Based Platforms

Homework

• No Homework
• Optional: New Avatar Hair in Second Life

Sep 4, 2007

Today we meet in Second Life.
Regular class time: 11am.
Run Ventrilo and log in to the server.
(Get the server / port info from the blue panel.)
Log into Second Life and I'll send you a teleport
to our location.

Homework:
(Read the Class Requirements for fuller details.)

• Student Setup
• Scavenger Hunt #1
• Class Photo

APPLIED SIMULATION     
COSC330.SG1     
Fall 2007     

-Ventrilo Information-     
Server: 69.12.74.141     
Port: 4143     

SOFTWARE SIMULATION DEVELOPMENT

Now we're going to shift from the role of an Instructional Designer to that of the Production/Development team. There are several "departments" in the development team, so we'll look at a few of them.

Graphics

As you might expect, the graphics team is responsible for creating the graphics that are on the screen. These will include splash pages, banners, buttons, interfaces, congratulatory screens, and so forth. You may well be in charge of setting the project's color palette, or you may be responsible for making all the graphics fit within a pre-defined color palette. You may also find yourself tasked with taking photographs and/or videos for the project. The videos may be live-motion video or may be animations created with an animation package. If you or your team members possess the skills you may find yourself creating 3D-models of equipment or people.

Some tools you may find yourself using...or may be handy to use...or you may find yourself recommending to use are:

• Photoshop, of course, for digital editing. Corel PhotoPaint is an equivalent.
• Illustrator for the sort of work it does. Corel Draw! is an equivalent.
• 3DStudio Max, Carerra (sp?), GameSpace, TrueSpace, LightWave, DAZStudio, Bryce, or some other 3D modelling tool.
• Poser for creating human models. Much cheaper than real actors! And can create animations of model movement.
• Flash, of course, for some animations.
• Premier or some other "video" editing suite.
• Particle Illusion for the creation of particle effects.

You may have access to the company's collection of licensed clipart and photo files. Using Photoshop and other tools you will likely be tasked with altering these images to fit the project. I was on a project for a Canadian banking firm and one of the images was that of paper money strewn across a desktop with other images overlaid on top. About three-quarters of the way through the project, it was brought to our attention that the money was all American bills...and we should have used Canadian bills instead. The image had to be reshot with the correct currency. Keeping your "working" images set with layers and so forth will make those sorts of changes easier.

If your project requires taking photographs of real people as models, you may have to consult with your legal team and have consent/release forms prepared. Scheduling times and locations to hold the photo shoots will have to be taken into consideration. Professional models may require payment.

Audio

The audio team is responsible for providing the audio effects for the project. Depending on the scope of the project, the team may only be the programmers using readily available sounds. Generic button clicks, whooshes, and other support noises are frequently available in royalty free packages.

Larger productions, however, may have more stringent requirements. Musical scores, overtures, and interludes, and special sound effects will require creating, finding, purchasing, and/or licensing of those sounds. There are a double-handful of sound sources for obtaining the necessary sounds ranging from internet downloads, to sound-effect collections, to music distribution companies like Music Bakery. I held a yearly membership to Music Bakery for about 5 years. Every month I received 1 or 2 CD's full of music that--because I'd bought them--I was free to use in any endeavor I chose.

If the project has voice overs, you will find yourself in with a whole new parcel of difficulties. The voice script will need to be prepared far in advance of recording date, which may mean that you will have to keep pressure on the Instructional Design team to finalize the audio script in a timely manner and discourage them from making changes. They probably won't like this as they tend to revisit their content and tweak, tweak, tweak. But you will have to get the script to your voice actors in plenty of time for them to review and practice the reading...just as if they were working a Broadway show.

Voice overs are usually done in two phases. The first phase is rough audio and the second is "final" audio. Rough audio is usually done...well, by you...and is made so that the programming team has "something to plug in" to their software to make sure their code is working. It is vitally important that naming conventions are established at this time. Instead of using descriptive names like "AllAboutInsurance.wav" you'll find you'll probaby name the files something like "CH1L12V23.wav." Keep a copy of the script with these file names written beside the text for each clip. The program will be written to play "CH1L12V23.wav" and that's what it will play. Later, when you create the final audio, the same clip will be saved with the same file name. This allows the programming team to just overwrite the old files with the new files of the same name. They won't have to go into their code to make line-by-line changes.

The final voice cuts will require fairly high-quality recording equipment and some sort of recording studio. One company that I worked for built a sound-studio out of an old closet. It was just big enough for the speaker to sit in and speak into a microphone, but it was sound-proofed well enough to prevent unwanted ambient noise.

The recording sessions have to be booked well in advance to make sure you have the equipment and can get your voice actor(s) into the studio. Make sure you have water (and lemon) available to keep those throats lubricated and healthy...or whatever needs the actor may need for those purposes. Again, your actors will likely have to sign legal release forms, and will expect payment! If you get Susie the Secretary to do your audio "for free," you will hear it in the final result with plenty of lip-smacking, dropped consonants, microphone "popping" and so forth. The professional voices are pricey...but the quality is worth the cost.

Be sure to schedule "re-take" sessions with your actors. It's almost a guarantee that sections of the script will have wording changes by the Instructional Designers, and new sections will be added. Other mishaps may occur such as "hiccups" in the recording process may also require retakes. Schedule them in advance, just in case, so that your actors will be available should you need then.

Besides collecting the sounds, you will also have to digitize the sounds into a format that is compatible with your programming software. Using a sound editing package you may have to add effects, shorten, or combine sounds. If you have a lot of sound effects--particularly voice overs--you will need an equal amount of room on the final media to store those audio files! Nothing bloats the size of a project like audio can.

• SoundForge is a good sound editing package.

Programming

The programming team puts it all together. Your tasks on the project will depend on your role in the team. The programming team must be able to read the instructional designer's storyboards, locate all the pertinent assets, and assemble the program according to the design document.

The lead programmer sets the standard for how the project is assembled. The lead will design many of the more important routines and specify how the other programmers will access and use those routines. She will also be the "point man" between the programmers and the other teams. If a graphic is too big to fit on the screen, the lead will talk to the graphics team to have the image resized. If a sound is somehow wrong, she'll discuss repairs with the audio team. Instructional data that is wrong, misleading, unclear, omitted, or otherwise incorrect will be addressed with the instruction designers. Bug reports from testing are examined and forwarded to the appropriate programmer.

The programming team follows the standards set by the lead programmer and assembles the project. As a programmer you'll find yourself working with all the elements of the project. You'll see all the graphics, hear all the sounds, read all the training, and--as a result--become pretty proficient with the target software yourself! On the other hand, you will be so bored with the content and repeated viewings that you'll be glad the project is finally over!

Any issues that surface while programming are taken to the lead programmer who will examine the difficulty, point out solutions, or take the problem farther "up the chain."

Finally, any bug-reports that come back from testing have to be fixed, tested, then resubmitted to QA (Quality Assurance) for re-testing.

Depending on the project, programming may be done in:

• C, C++, Java, BASIC, VisualBASIC
• Toolbook, Toolbook Assistant
• Director, Authorware
• Flash
• DazzlerMax

Quality Assurance

After assembling the project, or even part of the project if it's done as a series of lessons, the program is sent to QA (or some renaming thereof) for testing and bug hunting. If you're in QA, you will read the storyboards, test the expected flow of the program, and report anything that doesn't work as expected. Then you'll spend more time doing things that are not expected. Do the instructions say to "left click the File button"? If so, you'lll hold down the SHIFT key and double-right-click the button. Click the wrong button entirely. Press keyboard keys randomly. Enter numbers in fields that expect text, and text in fields that expect numbers. "Accidentally" exit the program to see how it messes with the operating system and if the program can be restarted properly. Any action that is incorrect, produces the wrong results, or otherwise "breaks" the program is recorded in meticulous detail and submitted back to the instructional designers or lead programmer for repair.

Often the QA team and the programmers feel "at odds" with each other. Programmers take pride in the cleverness of their code and hate it when the bug-reports point out errors. At times like this, it's important that everyone remember that they're all part of the greater team working toward a flawless release.