Intybasic use of the controller?

[CrazyBoss]

Hi,the intellivision controller seems to be quite complicated.

REM DISC - Compass.
REM -------------------------------------------------------------------------
REM   NW         N         NE
REM     \   NNW  |  NNE   /
REM       \      |      /
REM         \    |    /
REM    WNW    \  |  /    ENE
REM             \|/
REM  W ----------+---------- E
REM             /|\ 
REM    WSW    /  |  \    ESE
REM         /    |    \
REM       /      |      \
REM     /   SSW  |  SSE   \
REM   SW         S         SE
REM -------------------------------------------------------------------------

maybe for an arcade game its a bit narrow only to move if the player hit N,S,W or E.

 

Should it be move up, if N,NNW or NNE ? so read the direction and the nearby directions order to move.

 

eg for moving south is it coded like this?

if cont1=DISC_SOUTH_SOUTH_EAST or cont1=DISC_SOUTH or cont1=DISC_SOUTH_SOUTH_WEST then REM MOVE DOWN

[+DZ-Jay]

Aha! The old "convert 16-way into 4-way" problem. The way I solved this in Christmas Carol was a bit of technical ingenuity and a bit of esoteric magic. Well, perhaps not real magic, but human-nature inspired real-world heuristics.

 

First, we divide the 16 directions into zones. This gives the player's thumb enough range to press in a particular cardinal direction and for our program to accurately detect his intent.

            F   0   1
       E     N..N..N     2
         x  ';:::::;'  x         Legend:
    D        ';:::;'        3    -------------
       W:,     ':'     ,:E       N: North    ^
       ::::-_   v   _:::::       E: East     >
   C  W::::::"> + <"::::::E  4   S: South    v
       :::::-'  ^  '-:::::       W: West     <
       W:-"    ,:,    "-:E       x: Invalid
    B        .;:::;.        5
         x  ,:::::::,  x
       A     S''S''S     6
            9   8   7

As you can see, this leaves four "dead-zones" on the "perfect diagonals." We need this in order to distinguish adjacent directions unambiguously and accurately. We could leave them "dead" and ignore them (and in fact, some games do precisely this), but this perhaps may have an impact on playability: the player may occasionally and inadvertently press a diagonal when aiming to one of the four pre-defined zones, and when he misses, the game won't react as he expected.

 

This puts the onus of accuracy on the player, and with an input surface with no markings and no accuracy affordances like the Intellivision hand-controller disc, this is not a nice thing to do to him. You are essentially telling the player "look at the disc and make sure you press in the exact spots that I recognize, or else you're out of luck." That's no good.

 

Alternatively, we could assign the diagonals to any of the defined zones, but it would be absolutely arbitrary precisely because they are equidistant from two zones at a time. For instance, input #2 (NE), if detected tells us little about which side the player intended to go -- it could be equally applied to North or East.

 

This is where the heuristics magic comes in. We take a step back and use our experience and understanding in human nature, and specifically, of Intellivision usage, and see if it gives us anything.

 

The approach I took was this: In my experience, the Intellivision hand-controller disc is not pressed like a joystick, but actually used like a "D-Pad," in which the player rest his thumb and rolls it around in order to change directions. Moreover, knowing that the game accepts movements only in the four main cardinal directions, the player will always aim to press at those points as precisely as he can. I then used this notion to my advantage and assume that if a perfect-diagonal is detected, it was not done on purpose, but it is the natural side-effect of the player rolling his thumb from one cardinal point to the other, and so it is merely transient input.

 

We could ignore this transient input, but then we fall again in putting the onus of accuracy on the player, something we were trying to avoid. I instead opted to use this knowledge as the basic rules to decode those pesky perfect-diagonals. Essentially, it works like this:

• We keep track of the player's last known decoded direction
• We read the new input
• If it falls in one of our pre-defined zones, we decoded as such and we're done.
• If it falls in one of the four perfect-diagonals, we try to discern the player's intent by assuming that he was on his way to another zone and we just caught him in the middle:
  • If his last known direction was North
    • If we just read NE, then he is rolling his thumb towards East.
    • If we just read NW, then he is rolling his thumb towards West.
  • If his last known direction was East
    • If we just read NE, then he is rolling his thumb towards North.
    • If we just read SE, then he is rolling his thumb towards South.
  • If his last known direction was South
    • If we just read SE, then he is rolling his thumb towards East.
    • If we just read SW, then he is rolling his thumb towards West.
  • If his last known direction was West
    • If we just read SW, then he is rolling his thumb towards South.
    • If we just read NW, then he is rolling his thumb towards North.

Ta-da... Magic!

 

You'd be surprised at how delightfully accurate this feels in practice. It is not perfect, for sure, and it assumes a particular way of using the disc controller, but it covers most of the cases fairly accurately without getting in the player's way.

 

-dZ.

Edited March 25, 2017 by DZ-Jay

[decle]

You'd be surprised at how delightfully accurate this feels in practice. It is not perfect, for sure, and it assumes a particular way of using the disc controller, but it covers most of the cases fairly accurately without getting in the player's way.

 

-dZ.

 

 

Interesting, when you hit a diagonal and it is not part of a rolling pattern what do you do (e.g. NE following a previous input of S), keep going with the previous input (South in this case) or stop and wait for an unambiguous input? Sorry, I've not played Christmas Carol.

 

And when you are rolling your thumb round, you can tell the difference between the heuristic and the simpler strategy of just continuing with the previous direction for the dead zone? Obviously the effect is to make the controls marginally more responsive, but I would not have predicted it would be noticeable in play. It is very interesting that it is.

 

decle

[+DZ-Jay]

Interesting, when you hit a diagonal and it is not part of a rolling pattern what do you do (e.g. NE following a previous input of S), keep going with the previous input (South in this case) or stop and wait for an unambiguous input? Sorry, I've not played Christmas Carol.

 

If a combination of previous input and diagonal is not recognized, it is ignored, so the movement continues as it was, and the previous input remains the last valid input.

 

Just to be sure, the intention is not to prevent user abuse or misuse, but to try to discern user intent when playing the game. I cannot think of a valid reason why a user would switch from S to NE and mean to go NE -- except if he actually meant to go E or N and missed. In such a case, I would expect that the lack of response would trigger a slight adjustment from the player.

 

The ultimate goal is to minimize these adjustments from the player by offering an intuitive an easy way of using the disc (i.e., rolling the thumb), and trying to discern his intent.

 

 

Human fingers are exceedingly accurate (we can pick up grains of sand and specks of dust by merely pointing our fingers at them and pressing on them), but the disc provides very little affordances for direction (no tick marks, no "clicks," no discernible pressure points) other than the imaginary and intuitive cardinal points the user projects on it.

 

And when you are rolling your thumb round, you can tell the difference between the heuristic and the simpler strategy of just continuing with the previous direction for the dead zone? Obviously the effect is to make the controls marginally more responsive, but I would not have predicted it would be noticeable in play. It is very interesting that it is.

 

decle

 

Yes, it feels more responsive and naturally fluid. It is very subtle, but perceivable. I believe it's because, while rolling the thumb, it does not have to land precisely on the next zone before reacting to the user's intent, so the user is free to jerk and slide his thumb as quickly or abruptly as he wants to without any perceivable loss of control.

 

The other part of the equation is that Christmas Carol polls the hand-controller channel at a higher resolution than 60 Hz. It actually polls on the "idle" task of the core engine repeatedly, with a guarantee of a minimum of once per frame. This means that there is more granularity in the input response, so the act of rolling the thumb around the disc has the opportunity to provide more discrete signals.

 

I think this lends itself to higher precision and response time needed for action games than, say, polling at 60 Hz on the ISR. The problem is not necessarily the polling rate (since human reaction time may not be that high), the problem is in polling on the VBLANK interrupt after processing the current frame. This means that your input is always processed on the next frame, so your game state is one frame behind the user's response. By polling on the idle task, you have a chance of having a fresh new input right when the interrupt occurs, and so you get to render the current frame with potentially more actual information.

 

We discovered during testing that the combination of the heuristics and almost real-time input polling enhances the response time of the game significantly and perceivably. Of course, without them the game still played fine and people mostly didn't consciously notice anything amiss; but they did report it feeling faster and better with them. To me it's the difference between a typical Intellivision action game and an arcade game.

 

-dZ.

Edited March 26, 2017 by DZ-Jay

[decle]

Human fingers are exceedingly accurate (we can pick up grains of sand and specks of dust by merely pointing our fingers at them and pressing on them), but the disc provides very little affordances for direction (no tick marks, no "clicks," no discernible pressure points) other than the imaginary and intuitive cardinal points the user projects on it.

I see you are a fan of Donald Norman

 

As a further aside, the sensitivity of human touch is incredible. Although if you just rest your finger on something something you can spot imperfections of about 0.2mm, if you drag your fingertip across a surface you can spot imperfections of less than 1micron in height. So when you run your finger over something or rotate an Inty disk and it feels smooth, it is really, really smooth.

 

The other part of the equation is that Christmas Carol polls the hand-controller channel at a higher resolution than 60 Hz. It actually polls on the "idle" task of the core engine repeatedly, with a guarantee of a minimum of once per frame. This means that there is more granularity in the input response, so the act of rolling the thumb around the disc has the opportunity to provide more discrete signals.

 

I think this lends itself to higher precision and response time needed for action games than, say, polling at 60 Hz on the ISR. The problem is not necessarily the polling rate (since human reaction time may not be that high), the problem is in polling on the VBLANK interrupt after processing the current frame. This means that your input is always processed on the next frame, so your game state is one frame behind the user's response. By polling on the idle task, you have a chance of having a fresh new input right when the interrupt occurs, and so you get to render the current frame with potentially more actual information.

This is also a helpful tip. Having only written emulators thus far I reserved the "idle" for the emulator core itself and had all the UI including input scanning in the ISR. However, I can see that reducing controller lag by moving scanning from the ISR to the idle and oversampling would be an excellent idea. I will look to do that in the synth project I'm working on.

 

We discovered during testing that the combination of the heuristics and almost real-time input polling enhances the response time of the game significantly and perceivably. Of course, without them the game still played fine and people mostly didn't consciously notice anything amiss; but they did report it feeling faster and better with them. To me it's the difference between a typical Intellivision action game and an arcade game.

Cool, very helpful. Thanks DZ.

[+DZ-Jay]

As a further aside, the sensitivity of human touch is incredible. Although if you just rest your finger on something something you can spot imperfections of about 0.2mm, if you drag your fingertip across a surface you can spot imperfections of less than 1micron in height. So when you run your finger over something or rotate an Inty disk and it feels smooth, it is really, really smooth.

 

Agreed. There's also the innate human ability to sense and track the position of its limbs and digits in three-dimensional space, so you can somehow tell when rolling your thumb around at which cardinal point it is even when not looking at it. This is why I imagine a player would tend to "correct" their thumb position automatically if it happens to land on a perfect diagonal, just because he can sense it is not at the precise cardinal point he intended.

 

However, in my opinion, while the player is making such corrections to his previous response, his next response is necessarily delayed. This is why I feel it is important to attempt to discern his intent to avoid such corrections.

 

None of this is scientific -- at least not on my case. It's all based on my own personal experience, conjecture, mixed in with stuff I've read. There was no "master design," just a series of notions that I thought could improve game-play if we embrace the quirkiness of the disc.

 

 

This is also a helpful tip. Having only written emulators thus far I reserved the "idle" for the emulator core itself and had all the UI including input scanning in the ISR. However, I can see that reducing controller lag by moving scanning from the ISR to the idle and oversampling would be an excellent idea. I will look to do that in the synth project I'm working on.

 

 

Cool, very helpful. Thanks DZ.

 

No worries. I think this is an underestimated topic. Most people set aside any considerations for the Intellivision hand-controller and treat it as a 16-button surface or narrow it down to 8 or 4. However, it is much more than that: it is an analog human-computer interface used to track player's intent during games. The problem domain is even more narrow when you consider specific interaction mechanics for a particular game.

 

Applying some critical thought about this can yield better and more responsive and fluid game mechanics. In the same way that most games try to advance the state-of-the-art on graphics and sounds to a much higher degree than they were exploited 30 years ago, we could do the same for player interaction.

 

In a sense, we've gone backwards because, while these considerations were very present in the minds of programmers back in the day (the EXEC was able to translate directional input into angular velocity, etc.), they are obviated or ignored today.

 

-dZ.

Edited March 26, 2017 by DZ-Jay

[+DZ-Jay]

One correction I'd like to make is to say that the above applies exclusively to high-speed arcade action games, where one expects the user to press their thumb against the disc and roll it around in order to maximize reaction time.

 

For menus or any other user input that does not require such immediate and consistent reaction, I typically leave the dead zones intact. For instance, when presented with a menu, I would expect a user to just press a direction rather than constantly slide his thumb across the disc surface.

 

In such more "passive" cases I also add additional heuristics and a state machine to debounce and condition the signal aggressively. I forgo expensive line conditioning during Christmas Carol's normal game-play because, in practice, the layout of the screen and the nature of the game mechanics constraint the input to specific places and valid directions, which serve to quantize the input already.

 

This is an insight that Joe Z. shared with me when we discussed input handling in his game Space Patrol: he also forwent debouncing and expensive processing during game-play because the mechanics and input types were constrained enough to cause invalid or unwanted input to be discarded anyway. Both our games attest to the validity of this in practice.

 

Conversely, during menu entry (especially when accepting simultaneous input from disc and keypad), both our games employ a bit more logic to debounce and condition the signal.

 

-dZ.

Edited March 26, 2017 by DZ-Jay