Making Score Recording Work for You!

January 19, 1999
by Chris Griffith

A few months ago I was programming an informational CD-ROM that was based on the user navigating around a virtual university campus. As the senior developer on the project, I was faced with developing the engine that would manage and control the user's location in this environment. This environment consisted of a large Quad area surrounded by ten buildings that the user would enter and explore. Within each of the buildings would be exhibits and other interactive elements.

The main question before me was how to program the core navigation. The user for about 95% of the CD-ROM would only have four views to rotate through at each navigation node. In working with the lead 3D designer, it was clear that no section of the disc was going to have no more than 30 nodes. We mapped the location of each of these nodes on a wire frame map of each section, and gave an id code to each. We also applied an universal north to all the models. This would enable me to tell which direction the user was facing based on the file name. Using this fixed direction, all the camera views for each node were rendered in a similar manner. Thus a series of images for a node would look like: GK10-001, GK10-002,GK10-003, GK10-004. We used the G at the start of the file to tell what type of element it was (G was for graphics, A for animation, S for sound, V for Video, T for Text, and X for Xylophone because X is ALWAYS for Xylophone!) This naming and numbering system eased the asset management burden through the numerous client revisions.

But how to assemble these assets in Director and construct some form of engine to enable the user to navigate?

The first approach that I considered was from a programmer's frame of reference. Since most of the scenes would be simple static images with just navigational hotspots on them, controlling the score by reading the scene's information from a large list and puppeting elements on to the stage seemed fairly straight forward. Just create some really large list of property lists, maybe even use an XTRA-based database, and start coding.

But this approach did have some drawbacks. Most notably the lack of visual inspection of the virtual environment within Director. One would have to run the code and navigate to the node to view the composited scene. It also forced much of the visual construction to the programmer (read: me) rather than the artists.

So given these issues, I chose to develop a simpler navigation engine and let the score do most of my work. Why not let each scene be placed on the score in its own frame? It was certainly not as cool as a one frame movie controlled by some really complex lingo, but perhaps more practical.

All I had to do was code the engine to jump from frame to frame based on the user's choices. But why should I have to place each scene, add the appropriate labels, and position the navigation hotspots? Remember I have some 300-400 separate nodes to build, each with 4 views (some nodes had more).

Enter score recording. Remember that the artist and I have set a fixed direction and created a node identification system. Well, that meant that my cast was going to be nicely organized as I imported them. All I had to do was construct some Lingo to work its way through the cast and place them correctly on the score, add the fixed hotspots, and a marker label, and I was ready for a some coffee. Here is the Lingo I wrote to do this:


on buildLayout theStartFrame,theStartCast, theEndCast, theCastLib
  set currentNodeName = ""
  beginRecording
  
    go frame theStartFrame
    
    repeat with theCurrentImage = theStartCast to theEndCast
    
      set theCurrentImageName = the name of member theCurrentImage ¬
        of castlib theCastLib
      set theCurrentImageID = char 1 to 4 of theCurrentImageName
      
      if currentNodeName <> theCurrentImageID then
        -- New Node
        set currentNodeName = the name of member theCurrentImage ¬
          of castlib theCastLib
        set currentNodeName = char 1 to 4 of currentNodeName
        set the frameLabel = currentNodeName
        updateFrame
      end if
      
      set the member of sprite 1 = member theCurrentImage of ¬
        castlib theCastLib
      set the locV of sprite 1 = 188
      set the locH of sprite 1 = 320
      updateFrame
    end repeat
    
  endrecording
  
end

About every two days I would receive a new set of renders. I would then import the PICTs into the media cast for that movie, and run the build layout script. This whole process would take about ten minutes. I would take about another ten minutes to input the data from the wireframe map into the navigation engine and we were ready to explore our virtual environment.

The actual navigation engine took about a half day to write. It was basically a property list of lists that contained each node as the property. Each node also contained a list of which scene could be viewed from that node. The list would also contain the node id of where a forward navigation would lead to. Thus a sample entry would look like:


[#GK02: [ [ [4,2], [1,3], [2,4], [3,1]], [#GK04, 0, 0, #GK00] ]

Unfortunately, I can not release the actual code, but this should give you some ideas how this could be done.

Oh, remember how I was concerned about having to do much of the tedious visual composition tasks?

In one large section of the environment, the user is in an underground maze. The client switched from normal lights to torches. So we now had to add flames on to each torch. This meant positioning filmloops on about 100 nodes, and many views had multiple torches. If I had used the 'one frame' method I would have been the one to add the torches. But, by having the actual scene on the score, one of the junior artists was able to create the film loops and position them on each view without much trouble.

Starting with a MacSE (now a MacAquarium), Chris has been working with Director since version 3 and continues to explore the uses of multimedia. He is currently an engineer at Pacific Science & Engineering Group, Inc., a company specializing in human factors research and development. He has developed DVD, CD, and Shockwave projects for such clients as Presto Studios, The Coca-Cola Company, J. Walter Thompson, and the United States Marines Corp. Chris can be reached at cgriffith@pacific-science.com when he is not kayaking in the Pacific Ocean or playing with his 6 year old twins.