The design of the interactive play space dominated this programming session. I focused on three areas in this order: 1) programming the cueing of the many landmarks along the ride, starting on Nowhere Road, going through Athens, and ending at the University of Georgia campus; 2) programming some curves into the ride along with the interaction of the player steering the bike; 3) minor redesigning of the hill gauge which gives the player feedback as to the terrain of the road.
This prototype again represents about 5 hours of work. A large portion of this time was spent 'coding' spots on the map where the curves should start and end. It also took a surprising amount of time to 'code' the spots on the map where each of the landmarks should appear.
Interface Design Issues
Adding landmarks
In this prototype, I embedded a total of 14 landmarks corresponding to actual places on Nowhere Road and the Athens area. The programming triggers the landmark when a certain distance has been reached. This prototype does not yet include actual photos of the landmarks. I'm not worried about adding those until the end. (Though I am apprehensive about how the performance of the program will be affected once the photos are actually added, at least in the shocked Internet version. As previously noted, I've intentionally kept the screen area small -- thumbnail size -- for this very reason. (I figure I can put larger versions of this photos elsewhere on my web site for people to browse if needed.)
Adding Curves and Steering
I had a great time with this! I honestly enjoy these kinds of design problems and the programming challenges that ensue. I had been thinking about the proper design strategy for quite some time. As noted previously, I thought a first-person view would work in some way, similar to what is used in hundreds of video games. Using the bicycle's handle bars as the key reference point, I figured I could somehow get some illusion of the roadway curving in this graphical area. This prototype shows one approach that I'm quite happy with. It uses a simple graphic of a roadway (complete with shoulder areas and a yellow dotted line marking the center) that animates left and right. The roadway display perpetually animates from 0-10 controlled by the variable "roadway" using the following command line:
...where "curve" is a variable that determines the curvature of the road (when its value is positive the road turns right and when negative the road goes left; the larger the absolute value, the curvier the road at that point;
...and where "turn" is a variable under control of the player that steers the bike left and right. If the player turns the bike at exactly the same value of the curve, the bike follows it path precisely on the roadway. Obviously, if both "curve" and "turn" are zero, then the road is perfectly straight and the bike is moving perfectly straight as well.
I have built scores of similar kinds of perpetual animations in Authorware over the years, so I felt very comfortable and confident about how it might work.
NOTE: I intentionally left the edges of the animating roadway fully exposed in this prototype in order to give you the idea. In the next prototype, I will hide the edges so that the roadway seems to come and go into view. I also removed the option to use mouse clicking as an alternative way to pedal the bike. It interfered with the steering feature. (Authorware had competing instructions on how to interpret a mouse click.
Hills
Effectively communicating the concept of a hill is proving to be a difficult design problem. I don't like having a "hill gauge" for several reasons. It is completely artificial. Instead, bikers rely on the "feel" of the road to detect changes in a road slope. Most importantly, bikers anticipate the terrain by using the straightforward visual cues of what lies ahead. In playing prototype 2, it is impossible to anticipate a hill change (other than playing the game lots of times and memorizing where the changes occur). Again, the best visual cue would be to rotate the biker animation to show the slope. Knowing that I can't do that with Authorware, I decided to just tweak my hill gauge for now. I've added a second gauge that shows that the upcoming terrain will be like. This, at least, helps the player to anticipate the upcoming slope.
Technical Problems & Solutions
Post Script: Search for a lost road
I think I solved the mystery of the lost road, though one or two new mysteries have taken its place. I took a ride this morning, deciding to take SR 334 south all the way to where Wages Bridge Road should start (kind of like searching for the source of a river). The map shows an unnamed road intersecting SR 334, about a half mile from US 441, which leads to Wages Bridge Road. As it turns out, this unnamed road is Wages Bridge Road. The road labeled Wages Bridge Road is actually called Ed Bennett Road. I had seen Ed Bennett Road yesterday where it intersected what is labeled Sanford Road on the map and had wondered about it since it was about where Wages Bridge Road ought to be. It was a dirt road at the northern end, though it was paved where it turned off of Wages Bridge Road at the South.
So, now I'm left wondering why this map had the wrong roads labeled. As you recall, I downloaded this map from one of those "Whowhere" web sites (you enter an address and it finds it for you, map and all). Is the map just wrong or did this road get renamed recently? Another mislabeling on the map is that it shows that Wages Bridge Road goes all the way to Sanford Road. It does not. Instead, it stops at another road, named Cooper Road, that runs roughly parallel to Sanford Road about a half mile or so south of Sanford Road. Again, is the map just wrong, or did Ed Bennett Road actually go all the way to Sanford Road at one time. If it did, what happened to cut it off?