Difference between revisions of "SCI/FreeSCI/Pathfinding/Semantics"

Jump to navigation Jump to search
m
behaviour -> behavior
(Added images, linkify section references. Page done.)
m (behaviour -> behavior)
 
(One intermediate revision by the same user not shown)
Line 24: Line 24:
Figure 7 illustrates the semantics of near-point access polygons. The path goes from <i>s</i> to the near point <i>s'</i> and ends at <i>t</i> coming from the near point <i>t'</i>. We did not come across any near-point access polygons in games so the purpose behind these is unknown.
Figure 7 illustrates the semantics of near-point access polygons. The path goes from <i>s</i> to the near point <i>s'</i> and ends at <i>t</i> coming from the near point <i>t'</i>. We did not come across any near-point access polygons in games so the purpose behind these is unknown.


The fourth polygon type is the contained access polygon. Unfortunately we could not test its semantics with the experimentator. The experimentator only works with a particular version of Sierra SCI that predates the addition of this fourth polygon type. In order to solve this problem we added a debug mode to FreeSCI to visualize the polygons on the display, using a different colour for each polygon type. We found a contained access polygon this way and we observed its semantics in Sierra SCI. Figure 8 illustrates these semantics. As the end point <i>t</i> is outside the polygon it cannot be reached. The path will end at the near point <i>t'</i> instead. The idea of this polygon is that it defines the outer boundary and Ego must stay inside of it, i.e. no path may exit this polygon. As any two polygons cannot intersect it follows that there can only be one such polygon. With more than one contained access polygon no path exists that is fully contained in each of those polygons.
The fourth polygon type is the contained access polygon. Unfortunately we could not test its semantics with the experimentator. The experimentator only works with a particular version of Sierra SCI that predates the addition of this fourth polygon type. In order to solve this problem we added a debug mode to FreeSCI to visualize the polygons on the display, using a different color for each polygon type. We found a contained access polygon this way and we observed its semantics in Sierra SCI. Figure 8 illustrates these semantics. As the end point <i>t</i> is outside the polygon it cannot be reached. The path will end at the near point <i>t'</i> instead. The idea of this polygon is that it defines the outer boundary and Ego must stay inside of it, i.e. no path may exit this polygon. As any two polygons cannot intersect it follows that there can only be one such polygon. With more than one contained access polygon no path exists that is fully contained in each of those polygons.


==Keyboard handling==
==Keyboard handling==
Even though the mouse is the main method for moving Ego in SCI1, the games still have keyboard support. This keyboard support exhibits the same behaviour as in SCI0. That is, after the user presses a directional key Ego will move in that direction until he bumps into an object, at which point he will stop. As the user has only indicated a direction, it is impossible to know to what exact location the user wants Ego to go. No attempts to avoid obstacles are made.
Even though the mouse is the main method for moving Ego in SCI1, the games still have keyboard support. This keyboard support exhibits the same behavior as in SCI0. That is, after the user presses a directional key Ego will move in that direction until he bumps into an object, at which point he will stop. As the user has only indicated a direction, it is impossible to know to what exact location the user wants Ego to go. No attempts to avoid obstacles are made.


The games implement this by calling AvoidPath with the optimization level set to 0. The end point is chosen in such a way that it is outside of the display and exactly in the direction the user has indicated. For example, if Ego is positioned at coordinates (100, 100) and the user presses left; the end point might be (-10000, 100). Optimization level 0 is perfect for implementing this functionality as the returned path will move along the direct trajectory from start point to end point until the first obstacle is encountered (see Figure 1). The games simply take the first two points of the returned path and throw away the rest.
The games implement this by calling AvoidPath with the optimization level set to 0. The end point is chosen in such a way that it is outside of the display and exactly in the direction the user has indicated. For example, if Ego is positioned at coordinates (100, 100) and the user presses left; the end point might be (-10000, 100). Optimization level 0 is perfect for implementing this functionality as the returned path will move along the direct trajectory from start point to end point until the first obstacle is encountered (see Figure 1). The games simply take the first two points of the returned path and throw away the rest.
2,051

edits

Navigation menu