Processing collisions between digitally represented mobile objects and free form dynamically created electronic ink

FIELD OF THE INVENTION

[0001] The invention relates to allowing a computer user to use free form dynamically created electronic ink to interact with digitally represented mobile objects and relates to various techniques for processing collisions between the mobile objects and the ink.

BACKGROUND OF THE INVENTION

[0002] Computer application programs, such as computer games, screen savers, and the like, may have objects that move around the display screen and interact with other objects within the application program. Computer games in which a ball or other similar moving object moves around and bounces off of walls, paddles, and the like are well known in the art. JezzBall is an example of such a game. FIGS. <b>1</b>-<b>4</b> are Jezzball screen shots. JezzBall begins by displaying a game board <b>100</b> of tiles <b>102</b>. The game board initially represents a large area in which balls <b>104</b>-<b>1</b> and <b>104</b>-<b>2</b> bounce around off of each other and off of the walls <b>106</b>-<b>1</b> through <b>106</b>-<b>4</b>. The two balls <b>104</b> move around the screen bouncing off each other and off of the walls <b>106</b> according to expected physics principles, such as that the angle of incidence of a collision between a ball and a wall will equal the angle of reflection of the ball as it leaves the wall after the collision. The object of the game is to trap the balls into progressively smaller areas by building horizontal and vertical walls. A person playing JezzBall builds a wall by positioning the cursor and clicking a mouse button. JezzBall builds walls from a central point in opposite vertical or horizontal directions. FIG. 2 shows a vertical wall being built in two wall sections <b>200</b>-<b>1</b> and <b>200</b>-<b>2</b>. FIG. 3 shows a completed version of the wall <b>300</b>, which was shown being built in FIG. 2.

[0003]FIG. 4 shows the balls <b>104</b> confined to small areas <b>400</b>-<b>1</b> and <b>400</b>-<b>2</b>. A user interface element <b>402</b> indicates the percentage of the game board <b>100</b> that has been cleared. Once 75 percent of the game board has been cleared, the player advances to the next game board, which will have more balls than the previous game board.

[0004] Relative to the conventional keyboard and mouse input devices, computer systems are providing more natural ways for users to interact with their computers. One of these more natural ways is handwritten electronic ink. Accordingly, an application program, such as a computer game, that allows a user to interact naturally, via electronic ink, with mobile objects, such as bouncing balls and the like, within the game would be desirable.

[0005] Such a game, however, presents technical challenges regarding processing collisions between the mobile objects and free form electronic ink. Free form electronic ink refers to ink that may be entered by a user and that is not limited to predefined shapes and/or predefined orientations. The technical challenges are presented by the many orientations that the ink may have at locations at which a mobile object collides with the ink.

[0006] In contrast, conventional application programs, typically process collisions between mobile objects and a limited number of predefined shapes in predefined orientations. For instance, FIG. 5 depicts velocity vectors <b>504</b> and <b>506</b> of a conventional application program's mobile object <b>500</b> (e.g., a ball) before and after, respectively, a collision with a flat horizontal surface <b>514</b> (e.g., a wall). The angle <b>516</b> of velocity vector <b>504</b> relative to the velocity vector's vertical or y-coordinate component <b>502</b>, before the collision, is equal to the angle <b>518</b> of velocity vector <b>506</b> after the collision. The mobile object's velocity vector may be changed from <b>504</b>, before the collision, to <b>506</b>, after the collision, by negating the y component <b>502</b> of the mobile object's velocity vector <b>504</b>. The mobile object's post-collision velocity vector <b>506</b>, will then have an x component, <b>512</b> that is the same as the x component value <b>510</b> of pre-collision velocity vector <b>504</b>, but a y component value <b>508</b> that is the inverse of the pre-collision y-component vector <b>502</b>. Techniques for processing other types collisions, such as collisions with flat vertical surfaces, and collisions with circular shapes are also well known in the art.

[0007] Processing collisions between an application program's mobile objects and free form electronic ink is more complicated than processing collisions for which the shapes and orientations are known at development time of the application program. Accordingly, relatively simple and efficient techniques for processing collisions between an application program's mobile object and free form electronic ink would be desirable.

BRIEF SUMMARY OF THE INVENTION

[0008] In accordance with the invention, a collision between a digitally represented mobile object and free form electronic ink is processed simply and efficiently. A collision angle is determined. The collision angle may bisect a first and last intersecting point along a periphery of the mobile object. The mobile object's trajectory is then changed is such that the mobile object moves away from the ink as if the mobile object had collided with a flat surface that is oriented perpendicular to the collision angle.

[0009] The mobile object's trajectory may be changed as a result of the collision by: rotating the mobile object's velocity vector in a first direction by an amount that would make the collision surface orientation vertical; negating an x component value of the mobile object's velocity vector; and rotating the mobile object's velocity vector in a direction opposite to the first direction by the amount that would make the collision orientation vertical. Alternatively, the mobile object's velocity vector could be rotated in a first direction by an amount that would make the collision surface orientation horizontal; a y component of the mobile object's velocity vector could then be negated; and the mobile object's velocity vector could then be rotated in a direction opposite to the first direction by the amount that would make the collision orientation horizontal.

[0010] A computer system, in accordance with the invention, includes an application program that uses an ink API. The ink API provides services for capturing, storing, and displaying ink entered by a user. The computer system includes: an input device for entering free form handwritten electronic ink, and an ink-based computer application program that includes a collision processing module. The collision processing module requests information from the ink API about whether free form ink, entered by a user at run time of the application program, exists at locations occupied by one or more selected mobile application-program objects. And the collision processing module causes a change to a trajectory of at least one of the selected mobile application-program objects, based on how the locations of the mobile application-program objects overlap with the free form ink.

[0011] An ink-based computer game, in accordance with the invention, provides a natural way, via handwritten electronic ink, for players of the game to interact with mobile objects within the game. The game may include colored balls; game boards; and free form handwritten electronic ink entered by a user while playing the game, wherein the balls bounce off of other balls, wall tiles, and the electronic ink and go through drainpipes in the game board.

BRIEF DESCRIPTION OF THE DRAWINGS

P-0012[0012] FIGS. <b>1</b>-<b>4</b> show a prior art computer game in which balls bounce off each other and off of flat horizontal and vertical walls.

P-0013[0013]FIG. 5 shows velocity vectors for a mobile object before and after the mobile object has a conventionally processed collision with a horizontal surface.

P-0014[0014]FIG. 6 is a schematic diagram of an exemplary operating environment, in the form of a general purpose computer, in which various aspects of the invention can be implemented.

P-0015[0015]FIG. 7 is a schematic diagram of an exemplary operating environment, in the form of a tablet-and-stylus computer, in which various aspects of the invention can be implemented.

P-0016[0016] FIGS. <b>8</b>-<b>11</b> show an exemplary computer-game layout in accordance with the invention.

P-0017[0017]FIG. 12 is a schematic diagram of components of a system in accordance with the invention.

P-0018[0018]FIG. 13 shows collision of a single point along the periphery of a mobile object with electronic ink.

P-0019[0019]FIG. 14 shows collision of multiple points along the periphery of a mobile object with electronic ink.

P-0020[0020]FIG. 15 is a high-level flow chart showing steps for providing a computer game in accordance with the invention.

P-0021[0021]FIG. 16 is a more detailed flow chart of the game loop mentioned in FIG. 15.

P-0022[0022]FIG. 17 is a more detailed flow chart of the collision-checking step of FIG. 16.

DETAILED DESCRIPTION OF THE INVENTION

P-0023[0023] General Purpose Computing Environments

P-0024[0024] Although not required, the invention will be described in the general context of computer-executable instructions, such as program modules. Generally, program modules include routines, programs, objects, scripts, components, data structures, and the like that perform particular tasks or implement particular abstract data types. The invention provides for a software system that may be implemented on any network infrastructure such that networked devices may be remotely controlled by, for example, a general-purpose computer, or a system whereby the networked devices may share information with and about each other. The invention provides and accepts common command, control, and communication through the network while retaining the ability of each device to operate autonomously. In a distributed computing environment, program modules may be located in both local and remote memory storage devices

P-0025[0025]FIG. 6 illustrates a schematic diagram of an exemplary conventional general-purpose digital computing environment that can be used to implement various aspects of the invention. In FIG. 6, a computer <b>600</b> includes a processing unit <b>610</b>, a system memory <b>620</b>, and a system bus <b>630</b> that couples various system components including the system memory to the processing unit <b>610</b>. The system bus <b>630</b> may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory <b>620</b> includes read only memory (ROM) <b>640</b> and random access memory (RAM) <b>650</b>.

P-0026[0026] A basic input/output system <b>660</b> (BIOS), containing the basic routines that help to transfer information between elements within the computer <b>600</b>, such as during startup, is stored in the ROM <b>640</b>. The computer <b>600</b> also includes a hard disk drive <b>670</b> for reading from and writing to a hard disk (not shown), a magnetic disk drive <b>680</b> for reading from or writing to a removable magnetic disk <b>690</b>, and an optical disk drive <b>691</b> for reading from or writing to a removable optical disk <b>692</b> such as a CD ROM or other optical media. The hard disk drive <b>670</b>, magnetic disk drive <b>680</b>, and optical disk drive <b>691</b> are connected to the system bus <b>630</b> by a hard disk drive interface <b>692</b>, a magnetic disk drive interface <b>693</b>, and an optical disk drive interface <b>694</b>, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for the personal computer <b>600</b>. It will be appreciated by those skilled in the art that other types of computer readable media that can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories (RAMs), read only memories (ROMs), and the like, may also be used in the example operating environment.

P-0027[0027] A number of program modules can be stored on the hard disk drive <b>670</b>, magnetic disk <b>690</b>, optical disk <b>692</b>, ROM <b>640</b> or RAM <b>650</b>, including an operating system <b>695</b>, one or more application programs <b>696</b>, other program modules <b>697</b>, and program data <b>698</b>. A user can enter commands and information into the computer <b>600</b> through input devices such as a keyboard <b>601</b> and pointing device <b>602</b>. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner or the like. These and other input devices are often connected to the processing unit <b>610</b> through a serial port interface <b>606</b> that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port or a universal serial bus (USB). Further still, these devices may be coupled directly to the system bus <b>630</b> via an appropriate interface (not shown). A monitor <b>607</b> or other type of display device is also connected to the system bus <b>630</b> via an interface, such as a video adapter <b>608</b>. In addition to the monitor, personal computers typically include other Eperipheral output devices (not shown), such as speakers and printers. In a preferred embodiment, a pen digitizer <b>664</b> and accompanying pen or stylus <b>665</b> are provided in order to digitally capture freehand input. Although a direct connection between the pen digitizer <b>664</b> and the processing unit <b>610</b> is shown, in practice, the pen digitizer <b>664</b> may be coupled to the processing unit <b>610</b> via a serial port, parallel port or other interface and the system bus <b>630</b> as known in the art. Furthermore, although the digitizer <b>665</b> is shown apart from the monitor <b>607</b>, the usable input area of the digitizer <b>664</b> may be co-extensive with the display area of the monitor <b>607</b>. Further still, the digitizer <b>664</b> may be integrated in the monitor <b>607</b>, or may exist as a separate device overlaying or otherwise appended to the monitor <b>607</b>.

P-0028[0028] The computer <b>600</b> can operate in a networked environment using logical connections to one or more remote computers, such as a remote computer <b>609</b>. The remote computer <b>609</b> can be a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer <b>600</b>, although only a memory storage device <b>611</b> has been illustrated in FIG. 6. The logical connections depicted in FIG. 6 include a local area network (LAN) <b>612</b> and a wide area network (WAN) <b>613</b>. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

P-0029[0029] When used in a LAN networking environment, the computer <b>600</b> is connected to the local network <b>612</b> through a network interface or adapter <b>614</b>. When used in a WAN networking environment, the personal computer <b>600</b> typically includes a modem <b>615</b> or other means for establishing a communications over the wide area network <b>613</b>, such as the Internet. The modem <b>615</b>, which may be internal or external, is connected to the system bus <b>630</b> via the serial port interface <b>606</b>. In a networked environment, program modules depicted relative to the personal computer <b>600</b>, or portions thereof, may be stored in the remote memory storage device.

P-0030[0030] It will be appreciated that the network connections shown are exemplary and other techniques for establishing a communications link between the computers can be used. The existence of any of various well-known protocols such as TCP/IP, Ethernet, FTP, HTTP and the like is presumed, and the system can be operated in a client-server configuration to permit a user to retrieve web pages from a web-based server. Any of various conventional web browsers can be used to display and manipulate data on web pages.

P-0031[0031]FIG. 7 illustrates an exemplary tablet-and-stylus computer <b>701</b> that can be used in accordance with various aspects of the invention. Any or all of the features, subsystems, and functions in the system of FIG. 6 can be included in the computer of FIG. 7. Tablet-and-stylus computer <b>701</b> includes a large display surface <b>702</b>, e.g., a digitizing flat panel display, preferably, a liquid crystal display (LCD) screen, on which a plurality of windows <b>703</b> is displayed. Using stylus <b>704</b>, a user can select, highlight, and/or write on the digitizing display surface <b>702</b>. Examples of suitable digitizing display surfaces <b>702</b> include electromagnetic pen digitizers, such as Mutoh or Wacom pen digitizers. Other types of pen digitizers, e.g., optical digitizers, may also be used. Tablet-and-stylus computer <b>701</b> interprets gestures made using the stylus <b>704</b> in order to manipulate data, enter text, create drawings, and/or execute conventional computer application tasks such as spreadsheets, word processing programs, and the like.

P-0032[0032] The stylus <b>704</b> may be equipped with one or more buttons or other features to augment its selection capabilities. The stylus <b>704</b> could be implemented as a “pencil” or “pen”, in which one end constitutes a writing portion and the other end constitutes an “eraser” end, and which, when moved across the display, indicates portions of the display are to be erased. Other types of input devices, such as a mouse, trackball, or the like could be used. Additionally, a user's own finger could be the stylus <b>704</b> and used for selecting or indicating portions of the displayed image on a touch-sensitive or proximity-sensitive display. Consequently, the term “user input device”, as used herein, is intended to have a broad definition and encompasses many variations on well-known input devices such as stylus <b>704</b>. Region <b>705</b> shows a feedback region or contact region permitting the user to determine where the stylus <b>704</b> has contacted the display surface <b>702</b>.

P-0033[0033] Ink or electronic ink as used in this document refers to a sequence or a set of strokes that may have various properties. The sequence of strokes may include strokes ordered, for example, by the time captured. Each stroke is typically comprised of a sequence of points, which may be represented using a variety of known techniques including Cartesian coordinates (X, Y), polar coordinates (r, Θ), and other techniques as known in the art.

P-0034[0034] A stroke as used in this document refers to a sequence or set of captured points. For example, when rendered, the sequence of points may be connected with lines. Alternatively, the stroke may be represented as a point and a vector in the direction of the next point. In short, a stroke is intended to encompass any representation of points or segments relating to ink, irrespective of the underlying representation of points and/or what connects the points. A stroke may consist of the sequence or set of points captured from when a user performs a pen down action to when the user performs a pen up action.

P-0035[0035] In various embodiments, the system provides an ink platform or API as a set of COM (component object model) services that an application can use to capture, manipulate, and store ink. One service enables an application to read and write ink using the disclosed representations of ink. The ink platform may also include a mark-up language including a language like the extensible markup language (XML). Further, the system may use DCOM as another implementation.

P-0036[0036] Exemplary Application Program

P-0037[0037] FIGS. <b>8</b>-<b>11</b> are screen shots from an exemplary application program in the form of a computer game in which various aspects of the invention can be implemented. In the exemplary game, balls, such as ball <b>800</b>, bounce off of other balls, walls <b>808</b>, and ink <b>806</b> entered by the user. When a ball <b>800</b> bounces off of ink <b>806</b> the ink may disappear. The object of the exemplary game is to get colored balls, to go into like-colored drainpipes, such as drainpipe <b>802</b>. When a colored ball <b>800</b> goes into a like-colored drainpipe, the user scores points. But when a colored ball <b>800</b> goes into a drainpipe <b>804</b> having a color other than the color of the ball <b>800</b>, the user loses a “life” within the game. At various times during the game, a player may have one or more lives within the context of the game.

P-0038[0038] To play the game, a user, also referred to as a player of the game, enters free form electronic ink <b>806</b> onto the computer's display screen much like a traditional pen lays down liquid ink on paper. The electronic ink <b>806</b> is not limited to pre-defined shapes in orientations that are known at development time of the application program. The shape of the electronic ink is determined based on the free form ink input by the player while playing the game.

P-0039[0039] The screen shots of FIGS. <b>8</b>-<b>11</b> are like snap shots that progress through time. The screen shots are separated by approximately 100 milliseconds. As can be seen from the figures, the ball moves towards the ink line in FIGS. 8 and 9. In FIG. 10, the ball hits the ink. In the FIG. 11, the ball has reflected away from the ink. The ball's collision with the ink changed the direction of travel, also referred to as the ball's trajectory. The angle of incidence of this collision equals the collision's angle of reflection.

P-0040[0040] A game board is a layout of tiles that can be a wall tile, a floor tile, or a drainpipe. In this exemplary game, the balls can move freely over floor tiles and can deflect off of wall tiles. Any number of balls can be launched from a predefined spot on the board. Balls can also start on the board or off the board. There can be many different boards, grouped into multiple difficulty levels. The game may include user interface elements, such as the score and how much time is left to complete a game board.

P-0041[0041] Various objects within the game may have various properties. For example, when a ball collides with a colored wall, the ball may take on the wall's color. Colored balls may break down similarly colored breakable walls. Color filter walls may let only balls of a certain color through.

P-0042[0042] A breakthrough or breakaway wall may disappear when a ball hits the breakthrough wall. Breakaway walls can release a different kind of wall or floor tile behind the breakaway wall, such as a speed up floor.

P-0043[0043] Door walls may oscillate between being floor tiles and wall tiles. Sticky walls may stop or slow down a ball. One-way floor tiles may allow balls to pass in only one direction. One side of the one-way floor tile could act as a wall when a ball hits that side from the outside of the tile.

P-0044[0044] Transport tiles may teleport a ball to another spot on the board. Sticky floor or wall tiles may cause a ball to be stuck to the floor or wall until another ball hits the ball that is stuck. A ball launcher where balls materialize and that launches balls can be placed anywhere on the game board. Game board tiles that are drainpipes take the ball off the game board.

P-0045[0045] Balls may change color when they hit ink. Colored ink may change the color of balls that hit the colored ink. Translucent ink may be used that slows down or speeds up a ball that hits the translucent ink.

P-0046[0046] Those skilled in the art will appreciate that the above examples are merely illustrative and that other variations of the board, walls, balls, and colors may be utilized.

P-0047[0047] Referring to FIG. 12, an application program <b>1200</b>, such as the exemplary game of FIGS. <b>8</b>-<b>11</b>, uses an ink API <b>1212</b> to capture, store, retrieve information about, and display ink, which has been entered by a user through input devices <b>1214</b>. As described above, the input devices <b>1214</b> could be a stylus, a mouse, or any device that emulates a mouse or allows control of a cursor on a computer's display screen. The application program <b>1200</b> gives permission to the ink API <b>1212</b> to display ink on the application program's video memory.

P-0048[0048] The application program <b>1200</b> takes advantage of the ink API's knowledge of ink strokes. The application program <b>1200</b> knows where the mobile objects are located and asks the ink API <b>1212</b> whether any ink is located where the mobile objects are located. If ink and a mobile object occupy the same location, then the mobile object has collided with ink. The application program <b>1200</b> may then change the mobile object's trajectory based on the collision. The application program can also ask the ink API <b>1212</b> to make the collided with stroke disappear.

P-0049[0049] Once such an intersection between a mobile object and ink is detected, the application program <b>1200</b> may perform a more complicated search to figure out how the mobile object intersects with the ink and, based on the object's movement, how the object should deflect off of the ink to look realistic.

P-0050[0050] With respect to the exemplary game discussed above in connection with FIG. 8-<b>11</b>, the board manager <b>1208</b> retrieves and loads game boards. The different tile types <b>1204</b> can be represented as different objects. When a ball collides with a wall, for instance, the ball can ask the wall, how it should deflect. In response, the wall can tell the ball to deflect in a well-known manner, such as the manner discussed above in connection with FIG. 5. For example, a colored wall could tell the ball to deflect in such a manner and to change the color of the ball to the same color as the colored wall. Ball-collision processing is discussed in greater detail below. The tile types <b>1204</b> and/or the balls <b>1206</b> may be child objects of a game board managed by the board manager <b>1208</b>.

P-0051[0051] User Interface components <b>1210</b> may include a player's score, a time limit for finishing a game board, a ball preview, which indicates what color ball will come out next, and the like. As balls move around the screen, the balls check to see whether they have collided with anything by calling into the collision-processing module <b>1202</b>. Alternatively, the walls could call into the collision-processing module <b>1202</b> for detecting and processing collisions between balls and walls.

P-0052[0052] Referring to FIGS. 13 and 14, the exemplary game uses ball points to simplify the process of determining an orientation of ink off which the ball should deflect. Exemplary ball points <b>1300</b>-<b>1</b> through <b>1300</b>-<b>8</b> are positioned around the periphery of balls <b>1314</b> and <b>1406</b>. Although FIGS. 13 and 14 show eight ball points, any other suitable number of ball points, such as 32, may be used.

P-0053[0053] The application program <b>1200</b> asks the ink API <b>1212</b> whether a bounded shape at a particular location collides with any ink. If there is such a collision, and the ink is curved, determining how a mobile object should bounce off of the curved ink can be relatively complicated. For example, if the ink is concave-shaped, then determining how the mobile object should move after the collision can become much more complicated by the mobile object colliding with the ink at multiple collision points along the periphery of the mobile object.

P-0054[0054] Collision Processing

P-0055[0055] Determining an orientation of an ink surface off which the mobile object should deflect will now be discussed in the context of the exemplary game. But the concepts apply to other shapes and in other contexts. After calling the ink API to figure out whether there is a collision for a ball of a given size, a more detailed search is performed with the center of the ball being moved out to the perimeter and the radius being relatively small, such as one-tenth of a pixel, or any other suitable size. Using more ball points along the perimeter will provide more precision. FIG. 14 provides an example in which there are two intersecting ball points <b>1300</b>-<b>2</b> and <b>1300</b>-<b>3</b>. An angle of collision <b>1400</b> can be determined by averaging the angles of the two ball points together.

P-0056[0056] Once the angle of collision is known, the angle at which the ball should leave the ink can be determined. This technique handles the situation in which multiple points collide with ink simultaneously. A data structure can maintain an x value, a y value, and an angle for each ball point, also referred to as each point along the periphery of the ball or mobile object. The x and y values may represent respective x and y coordinate difference values from the center of the circle to the point. For instance, if the radius of the ball <b>1314</b> shown in FIG. 13 is <b>5</b>, then ball point <b>1300</b>-<b>7</b> could be assigned an angle of 0 and x and y difference values of −5, and 0. Ball point <b>1300</b>-<b>1</b> would have difference values of 0 and −5, and an angle of 90 degrees. Note that y coordinates start at 0 at the top of the screen and get larger as they move down the screen. By maintaining a data structure that stores these relative distances between a center point of the mobile object and the points along the periphery of the mobile object, techniques for determining an orientation of the ink surface of which the mobile object should deflect can be independent of the size of the mobile object.

P-0057[0057] Other conventions for assigning degree values to particular angles could also be used. For instance, 0 degrees can be defined elsewhere and/or negative angle values can also be used for some of the points along the periphery of the mobile object. As discussed in more detail below, once a collision angle is determined, then an orientation <b>1404</b> of an ink surface that is perpendicular to the collision angle, also referred to as the collision orientation, can be determined. To reduce the number of time-consuming sine and cosine functions performed, the application program may rotate the mobile object's velocity vector by an amount of rotation that, if applied to the collision orientation would make the collision orientation vertical, negate the object's x velocity vector, and rotate the velocity vector back the amount it was rotated. The mobile object will then move away from the ink as if the mobile object collided with ink oriented perpendicular to the collision angle.

P-0058[0058]FIG. 15 is a high-level flow chart showing steps for providing the exemplary game. User settings, such as the difficulty level, high score, and the like, are loaded, as shown at <b>1500</b>. A game board is loaded, as shown at <b>1502</b>, based on a difficulty level. The game board is displayed and the game loop begins as shown at <b>1504</b>. The game loop is described in more detail below in connection with FIG. 16. A game board can end in two ways. The player can complete the game board. Then a new game board can be randomly selected and loaded based on difficulty level, as indicated with the yes branch from <b>1506</b>. Or, a player can fail to complete the board by, for instance, putting a colored ball into a wrong-colored hole or by running out of time, as shown by following the yes branch from <b>1508</b>. A game completion failure message box is then generated, as shown at <b>1510</b>. After clearing the message box, the game will restart with a new ball, as shown by the yes branch from <b>1512</b>. The loop may pause upon menu interaction where the user can change the difficulty level.

P-0059[0059] The game loop referred to in step <b>1504</b> is shown in more detail in FIG. 16. Referring to FIG. 16, each time the game loop is executed, it may determine how much time has passed since the last game-loop iteration, as shown at <b>1600</b>. Based on this information, the application program can account for situations in which the application program is not executed at precise intervals. Such situations can occur in a multitasking operating system having other applications running. Based on the amount of time elapsed since the last time the loop was run, a ball can determine how much it should move itself.

P-0060[0060] Updateable objects, which are things within the game that change over time, are updated, as shown at <b>1602</b>. Updateable objects may include balls, tile types, and a game board timer.

P-0061[0061] The exemplary game then checks for collisions between the balls and ink, as shown at <b>1604</b>. The balls can tell the board manager <b>1208</b> to check for collisions. A ball can pass information about itself, such as its location, to the board manager <b>1208</b>, which can then check for collisions between balls and ink. As will be apparent, other suitable collision-checking techniques could also be used, such as having a separate game manager (not shown), or the balls themselves, check for collisions between the balls and ink.

P-0062[0062] After checking for collisions and updating ball trajectories, the game will re-display parts of the game board that have changed as depicted at <b>1606</b>. Rather than redrawing the entire screen, the game redraws the rectangular portions of the screen that have changed.

P-0063[0063] The ink API <b>1212</b> may manage a separate thread for capturing, storing, and displaying ink entered by a user. The game may give the ink API permission to write to the game's video memory for displaying ink. The display screen gets updated each time the game loop runs. But the user can input ink with an input device at any time. So even though the screen may be updating only 20 times per second on a slow machine, the ink can be captured, stored, and displayed with a higher resolution.

P-0064[0064] The collision-checking step <b>1604</b> is shown in more detail in FIG. 17. Whether the ball has gone off the board is checked at step <b>1700</b>. Some boards may have walls drawn all the way around the edges. Other boards may not have walls all the way around the edges.

P-0065[0065] Step <b>1700</b> also includes checking for ball-to-ball collisions and ball-to-tile collisions. Techniques for processing ball-to-ball collisions are well known in the art. In the context of the exemplary game, if a first ball collides with a second ball, the first ball may update itself and the second ball's trajectory, and the second ball does not need to check for collisions with the first ball or update its own trajectory in response to the collision.

P-0066[0066] Ball-to-wall collisions can be handled in a manner that is well known in the art, including any manner similar to what was discussed above in connection with FIG. 5 for collisions with horizontal or vertical flat surfaces.

P-0067[0067] In step <b>1702</b>, the ball's area is checked for any collisions with ink. If no collisions are detected, ball-to-ink collision processing is done for the ball for this iteration of the game loop, as depicted by <b>1708</b>, at the end of the no branch from <b>1704</b>.

P-0068[0068] If any area of the ball has collided with ink, then a determination is made as to which ball points should be checked in step <b>1706</b>. The ball's trajectory can be used to select ball points along the perimeter of the ball that are most likely to have collided. For instance, based on the ball's trajectory, ball points along a semi-circle in the front of the ball can be checked and ball points in the back of the ball can be ignored. The front and the back of the ball may be defined relative to the ball's trajectory. So, with reference to FIG. 13, if the ball is moving horizontally from left to right, as depicted by arrow <b>1310</b>, then ball points <b>1300</b>-<b>1</b> through <b>1300</b>-<b>5</b> could be checked. If the ball was moving down vertically, as depicted by arrow <b>1312</b>, ball points <b>1300</b>-<b>3</b> through <b>1300</b>-<b>7</b> could be checked.

P-0069[0069] In step <b>1710</b>, the ball points selected in step <b>1706</b> are checked for intersection with ink. Based on which of these selected ball points intersect with ink, a collision angle is determined. With reference to FIG. 13, intersection of a single ball point <b>1300</b>-<b>4</b> with the ink <b>1308</b> is detected. The collision angle, therefore, is determined to be angle <b>1304</b>. As previously discussed, a data structure may be maintained that includes, for each ball point along the periphery of the ball, both location information and an associated angle relative to the ball's center point.

P-0070[0070]FIG. 14 depicts the case in which two ball points <b>1300</b>-<b>2</b> and <b>1300</b>-<b>3</b> intersect with concave-shaped ink <b>1402</b>. Accordingly, the collision angle <b>1400</b> bisects the angles associated with the first intersecting ball point, <b>1300</b>-<b>2</b> and the last intersecting ball point <b>1300</b>-<b>3</b>. By bisecting the angles associated with the first and last intersecting ball points, wherein the first and last intersecting angles may be the same, one or more intersecting ball points can be handled.

P-0071[0071] After determining the collision angle, an ink surface collision orientation, depicted at <b>1306</b> and <b>1404</b>, is determined, as shown at <b>1714</b>, by determining an angle that is perpendicular to the collision angle. This ink surface collision orientation is essentially a line that is tangent to the surface of the ball and perpendicular to the collision angle. For instance, ink surface collision orientations <b>1306</b> and <b>1404</b> are tangent to the surfaces of balls <b>1314</b> and <b>1406</b> and are perpendicular to collision angles <b>1304</b> and <b>1400</b>. These ink surface collision orientations can be thought of as flat surfaces off which balls <b>1314</b> and <b>1406</b> should bounce to make collisions between the balls and the ink look realistic.

P-0072[0072] To avoid performing time-consuming trigonometric functions at run time, the ball's velocity vector may be rotated by an amount that, if applied to the ink surface collision orientation, would make the ink surface collision orientation vertical. An example of this amount of rotation is shown by angle <b>1408</b> in FIG. 14. Then, in a manner similar to that discussed above in connection with FIG. 5, the x or horizontal velocity component of the ball's velocity can be negated, as shown at <b>1718</b>. In step <b>1720</b>, the ball's velocity vector can then rotated by an inverse of the amount it was rotated in step <b>1716</b>. The ink may expose a property, several of which were discussed in more detail above, that may change one or more properties of the ball after the collision. For example, the ball's velocity could be increased or decreased and/or the ball could change color based on the ink's color.

P-0073[0073] As will be apparent, in steps <b>1716</b>, <b>1718</b>, and <b>1720</b>, the ball's velocity vector could be rotated by an amount that, if applied to the ink surface collision orientation, would make the ink surface collision orientation horizontal. Then, the y or vertical velocity component of the ball's velocity could be negated. The ball's velocity vector could then be rotated back. In another embodiment, steps <b>1716</b>-<b>1720</b> may be replaced with dot-product math or trigonometric calculations, both of which are well known in the art, for calculating a ball's exit angle from a collision. The dot-product-math approach advantageously eliminates execution of costly sine and cosine operations.

P-0074[0074] While the exemplary game has mobile balls, the techniques discussed above for determining a collision angle and an ink surface collision orientation could be applied to objects of other shapes, such as a hexagon, for which the location of points along the perimeter of the shape are known. For instance, instead of balls, the mobile objects could be cars, animals, or any other object having a randomly selected fixed shape. The user of an application program could generate shapes on the screen in any suitable way. The mobile objects could bounce off of windows and icons in the context of a screen saver application program.

P-0075[0075] While the invention has been described with respect to specific examples including presently preferred modes of carrying out the invention, those skilled in the art will appreciate that there are numerous variations and permutations of the above described systems and methods that fall within the spirit and scope of the invention as set forth in the appended claims.