Patent Application
20130260848
Today's electronic devices provide tremendous opportunities for enjoying various types of electronic games. Further, typical devices can connect to a network (such as the Internet) to enable individuals to play games competitively with each other. While most players rely on skill and experience during competitive gameplay, a few players do engage in some form of cheating. For example, a player that violates the rules of a particular game can obtain an unfair advantage over other players that observe the rules during gameplay. Cheating reduces the overall enjoyment of gameplay for many players, and can cause some players to quit playing out of a sense of frustration.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
Techniques for implementing a guessing threshold for a game challenge are described. In at least some embodiments, a guessing threshold can specify a number of guesses that a player is permitted to make during a particular period of time. In implementations, a guess can be an incorrect solution to a game challenge, a correct solution to a game challenge that was previously provided during a game session, an incorrect solution to a game challenge that is not a legitimate solution attempt, and so on.
In at least some embodiments, if a player exceeds a guessing threshold, the player can be warned and/or penalized. For example, the player can be locked out of gameplay for a penalty period and/or the player can be docked a number of points. Thus, techniques discussed herein can serve as a deterrent to guessing during gameplay by throttling a number of guesses that a player may provide in a given period of time.
The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different instances in the description and the figures may indicate similar or identical items.
Overview
Techniques for implementing a guessing threshold for a game challenge are described. In at least some embodiments, a skill-based game can be played that presents a challenge that can be answered by providing one or more correct solutions. For example, a word game can be associated with a set of words that correspond to correct solutions to a challenge presented by the game. A player is rewarded for providing a correct solution, such as with game points, advancement in rank, and so on. The game can also be associated with a time parameter. For example, a gameplay period can be specified during which a player may attempt to provide correct solutions to a challenge. After the expiration of the gameplay period, no further attempts to provide correct solutions may be accepted, and the correct solutions provided are tallied to determine respective player's scores.
To prevent players from randomly guessing in an attempt to arrive at a correct solution, a guessing threshold can be specified that indicates a number of guesses that a player can make during a particular period of time. In implementations, a number of different parameters are specified that can be applied to an attempted solution to determine whether the attempt is a “guess.” For example, an incorrect answer can be specified as a guess. In another example, an incorrect answer that is not a legitimate solution attempt can be specified as a guess. A number of different metrics can be applied to determine whether an incorrect solution that is provided is a legitimate solution attempt, e.g., not a guess. Further ways of distinguishing between a guess and a legitimate attempt at a correct solution are detailed below.
In implementations, game rules can specify that if a player exceeds a guessing threshold, the player can be warned and/or penalized. For example, the player can be locked out of gameplay for a penalty period and/or the player can be docked a number of points. Thus, techniques discussed herein can serve as a deterrent to guessing during gameplay by setting a threshold number of guesses that a player may provide in a given period of time without incurring some form of penalty.
Having presented an overview of example implementations in accordance with one or more embodiments, consider now an example environment in which example implementations may by employed.
The browser 108 is representative of functionality (e.g., a web browser) that is configured to navigate via a network 110 to access one or more web resources 112. Although the network 110 is illustrated as the Internet, the network may assume a wide variety of configurations. For example, the network 110 may include a wide area network (WAN), a local area network (LAN), a wireless network, a public telephone network, an intranet, and so on. Further, although a single network 110 is shown, the network 110 may be configured to include multiple networks.
The browser 108, for instance, may be configured to navigate via the network 110 to interact with content available from the web resources 112 as well as communicate data to the one or more web resources 112, e.g., perform downloads and uploads. The web resources 112 may include any suitable computing resource that is configured to provide content that is accessible via the network 110. Examples of such content include web pages, games (e.g., online games), text content, video, audio, and so on.
The computing device 102 further includes at least one game module 114, which is representative of functionality to enable various types of games to be played via the computing device 102. Examples of such games include action games, shooters, skill-based games, educational games, role playing games, strategy games, and so on.
The game module 114 includes a game rules module 116, a game solutions module 118, and a game administrator module 120. The game rules module 116 is representative of functionality to specify various rules and parameters for gameplay for the game module 114. For example, the game rules module 116 can specify a guessing threshold, which corresponds to a number of guesses at a correct game solution that a player can provide during a particular period of time. The game rules module 116 can also specify one or more penalties that can be applied if a player exceeds the guessing threshold. Example implementations of rules, penalties, and their application are discussed in detail below.
The game solutions module 118 is representative of functionality to manage sets of correct solutions for particular games. For example, a word game can be associated with a set of correct solutions that correspond to words that are commonly recognized as valid words in a particular language. Although examples are discussed herein with reference to word and spelling games, this is not intended to be limiting. Embodiments can be utilized in wide variety of other game scenarios in which correct solutions to a challenge can be specified, such as math games, geography games, memorization games, trivia games, and so on.
In implementations, the game solutions module 118 can store sets of correct solutions for particular games. Alternatively or additionally, the game solutions module can be configured to access a remote resource that can ascertain whether a particular solution attempt is correct. For example, the game solutions module can query one of the web resources 112 with a solution attempt to determine whether the solution attempt corresponds to a correct solution.
The game administrator module 120 is representative of functionality to manage various aspects of gameplay for the game modules 114. For example, the game administrator module 120 can administer and enforce rules specified by the game rules module 116. Further, the game administrator module can manage transitions between different gameplay modes, such as the penalty mode, probationary mode, and normal gameplay mode detailed below. In at least some embodiments, the game administrator module can be configured to compare a solution attempt by a player with correct solutions indicated by the game solutions module 118, to determine whether the solution attempt corresponds to a correct game solution.
Further included in the environment 100 is a game server 122, which is representative of functionality to host and/or administer online games. For example, the game module 114 can include games that can be played in an online environment, such as between multiple players that are connected via the network 110. Thus, in at least some embodiments, the game module 114 and/or one or more of its component modules can be implemented by the game server 122 to enable games to be played online.
Having described an example environment in which the techniques described herein may operate, consider now a discussion of some example implementation scenarios in accordance with one or more embodiments.
Gameplay Scenarios
The following discussion describes some example gameplay scenarios in accordance with one or more embodiments. In portions of the following discussion, reference will be made to the environment 100 of
Also displayed is a challenge region 206, which corresponds to a region of the GUI 202 in which gameplay-related aspects can be displayed. For example, a player can enter a game solution attempt via the challenge region 206 as part of an attempt to provide a correct solution to a game challenge. In this example, a game challenge specifies that a player sequentially select letters that are adjacent to one another in the challenge region 206 to form a recognized word. Thus, the challenge region 206 includes selectable letters that can be selected to form words.
An advertising region 208 displays various types of advertising, such as advertising for an enterprise or other entity. In implementations, portions of the advertising region 208 are selectable to retrieve further information about an entity associated with the advertising region 208. For example, the advertising region 208 can display an advertisement that, when selected, initiates a navigation to a website associated with a sponsor that pays to use the advertising region 208.
Continuing to the lower portion of the scenario 200, a user selects several letters from the challenge region 206 as part of an attempt to provide a correct solution to a game challenge. In this example, the computing device 102 includes a touchscreen, and the user selects the letters via touch input using a user's hand 210. As explained below, techniques discussed herein can ascertain whether the solution attempt is correct, and can also ascertain whether the solution can be characterized as a guess for purposes of implementing techniques discussed herein.
Continuing to the lower portion of the scenario 300, the game transitions to a penalty mode in response to the user exceeding the guessing threshold. As part of the penalty mode, a penalty window 302 is displayed that includes a notification indicating that a guessing threshold has been exceeded. Further, the challenge region 206 is locked such that user input to the challenge region 206 cannot be received, e.g., as part of further attempts to enter correct solutions. In at least some embodiments, in a penalty mode the challenge region 206 can be visually obscured (e.g., blurred) such that letters, characters, and/or other visual indicia included in the challenge region are not visually discernible.
While the penalty mode can prevent a user from participating in gameplay, the advertising region 208 can remain active during a penalty mode. For example, when a game is in a penalty mode, a user may interact with an advertisement to receive more information about an advertised service and/or product. During a penalty period, for instance, a user can select a portion of the advertising region 208 to navigate to a website associated with an advertised entity.
The game remains in the penalty mode for a penalty period (e.g., 5 seconds), during which a user cannot participate in gameplay. When the penalty period expires, the game can return to a normal gameplay mode. For example, the challenge region 206 can become active such that a user may reengage in gameplay. Further, upon expiration of the penalty period, the challenge region 206 can be visually de-obscured.
In at least some embodiments, after a penalty period expires, a game can transition to a probationary gameplay mode. During a probationary gameplay mode, a user can enter a correct solution to a current game challenge to cause the game to transition to a normal gameplay mode. If a guess (e.g., an incorrect solution) is provided during the probationary gameplay mode, the game can transition back to the penalty mode. The game can remain in a probationary gameplay mode for a probationary period (e.g., four seconds), after which the game can transition to a normal gameplay mode. Thus, a game can transition from a probationary gameplay mode to a normal gameplay mode in response to a user providing a correct solution, or in response to an expiration of a probationary period. Further, a guess provided during a probationary period can cause a transition from a probationary gameplay mode to a penalty mode.
Guessing Scenarios
The following discussion describes some example guessing scenarios in accordance with one or more embodiments. In portions of the following discussion, reference will be made to the environment 100 of
As discussed above with reference to
Continuing to the lower portion of the scenario 400, a user provides input to the challenge region 402 via the user's hand 406. As part of the input, the user selects letters from the challenge region 402 according to an attempt path 408. Generally, the attempt path 408 corresponds to a sequence of letters from the challenge region 402 that are selected by the user.
As illustrated, the user has selected the letters P-O-M-O-G-R-A-N-A-T-E. In some embodiments, the attempt path 408 corresponds to an incorrect solution attempt (e.g., a guess), since the selected letters do not correspond to a correct spelling of a recognized word. For example, the user has replaced the first “E” in “POMEGRANATE” with an “O,” which is an incorrect spelling of the word.
Some embodiments, however, can ascertain that significant portions of the attempt path 408 overlap with a known correct solution, e.g., the known solution “pomegranate” indicated by the solution path 404. Based on this overlap, techniques can characterize the attempt path 408 as a legitimate solution attempt, and thus not a guess. Accordingly, in such embodiments, the user attempt that generated the attempt path 408 will not counted as a guess for purposes of determining whether a user has exceeded a guessing threshold.
Techniques discussed herein can utilize a number of different metrics for determining whether an incorrect solution attempt is a guess, or is a legitimate solution attempt. For example, with reference to games that involve word solutions (e.g., spelling games, trivia games, and so on), a spelling overlap threshold can be specified that corresponds to a percentage of overlap between a correct solution and a solution attempt. The spelling overlap threshold can correspond to a percentage of letters in a solution attempt that correspond to letters in a correct solution, both with respect to the letters themselves and their relative positions in the correct solution. For instance, a spelling overlap threshold of 80% can specify that if at least 80% of the letters in a solution attempt correctly correspond to letters in a correct solution, the solution attempt is not characterized as a guess. With reference to scenario 400, the user attempt at a correct solution has correctly specified 10 out of 11 letters, which corresponds to approximately 91% of the correct letters. Thus, the user's solution attempt can be characterized as a legitimate solution attempt, and thus not a guess. This spelling overlap threshold in presented for purposes of example only, and a variety of different thresholds can be specified in accordance with the claimed embodiments.
Embodiments can consider the overlap of a number of different character types, such as letters, numbers, symbols, and so on. For example, for games that utilize numeric solutions (e.g., math games), a threshold overlap can be defined with reference to an overlap of numbers between a solution attempt and a known correct solution. Additionally or alternatively, a proximity threshold can be defined that specifies a proximity to a correct numeric answer. For example, if a solution attempt is determined to be within 5% of a correct numeric answer, the solution attempt can be considered to overlap with the correct numeric answer. Thus, the solution attempt can be considered a legitimate solution attempt.
Another example metric considers a physical input path that corresponds to a solution attempt as compared to a path that corresponds to a correct solution. For example, a path overlap threshold can be specified that corresponds to a percentage of overlap between a correct solution path and a solution attempt path. If the solution attempt path meets and/or exceeds the path overlap threshold, the solution attempt can be characterized as a legitimate solution attempt, e.g., not a guess.
In implementations, path overlap can include a permitted path deviation with respect to a mean value defined by a correct solution path. For example, techniques can consider distance between paths in units such as centimeter, millimeter, and so on. For instance, a threshold average distance between a physical input path that corresponds to a solution attempt and a path that corresponds to a correct solution can be specified, e.g., 10 millimeters. The distance between points on a correct solution path and closest points on a solution attempt path can be calculated and averaged. If the average distance between the points on the solution attempt path and the points on the correct solution path does not exceed the threshold average distance, the solution attempt path can be considered to overlap. Thus, the solution attempt that generated the solution attempt path can be characterized as a legitimate solution attempt, e.g., not a guess.
While examples are discussed with reference to a difference between paths in terms of physical distance, implementations may also utilize other distance metrics. For example, consider a scenario where a correct solution path (e.g., the solution path 404) is defined with reference to a pixel path on a display screen that corresponds to a correct solution. The pixel path, for instance, can be defined with reference to (x, y) values for pixels that correspond to the correct solution path. If a solution attempt pixel path corresponds to the correct solution pixel path within a permitted pixel deviation from the correct solution pixel path, the solution attempt pixel path can be considered to overlap with the correct solution pixel path. In implementations, the permitted pixel deviation can be defined with respect to a number of pixels (e.g., 50 pixels) that a pixel value for a point on a solution attempt pixel path deviates from a pixel point (e.g., the closest pixel point) on a correct solution pixel path. The following implementation scenario discusses example ways of determining whether a solution attempt path sufficiently overlaps with a correct solution path to be considered a legitimate solution attempt.
Continuing to the lower portion of the scenario 500, the attempt path 408 is compared to the path threshold 502. For example, a determination is made as to which points along the attempt path 408 fall within the bounds of the path threshold 502. In implementations, points along the attempt path 408 that fall within the path threshold 502 can be considered to overlap with the path threshold 502.
As referenced above, a path overlap threshold can be specified to aid in determining whether a solution attempt is a guess or a legitimate solution attempt. The path overlap threshold can specify a threshold amount of a solution attempt path that is to overlap with a correct solution path for the solution attempt path to be considered a legitimate solution attempt. If a solution attempt path does not meet and/or exceed a correct solution path, the solution attempt can be considered a guess. As illustrated in the scenario 500, significant portions of the attempt path 408 overlap with the path threshold 502. Some portions, however, do not. For example, a portion 504 and a portion 506 of the attempt path 408 do not overlap with the path threshold 502.
Further to the scenario 500, techniques determine that the attempt path 408 exceeds the path overlap threshold, and thus is considered a legitimate solution attempt. For example, the number of pixels of the attempt path 408 that are inside of the path threshold 502 can be compared with a total number of pixels for the attempt path 408 to calculate a total path overlap. In this example, for instance, a path overlap threshold of 80% can be specified. For example, if an overlap for an attempt path falls below the overlap threshold of 80%, the attempt path can be considered a guess. In this example, techniques determine that 85% of the attempt path 408 overlaps with the path threshold 502. Thus, the attempt path 408 exceeds the path overlap threshold, and thus is considered a legitimate solution attempt.
These example ways of determining whether a solution attempt is a legitimate solution attempt, or a guess, are presented for purposes of illustration only. A wide variety of different techniques, however, can be implemented to determine whether a solution attempt is a legitimate solution attempt or a guess while remaining within the spirit and scope of the claimed embodiments.
Having discussed some example implementation scenarios, consider now some example procedures in accordance with one or more embodiments.
The following discussion describes example procedures for providing input data type profiles in accordance with one or more embodiments. In portions of the following discussion, reference will be made to the environment 100 of
Step 602 determines that the solution attempt is a guess. Example ways of determining whether a solution attempt is a guess are discussed above and below. Step 604 ascertains whether the guessing threshold is exceeded. As discussed elsewhere herein, the guessing threshold can specify a number of guesses that can be entered during a particular period of time. Thus, a guessing threshold can include both a guess count and an accrual period during which guesses are counted toward the guess count. For example, the guessing threshold can specify a guess count of five guesses during a three second accrual period. If more than five guesses are accrued during a particular three second interval, the guessing threshold has been exceeded. A variety of other guess amounts and time periods can be utilized in accordance with the claimed embodiments.
In implementations, if a user provides a correct solution after the user has begun accruing guesses, a guess count can be reset to zero. For example, if during an accrual period a user provides two solution attempts that are determined to be guesses, the user accrues two guesses towards a guessing threshold. If the user then provides a correct solution during the accrual period, the guess count can be reset from two to zero. Further, if an accrual period expires with no guesses being detected, a guess count can be reset to zero.
If the guessing threshold has been exceeded (“Yes”), step 606 transitions to a penalty mode. For example, a penalty notification (e.g., the penalty window 302) can be presented, and/or a user can temporarily be prevented from participating in gameplay, e.g., during a penalty period. If the guessing threshold has not been exceeded (“No”), the method returns to step 600.
Step 700 receives an indication that a penalty period has expired. In implementations, the penalty period refers to a period of time during which a game remains in a penalty mode. Step 702 transitions to a probationary mode. As discussed above, a probationary mode can unlock gameplay functionality that was locked during a penalty period such that a user can engage in gameplay, e.g., provide solution attempts.
Step 704 determines whether a probationary period has expired. As referenced above, a probationary period is a specified period of time that occurs after a penalty period. For example, the probationary period can be two seconds, three seconds, and so on. For example, a timer can be initiated when the probationary period begins. When the timer expires, a notification can be generated that the probationary period has expired.
If the probationary period has expired (“Yes”), step 706 transitions to normal gameplay. For example, a guess count can be reset, and a user can provide solution attempts to a game challenge.
If the probationary period has not expired (“No”), step 708 ascertains whether a solution attempt is received during a probationary period. If a solution attempt is not received during the probationary period (“No”), the method returns to step 704.
If a solution attempt is received during the probationary period (“Yes”), step 710 ascertains whether the solution attempt corresponds to a correct solution. If the solution attempt corresponds to a correct solution (“Yes”), step 712 ascertains whether the correct solution was previously provided during a current game session. If the correct solution was not previously provided during a current game session (“No”), step 706 transitions to normal gameplay. Thus, a user can be credited for a correct answer, and the game can return to a normal gameplay mode.
If the correct solution was previously provided during a current game session (“Yes”), step 714 transitions to a penalty mode. As discussed elsewhere herein, in certain scenarios a solution attempt that corresponds to a correct solution that was previously provided during a current game session can be characterized as a guess.
Returning to step 710, if the solution attempt does not correspond to a correct solution, step 716 determines whether the solution attempt is a guess. Techniques discussed herein can be used to analyze the solution attempt to ascertain whether the solution attempt is a guess. As detailed elsewhere herein, certain incorrect solution attempts can be characterized as a legitimate solution attempt, e.g., a “non-guess.”
If the solution attempt is a guess (“Yes”), step 714 transitions to a penalty mode. In implementations, when the game transitions to a penalty mode, a game will wait for a penalty period to expire. After the penalty period expires, the method described with reference to
Step 800 ascertains whether a solution attempt from a user corresponds to a correct solution. For example, the game solutions module 118 can compare the solution attempt to correct game solutions to determine whether the solution attempt matches a correct game solution.
If the solution attempt corresponds to a correct solution (“Yes”), step 802 determines whether the correct solution was previously provided by the user during a current gameplay session. For example, a user can re-enter a correct solution that the user previously entered during the current gameplay session.
If the correct solution was not previously provided during the current gameplay session (“No”), step 804 credits the user for a correct solution. For example, the user can be credited with points and/or other type of award for providing the correct solution.
If the correct solution was previously provided during the current gameplay session (“Yes”), step 806 ascertains whether at least one guess has been accrued towards a guessing threshold. For example, the game administrator module 120 can determine whether a previous solution attempt was characterized as a guess. If at least one guess has not been accrued (“No”), step 808 ascertains that the solution attempt is not a guess.
If at least one guess has been accrued (“Yes”), step 810 ascertains that the solution attempt is a guess. Thus, in implementations a correct solution that is repeated during a gameplay session does not initiate the accrual of guesses that count towards a guessing threshold. However, if one or more guesses have already been accrued, a repeated correct solution can be counted as a further guess in accruing guesses towards to guessing threshold.
Returning to step 800, if the solution attempt does not correspond to a correct game solution (“No”), step 812 determines whether the solution attempt is a legitimate solution attempt. Example ways of determining whether an incorrect solution attempt is a legitimate solution attempt are discussed elsewhere herein. If the solution attempt is a legitimate solution attempt (“Yes”), step 808 ascertains that the solution attempt is not a guess. If the solution attempt is not a legitimate solution attempt (“No”), step 810 ascertains that the solution attempt is a guess.
Step 900 compares an incorrect solution attempt with a known correct solution. For example, an incorrect solution attempt can be compared with a set of known correct solutions. The game solutions module 118, for instance, can compare an incorrect solution attempt provided to one of the game modules 114 to a set of known correct solutions associated with a game challenge for the game module 114.
Step 902 ascertains whether the incorrect solution attempt exceeds an overlap threshold for a legitimate solution attempt. As discussed above, the overlap threshold can be based on how much an incorrect solution attempt overlaps with a known correct solution. If the incorrect solution attempt exceeds the overlap threshold (“Yes”), step 904 determines that the incorrect solution attempt is a legitimate solution attempt. As referenced above, a legitimate solution attempt can be characterized as a “non-guess.”
If the incorrect solution attempt does not exceed the overlap threshold (“No”), step 906 determines that the incorrect solution attempt is a guess. Thus, in implementations the incorrect solution attempt can be counted as a guess for purposes of accruing guesses towards a guessing threshold.
Having discussed some example procedures, consider now a discussion of an example system and device in accordance with one or more embodiments.
The example computing device 1002 as illustrated includes a processing system 1004, one or more computer-readable media 1006, and one or more Input/Output (I/O) Interfaces 1008 that are communicatively coupled, one to another. Although not shown, the computing device 1002 may further include a system bus or other data and command transfer system that couples the various components, one to another. A system bus can include any one or combination of different bus structures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and/or a processor or local bus that utilizes any of a variety of bus architectures. A variety of other examples are also contemplated, such as control and data lines.
The processing system 1004 is representative of functionality to perform one or more operations using hardware. Accordingly, the processing system 1004 is illustrated as including hardware element 1010 that may be configured as processors, functional blocks, and so forth. This may include implementation in hardware as an application specific integrated circuit or other logic device formed using one or more semiconductors. The hardware elements 1010 are not limited by the materials from which they are formed or the processing mechanisms employed therein. For example, processors may be comprised of semiconductor(s) and/or transistors (e.g., electronic integrated circuits (ICs)). In such a context, processor-executable instructions may be electronically-executable instructions.
The computer-readable media 1006 is illustrated as including memory/storage 1012. The memory/storage 1012 represents memory/storage capacity associated with one or more computer-readable media. The memory/storage 1012 may include volatile media (such as random access memory (RAM)) and/or nonvolatile media (such as read only memory (ROM), Flash memory, optical disks, magnetic disks, and so forth). The memory/storage 1012 may include fixed media (e.g., RAM, ROM, a fixed hard drive, and so on) as well as removable media (e.g., Flash memory, a removable hard drive, an optical disc, and so forth). The computer-readable media 1006 may be configured in a variety of other ways as further described below.
Input/output interface(s) 1008 are representative of functionality to allow a user to enter commands and information to computing device 1002, and also allow information to be presented to the user and/or other components or devices using various input/output devices. Examples of input devices include a keyboard, a cursor control device (e.g., a mouse), a microphone (e.g., for voice recognition and/or spoken input), a scanner, touch functionality (e.g., capacitive or other sensors that are configured to detect physical touch), a camera (e.g., which may employ visible or non-visible wavelengths such as infrared frequencies to detect movement that does not involve touch as gestures), and so forth. Examples of output devices include a display device (e.g., a monitor or projector), speakers, a printer, a network card, tactile-response device, and so forth. Thus, the computing device 1002 may be configured in a variety of ways as further described below to support user interaction.
Various techniques may be described herein in the general context of software, hardware elements, or program modules. Generally, such modules include routines, programs, objects, elements, components, data structures, and so forth that perform particular tasks or implement particular abstract data types. The terms “module,” “functionality,” and “component” as used herein generally represent software, firmware, hardware, or a combination thereof. The features of the techniques described herein are platform-independent, meaning that the techniques may be implemented on a variety of commercial computing platforms having a variety of processors.
An implementation of the described modules and techniques may be stored on or transmitted across some form of computer-readable media. The computer-readable media may include a variety of media that may be accessed by the computing device 1002. By way of example, and not limitation, computer-readable media may include “computer-readable storage media” and “computer-readable signal media.”
“Computer-readable storage media” may refer to media and/or devices that enable persistent and/or non-transitory storage of information in contrast to mere signal transmission, carrier waves, or signals per se. Thus, computer-readable storage media does not include signal bearing media. The computer-readable storage media includes hardware such as volatile and non-volatile, removable and non-removable media and/or storage devices implemented in a method or technology suitable for storage of information such as computer readable instructions, data structures, program modules, logic elements/circuits, or other data. Examples of computer-readable storage media may include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, hard disks, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other storage device, tangible media, or article of manufacture suitable to store the desired information and which may be accessed by a computer.
“Computer-readable signal media” may refer to a signal-bearing medium that is configured to transmit instructions to the hardware of the computing device 1002, such as via a network. Signal media typically may embody computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as carrier waves, data signals, or other transport mechanism. Signal media also include any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media.
As previously described, hardware elements 1010 and computer-readable media 1006 are representative of instructions, modules, programmable device logic and/or fixed device logic implemented in a hardware form that may be employed in some embodiments to implement at least some aspects of the techniques described herein. Hardware elements may include components of an integrated circuit or on-chip system, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), and other implementations in silicon or other hardware devices. In this context, a hardware element may operate as a processing device that performs program tasks defined by instructions, modules, and/or logic embodied by the hardware element as well as a hardware device utilized to store instructions for execution, e.g., the computer-readable storage media described previously.
Combinations of the foregoing may also be employed to implement various techniques and modules described herein. Accordingly, software, hardware, or program modules and other program modules may be implemented as one or more instructions and/or logic embodied on some form of computer-readable storage media and/or by one or more hardware elements 1010. The computing device 1002 may be configured to implement particular instructions and/or functions corresponding to the software and/or hardware modules. Accordingly, implementation of modules that are executable by the computing device 1002 as software may be achieved at least partially in hardware, e.g., through use of computer-readable storage media and/or hardware elements 1010 of the processing system. The instructions and/or functions may be executable/operable by one or more articles of manufacture (for example, one or more computing devices 1002 and/or processing systems 1004) to implement techniques, modules, and examples described herein.
As further illustrated in
In the example system 1000, multiple devices are interconnected through a central computing device. The central computing device may be local to the multiple devices or may be located remotely from the multiple devices. In one embodiment, the central computing device may be a cloud of one or more server computers that are connected to the multiple devices through a network, the Internet, or other data communication link.
In one embodiment, this interconnection architecture enables functionality to be delivered across multiple devices to provide a common and seamless experience to a user of the multiple devices. Each of the multiple devices may have different physical requirements and capabilities, and the central computing device uses a platform to enable the delivery of an experience to the device that is both tailored to the device and yet common to all devices. In one embodiment, a class of target devices is created and experiences are tailored to the generic class of devices. A class of devices may be defined by physical features, types of usage, or other common characteristics of the devices.
In various implementations, the computing device 1002 may assume a variety of different configurations, such as for computer 1014, mobile 1016, and television 1018 uses. Each of these configurations includes devices that may have generally different constructs and capabilities, and thus the computing device 1002 may be configured according to one or more of the different device classes. For instance, the computing device 1002 may be implemented as the computer 1014 class of a device that includes a personal computer, desktop computer, a multi-screen computer, laptop computer, netbook, and so on.
The computing device 1002 may also be implemented as the mobile 1016 class of device that includes mobile devices, such as a mobile phone, portable music player, portable gaming device, a tablet computer, a multi-screen computer, and so on. The computing device 1002 may also be implemented as the television 1018 class of device that includes devices having or connected to generally larger screens in casual viewing environments. These devices include televisions, set-top boxes, gaming consoles, and so on.
The techniques described herein may be supported by these various configurations of the computing device 1002 and are not limited to the specific examples of the techniques described herein. For example, functionalities discussed with reference to the computing device 102 and/or the game module 114 may be implemented all or in part through use of a distributed system, such as over a “cloud” 1020 via a platform 1022 as described below.
The cloud 1020 includes and/or is representative of a platform 1022 for resources 1024. The platform 1022 abstracts underlying functionality of hardware (e.g., servers) and software resources of the cloud 1020. The resources 1024 may include applications and/or data that can be utilized while computer processing is executed on servers that are remote from the computing device 1002. Resources 1024 can also include services provided over the Internet and/or through a subscriber network, such as a cellular or Wi-Fi network.
The platform 1022 may abstract resources and functions to connect the computing device 1002 with other computing devices. The platform 1022 may also serve to abstract scaling of resources to provide a corresponding level of scale to encountered demand for the resources 1024 that are implemented via the platform 1022. Accordingly, in an interconnected device embodiment, implementation of functionality described herein may be distributed throughout the system 1000. For example, the functionality may be implemented in part on the computing device 1002 as well as via the platform 1022 that abstracts the functionality of the cloud 1020.
Discussed herein are a number of methods that may be implemented to perform techniques discussed herein. Aspects of the methods may be implemented in hardware, firmware, or software, or a combination thereof. The methods are shown as a set of blocks that specify operations performed by one or more devices and are not necessarily limited to the orders shown for performing the operations by the respective blocks. Further, an operation shown with respect to a particular method may be combined and/or interchanged with an operation of a different method in accordance with one or more implementations. Aspects of the methods can be implemented via interaction between various entities discussed above with reference to the environment 100.
Techniques for implementing a guessing threshold for a game challenge are described. Although embodiments are described in language specific to structural features and/or methodological acts, it is to be understood that the embodiments defined in the appended claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claimed embodiments.
