The right consistency


In part 5 of this series, Xav looks at user interface design, and throws down a multi-player gauntlet...


[Screenshot]


Over the past three issues we've examined the Jaguar joypad on both a hardware and software level. I've explained how they work, how to read from them, along with a couple of tricks to make life a little easier. The one area we haven't covered is consistency.

We are all used to a consistent user interface in GEM, but it also pays to think about the consistency exhibited by your own programs. Most programs using joypads will be games, for which consistency tends not to be considered too much, but a little attention to detail can make life far easier for the player - and make them more likely to return to your game again and again.

A quick look around the STe and Falcon games that already use joypads reveals very little consistency. Almost all Jaguar games, on the other hand, conform to a small selection of simple rules which are equally valid for other games using the joypads. These are as follows:

  • The main fire button should be button B. The reason is simple: from B it is easy to move to A or C in order to trigger other events. If your program only needs one fire button, then let the user press any of them; if more, then it's far nicer to allow them to select which buttons are assigned to which functions from an options screen.
  • The Pause button should pause the game, if this is an option. Ideally this should display a message to that effect, though many Jaguar games allow you to remove the message (whilst leaving the game paused) by pressing 1 and 3 simultaneously. Pressing Pause a second time should un-pause the game - it's surprising how many programs ignore that one.
  • If there's music in the game, and if the music can be turned off, 0 on the numeric keypad should toggle this option. The volume of music and/or sound effects, if configurable, should be set from an options screen, usually accessed by pressing the Option button.
  • For those few games which use the Option button as part of the game logic, the options screen should be made available if the user presses Option whilst the game is paused.
  • Pressing * and # simultaneously should reset the game - i.e. "end the current game", but not "quit the program". This should take place before testing for 0 to toggle the music, as at least one of the forthcoming projects scrimps on hardware by making it look like all three buttons are being pressed in order to trigger a reset.
  • If the logic of your game would benefit from Procontroller support, then add it as an option. The extra decoding is minimal, and your users will appreciate you for it.

Teaming with players

Some of you may have noticed a certain amount of redundancy in the joypad design. We test four banks of switches by using four data lines, but isn't that a bit wasteful, when two binary lines could be easily decoded into the four we require? In fact, from four lines we could decode up to sixteen banks of switches.

Which is exactly what Atari's "Team Tap" does. By fully decoding the four lines, it allows up to four joypads to be read from each EJP. All that happens is that previously "undefined" masks, such as 0xFFF8, now relate to a specific bank of switches (port A, tap C, group 4 in this case). Using a pair of Taps, therefore, it's possible to read up to eight joypads between the two EJPs. Now, does anyone want to write a Falcon version of Gauntlet?

The Team Tap was supplied "free" with the Jaguar game "White Men Can't Jump" and was also supposed to be available separately. I've never seen it sold as a standalone device, though, so in the next issue we'll look at how they actually work, so that you can build your own. If you find anywhere selling them with the bundled game for less than twenty pounds or so, however, I would recommend buying one - even if you don't have a Jaguar - as the parts themselves cost about half that, and that's without a nice box to put it in.

One of the great things about the Team Tap design is that the joypad which is plugged into the first connector behaves in almost the same way as one plugged directly into the machine. Certainly, if all four groups of switches are read separately, there is no difference - so the Tap can be left permanently plugged in. The only problem arises when trying to read more than one group at a time (see last issue), so you should avoid this trick in your programs unless you're sure that the user doesn't have a Team Tap.

Next issue...

We'll start looking at the Team Tap hardware and how it works - eventually aiming for a design that you can build at home. If you've got any plans for multi-player games, now is the time to start dusting them off.

[Home] [Info] [Back] [Next]