This is the final prototype which I will now heretofore refer to as "Nowhere Road - The Game 1.0". I certainly do not feel that the game is finished (see the discussion below about things still needing attention), but I feel this prototype meets all of the original design goals in a complete and stand-alone form. This journal entry describes the modifications added to this final prototype. This is also my final journal entry and, as such, I will conclude with some final reflections on this design experiment.
Graphic design
I replaced many of the original photos of the Nowhere Road landmarks with better quality photos. Yes, my photography skills, coupled with the small size of the final photos, still leave a lot to be desired. When I get some time, I plan on constructing a few web pages to supplement the game, such as showing the full-size photographs along side the same map of Nowhere Road used in the game. Other graphics were added, such as a good photo of the UGA Arches ("borrowed" from UGA's main web site) to the end of the game.
Cars, dogs, and stress points
Although I had long ago added the "mean country dogs" and had built the programming to ward them off with the bottle of dog repellent, I never really put any "teeth" into these game objects (bad pun, I know). That is, if a dog caught you, nothing bad happened. Instead, the dog actually appeared to ride on your handlebars -- not the vision of a mean country dog that I had intended! The reality of riding on Nowhere Road (at least for me) is that the sound of a dog bark immediately gets my attention, but I don't get stressed if a dog chases me at first (after all, it happens so often). However, I do get stressed if the dog appears aggressive or catches me unprepared. (There are a few dogs I've encountered elsewhere that do not bark before they chase and appear suddenly -- these guys really stress me out.) Likewise, I don't get stressed as cars pass me since it is a routine event, but occasionally I have what I consider to be a "close call" with a car which does make my heart pound a little stronger (more about cars below). To account for these negative events I decided to include stress points which accumulate when "bad things" happen such aggressive dogs and close calls with cars. I have not programmed any way to reduce stress, though had talked of doing so in earlier entries (such as enjoying the scenery), and may add this feature later.
After much deliberation, I also decided not to include the situation where a dog actually bites the player or causes the player to crash. I struggled with this. I have heard of cases where a dog has brought down a cyclist or has bitten a cyclist, but it has never happened to me. So, I'm going to leave all the negative consequences represented solely with the stress points. Coincidentally, just a few days before writing this entry (and after I had decided on this design feature), I had a very close call with one of the Nowhere Road dogs that I encounter almost every day. This is the most aggressive dog I've yet encountered anywhere -- a large mastiff-looking dog (with some Rottweiler lineage, I think) that lives in the "Valley of Fear" landmark depicted in the game, just a quarter of a mile or so from my house. I usually am able to get up enough speed as I ride past to make it difficult for this dog to really threaten me. However, on this day I had been riding into a strong headwind, making it difficult to keep my speed up. Also, I was not feeling well and was pretty much limping home at this point. Well, the dog capitalized on the situation and was all over me. When I saw him, I began to increase my speed and, luckily, decided to reach down for my bottle of dog repellent. By the time he reached me (he has to run across a large unfenced yard), I had my bike in a good gear to maintain my speed and had the dog repellent ready. I sprayed him well on his first attack. But he has never been one to quit early and he began maneuvering behind me left and right. He really seemed intent on getting one of my legs. He was quite cunning and all I could do was spray indiscriminately in his general direction. I was all over the road at this point. I do not know what would have happened if a car had come by. I wound up using most of bottle (whereas I rarely ever use even half after several weeks of riding). Boy, I racked up the stress points that day! Even given this encounter, I've decided to leave the game as is.
Side Note: I decided the danger posed by this dog warranted calling the Madison County Sheriff's office. They asked if I ever stopped to talk to the owner about the situation. Well, I would like to talk to the owner, but given that I think the owner lives in a run-down mobile home with a Confederate rebel flag hung in the window as a curtain, I somehow imagine that I would not be too warmly received. The officer said that he would go out and try to find and talk to the owner. If the officer did go and have a chat with the owner, it apparently had little effect because the dog has chased me several times since. For the record, in case I'm ever brought down and mauled to death by this dog, it usually runs out of the driveway at 5579 Nowhere Road. (I can't say for sure if this is the owner's address, as there are other residences in this area.)
The cars of Nowhere Road
Probably the most noticeable modification to this prototype is the addition of cars to Nowhere Road. Here, too, I had long been struggling on how to represent cars adequately in this game given the 2-D format. My first inclination was to include the car graphics somewhere on the roadway, but I knew this would be problematic because the roadway itself animates. I knew it was also very important to cue the player that a car was approaching either in front or behind. When riding a bike for real, the sound of an approaching car is the first and main cue and I considered embedded such a sound in the game. Instead, I opted for a visual cue -- a picture of a small car appearing at the top left (approaching car) or right (car from behind) of the roadway graphic). Admittedly, I used the American standard of driving on the right side of the road in deciding upon the placement of these graphics, just as the decision to place the biker on the right side of the road was based on this standard (but this could easily be made into a player option later). The main reason for going with a visual cue instead of an aural cue was that I could not find a suitable car sound to use. I also have a variety of other sounds in the game and was worried that another one would be confusing. (Of course, adding yet another visual is subject to the same criticism.) However, I did add a convincing "car passing" sound to accompany the animated car as it flies by the cyclist.
The major advantage of having cars in the game is that it provides an intuitive reason for the player to take steering more seriously. It also provided the context and relevance for choosing to wear reflective or bright clothing and a helmet. As discussed in previous entries, being visible is one of the cardinal rules of bike riding -- if cars can see you, they can also choose to avoid you! Should the unthinkable happen and you are struck by a car, or if a car takes you by surprise and forces you off of the road, whether you are wearing a helmet or not can mean the difference between getting just some cuts and bruises or a life threatening head injury. Of course, I was faced to "play God" in this game and determine just what the conditions and consequences would be for getting hit by a car. In the end, I decided that any player who chooses to wear reflective or bright clothing would never be struck by a car. My reasoning is that every motorist would do whatever was necessary to avoid even the most wayward cyclist. The problem is when a motorist, especially one who is perhaps going a little too fast and/or is distracted by a song on the radio or so involved in a conversation (especially given the rise of cell phones), notices a cyclist with little or no time to make the necessary adjustment to avoid a disaster. My experience, especially on a curvy, narrow road such as Nowhere Road, is that a cyclist needs to be ever vigilant to maintain absolute concentration and steer as close to the right side of the road as possible while being as visible to the motorist as possible due to the decision (made at the start of the ride) to wear appropriate clothing. In this game, you only run the risk of being hit by a car if you are wearing dark clothing.
Of course, errant steering is a cause for concern and therefore a source of stress. In the game, cars that barely miss you honk their horns -- once, twice, or three times, depending on just how close a call it was. Stress points accumulate accordingly. This is an intuitive source of feedback to the player and conveys well the need to do a better job of steering.
To be sure, field testing is necessary here.
Importance of sound
For most of my career I have focused almost exclusively on the role and value of non-textual visual elements in interactive multimedia, such as animation. I practically discounted other features, such as sound. However, in recent years I have come to recognize just how important it is to use all of the available channels to both cue and give feedback to a user if only for the reason that any one channel can quickly become overloaded. I know this is a simple observation that most people take for granted. But, like most of the decisions surrounding design, how to best use the available channels is anything but obvious. In the past few years, I have tried to pay closer attention to how game developers use sound effectively in their designs. One of my favorite examples is a game called Maelstrom by Ambrosia Software (a shareware version can be downloaded from Shareware.com). This is really just a form of the old Asteroids game made famous on Atari systems. This is a real "twitch game", requiring very good and fast eye-hand coordinator. If you take your eye off of the screen for even an instant, you might get blown to smithereens. Luckily, the game conveys much of the feedback via sound. A real clever example concerns one of the obstacles that you have to avoid -- asteroids. Most of the asteroids are made of rock and can be blown apart with your ship's laser canon. But there are also other asteroids made of iron that cannot be destroyed, only nudged. When your laser hits one of these, you hear a simple, yet marvelously clear metallic "ding" that instantly conveys not only that you hit it, but that it is made up of metal. The entire game is filled with little, but ingenious examples such as this. Appropriate use of sound is not an embellishment, but a necessity in highly interactive forms of multimedia.
Here is a list of the all the sounds now embedded in the game: 1) barking dog -- cue that a dog is approaching; 2) yoo hoo! -- cue that the cyclist is now going downhill; 3) panting -- cue that the cyclist is now going uphill; 4) passing car -- this accompanies the car graphic; I added it more for the sense of "location" that it provides; 5) car honk -- cue for poor steering as a car is passing; 1, 2, or 3 honks denotes the magnitude of the poor steering and each honk earns 10 stress points; and 6) a classic Homer "doh!" when the cyclist runs off of the road (I know I'm pushing the boundaries of copyright here, but I just couldn't resist).
I'm quite satisfied with these sounds. They are not only functional, but add a fun element to the game. One more sound that I still want to embed is a dog "yelp" when the cyclist successfully sprays an approaching dog with dog repellent. I just couldn't find an existing example and my feeble attempts to imitate this sound myself were quite pitiful. Actually, I think it's a very important sound because it will denote clearly whether the dog has been repelled.
As I think about this project and as I review earlier journal entries, it's interesting to consider some of the ideas I had early on but, for one reason or another, did not make it into Version 1.0.
Upon finishing the game, I turned attention to revising the web site. I wanted to focus visitors' attention more on the finished game and less on "the making of" the game. Consequently, I overhauled the game's web pages starting with a new entry on the Nowhere Road menu page to reflect a link to the completed game. I am making the final version of the game available in two forms: 1) shocked (just like the prototypes); and 2) downloadable to the user's hard drive. Orienting (educating?) the user to both game forms in a clear and simple way is quite a challenge. I've faced this dilemma for a few years now with my other web sites, so I did not approach the problem uninformed. Still, I'm not sure how well I've succeeded and will rely on feedback from users (especially the confused one) in the weeks and months ahead. I kept the page introducing the game itself (consider this the game's home page) as simple as I could, describing the game's context with an obvious link to begin the game. At the bottom of this page, I duplicated the link to the "making of" section and I also included a link to my Authorware book (recall my unashamed goal from the very beginning of this project to try to sell some books based on this effort). When a user takes the prominent link to the game, they are immediately asked the question "shockwave or download?" I tried to make the navigation on this page as visually intuitive as I could, interspersing some minimal text explaining what the decision was all about. I wanted a design that an experienced user could navigate quickly, but also one that would alert the novice to the importance of the decision coupled with a reasonable explanation of the concept of shocked media vs. downloading the game. I used an elaboration model in that I provided a link to a page giving a much more complete explanation of the "wonderfully confusing world of shockwave plug-ins", poking fun at the confusion in order to make it clear that the fault belongs not with the user, but with the technology. Also, this alerts the user, I hope, to take their time at this point. (I had constructed this shockwave description page at the start of the project and so was able to use it again here.)
Just when I thought I was a hour or so away from being completely done, I hastily began work on a graphic to be used on the game's home page and also on the title page of the downloadable version of the game. To be honest, I figured this graphic would take about 15 minutes to construct. You know, something short and sweet, and then "Miller Time!" But as I began constructing this graphic, I realized just how important this graphic was to the game. In a way, it had to symbolize the content and feel of the game. This graphic was to be a user's "first impression" to the game. However, I found my lack of graphic design skill quite debilitating and I stopped in frustration. I decided to think this through a little bit and waited until the next day to attack the problem again. I decided to use some of the existing photos of Nowhere Road in the design. I was clearly on to something, but I began to stall. Fortunately, I decided to do this work in the EDIT Studio and sought help from some of the students also working in the lab. I got some great, quick advice from Michael Gardner and Michael Grant and I am pleased with the result.
I packaged (Authorware term) two forms of the game, one to be downloaded by the user (with the title screen and background of the game from the game's home page embedded within) and one to be shocked. I performed the necessary "zipping" and "shocking", then I uploaded all these resources to the web site. Finally, I performed some quick tests of the links and to be sure the various media worked. Done at last.
As I end this little design experiment, I realize that many of you may have just stumbled across this site and may have no intention to actually read the rest of my design journal. The principal catalyst for this project was my dissatisfaction during the preparation of an article that I co-wrote with Michael Matzko, entitled Serious Design for Serious Play for a special upcoming issue of Educational Technology. In that article, we were given an instructional problem and were asked to describe our approach for designing a single lesson. There was no expectation to do any development work, just describe our design in hypothetical terms. Although I found this to be a wonderful idea for a journal article and eagerly accepted the invitation, I later found the task unsatisfying because I do not design that way. It also occurred to me how little I have written about my own design efforts, at most just off-handed comments embedded deep within various papers. Finally, "Nowhere Road - The Game" was a project idea that I had been kicking around for some time and presented a nice opportunity to deal interactively with subject matter -- bicycle safety -- that I had never seen dealt with elsewhere. I think this web-based design journal, the game prototypes programmed in Authorware, and the Serious Design for Serious Play article make an interesting collection of design documentation. Looking at any one of these artifacts fails to capture completely how I design, but together they represent well my design beliefs and approach.
As I wrap up this project, let me say that I understand completely if you disagree with the views of Mike and I in the Serious Design for Serious Play article and I also understand if you do not like my design of this little game. Indeed, I hope you feel you have better ideas -- reviewing an existing product followed by brainstorming of ways to improve it is an excellent design activity and one I have often used myself (as I discussed in journal entry 7). However, I hope you will avoid the temptation to disagree with my approach to building this game. It is meant to give a peek inside my thinking. It is not bad or good, it simply is. Frankly, I would like to see more designers keep a journal as they design a project they consider important plus share prototypes as the project evolved. I would especially like some of the individuals who write persuasively in our field about design to complete a similar design experiment. There is something quite revealing in looking at the product of one person's efforts over time. IT faculty are well-known for giving their critiques of student projects, but it is astonishing rare to have the chance to critique a faculty member's efforts within the same design parameters, especially a project in which the individual is both designer and developer. It shows their design strengths and weaknesses in light of their development skills. For example, I'm sure it is clear from my game that I do not have a gift for graphic design and my programming skills are limited. For example, just when I think I know something about Authorware, I look at the state-of-the-art in video games to remind myself of how much further I could go and to also remind myself that design efforts of that magnitude must be a team, not an individual, endeavor. Of course, one must remember that I completed this project without a budget or resources beyond the university computer hardware and software and, of course, my own time. A large budget would have been great and I think a serious development effort would result in a superb Nowhere Road game. But, in the end, "the play's the thing" -- it is the quality of the idea that really counts.
Speaking of time, I have been asked by my students how long I actually spent working on the project. Early on, I tried to track my "computer design time" carefully, but interestingly it became very difficult to log this well. I gauge that I invested between 50-60 hours into the actual programming of the game. Much additional time was spent just thinking about it, talking to people about the game and the issues it raised, and watching them play the game.
One of the main themes that I hope has come through loud and clear is the role and value of prototyping as a design methodology. During the summer of 1999, there was an interesting, impromptu discussion on ITFORUM trying to get at relationship between instructional design and programming. I hope this project shows how some, like me, can't separate the two, much like for me how the act of writing and use of a word processor are interdependent. Authorware is both a design and development tool for me and I generated almost no other design documents beyond the prototypes. This is not to say that everyone should do it this way. I always use the advice "to thine own self be true" when it comes to design. The right way is the one that works. One has to be comfortable and feel totally in control of the design process. Most important, prototyping allowed me to get user input early and often. To be honest, I do not feel I ever reached my own benchmark of getting user input to the point that I could consider the "user as a co-designer". This is probably because the project remained informal throughout its development. I would have needed to have formed a close working relationship with at least a small set of users. Nonetheless, I hope it shows what I value and what I strive for.
I have learned much about many things in the course of this project -- not only about my design philosophy, techniques, and limitations, but also about my beliefs about bicycle safety, the responsibility in owning pets (especially dogs), and the great feeling of being part of a community, especially one as eccentric as Nowhere Road. So, I end this design journal with a sense of satisfaction that even if no one cares to read my entries or review the prototypes I have saved and shared, I have completed a very interesting and (mostly) enjoyable design exercise. I have grown as a result of having done it and that alone justifies the attempt. I hope my effort convinces others that it, too, is worth the effort of trying.
Hmm, maybe I'll make just one more little change to the game........