@DATABASE AmigaMail
@NODE MAIN "XII-1: CDTV Application Guidelines"
@TOC "Table_of_Contents/XII"
Staff


A CDTV application is not simply an Amiga application running in a
different box.  The CDTV player imposes certain restrictions on an
application--no menus and large icons, for example, and provides
certain benefits--large storage capacity and digital audio.  The wise
CDTV developer respects the former and takes advantage of the latter.

The list below gives you, the developer, a quick reference to the do's
and don'ts of CDTV applications. It contains rules and common sense
advice. They are broken into two groups, minimum requirements and
quality standards.

Minimum Requirements - The minimum necessary to be an acceptable CDTV
application.

Quality Standards - To get into people's homes, you need to do more
than the minimum.  These will help you make the trip.

@{" Level 1 Minimum Requirements " link XII-1-1}
@{" Reference Titles " link XII-1-2}
@{" Recreation Titles " link XII-1-3}
@{" Level 2 Quality: The Next Standard " link XII-1-4}

@ENDNODE

@NODE XII-1-1 "Level 1 Minimum Requirements"
1. No program crashes.  The application should not crash, guru or
  otherwise cease to be functional.  Test, retest and test again till you
  are sure your application is robust.

2. No logic or flow errors.  The application cannot take a path other
  than the one requested or expected by the user.  For example, if the
  user asks for a map, but instead gets a picture of a tree, a logic or
  flow error has occurred.

3. All images presented should be free of error and look clean.  For
  example, a title should not have a garbled picture or a video sequence
  that exhibits solarization, i.e., a color picture that looks like a
  negative.

4. No low quality images.  All still images should be high quality,
  preferably digitized interlaced HAM images.  Drawings or animations
  should be detailed and free of major color banding.  All still images
  should be overscanned unless a conscious effort is made to provide a
  colored border.

5. User interface.  The program should follow generally accepted CDTV
  interface rules including:

      A button for action, B button for backup, arrow keys move in
      direction of arrow.

      Single click to select an object.

      Use highlighted hitboxes rather than a pointer where possible.

      Highlighted hitboxes should be accessible by cursor keys in any
      direction.

      If a pointer is used for products with invisible hot boxes or for
      special purposes such as coloring, the pointer should change when
      it is over an invisible hot box and be in a form relevant to the
      application (paint brush, wand, etc.).

      Numbered items should allow use of the numeric keypad on the
      controller.

      Selectable items should stand out (e.g., 3D buttons) from
      non-selectable items, and they should give audio/visual feedback
      when selected.

      Selectable items should give appropriate, consistent, and
      predictable results.

      There should be no references to a computer keyboard (e.g., F1 key).

6. The application should look good on any television.  This means you
  should buy a cheap television for testing.

7. There should be no signs of AmigaDOS.  Examples include the AmigaDOS
  cursor, Workbench screen, system requesters, sleep icon, pull down
  menus, flashing title bar, front/back gadgets, or jargon (x memory
  free, loading next module, etc.).

8. Efforts must be made to reduce perceived boot-up time.  The
  titlescreen should appear within five seconds of the appearance of the
  CDTV Interactive Multimedia logo.  (See Discis' products) The program
  should show a title screen before doing anything else.  It should not
  show CLI, Workbench, or any pointer.

9. It must have a screen blanker tied to preferences.  We recommend the
  screen blanker supplied as part of the OS.

10. Applications must work under AmigaDOS 1.3 and 2.0 in both NTSC and
  PAL. Programs should be able to successfully pass enforcer and mungwall
  testing.

11. The program must be designed for use on a PAL or NTSC TV, which
  means care must be taken in regard to all graphic elements (fonts,
  symbols, pictures, animations, video) with respect to size, style,
  color combinations, and contrast.  Test your applications on those two
  environments, not just with a monitor and one of the two standards.
  Specific suggestions include:

      Fonts should be simple with no thin lines, anti-aliased, easy to
      read on a television and at least 20 point size.

      Text should generally be highly contrasted to its background.

      Text should have borders or drop shadows to make it more readable.

      Don't use pure colors (R, G, B values should be less than or equal
      to 13 out of a range of 0--15) because they bleed on television
      sets.

      Be careful of the colors used as some colors show up very
      differently on NTSC versus PAL.  For example, deep red in NTSC
      comes out pale pink in PAL.  The only way to find this out is to
      test on both systems.

      Avoid stark contrasts when using thin horizontal lines since this
      will not look good in an interlaced medium (TV), and avoid single
      pixel horizontal lines entirely.

      Do not base instructions solely on color, i.e., don't state ``Pick
      the orange button'' since TV sets will be adjusted differently.
      This could also be a problem for colorblind users.

      There should be no more than nine selectable (by cursor or by
      pointer) items on a screen unless the individual items are
      recognizable because they are part of a set (i.e., alphabet,
      numbers, states). Nine items fit well with the font size required
      for television.

12. Products must not substitute repetitiveness for depth by reusing
  the same elements in different places.  If a product is perceptually
  redundant, it is boring.  For example, using a passage from Beethoven's
  Piano Concerto No. 5 as an example of his music, and as an example of
  how a piano sounds, and as an example of a piano concerto is a lack of
  depth.

13. Eliminate all spelling and grammatical errors; people will not want
  to use a product, especially an education product, if they cannot trust
  something elementary like its spelling. Run your text through a spell
  checker and a grammar checker. Some of these titles are available in UK
  English or American English only, and these are acceptable, at least
  for the initial shipment.

14. Programs should reboot when the disc is removed unless the program
  disc needs to be removed for the product to be usable (CD-Remix).  The
  program should reboot when the eject button is pushed, and the reboot
  should occur even if the disk is being accessed or Amiga audio is
  playing.

15. Sound quality should match the application requirement. Use Amiga
  sounds for audio feedback; CD-DA for game background, dramatic intro
  music and other sections designed to evoke an emotional response. All
  sounds should be clear and free from hiss or other extraneous problems.
  Speech must be ungarbled and unclipped and digitized at a reasonable
  level or be CD-DA.

16. Volume levels of speech, music, and sound effects should be uniform
  throughout the product.  All audio must come through both channels
  unless there is a compelling reason to do otherwise.  Note that
  compelling does not mean being unwilling to take the time to code so
  that the sound comes through both channels nor does it mean that your
  authoring system only works with one channel.  Compelling does mean
  trying to add depth to the sound by having one person come through the
  right channel and another through the left channel.

17. Interruptability.  All titles need to be interruptable at any time,
  including title and credit screens, introduction, during accesses, or
  animations.

18. Products must use preferences for language selections.  Unless the
  language chosen in preferences is unavailable, the user should not
  normally see language selection screens.

19. All programs that can save to a floppy must be able to format a
  disk.

20. All programs should test for joystick/mouse mode.  If the
  controller is not in the proper mode, it should ask the user to change
  modes.

21. Programs should disable keys that are not functional in the
  product. Typically this means disabling the audio keys for CD control.

22. Controller responsiveness.  The product should not queue up button
  presses, it should react and give feedback immediately, and any cursor
  or highlight should move quickly enough for that specific application.
  In many cases, if a pointer is used it should include an accelerator
  feature.  If a user feels compelled to repeat an operation because
  there is no response, the application is at fault.

23. The products should not have any dead time, i.e., time when nothing
  is occurring.  Accesses should first give audio and visual feedback
  that a selection has been made, then have a transition of some sort,
  then begin the load during the transition. The transition interlude can
  consist of music, color cycling, a voice over, a fade to a colored
  screen, or in some way distract the user.  A sleep or load symbol is
  generally insufficient to improve the perception.

24. Test that your product works properly with a trackball and a mouse.

25. They should also not be adversely affected by the presence of video
  peripherals such as genlocks.

@ENDNODE

@NODE XII-1-2 "Reference Titles"
The reason someone purchases or uses a reference title is for the
information contained within.  A reference application should not have
any of the following:

26. Inaccurate reference data.  Imagine you're a student doing a
  homework assignment, using the CDTV title as a reference work. Your
  teacher gives you an ``F'' because your facts are wrong.

27. Missing information.  If a menu, icon or other reference indicates
  that information relating to the subject matter is available, the
  information should be accessible from that point.  In other words, if
  something is selectable, it must present the data associated with it.

28. An inability to accept keyboard input, print, or save to disk even
  though most people will not be able to take advantage of these features
  at the moment.

@ENDNODE

@NODE XII-1-3 "Recreation Titles"
29. A title must be playable to completion.  No user or program error
  should prohibit the game from continuing. If you make a stupid move and
  get eaten by a dragon and the game ends, you have played to completion.
  If you make an incorrect move and the game freezes up or prohibits the
  continuation of play, it is a not move that shouldn't have been made,
  it is a bug.

30. A multiple player option should be in every recreational product.
  Where it makes sense (certain sports and arcade games), two-player
  simultaneous play is a requirement (e.g., hockey and football).

31. Simulations must attempt to match the real world in as much detail
  as possible, including the standard rules of play in sports games.

@ENDNODE

@NODE XII-1-4 "Level 2 Quality:  The Next Standard"
In addition to the requirements of the Level One, products need to be
compelling enough to compete successfully in the marketplace.

32. All titles must have an important and distinguishing value over
  doing the product on magnetic media, or by book, or by cassette.
  Products should have greater detail, more choices, more ``sizzle'', be
  easier to use, or be faster to perform a function.  Ports from another
  platform--including the Amiga--must be enhanced (music, speech,
  additional video, more choices, etc.).  An example of an excellent port
  is SimCity which added digital audio and rewrote the user interface to
  take advantage of the numeric keypad on the IR controller.

33. Timely response is important.

    On a multitasking operating system, the time that elapses from when
    a selection is made till the activity begins  should be no more
    than three seconds.  This is part perception (i.e., start showing a
    graphic change while still loading), part disk organization (to
    speed access times), and part programming (sometimes things can be
    cached or optimized).  (Asterix appears to have achieved this goal,
    so it is therefore possible.)  To reiterate, first audio/visual
    feedback, then some type of transition interlude which lasts no
    longer than three seconds, then the desired result.

    For very long searches that cannot be done in a short period of
    time, inform the user of the progress of the search.  Options
    include putting up a screen and start listing ``hits'' or showing a
    ``gas gauge'' depicting the progress of a search.

34. Multimedia elements should be comparable to video or cartoons
  viewed on TV.  These elements (animations, speech, music, sounds,
  video) should be streamed from disk so that they can be more in-depth
  and longer in duration.  The animations should normally be 3
  dimensional and change focus (i.e., background, perspective), not
  limited to a static background screen.

35. Educational titles and adventure type recreational products need to
  have a depth of interactivity options.  For instance, if a character is
  walking down a street, the user should be able to go down alleyways,
  into buildings, etc. Each screen or in each section should have
  more than one (and more than two!) things that can be done. These
  options should include non-linear choices, i.e., being able to jump
  around. Linear choices are really no choices at all because you must
  follow a prescribed path.

36. Educational titles should have some type of testing function to
  allow you to examine your progress in a section.  The Bookmark feature
  should be used if appropriate (e.g., game scores, place in a book,
  tests, etc.).

37. Reference titles should allow numbers and spaces to be input for
  searches. All reference titles should support searches on keywords in
  body or title, and not be just an alphabetized index of options
  (similar to the index of a book). They should also have the Bookmark
  feature using Non-Volatile RAM (NVR) to save search criteria and
  possibly the resultant elements.

38. Recreational titles should use continuous streamed animations and
  CD audio for background.  They should be able to save game states and
  high scores using NVR.

39. Possible suggestions:

Online help

    Templates to fit on top of the IR controller to simplify the
    buttons for complex products (i.e., flight simulator).

    Optionally viewable demo commercials of other products.

    Hardware add-ons (a la Nintendo).

    Supply a formatted disk (or at least a disk label) if the product
    can use a floppy.

@ENDNODE