Patent Grant
11779833
This application claims the benefit of provisional patent application Ser. No. 63/151,652, filed 2021 Feb. 20 by the present inventor.
Not Applicable
Not Applicable
The present invention relates to an electronic game device and the software for a puzzle game to be played on this device.
The following is a tabulation of some prior art that presently appears relevant:
Handheld puzzle games are widely available and have been in various forms for centuries. Modern consumers of such puzzle games routinely seek out products which offer a portable form factor, a novel logic puzzle, a large number of game play levels of increasing difficulty, a spatial three-dimensional aspect, a straightforward path to puzzle mastery, a colorful and aesthetically pleasing form factor, and an inexpensive price.
Perhaps no product is more illustrative of this genre than the Rubik's Cube, U.S. Pat. No. 4,378,116 to Rubik (1983). Though purely mechanical in its original form, this invention's combination of manipulation in three dimensions, the use of a simple geometric form (a cube), and the objective of matching colors to complete the puzzle would become mainstays of the genre in the years following its invention. However, though challenging to the novice, this puzzle would quickly prove no challenge to experienced players. A quality often sought out by players is that a puzzle's challenge hold up for repeat play, so experienced players tired quickly of this purely mechanical device, and the “Rubik's Craze” of the 1980's ended as quickly as it began.
Separately, around the same time, the advent of the microprocessor in the 1970's led to the development of new electronic puzzles that promised the ability to give greater variety and depth of challenge to puzzle consumers. These electronic products also often adopted such color/pattern matching as the Rubik's Cube, but added the ability to control lights and offer multiple games and/or skill levels. Notable among these new digitally controlled games was Merlin, released by Parker Brothers, U.S. Design Pat. D256,139 to Venditti et al. (1980). This product included a matrix of 3×3 illuminated push buttons and six different games, including a novel game known as “Magic Square” in which pressing a given button would invert the state of its light (on or off) as well as the proximal lights in each cardinal direction, with the goal of achieving a specific pattern. This product was inexpensive to manufacture with multiple novel games included. However, its two-dimensional nonspatial game-play and limited 3×3 play area are generally no longer found to be captivating by the modern puzzle player.
In the years since, many inventors have used electronics to enhance the Rubik's Cube—for example, W.O. application 2008/131613 to Hsieh (2008), and Japan patent 2008307084A to Matsumoto (2008). Common elements of these proposed inventions include lights for each face segment (typically 9 multi-color LEDs per side, 54 total) with microprocessor control, as well as some electronic input means. However, such improvements still typically keep the original game-play of the Rubik's cube, and again do not provide any novel challenge to the experienced player. Additionally, the large number of LEDs and associated microprocessor connections necessitate these inventions to be complex and expensive to manufacture. These drawbacks typically limit these types of products to a niche market of Rubik's enthusiasts.
In addition to incremental improvements to the Rubik's cube, novel electronic 3-dimensional spatial puzzles have also continued to be created. A notable early work, U.S. Pat. No. 4,575,087 to Sinclair (1986) combined orientation detection with lighting up individual sides of a cube as part of the puzzle's game play. To improve on the limited challenge of Sinclair's invention, later works would add additional lights and input means to increase the variety and difficulty of their puzzles, such as U.K. patent 2,225,246 to Monticolombi and Norris (1990) and U.S. Pat. No. 4,809,979 to Skowronski et al. (1989), U.S. Pat. No. 4,957,291 to Miffit et al. (1990), U.S. Pat. No. 5,573,245 to Weiner et al. (1996), and U.S. Pat. No. 5,564,702 to Meffert (1996).
Common elements of many such novel 3D puzzles include the goal of making all lights the same color or state, various rules and/or levels of difficulty based on microprocessor control, and the use of push buttons or changes in the device's attitude as inputs used to solve the puzzle. The plethora of these games, many of which became commercially successful products, points to the ongoing popularity of such 3D puzzles as well as the need for novel challenges for puzzle enthusiasts. However, in addition to the logic problems for these aforementioned puzzles no longer being new and original for consumers, the prior art heretofore known have failed to successfully combine all of these aspects:
(a) A novel logic problem of significant challenge for enthusiasts, but with a straightforward path to eventual mastery (a balance greatly sought after by consumers);
(b) A logic problem that is also easily extendable to provide a large number of skill levels for the player (and thus greatly increase the amount of time it may hold a player's attention) while keeping the research and development costs to create such additional skill levels low;
(c) A puzzle logic problem which may provide the challenge and skill levels described in (a) and (b) in a cube shape that is preferred by customers due to its portable and attractive form factor, as well as its association with the iconic Rubik's Cube;
(d) A low manufacturing cost due to the simplicity of assembling a cube shape and reduced number of indicators (6 LEDs for the cube) versus more complex shapes such as spheres, tetrahedrons, dodecahedrons, etc.
(e) The use of blended multi-color illumination as the primary indication means of the puzzle's state, a feature which greatly improves the aesthetic appearance of the puzzle while also providing a color-based indication familiar from the Rubik's Cube.
In accordance with one embodiment, a three-dimensional puzzle of N sides, where N is at least 4, is provided. The puzzle contains (a) a means of visually indicating M states on each of the N sides, where M is at least 2; (b) an input means by which to change the state of a specific side; (c) a modular arithmetic or logical operation to be applied to the state of some or all N sides on user input; and (d) a means of changing the indication of puzzle state on the changed side and/or other side(s) of the puzzle based on the arithmetic or logical operation.
In the drawings, closely related figures have the same number but different alphabetic suffixes.
One embodiment of the game device 20 is illustrated in two perspective views in
Referring again to
A top printed circuit board assembly (PCBA) 40 has soldered to its top side (shown in detail in
and soldered to its bottom side (shown in
Referring again to
Laid inside an outer sleeve of cube structure 50 in this order are then:
To complete the internal wiring, one side of a 7-pin 1.25 mm pitch harness with connector on two sides 41 is plugged into header 58B on base PCBA 48, and battery assembly 45 is connected to base PCBA 48, header 46 by harness 49. Harness 41 is then connected to header 58A of top PCBA 40 and laid on top of inner frame 44 such that a box is formed, with battery assembly 45 and harness 41 fully contained inside.
A clear panel with etching for edge-lighting of top face 38A, and an outer lid of cube structure 36 are set atop top PCBA 40. Outer lid 36 is then screwed into inner frame 44 by screws (not pictured) sandwiching top PCBA 40 and clear panel 38A between them, and fully closing the cube structure.
After assembly, side-view LEDs 52A and 52B will be in close proximity to clear panels 38A and 38B respectively, and top-view LEDs 54A through 54D will be in close proximity to clear panels 42A through 42D respectively, such that, through edge-lighting, a circular etched pattern 66 (see
One embodiment of a charging and display base 68 for the game device 20 as assembled is shown in perspective view
The method of recharging the device's battery is depicted in
In this embodiment, the device's tap and gesture interfaces are realized through an acceleration sensor, in this case an accelerometer IC (not shown), part number KX023-1025 (KIONIX, Inc.) soldered to a daughter PCB, forming the accelerometer PCBA 60. Communication between MCU 64 and accelerometer PCBA 60 is performed through an Inter-Integrated Circuit (I2C) serial interface (NXP Semiconductors) as well as via a single digital signal (1 or 0). Gesture and tap recognition is performed within the accelerometer IC on the accelerometer PCBA 60. A tap recognition event recognizes the main axis of the tap (X, Y, or Z) with direction (+ or −), as well as whether the event was a single-tap or double-tap (two taps in fast succession). The accelerometer PCBA 60 will report such a tap event to the MCU 64 over I2C when the side of the game device 20 is tapped with a part of the body (such as a finger) or other object. The accelerometer PCBA 60 also reports events to the MCU 64 for a significant motion gesture. The accelerometer PCBA 60 will report such a significant motion gesture event to the MCU 64 as a digital signal (1 or 0) when the acceleration on any axis of the game device 20 exceeds a preset threshold. Examples of gestures that can generate a significant motion gesture event include clapping game device 20 between two hands, dropping it on something soft (like a pillow), or tossing it in the air and catching it.
A lithium battery and charger system 62, commonplace to those skilled in the art, is also provided. A +5V charging voltage is passed from USB cable 75 through USB power inlet 70 and pogo-pin contacts 72 in charging base 68 and then received in game device 20 through the target discs 28 (see
Next an internal timer known as the “Sleep Timer” is cleared. The function of the “Sleep Timer” is to put the system into a low-power and battery-saving “Sleep” mode if no user input is detected during the time period measured by the timer. After this, the game's previous state (if any), including current game level and colors of the game sides 22, 24, 26, 30, 32, and 34 (
After the current level is indicated for the player, LEDs 52A, 52B, and 54A through 54D (
Next, program operation checks if battery 47 (
Next, the “Sleep Timer” is checked. The “Sleep Timer” is cleared each time user input (either a tap or charging event) is registered. Thus, if the “Sleep Timer” ever expires, then the system presumes that since the player has not interacted with the game since the “Sleep Timer” was started, game play should be paused at this moment and the system should be put into “Sleep Mode” to preserve the battery level, so program operation proceeds to “Enter Sleep Mode”.
Finally, the battery level is checked, by a divided battery voltage to the MCU 64 (
If none of the above state changes are detected in the “Main Loop”, then the loop function is executed again.
As described above, if the player has not interacted with the game in a significant amount of time, game play should be paused and the system should be put into “Sleep Mode” to preserve battery. Function “Enter Sleep Mode” will move the system into the “Sleep Mode” state.
First, all hardware external to MCU 64 (
Next the MCU 64 (
To enter “sleep mode”, the CPU of MCU 64 (
Also described in
At this point, after making the transformation, the program checks for the winning condition—in this embodiment that all LEDs 52A, 52B, and 54A through 54D are currently off. If the puzzle is not in the winning state, then the transform is pushed to the “Undo Stack” (see description of the “Inverse Transform” in
If the puzzle has been put in the winning state, then a “Level Up” sequence begins whereby game play on the current level is ended and game play on the next level begins. The “Level Up” sequence begins by first indicating the current (and just recently completed) level through setting the color of all LEDs 52A, 54B, and 54A through 54D to a single color and fading them in and out, again following Table 1 for indication. The level is then internally incremented. If the last level (in the described embodiment, this is Level 6) is competed, then the level is instead reset for the player back to level 0. The new level is then indicated in the same way through setting the color of all LEDs 52A, 52B, and 54A through 54D to the new level color and fading them in and out, again following Table 1 for indication, to clearly show the level change for the player. The game state and corresponding colors of each LED 52A, 52B, and 54A through 54D are then randomized, and program operation proceeds back to the “Main Loop” (
The last diagram of program flow,
To employ this “Undo” function and enter the “Inverse Transform” function, the player double-taps on any device side 22, 24, 26, 30, 32, or 34 (see “Main Loop”,
The operation of “Inverse Transform” is as follows. First, since a double-tap event is a user interaction, the above-described “Sleep Timer” is cleared. Secondly, the data in the “Undo Stack” is checked. Note again that each non-winning game state change by single-tap on a device side 22, 24, 26, 30, 32, or 34 is pushed to an “Undo Stack” (“Transform” function,
If the “Undo Stack” is non-empty, then the “Undo” operation is performed. “Transform” operations are “pushed” to the undo stack (
To better illustrate the puzzle's logic problem, one embodiment is described below in detail.
In order to effectively solve the puzzle, the faces of the game device 20 are best understood by the player as N digits of a modulo-M number, where N is the number of faces of the puzzle, and M is the number of colors displayable on each face.
Thus, in
To the casual user, this correlation is not easily deduced, but experienced players of the game will understand well that digit 0 (base face 22) is easily recognized as the side of game device 20 with charging contacts 28. Then, holding the puzzle so that the contacts 28 are in the upper right corner of face 22, the cube may be rotated repeatedly up, right, up, right, up, and right, to cycle through the digits from 0 to 5 and back to 0. In other words, each rotation will present the face of an increasing digit place to the user, in the order listed in Table 2, finally ending up again at base face 22 (digit 0). Note this rotational pattern which correlates digits to game faces is arbitrary, and alternative patterns are clearly possible, but an easily remembered pattern for the player may speed up mastery of the game.
In an additional layer of abstraction, the color of each game face 22, 24, 26, 30, 32, and 34 as illuminated by LEDs 52A, 52B, and 54A through 54D should be considered by the experienced player as the value of each aforementioned digit, as follows in Table 3:
Thus, considering the puzzle as shown in
To better illustrate the above, consider the following game state in Table 4:
When game device 20 is in this state, it can be considered to have the octal value 611074.
Now that the puzzle's abstraction layer has been explained completely, its game state may just simply be referred to by a 6-digit octal number to simplify the mathematical explanation. The entire puzzle's game state will be additionally abbreviated as x.
It should be clear now, that the check for the puzzle's winning state “Are all lights off?” (
Consider then a simple “Transform” function, adding 1 to the digit that the player has tapped. Mathematically, this may be expressed as:
f(x, n)=x+000010n
Or to be stated in array notation that may be more familiar to software engineers: let a row vector a=(a0 a1 . . . a5) be set as
a=(000001 000010 000100 001000 010000 100000)
then the “Transform” function can be more simply stated as:
f(x, n)=x+an
Such a “Transform” function could potentially lead to the following sequence of game states in Table 5:
Note from Table 5 that the final tap to face 0 employs a feature of arithmetic that is another game mechanic, namely the idea of a carry. The reader will know well that 9+1=10 and 999,999+1=1,000,000 in base-10 arithmetic. Then similarly in the base-8 arithmetic of the game, 777777+000001=1000000. But since from
Also, in the above example illustrated in Table 5, the usage of a carry is assumed, but depending on the intended game rules, it can actually be seen as an optional part of the “Transform” as will be seen below in further illustrations. Therefore, a clearer representation of the “Transform” function should be to note the carry C in the function as well, such as:
f(x, n)=x+an+C
Further, where it may suit the challenge of a game level to do so, it is not required that C follow standard mathematical rules. A standard mathematical carry of a digit d is always into digit d+1. For example, in the octal operation 000070+000010, the carry from the overflow of digit 1 should be placed in digit 1+1=2, giving the result 000100. But for the purposes of the game, a carry can be made into any digit. Therefore, to note the carry behavior, subscript notation of the digit to apply it to shall be used. A standard mathematical carry left will be noted as Cd+1, and the “Transform” function demonstrated in Table 5 would be revised as:
f(x, n)=x+an+Cd+1
A reverse carry, i.e., one that carries right instead of left, conversely would be noted as Cd−1. Repeating the previous example, in the octal operation 000070+000010, the reverse carry Cd−1 from the overflow of digit 1 should be placed in digit 1−1=0, giving instead the result 000001.
The “Inverse Transform” (
a=(000001 000010 000100 001000 010000 100000)
f(x, n)=x+an+Cd+1
The “Inverse Transform” can then be clearly seen to be:
f(x, n)=x−an−Cd+1
Note that carry Cd+1 in the case of subtraction is more commonly known as a “borrow”, and functions in the inverse way. For example when 1 is subtracted from digit value 0 a borrow is invoked.
Table 6 shows how this “Inverse Transform” performs an “undo” of a portion of the previous sequence of Table 5:
Note how in Table 6 performing the “Inverse Transform” (for example with a double-tap on the device, see
Finally, now the concept of incrementing or otherwise changing the game “Level” as described in
In Table 7, find “Transform” functions for seven example levels:
It should be noted that the above “Transform” functions Table 7 will all be solvable for all states of the game, but this is not guaranteed. Take for example simple “Transform” function
a=(000002 000020 000200 002000 020000 200000)
f(x, n)=x+an
Clearly this function cannot mathematically reach state 000000 if any of the digits of the initial state are odd. For this reason, care should be taken when designing “Transform” functions and/or setting the puzzle's initial state to ensure that the puzzle is indeed always solvable.
In summary, the logic problem described above can be summarized as:
Above I've described my Interactive Electronic Puzzle Game Device one way in specific detail, but many other embodiments and alternative implementations are possible within the scope.
Incidentally, in the above embodiment, in order to define the form factor of the game device 20, a housing presenting as a cube with sides of the game 22, 24, 26, 30, 32, 34 has been depicted in
Incidentally, in the above embodiment, in order to define the control means of the game device as used in the software flow shown in
Additionally tap, double-tap, and significant-motion gestures are described as a control means for the current game play described in
Incidentally, in the above embodiment, in order to define the indicator means of the game device, a specific means of LED indication is described. In Table 3, specific colors are listed, but any equivalency of colors to digit value are possible, as well as the number M of digit values and corresponding colors clearly being variable according to the modulo-M arithmetic used by the game logic, from M=2 (single color LED on/off) and up. The LEDs for indication 52A, 52B, and 54A through 54D also need not be of the specific multi-die RGB (Red-Green-Blue) type as described in the above embodiment. Any other type of multi-die LED (such as Red-Blue, or Orange-Green-Blue) or combination of single or multi-die LEDs used to achieve the color perceived by the user are clearly possible. In addition, in the above embodiment, indication is performed by one LED per side 22, 24, 26, 30, 32, and 34 of the game device, but clearly two or more LEDs per side (optionally LEDs on both top and bottom PCBs lighting each side, for example) can be used for additional light intensity or effect as dictated by the specific application.
Incidentally, in the above embodiment, in order to define the indicator means of the game device, a specific circular etched pattern to be lit up upon edge-lighting panels 66 is depicted and described. However, clearly this is not limited to this specific pattern, and can be virtually any pattern, photographic image, texture (molded or otherwise), printed material, or even an LCD or other controlled display panel. Moreover, an embodiment with one etched panel per side is described, but clearly any number of panels can be included as needed. Such additional panels could be either arranged either next to or on top one another, and could be illuminated by separate LEDs, such that different etched patterns and/or colors may be illuminated and revealed to the user based on which LED is illuminated.
Incidentally, in the above embodiment, in order to define the indicator means of the game device, a specific means of displaying the N digits of a modulo-M number is described in Table 3, whereby each digit value is represented by a specific color. However, many other means of indicating the numeric state of a digit using LEDs are clearly possible. For example, LEDs may be arranged on one face to symbolically indicate the count using a 7-segment numeric display, discrete LEDs may be arranged in the pattern of the dots on a traditional gaming die, or any other symbolic pattern. Additionally, besides using LEDs, clearly myriad means of indicating a digit value exist in the state of the art, such as LCD displays, OLED displays, the display of a numeric or non-numeric symbol, mechanical indicators, or any combination thereof.
Incidentally, in the above embodiment, in order to define the indicator means of the game device, a specific means of displaying the N digits of a modulo-M number is described as the static illumination of a full face of the game device by LED edge-lighting. Alternatively this indication could clearly also be performed by a single point-source LED or back-lit housing, or could potentially be a glowing logo or symbol, or possibly different means for different sides. Additionally, the indication means clearly need not be static—the M values of a modulo-M digit could clearly be represented by different dynamic patterns, such as a flashing pattern (for example by Morse code), or video or other sequence of images displayed on an electrically controlled display such as an LCD.
Incidentally, in the above embodiment, in order to define the indicator means of the game device, a specific visual means of displaying the N digits of a modulo-M number is described. However, such indicator means clearly need not be visual. The indication means could be auditory, such as by a speaker playing a sound that correlates to a digit's value. Alternatively, the indication means could be by sense of touch, for example a vibration motor or other transducer indicating a digit's state by a pattern or intensity of transduced vibration.
Incidentally, in the above embodiment, an electrical hardware system in
Further, in the above embodiment, a device with the single purpose of a puzzle game is described. However, clearly such a puzzle game could be included as part of some more complex device—for example, an embodiment whereupon solving the puzzle some larger goal is achieved, such as unlocking a lock or other game mode or triggering some mechanical action (such as the opening of a box with a prize or another game inside).
Incidentally, in the above embodiment, a specific means of associating the puzzle game side and corresponding digit in Table 2 is presented. However, options to make this association less abstract may be added such as labeling one or more sides, either directly by its numeric place in the N-digit number or by unique symbol.
Incidentally, in the above embodiment, one specific means of executing the software flow shown in
Incidentally, in the above embodiment, a specific software flow shown in
Incidentally, in the above embodiment, a standalone game device is described. However clearly a means of communicating with one or more other secondary electronic devices may be added. Such an additional secondary device could potentially be a smart phone, tablet, PC, or smart watch, and the means of communication could, for example, be any of the following: Wi-Fi, Bluetooth, NFC, infrared, sound, Lo-Ra, or any other wired or wireless connection. Such a communication means could enable further control and/or interactivity via the additional device, provide a method of level selection, update the behavior or levels of the device, recharge the device, save and restore the game state, continue the present physical game state on a software version of the game running on the device, or be used as a conduit for internet connectivity.
Additionally, in the above embodiment, a single player game is described. However the game may be clearly modified to be played by more than one player (i.e. multiplayer), such that one device is made to be played by multiple users, or multiple devices can communicate to coordinate together through a communication means as described above. Communication may be achieved either directly (peer-to-peer), through a third device (like a cloud server, smart phone, or hub device dedicated for this purpose), or via a network of devices, playing either cooperatively or competitively.
Incidentally, in the above embodiment, a specific logic problem for the puzzle game device is described, but many variations are clearly possible:
Incidentally, in the above embodiment, the “Transform” functions detailed in Table 7 are arithmetic operations, but may also include logical operations as well, such as:
Incidentally, in the above embodiment, the “winning state” goal of the puzzle is specified as “all lights off” (octal value 000000) in
Incidentally, in the above embodiment, a specific means of programming the logic problem for the puzzle game device is described, wherein for a given level:
Additionally, software flow as depicted in
Incidentally, in the above embodiment, a specific physical hardware device dedicated to playing the puzzle game described is presented. However, as is clear to those skilled in the art, this puzzle game may be easily realized and played as a purely digital version, such as a video game played on a computer, mobile phone, or game console. In such a video game version, the puzzle may be represented onscreen in a two-dimensional or three-dimensional aspect. Input devices common to such video games such as a mouse, touchscreen, or gamepad controller may be used as means of manipulating the puzzle's orientation of configuration onscreen, as well as for as the control means changing the puzzle state.
Additionally, the puzzle game may also be played in a hybrid digital/physical game, such as an augmented reality game or virtual reality game. In such a hybrid digital/physical game, additional means of manipulating the puzzle's orientation and changing its state may include gesture and attitude controls.
In any of the video game embodiments described above, the puzzle may be included as a smaller part of a larger goal, for example as a “mini-game” included inside of a larger video game.
From the description above, a number of advantages of some embodiments of my puzzle game device become evident:
Accordingly, the reader will see that the puzzle game devices of various embodiments provide a novel challenge to players in an inexpensive configuration. Additionally, the logic problem is easily extensible so that additional products of the same puzzle game may be developed easily. Minor changes such as updating the software to provide additional levels or changing the physical housing to change the configuration, indication means, or number of game sides (and according modulo-M number of N digits), allow providing additional challenge for players with low development effort.
Furthermore, the game puzzle has the additional advantages that:
Although the description above contains many specificities, these should not be construed as limiting the scope of the embodiments but as merely providing illustrations of some of several embodiments.
Thus the scope of the embodiments should be determined by the appended claims and their legal equivalents, rather than by the examples given.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4378116 | Rubik | Mar 1983 | A |
| 4575087 | Sinclair | Mar 1986 | A |
| 4809979 | Skowronski et al. | Mar 1989 | A |
| 4957291 | Miffit et al. | Sep 1990 | A |
| 5417425 | Blumberg | May 1995 | A |
| 5564702 | Meffert | Oct 1996 | A |
| 5573245 | Weiner | Nov 1996 | A |
| 5603500 | Olti | Feb 1997 | A |
| 5992849 | Olti | Nov 1999 | A |
| 7862415 | Ghaly | Jan 2011 | B1 |
| 8876585 | Ghaly | Nov 2014 | B1 |
| 20050079477 | Diesel | Apr 2005 | A1 |
| Number | Date | Country |
|---|---|---|
| 2225246 | May 1990 | GB |
| 2008307084 | Dec 2008 | JP |
| 2008131613 | Nov 2008 | WO |
| Entry |
|---|
| Corinne Iozzio and Amber Williams, The 10 Best Toys From Toy Fair 2013, Popular Science, Feb. 13, 2013, see section “ThinkGeek Princip Interactive LED Futuro Cube”, as published online https://www.popsci.com/technology/article/2013-02/10-best-toys-toy-fair-2013/. |
