22
The Internet
The Internet is the true universal distribution platform of our time. Using it, we can deliver our simulation to any user anywhere, without worrying about whether the user has the right disk, the right hardware, the right operating system, or whether the user can connect to an intranet, extranet, or area network. As long as the user has an Internet-enabled connection, we can reach him or her. While that used to mean the user needed a desktop PC or Mac, we can now count on reaching any user with access to a notebook computer, a handheld PC, a cellphone, an Xbox 360, a Windows MediaCenter, or an Internet Protocol television set.
However, the type of content that can be delivered may be constrained by the speed of Internet delivery, dependent on the available bandwidth a user may have access to. A brief overview of which media is most appropriate for each type of connection is presentedbelow.
DIAL-UP
Text e-mails, very light instant messaging, and very small office application files (short documents and spreadsheets, possibly some thumbnail graphics, but no PowerPoint slideshows, PDF files, partial or full-screen JPEGs, audio, or video) are the only media that will facilitate a useful simulation in this environment. Nothing is less immersive than waiting . . . and waiting . . . for downloads. A user is unlikely to consider, absorb, and put into play pedagogical content that frustrates just in its delivery.
Does dial-up bandwidth doom any sort of simulation? Not necessarily. We can imagine a story-driven simulation that works almost purely via e-mails and instant messaging; think of this as the 21st-century equivalent of the epistolary novel of long ago. The simulation must work as an asynchronous experience; perhaps a management, personnel, or other business communication simulation that replicates a communications situation handled strictly by e-mail, between a home office and remote office. Highly dramatic writing with appropriate cliff-hanger endings to each interaction can, in fact, make this a truly compelling experience.
BEYOND DIAL-UP, BUT NOT QUITE DSL
As a sidecar or alternate to Internet dial-up delivery, we should not discount cellphones and PDAs as completely valid receivers of content. As will be discussed in Chapter 23, these handheld devices are both ubiquitous and intimate, making them very logical platforms for certain kinds of media and content.
For example, cellular text messaging may be a useful adjunct or even a primary medium for asynchronous content. Multimedia messaging is now widely available, allowing for small graphics to also be used. Webpages customized for handheld PC and cellphone browsers, using text, still and animated graphics, and even small Flash movies, can carry content. GPRS-connected phones already provide dial-up speed, and newer l×RTT-connected and EvDO-connected cellphones begin to approach low-end DSL speeds. These higher-speed networks are rapidly being deployed by carriers like Verizon and Sprint, and by 2007–2008, near-DSL speeds will be quite common with cellphones.
Bandwidth is not the only factor in Internet delivery, however. We also need to look at screen size and ease-of-input. Though cellphones and PDAs can now handle standard e-mail content, lightweight application files, small audio files, and Websurfing, the relative awkwardness of both input and output, as they relate to the delivery of an immersive simulation, should be weighed. Left-right-up-down navigation will work pretty well; alphanumeric input of any duration won’t. Outputting small graphics and simple animations will be tolerable; out-putting lengthy, stuttering postage-stamp sized video isn’t. Bottom line: just because we can use this platform doesn’t mean we should. Again, a frustrated user will gain little from such a simulation. On the other hand, delivering dramatic text-based interactivity as described in our discussion of dial up Internet content could be extremely engaging when presented on cell phones and PDAs.
DSL AND CABLE
We can now expand our list of media to include complex HTML e-mail, Web content (HTML and Active Server pages, Web application, Flash animations, etc.), PDFs, PowerPoint presentations, JPEG and TIFF graphics, and streaming audio.
Streaming video is deliverable but not wholly reliable, and its value must be weighed against its relatively degraded nature. In general, we can usually only sustain a 320 × 240 video window without beginning to incur substantial frame dropout, and even at this size, pixelation and frame lag are common problems. At this bandwidth, video is best served at a stepped-down rate of 15 frames per second (television delivers just under 30 frames per second), making it a less than optimum experience.
True, real-time, CG 3D can’t hope to be delivered at this bandwidth. Nor can the rich graphical environments one might see in a popular massively multiplayer online game like an Everquest or a Worlds of Warcraft.
But, but . . . I’ve seen them!, you say.
Reality check: while it’s true that a Doom or an Everquest are played via the Internet, the reality is that the bulk of the graphical environment is available via CD-ROM or separately downloaded files made resident on a user’s local hard drive. For example, Kuma Wars (http://www.kumawars.com), a real-time, 3D ground combat game played wholly online, nevertheless must first deposit its engine, terrains, texture maps, characters, and other graphical elements in a separate and lengthy download (in fact, it is using the Half-Life game engine). And, as of this writing, this game distributor may well offer the state-of-the-art in this particular game niche.
Internet downloads and local installations invariably create user support issues. We have to deal with firewalls, administrator permissions, pop-up and spam blockers, anti-virus shields, operating systems, and compatibility issues. So we must begin to consider the cost of this kind of media delivery via the Internet, as opposed to CD-ROM or DVD-ROM distribution.
Often, corporate and institutional networks block any kind of saved file download or file installation onto a local hard drive, thus completely preventing this sort of hybrid solution to delivering rich graphical content. This becomes yet another factor to consider.
Assuming we can park our rich graphical content on a user’s local drive, interactive real-time 3D over the Internet still offers challenges. If very quick actions and reactions are required, the user may encounter data transmission latency issues. The user responds in a timely way in the simulation environment, but data latency, spread across the system, slows down the response.
In first-person-shooter games, this means that a user can fire a weapon at an enemy with deadly aim and timing, only to discover that the bullet or flame (which, by the rules of the game’s physics, should have struck the enemy), slowed down by Internet traffic, didn’t arrive when it should. Or, the enemy fired upon may have already moved on; although on the user’s system, he was still in location X (rather than Y).
While most simulations may not require this kind of split-second timing, the problem could become an issue and must be taken into account when considering delivery options.
Another type of 3D environment, the blockier X3D (the modern version of VRML) environment sometimes used in real estate walkthroughs and architectural renderings, can be delivered more effectively at this bandwidth; and for simulations not requiring exacting verisimilitude, may be a highly desirable environment (one emphasizing spatial relationships or basic activities, for example, a simulation training bank tellers).
If we’re willing to incorporate more cartoony, 2D environments, one markup language to explore is TVML (see http://www.nhk.or.jp/strl/tvml/ english/mini/index.html). This new language and player literally allows you to write a telescript indicating dialogue, camera movements, and character behavior, and have it converted to an animated movie, using predefined CG characters, sets, and props. Think of it as Flintstones anime machinama. Although the animations won’t allow for interactivity, this media type may be appropriate for certain projects, due to its low bandwidth demands.
In general, streaming audio becomes pretty reliable at this bandwidth, and as Chapter Twenty-Five will describe, a great deal can be achieved through the use of audio in simulations. We can imagine political and economic simulations being served very well in this environment, for example, a game that simulates some aspect of financial market trading, or data mining in a global surveillance/anti-terrorist operation.
T1/T3
Assuming the T1 connection is not shared by more than a couple of users, streaming video should now become wholly reliable and robust. True, real-time 3D CG becomes closer to a reality (especially so on the T3 line, which is more than 50 times faster than a typical DSL connection). With this kind of bandwidth, nearly all of our content constraints have evaporated. But how many users can be reached on virtually unshared T1 or T3 connections? This is a small user base indeed, and if you’re creating a simulation for this club, consider yourself lucky.
One caveat is that our concerns regarding file downloads and file installations remain, so we are restricted to maintaining a live Internet connection, and transactions outside of a connected session can’t be counted on (our data payload may never have been launched). For some simulations, this could be an issue.
INTERNET2
Often mistakenly considered as the next-generation Internet, Internet2 is actually a private Internet-like network, created by a consortium of universities along with corporate and government partners. Built on a much higher-speed backbone than the Internet itself, we might consider Internet2 as the ultimate wide-area network. Simulations have, of course, been developed for this network, and its ultra high-speed bandwidth solves most of the problems discussed in this chapter.
SECURITY ON THE INTERNET
For some projects of a sensitive, confidential, or government-classified nature, secure delivery of content and media over the Internet is going to be a major factor in determining whether the Internet is the appropriate delivery platform. Though our content will probably fail the Karl Rove “double super secret background” test, and although concerns about Internet security can sometimes escalate to the level of conspiratorial paranoia, the fact is that all Internet data runs some risk of being monitored and captured.
It is all but impossible to secure user client platforms, particularly if users have the option of accessing the simulation from multiple access points (headquarters, remote offices, home, hotels, etc.). Users accessing the simulation via WiFi pose an even greater security threat, as WiFi is notoriously porous when it comes to data snooping (the same goes with any content delivered via cellphone).
Even if the simulation is conducted and available solely on IT-monitored, in-house workstations behind a firewall, Internet security studies have shown a high prevalence of corporate systems being breached. Not only can simulation content, uploads, downloads, and keystroke activity be captured, but the simulation—if delivered via the Internet—may open the door to other Trojan Horse activity.
These security risks need to be weighed against the advantages and flexibility that Internet delivery promises. One approach may be the establishment and use of an SVPN (secured virtual private network), which uses cryptographic protocols and enhanced authentication to better protect sensitive data. While the SVPN diminishes the chances for data snooping, it doesn’t perfectly guarantee confidentiality.
Obviously, the more restrictions a simulation places on access (e.g., excluding offsite and WiFi access), the greater the security protection. But does this begin to deflect the prime value of Internet delivery? Every simulation is different, and so the answer is neither clear cut nor obvious. But if Internet delivery appears attractive, then the importance of secure delivery of content should be weighed, and strategies toward achieving it should be considered.
AUTHORING FOR THE WEB: SYSTEM DIFFERENCES ND SCALABILITY
One of the primary attractions of Internet delivery is that it appears to bypass issues of the user client platform (e.g., Mac? PC? Linux? Solaris?, etc.) and client software. However, this is not entirely true.
For example: font differences in application documents (Word, Excel, PowerPoint, etc.), as rendered by different operating systems, pose the risk of confusing users. Bullet points become question marks, quotation marks become alphabetic characters with umlauts, etc.—at best, the mistranslations of these characters is merely annoying, and at worst, may render useless the pedagogical or procedural content.
This may argue for delivery of any transmitted document in the simulation to be standardized on Adobe’s Portable Document Format (PDF), which will render identical content (both onscreen and in print) on all platforms.
This doesn’t solve the mistranslations that occur in HTML e-mail or in the differences of webpages being rendered by Internet Explorer, Firefox, or Safari, which can be substantial enough to misplace content, bungle page layout, and in general, frustrate and confuse users.
Another issue is the residency of software on a user system: Is the Flash Player, the Acrobat Reader, the QuickTime plug-in, or other software available when called? Can the simulation route the user to the appropriate download site if the software is missing? Does the user have permission to download the necessary software, and how are exceptions handled?
Required additional user hardware is yet another problem. Will the simulation require user printouts or user scanning or a digital camera (so users can upload photos)? Will a Bluetooth or WiFi connection be needed (so a user can connect with other systems or other users)? Will a very large desktop monitor be necessary, or can users get by with a laptop screen or even a handheld screen (PDA, cellphone, etc.)?
Clearly, in designing and authoring story-driven content, we’ll need to factor in how much our simulation can scale to the client system. We may have a rapid WiFi/WiMax connection (giving us the greenlight on streaming video, streaming audio, full screen and larger graphics, etc.), but if the client system is a handheld device, all of these media elements may be wasted, or, at least, too seriously degraded to propel our pedagogical content. If delivery is meant for handhelds, we may want to author for lower bandwidth media, emphasizing emails, smaller graphics, small document files, etc. A vast terrain map or long-running video will be less effective on a small screen.
As we’ve seen, bandwidth and security are not the only issues to consider when choosing the Internet as a primary delivery platform. As always, proof of concept, and substantial testing of the project as it’s built, will help to avoid many of the pitfalls mentioned above.
WEB ANALYTICS (BACK-END DATA COLLECTING)
Set up properly, Internet distribution makes possible a wealth of user data to harvest, via logfile analysis, page tagging, network traffic sniffing, and various hybrid methods. Web log analysis software such as AWStats and Click Tracks can coax hidden behavioral patterns out of seemingly unrelated data sets; and whether you use a commercial or open source package, or whether your organization assembles its own proprietary logfile analyzer, the analysis of user activity and input is an absolute must.
JavaScript webpage tagging can deepen and refine the data collected, and may only run into problems if delivery is occurring on browsers where JavaScript is disabled or nonfunctional (most likely on cellphones, though some organizations have crippled browser JavaScript for security and IT support reasons), or if Internet distribution is completely bypassing the browser.
Web analytics has become one of the most important and complex tasks involved with Internet distribution, and planning for this task should commence early in the development of an Internet-distributed simulation.
MAINTENANCE
Internet-distributed simulations require ongoing maintenance: everything from servers to routers, from data transmissions to data collections, along with the inevitable security concerns. Where we can more or less walk away from a simulation delivered from a local disk or a local area network, with little concern for system maintenance, the Internet distributed simulation will require ongoing monitoring. Without planning and budgeting for this, our simulation may quickly founder upon the rocks, shipwrecked.
A BRIEF CASE STUDY—LEADERS
Leaders suggests another way to use Internet distribution for simulations. In this project, Internet delivery was an interim development stage. To test decision points, and more importantly, to gather data that would help develop the natural language interface, a “choose your own adventure” version of Leaders was developed, using simple HTML to outline the setups, scenes, and interactivity for a user. (See Chapter Four for more detailed discussion of this phase of Leaders.)
Due to the low-bandwidth nature of this interim version, client platforms were of practically no concern. Data collection, all keyboard input, was relatively simple. And the online version had to be maintained for only a few days.
In this case, the media and gameplay were all appropriate for the distribution platform. When these pieces all fit together, the odds for a successful simulation greatly increase.
SUMMARY
The Internet is a highly tempting delivery platform, due to its ubiquity. However, available bandwidth will constrain media selection and content delivery, and the uncertainties about user bandwidth, privileges, software and hardware, along with Internet security, data harvesting, and ongoing maintenance—all need to be taken into account before a decision is made about the desirability of Internet delivery.