Episode 10: AI and the Problem of Missing Accurately

This episode we're not presenting some other code or achievement, but rather some of our pondering. On our way home from pre-Halloween festivities, we couldn't help thinking about the AI in our game. And, as we had to welcome this uninvited guest to our thoughts, we may invite everyone else to our reasoning, as well.

Hit by a saucer, once again in, ICSS v. 0.4.

So this time it's not about yet another piece of code, or about ancient machines, or their assembly language, but about a more general problem. Earlier, we already introduced our approach to the AI of the saucers, namely the targeting behavior. And while rather dumb than smart, the result isn't only close to that of the original game, most of the time, the aim of the saucers is also surpisingly accurate. Maybe a bit too accurate and deadly, as the little disks are really sharp — which isn't making this too good of a game at all.

The problem of a rather deadly game AI in a simple game lacking any story, arc, or development of characters is in effect the problem of the players frustration as a factor in the game as a closed HCI-system. With no superstructure or narrative framework to justify or sublimate this kind of challenge without relief, frustration is not only the defining factor of the very challenge a specific game poses, it's also a factor to be fine tuned with care for the game to succeed, since there simply isn't any other reason for us to accept the challenge but this provoking annoyance in relation to any cheers of triumph and success.

While Computer Space did at least better than we do currently, it is a well known fact that it was, in this regard, on the very edge itself, as illustrated by its rather mixed commercial success. So, while we see some similarities in the behavior of the two games, where are the differences, and where does Computer Space actually better than we do?

Comparing the current state of affairs of our game to various footage of Computer Space gameplay, there are many similarities, mercyless poundering of a sitting or re-accelerating player's rocket, deadly shots out of nowhere, quite accurate aim, and so on. But there's also a major difference: In the original game, at times, the saucer will miss quite at a distance. While this may appear to be a rather punny failure of the circuits in doing their job of reasonably acquiring a target, there's more to it: It introduces a moment of hope or relief in what were else an endless death race, much like the "scatter mode" in Pac-Man, where the ghosts stop to return to their respective home corners. — And this is also, what's currently lacking in our game: Approriately inaccurate target acquisition.

Signal to Noise

Ironically (that is, if there is any irony in this at all), target acquisition is one of the very purposes the PDP-1 had been once constructed for. The first announcement of the machine ("Special Purpose PDP Has GP Applications" in Datamation, Nov/Dec 1959) reads, "One of the application being planned for PDP is dynamic simulation of a weapons system using it as the central computer in combination with analog computers." (This may also explain the rather sophisticated IO-side of the machine.)

We may suppose this to have been much in the tradition of the work pioneered by Norbert Wiener in the early 1940s, eventually leading to the automated guns introduced with the B29 bomber. In other words, the problem of signal to noise ratio.

Here, we're facing the oppsite problem, introducing noise to effect in an apparently "organic" malfunctioning of the targeting system by provoking a false signal. But — and here we may find some irony, at last — there are also similarities.

Noise to Signal

The defining factors in the problem of target acquisition for our game AI may be illustrated as follows:

Targeting in game AI and factors involved.

As we observe two moving vessels in our game, a saucer and its presuming prey, the rocket ship, there are only two variables regarding the probability of the rocket occuring in a channel of aiming "vision" and thus exciting a signal of successfull target acquisition: The size of this channel (here, we're only observing a single one, while there are actually eight of them in the game) in relation to the size of the target and the area of noise introduced by a random factor varying with each frame. As soon as this area of noise and the targeting channel overlap, we have a signal.

In fact, there's a sweet spot in the calibration of the system, where the noise artificially introduced into the system helps in accurately acquiring the target as it cancels out any prediction errors in the projected path and delta V. (This sweet spot is defined by the size of the target, by its average distance and by its maneuverability.) And our problem is that we're too close to this sweet spot in our game.

A naïve approach may be to increase any of the two defining factors, either the width of the channel of vision (our epsilon), or the scaling of the random noise, or both. But, as we were putting it above, "As soon as this area of noise and the targeting channel overlap …". — By this, we'd just displace the class of the problem into a timing issue.

Noise to Signal Timing

As we're observing here two objects in relative motion — this is the only variable regarding target acquisition for our saucer because of its fixed shooting angles — widening any of these areas would, by all probability, just provoke an early signal. As we're dealing with shifting ranges at a rather high frame rate, odds are that an exaggerated random value would occure in the process of a saucer seeking for its target. Thus, introducing any random beyond the sweet spot of the system just results in the saucers shooting early and in them steadily missing by an, by all odds, rather constant range. — Not exactly what we were looking for.

Timing to Noise

For the moment, I see just two solutions to the problem:

A) Introducing another random factor with a very low probability that would very infrequently cause any of the targeting factors (epsilon and scaling of random noise) to go up by a magnitude. By keeping this a quite rare event, we may hope to miss equally early than late in our acquisition of an aiming signal.

B) We may introduce an additional random timer and, as it triggers, take the best shot we get, uncondionally. (This equals to our very first approach to the problem, which we found just not good enough. But, well, we could still mix this in.)

While both approches propabably would show similar effects, the second one would have required entirely separate circuits for the arcade machine and would force us to introduce completely new parts of code into our program. Therefor, odds are, we'll eventually go with the first of these two approaches to fix our problem in calibrating the gameplay regarding challenge, irritation, frustration, and reward.

But this will be postponed to when we'll fine tune the game.

Edit: Finally, there's a third option, widening any of the channels/areas and adding an offset to it again to compensate it completely and clearing this offset from time to time. Again, this is similar in effect to the other approaches.

That's all for this post. (See? No code …)

******

P.S.: While flying saucers are currently seen in Vienna quite frequently on the screen of my workstation, I've to disappoint about yesterday's UFO sightings in Vienna, Oct 28, as these were just part of a PR campaign by telephone carrier T-Mobile. However, I am grateful for the effort put in providing an ambient atmosphere to this post. — Was not yet necessary, really. ;-)

******

▶ Next:   Episode 11: It Lives!

◀ Previous:   Episode 9: Scores, Just in Time

▲ Back to the index.

— This series is part of Retrochallenge 2016/10. —