Generating Virtual Elements and Their Cues in Fitness-Based Games

Abstract

A computer-implemented method for generating virtual elements in a fitness-based game. The method includes hosting, by a game server (200), a fitness-based game module (224) and receiving, by the game server (200), fitness data from one or more devices of a user. The method also includes generating, by one or more processors (222), within the fitness-based game module (224) a plurality of combat options based at least in part on the fitness data. The method further includes generating, by the one or more processors (222), one or more combat cues of the plurality of combat options and transmitting, by the game server (200), the combat cues to the user.

Description

[Technical field]

[0001] FIELD OF THE DISCLOSURE The present disclosure relates to gaming systems, and more particularly, to fitness-based gaming systems. [Background technology]

[0002] The gaming industry includes location-based games. Such location-based games incorporate real-world geography and the player's physical location to enhance the player's overall gaming experience. Some location-based games align certain items and / or events in the virtual world with specific locations in the real world. Other location-based games, often referred to as parallel reality games, include virtual worlds that parallel the real world. The virtual worlds can have virtual recreations of buildings, statues, objects, or other geographic elements that exist in the real world.

[0003] The fitness industry is known to incorporate various types of technology to monitor and record a performer's vitals and fitness goals. For example, there are various wearable electronic devices for recording a performer's heart rate and blood pressure. After performing a particular activity, a performer can review and share their performance, which can further encourage the performer to maintain and achieve their fitness goals through the positive reinforcement of personal and peer reviews. Summary of the Invention

[0004] In one exemplary embodiment, a computer-implemented method for generating virtual elements in a fitness-based game is provided. The method includes hosting, by a game server, a fitness-based game module, and receiving, by the game server, fitness data from one or more devices of a user. At least one of the one or more devices comprises one or more sensors configured to sense the fitness data. The method also includes generating, by the one or more processors, within the fitness-based game module, a plurality of combat options based at least in part on the fitness data. The method further includes generating, by the one or more processors, combat cues for one or more of the plurality of combat options, and transmitting, by the game server, the combat cues to the user.

[0005] In another exemplary embodiment, a computer-based system for implementing a computer-implemented method of a game is provided. The system includes a game server comprising one or more computer-readable media, one or more processors, and a network interface. The game server is configured to host a fitness-based game module and receive fitness data from one or more devices of users via the network interface. At least one of the one or more devices comprises one or more sensors configured to sense the fitness data. The game server is also configured, via the one or more processors, to generate, within the fitness-based game module, a plurality of combat options based at least in part on the fitness data. The game server is further configured to generate, via the one or more processors, combat cues for one or more of the plurality of combat options and transmit, via the network interface, the combat cues to the user.

[0006] In yet another exemplary embodiment, a non-transitory computer-readable medium is provided that stores instructions that, when executed by one or more processors, cause the one or more processors to perform a method. The method includes receiving fitness data from one or more devices of a user. At least one of the one or more devices includes one or more sensors configured to sense the fitness data. The method also includes generating, within a fitness-based game module, a plurality of combat options based at least in part on the fitness data. The method further includes generating combat cues for one or more of the plurality of combat options and transmitting the combat cues to the user.

[0007] One possible advantage of the exemplary embodiments is that in-game elements may be generated using energy efficient methods to reduce operational costs.

[0008] Another possible advantage of example embodiments is that fitness data collection and / or generation of in-game elements may not occur until the player completes a fitness activity.

[0009] The embodiments illustrated herein are not limited to the precise arrangement, sequential steps, and dimensions shown. Like numbers refer to like elements throughout the drawings. The following figures: [Brief description of the drawings]

[0010] [Figure 1] 1 illustrates a computer-based system for implementing a fitness-based game, according to an exemplary embodiment of the present disclosure. [Diagram 2] 2 illustrates a game server of the computer-based system of FIG. 1; [Diagram 3] 1 illustrates a graph showing in-game element generation rates in relation to heart rate data. [Figure 4] 13 illustrates another graph showing in-game element generation rates in relation to heart rate data. [Diagram 5] 1 illustrates a summary of generated results including combat options generated by a game server. [Figure 6] 1 illustrates a time-independent combat queue of combat options generated by a game server. [Figure 7] 1 illustrates a time-dependent combat queue of combat options generated by a game server. [Figure 8] 1 shows a flowchart of a computer-implemented method for generating in-game elements. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] FIG. 1 illustrates an exemplary computer-based system 100 for implementing a fitness-based game. The system 100 may include a network 102, devices 104A, 104B, 104C, 106 of players, i.e., users, of the fitness-based game, and a game server 200 connected to the devices 104A-C, 106 via the network 102. The system 100 may include a fitness game application having an integrated video game downloadable to one or more of the devices 104A-C, 106. The system 100 may encourage exercise by integrating a video game into the overall fitness process. It is contemplated that in other embodiments, the system 100 may include different or additional elements than those illustrated in FIG. 1.

[0012] The system 100 relates exercise to increased generation of in-game elements when playing a video game. The system 100 may increase the chances of generating combat options when a player exercises, and accordingly encourage the player to exercise more frequently. For example, the system 100 may generate combat options that may include various monsters to fight. As used herein, "combat options" may refer to options to fight, i.e., virtually fight, one or more in-game characters, such as monsters, with the goal of capturing and collecting the monsters. As used herein, "monsters" may refer to any in-game character.

[0013] During the time that the monsters are not exercising and generating fitness data, the monsters can battle to capture other monsters. In this manner, the fitness activity or fitness session is not interrupted because the video game play session occurs at a separate time from the fitness activity. Because the video game fitness system 100 is not location-based, but instead fitness-based, there is no reason for a player to be in the same physical and / or virtual location associated with other players, monsters, or other in-game elements. Thereby, a player may not be advantaged or disadvantaged by residing in and / or traveling to any particular location.

[0014] The network 102 may be any type of communications network, such as a local area network (LAN), a wide area network (WAN), a public network, and / or any combination thereof. In general, communications between the game server 200 and the various devices 104A-C, 106 may occur over any desired network interface, using any type of wireless connection, and using a variety of communications protocols (e.g., UDP, TCP / IP, HTTP, S1v1TP, FTP), encodings or formats (e.g., HTML, JSON, XML), or protection schemes (e.g., VPN, Secure HTTP, SSL).

[0015] The devices 104A-C and / or the device 106 may be connected to the network 102. The devices 104A-C, 106 may be associated with one or more players and / or with each other. A single user may have two or more devices 104A, 106, which may be associated with each other, as shown in phantom in FIG. 1. Each device 104A, 106 may communicate individually with the game server 200 via the network 102. Additionally or alternatively, one device 104A may communicate with the network 102 while another additional device 106 may communicate with the device 104A but not directly with the network 102. Thus, at least one of the devices 104A, 106, or both, may communicate with the game server 200, e.g., one or more components thereof, via the network 102.

[0016] The various client devices 104A-C, 106 may or may not be identical to one another. By way of example only, a player may have a smartphone 104A and a wearable device 106, such as a smart watch, connected to the smartphone 104A and / or the network 102. It should be understood that a player may have only smartphones 104A-C, may have both smartphones 104A-C and wearable device(s) 106, or may have only wearable device 106.

[0017] As illustrated with respect to device 104A in FIG. 1, each device 104A-C may include input / output devices 108, such as a display screen, a speaker, local data storage 110, one or more sensors 112, one or more fitness applications 114, a notification module 116, and a fitness game application 118.

[0018] One or more devices 106 associated with a user may include, in addition to or separate from devices 104A-C, input / output devices, e.g., display screens, lights, speakers, etc., local data storage, one or more sensors, a fitness application, which may or may not include a fitness data collection module, a notification module, and / or a fitness game application. The various components of device 106 may be in the form of, or function similarly to, the various components of devices 104A-C, as described herein. The additional device 106 may or may not include a fitness game application 118. For example, if device 104A is in the form of a smartphone 104A and device 106 is in the form of a wearable device 106, then wearable device 106 may not include a fitness game application 118 in addition to smartphone 104A. Devices 104A-C, 106 may also include other components known to those skilled in the art. Therein, devices 104A-C, 106 may include any desired hardware and / or software for generating fitness data.

[0019] It should be understood that each user may have one or more devices 104A-C, 106, which may be fixed, portable, and / or wearable. As mentioned above, the devices 104A-C may be in the form of a smartphone, and the devices 106 may be in the form of a wearable device, such as a smart watch or smart shoes. However, the devices 104A-C, 106 may also be in the form of a computer, tablet, navigation system, handheld GPS system, user equipment (UE), portable gaming device, digital music player, media player head mounted display (HMD), virtual and / or augmented reality headset, smart glasses, smart clothing, smart shoes, data collection implants, and / or other suitable data collection electronic devices. It is contemplated that the devices 104A-C may not include sensors 112 for sensing fitness data. Thus, such devices may still include a fitness game application 118, even though the devices do not include sensors 112. For example, one device, such as a smartphone, computer, or game console, may be used to play a fitness-based game, and one or more other devices, such as a wearable device, may include sensors 112 for sensing fitness data.

[0020] Local data storage 110 may be one or more computer-readable media configured to store data. For example, local data storage 110 may store fitness data generated by any desired fitness application and / or fitness collection module. Local data storage 110 may also store any other suitable data. Additionally, data may be stored elsewhere (e.g., in a distributed database) and accessed remotely via network 102.

[0021] The one or more sensors 112 integrated within the devices 104A-C and / or the device 106 may include location sensors in the form of a positioning device, a speed sensor, an accelerometer, a gyroscope, an altimeter, a pedometer, and / or a heart rate sensor. For example, the positioning device may monitor the location of the smartphone and / or the wearable device 104A-C, 106. In this embodiment, the one or more sensors 112 include a positioning device, a pedometer, and a heart rate monitor. However, the one or more sensors 112 may include other and / or additional sensors, as will be appreciated by those skilled in the art.

[0022] The positioning device may be any device or circuit, for example, the positioning device may comprise a GPS system, a Galileo positioning system, a Global Navigation Satellite System (GLONASS), a Beidou navigation satellite, or a positioning system. As the player moves with the device 104A-C, 106 in the physical world, the positioning device may track the player's position and provide player location data to the fitness game application 118.

[0023] Fitness application 114 monitors and collects fitness data associated with one or more fitness activities of a player. Fitness application 114 may be part of the device's 104A-C, 106 operating system or additional software installed by the player (e.g., an application installed for use with a wearable device such as a smart watch or fitness tracker). Fitness application 114 may or may not include a fitness data collection module.

[0024] Fitness data may be collected by any suitable fitness application(s). Fitness data may include activity time, i.e., the time a fitness activity begins and ends, the user's location, cadence, distance traveled, the player's heart rate, and / or time spent exercising based on high heart rate levels, both low and high intensity, compared to the player's resting heart rate and / or optimal heart rate. Fitness data may also include values ​​of variables over time, such as periodic (e.g., every few seconds or every minute) measurements of heart rate or the time spent continuously performing a specified exercise. Fitness data may include any data associated with a fitness activity. In addition, fitness data may include any data associated with the player's physical health, regardless of whether the data is associated with a fitness activity or a non-fitness activity or the player's normal resting state. Fitness data may be raw data and / or pre-processed data from one or more fitness applications 114.

[0025] The notification module 116 notifies or otherwise presents information to the player via various visual and / or audible signals known to those of skill in the art. The notification module 116 may comprise any desired software and / or hardware.

[0026] The fitness game application 118 executed by the devices 104A-C, 106 provides an interface between the players and the video game server 200. The fitness game application 118 may include a fitness collection module 120, a fitness data extraction module 122, a notification module 124, and / or a native plug-in 126. In some embodiments, the fitness game application 118 may not include a native plug-in 126, in which the fitness game application 118 may receive fitness data directly from the fitness application(s) 114 of the devices 104A-C and / or device 106.

[0027] The fitness collection module 120 collects fitness data. The fitness collection module 120 may be part of the fitness game application 118. The fitness collection module 120 may be separate from and / or at least partially integrated with other fitness collection modules of the devices 104A-C, 106, in which the fitness collection module 120 may be part of the fitness game application 118, or both the fitness application 114 and the fitness game application 118. It should be noted that the fitness data may be collected by any suitable fitness monitoring application in communication with one or more sensors 112 of the devices 104A-C, 106.

[0028] The fitness data extraction module 122 extracts the fitness data generated by the fitness collection module 120 and sends it to the local data storage 110 and / or the game server 200. The fitness data extraction module 122 may be part of the fitness game application 118. In some embodiments, the fitness data extraction module 122 performs a process that periodically checks for updated fitness data. The fitness data extraction module 122 may filter the fitness data based on the source of the fitness data. The fitness data extraction module 122 sends the fitness data, subject to any applied filtering, along with an identifier for the corresponding player to the game server 200.

[0029] In some embodiments, the fitness data extraction module 122 may extract fitness data according to one or more parameters. For example, the fitness data extraction module 122 may continuously extract fitness data at a predetermined interval so that the game server 200 may generate in-game elements in real time. In addition, for example, the fitness data extraction module 122 may extract fitness data only after the sensor(s) 112 of the devices 104A-C, 106 register a particular heart rate of the player, such as the player's resting heart rate. The fitness data extraction module 122 may also extract fitness data upon or immediately after downloading the fitness game application 118. The game server 200 may determine the player's resting heart rate, e.g., 50-80 bpm, via the fitness collection module 120 and the fitness extraction module 122. Alternatively, the game server 200 may store an average heart rate instead of the player's particular resting heart rate. Thereby, the fitness game application 118 and / or game server 200 may not extract fitness data and / or generate in-game content based on the fitness data without first verifying that the player has completed the exercise. Thus, players' mental health and / or safety may be enhanced by eliminating various distractions during their fitness activities.

[0030] The notification module 124 of the fitness game application 118 may be separate from the notification module 116 of the device 104A-C, 106. Alternatively, the notification module 124 of the fitness game application 118 may be in the form of, or at least partially incorporated into, the notification module 116 of the device 104A-C, 106. As shown, the fitness game application 118 includes a notification module 124 that communicates with the notification module 116 of the device 104A-C, 106. The notification module 124 may receive communications from the game server 200. For example, the game server 200 may communicate with the notification module 124 when the fitness data provided by the fitness data extraction module 122 reaches a predetermined level. The notification module 124 may communicate various messages in various manners known to those skilled in the art.

[0031] The fitness game application 118 also presents a player interface of the game on the display screen(s) of the device 104A-C, 106. The fitness game application 118 thereby enables the player to interact with the game to perform various game activities. The fitness game application 118 also controls various other outputs to enable the player to interact with the video game server 200 without the player needing to see a display screen. For example, the fitness game application 118 may control various sounds, vibrations, or other notifications. The fitness game application 118 accesses game data to provide the player with an accurate representation of the current state of the game. The fitness game application 118 receives and processes player input and provides updates to the game server 200 over the network 102.

[0032] In some embodiments, players must download the fitness game application 118 of the video game fitness system 100 onto their devices 104A-C and / or 106. As a result, the devices 104A-C, 106 can execute software enabling them to monitor the player and collect fitness data. Players can play the game after monsters and / or combat options have been generated in accordance with the video game fitness system 100.

[0033] Devices 104A-C and / or devices 106, for example, their fitness data extraction modules 122, can retrieve fitness data in foreground and / or background processes. Therewith, continuously, in real-time, and / or later in a bulk communication after pre-set conditions, fitness data extraction module 122 may send fitness data to game server 200. Foreground processes are processes that a player is actively aware of while using fitness game application 118, while background processes perform operations that are not directly noticed by the player. In the foreground process, a player can have fitness game application 118 open on his / her device 104A-C, 106 and visually see updates related to his / her activity.

[0034] In a background process, the player may lock the display screen while still having the fitness game application 118 open and / or close the fitness game application 118. The background process continues to collect fitness data. For example, one or more fitness applications 114 may continue to collect fitness data, and the fitness data extraction module 122 may receive the fitness data in response.

[0035] As an example, the fitness game application 118 may use the native plugin 126 to handle fitness data collection. In this manner, the native plugin 126 may continue to run in the background to collect the necessary fitness data. The native plugin 126 may communicate with the game server 200 when the fitness game application 118 is open. When the devices 104A-C, 106 and the fitness game application 118 are open, the fitness game application 118 may be considered to be running in a foreground mode.

[0036] For example, when a player has the fitness game application 118 open and is walking around, the fitness game application 118 itself may collect fitness data. However, native plug-ins 126 may be used to collect fitness data in the foreground and background and then send the fitness data to the game server 200 for processing.

[0037] In some embodiments, the native plugin 126 accumulates the data in the background and sends it to the game server 200 for processing in the background. The player will simply see the updated information when they reopen the fitness game application 118. According to other embodiments, the native plugin 126 accumulates the data in the background and then when the fitness game application 118 is opened, the native plugin 126 hands the data off to the fitness game application 118, which in the foreground itself sends the data to the game server 200 to be processed.

[0038] 2-7, the game server 200 includes a network interface 202, a computer-readable storage medium 210, such as a memory, and a processing unit 220. The game server 200 hosts fitness-based games, receives and analyzes input, e.g., fitness data, and provides various game status updates to at least one of the player's devices 104A-C, 106. In some embodiments, the game server 200 may include different or additional elements, and its various functions may be distributed among its various elements in a manner different than described herein.

[0039] The network interface 202 establishes communications between the game server 200 and the network 102. The network interface 202 may include any suitable components for interfacing with one or more networks, including, for example, a transmitter, a receiver, a port, a controller, an antenna, or other suitable components.

[0040] The memory 210 stores game data from players and collected fitness data. The memory 210 may generally include any suitable computer-readable medium, temporary or non-transitory, for storing instructions. The memory 210 includes a game database 212 and a fitness database 214. The game database 212 and / or the fitness database 214 may be part of the game server 200 or separate from the game server 200 and thus may be accessed remotely over the network 102. The game database 212 may store information associated with fitness-based games. The fitness database 214 may store information associated with fitness and non-fitness activities of players. In some embodiments, the memory 210 may include a single database, such as a game and fitness database, that stores both fitness and game data.

[0041] The processing unit 220 generally includes one or more processors 222 for executing computer-readable instructions. The processing unit 220 may further include a universal game module 224, a fitness data processing module 226, an element generation module 228, and a notification generation module 230.

[0042] The one or more processors 222 may comprise any desired software and hardware. The one or more processors 222 may perform various functions of the processing unit 220 described herein.

[0043] The universal game module 224 hosts and generates game content for the player. The universal game module 224 may be referred to as a fitness-based game module, where the generated virtual content that affects the game is generated based at least in part on the player's fitness activity in the real world. The universal game module 224 may access and store data in the game database 212 and the fitness database 214. The universal game module 224 may further be responsible for device connectivity and its security. It should be noted that the fitness data processing module 226, the element generation module 228, and / or the notification generation module 230 may be part of the universal game module 224 or may be separate from the universal game module 224.

[0044] The fitness data processing module 226 may receive fitness data associated with a player's fitness activity via various sensors 112 of the player's devices 104A-C, 106. For example, the fitness data processing module 226 may retrieve the fitness data via a background process of one or more of the player's devices 104A-C, 106. The fitness data processing module 226 may also process the fitness data. Among other things, the fitness data processing module 226 may determine the type of fitness activity, the duration of the fitness activity, the player's resting heart rate, the player's resting heart rate range, the average heart rate, an optimal heart rate or optimal heart rate range for one or more players, the player's steps during the fitness activity, the player's average steps within a particular period of time, the distance traveled by the player, and / or any other desired fitness metrics associated with the player's fitness activity.

[0045] For example, given a player's heart rate, the fitness data processing module 226 may determine one or more parameters related to the duration of high heart rate, heart rate intensity, and / or optimal heart rate for subsequently generating combat options. The optimal heart rate may be a pre-calculated parameter or may be calculated individually for each player by evaluating the player's resting and active heart rates. The fitness data processing module 226 may determine a primary parameter, such as whether the player's heart rate is active, e.g., 80-220 bpm, and a secondary parameter, such as the player's particular heart rate at a given time during a fitness activity, which together may be used to generate in-game content. The secondary parameter may be matched to a multiplication factor that in turn increases the combat option generation rate. The fitness data processing module 226 may also determine a first factor based on the user's heart rate and a second factor based on the optimal heart rate. The optimal heart rate factor may be greater than the actual heart rate factor. For example, the game module 224 may provide a 1% chance of generating a combat option all the time the player is exercising, i.e., has a high heart rate. The fitness data processing module 226 may generate a first multiplication factor, e.g., 1.2x, based on the user's heart rate, and a second multiplication factor, e.g., 4x, based on the user's optimal heart rate, or range thereof. As described in more detail below, the factor generation module 228 then generates a greater number of combat options for the player when the player spends more time at or near the optimal heart rate, as opposed to merely at a high heart rate. Therein, a greater number of combat options may be granted to players who exercise at their optimal heart rate, correspondingly, than players who exercise at a higher intensity and / or for a greater amount of time. Additionally, a decreasing number of combat options may be granted for a particular range of heart rates, such as 180 bpm to 220 bpm. Additionally, combat options may be granted for certain ranges of heart rate, still in increasing numbers but at a decreasing rate.Thus, a player who may be less physically fit may be given equal or greater combat options than a player who is more physically fit.

[0046] In addition, for example, considering the player's heart rate, the fitness data processing module 226 may determine a first coefficient for generating the number of monsters and a second coefficient for generating the rarity of the monsters. For example, the number of monsters generated may increase based on the intensity of the player's heart rate. The lower the intensity, the fewer the number of monsters, and the higher the intensity, the more the number of monsters. The rarity coefficient may remain the same as the heart rate data or may be irrelevant. Thus, the probability of receiving a higher number of rare monsters also depends on the number of monsters generated.

[0047] In addition, for example, taking into account the player's heart rate, the fitness data processing module 226 may determine one or more rarity factors based on the duration of high heart rate, heart rate intensity, and / or optimal heart. For example, the game module 224 may provide a 15% chance of generating a common monster and a 1% chance of generating a rare monster. The fitness data processing module 226 may generate a rarity multiplication factor, for example, 5x, based on the optimal heart rate. The fitness data processing module 226 may then send the rarity multiplication factor based on the optimal heart rate to the element generation module 228. It is possible that the element generation module 228 may generate a greater number of rare monsters within the combat options for the player when the player spends more time at or near the optimal heart rate, as opposed to simply a high heart rate or a greater duration of a high heart rate.

[0048] Furthermore, the fitness data processing module 226 may determine two or more rarity coefficients to finally generate the rarity of the monster. The fitness data processing module 226 may generate a first multiplication coefficient based on the duration when the player has a high heart rate and a second multiplication coefficient, or a range thereof, based on the duration when the player has an optimal heart rate. The first multiplication coefficient and the second multiplication coefficient may be weighted differently. Also, the fitness data processing module 226 may add or multiply the first and second multiplication coefficients. Then, the fitness data processing module 226 may send the first and second multiplication coefficients, or a combined coefficient therefrom, to the element generation module 228 for subsequent rarity value generation of each monster.

[0049] In addition, for example, considering the distance traveled and / or the number of steps taken by the player during the fitness activity, the fitness data processing module 226 may determine an optimal distance traveled and / or an optimal number of steps. For example, the fitness data processing module 226 may determine an average distance traveled during the fitness activity and thus generate an optimal distance traveled that varies as the player averages more or less meters traveled. Furthermore, the fitness data processing module 226 may determine two or more coefficients that influence the combat option generation. For example, the fitness data processing module 226 may determine a first coefficient based on the distance traveled, the speed, and / or the number of steps taken by the player during the fitness activity and may determine a second coefficient based on the optimal speed of the player during the fitness activity. The optimal speed coefficient may be greater than the distance traveled coefficient, the speed coefficient, and / or the number of steps coefficient. Therein, a player who achieves the optimal speed for a greater amount of time may be granted more combat options than a player who jogs the fastest and / or goes the furthest distance.

[0050] Alternatively, the fitness data processing module 226 may generate a speed factor and a distance factor. The fitness data processing module 226 may make the speed factor larger than the distance factor, so that a player moving faster, such as a player running 1 km, may be given more combat options than a player moving slower, such as a player walking 1 km. The fitness data processing module 226 may also assign a larger value to the distance factor than the speed factor, such that a player moving a longer distance at a slower pace may receive more combat options than a player moving a shorter distance at a faster pace.

[0051] The element generation module 228 may receive the fitness data from the fitness data processing module 226. The element generation module 228 may generate in-game content including various in-game elements and features. More specifically, the element generation module 228 may generate combat options and one or more combat cues of the combat options within the game module 224 based at least in part on the fitness data. In generating the combat options, the element generation module 228 may create a number of possible battles and / or characters (and their characteristics) within the possible battles.

[0052] The battle queue may include quantity-based battle options and / or monster-based battle options. In the quantity-based battle options, the battle queue may include several monsters and / or several rarities associated with a particular monster (the monster(s) may not yet be revealed to the player). Thus, upon selecting a monster rarity, i.e., initiating an in-game battle, the element generation module 228 may select a monster corresponding to the selected rarity. In the monster-based battle options, the battle queue may include a list of the monsters themselves. The monster battle queue may be generated when processing the fitness data and stored accordingly. Upon selecting a battle option, the game server 200 may battle the corresponding generated monster from the battle queue.

[0053] For example, each combat option may include an option to combat a particular rarity of monster. Thus, the combat queue may include a quantity of each rarity category, in which the element generation module 228 may generate a list of quantities of monster rarities. When a player initiates a combat with a particular rarity, the game server 200 may randomly select, for example, a particular species of monster that corresponds to the particular rarity selected by the player. Thus, processing time and data storage may be reduced in storing and transmitting only the quantities of rarities in the quantity-based combat options of the combat queue. In turn, the quantity-based combat queue may reduce the operating costs of the system 100.

[0054] Additionally, for example, each combat option may include one or more virtual monsters configured to combat other monsters in the game module 224. The element generation module 228 may generate the monsters themselves, in which the element generation module 228 may assign various characteristics to the monsters, including design (e.g., shape, size, color, and overall appearance), various powers, various health and defense attributes, and / or a rarity designation based at least in part on the fitness data. Additionally and / or alternatively, the element generation module 228 may modify characteristics of existing or pre-generated monsters based at least in part on the fitness data.

[0055] As used herein, the rarity and / or commonality associated with a monster may refer to the numerical value of the monster and / or various characteristics of the monster. For example, the rarity of a monster may refer to the overall number of monsters in a particular category of monsters and / or the unique characteristics of a particular category of monsters, such as strength, health, design, etc. Additionally, the element generation module 228 may use the rarity coefficients and / or commonality coefficients generated by the fitness data processing module 226 to generate both rare and common virtual monsters.

[0056] The element generation module 228 can generate the combat options based on various parameters. The element generation module 228 can generate the combat options based on the speed, optimal speed, distance, heart rate, optimal heart rate, and / or rarity factor from the fitness data processing module 226. The element generation module 228 can generate the combat options based only on the heart rate data. The element generation module 228 can generate several combat options based on the fitness data, where the combat options have a predetermined rarity. The rarity value, or the rarity factor used to determine the rarity value of each monster, may or may not depend on the fitness data. The element generation module 228 can also generate several combat options and their rarity, where both the number and the rarity of the combat options are based on the fitness data. The element generation module 228 can generate several monsters based at least in part on the fitness data, thereby increasing or decreasing the number of monsters generated.

[0057] Additionally, the factor generation module 228 may determine which coefficients to use based on fitness data, such as previously recorded fitness data, from the fitness data processing module 226. Thereby, for the same fitness activity, the factor generation module 228 may award a greater or lesser number of combat options to a player(s) based on the player's current physical fitness. In this regard, the factor generation module 228 may award players for performing more strenuous exercise and / or level the playing field by awarding players equally for distance traveled regardless of speed.

[0058] Further, the element generation module 228 may generate and assign rarity values ​​to the monsters at least in part depending on the fitness data. For example, the element generation module 228 may receive the rarity coefficients generated from the fitness data processing module 226. The element generation module 228 may then generate the number of monsters and a rarity value for each monster accordingly depending on the rarity coefficients. Thus, the number of monsters and their rarity may be based at least in part on the fitness data.

[0059] For example, both the active time and optimal heart rate bpm of the player may be parameters for determining the probability coefficient of some generated battle options and / or the probability coefficient of the rarity of the monsters in the battle options. Thus, instead of assigning some monsters generated at a certain heart rate, e.g., 0 battle options at a resting heart rate, e.g., 50 bpm, and 50 battle options at an active heart rate, e.g., 100 bpm, the element generation module 228 may assign a monster generation probability coefficient, e.g., a probability coefficient of 2%, to the determined heart rate from the fitness data processing module 226, or alternatively, a standard optimal heart rate. This probability coefficient may be multiplied by the distance traveled and / or the exact and / or average time the player was at a certain optimal heart rate. Furthermore, the element generation module 228 may generate the maximum number of battle options when the player reaches the optimal heart rate and / or spends a certain period of time at or above the optimal heart rate.

[0060] Now, with particular reference to FIGS. 3-4, the element generation module 228 may adjust the combat option generation rate according to a desired algorithm. The element generation module 228 may be tailored to a particular parameter, set of parameters, or may increase linearly in relation to the player's heart rate. The element generation module 228 may determine the particular algorithm to use based on the fitness data of the player(s), such as, for example, a parabolic curve optimized for optimal heart (FIG. 3) or an asymptotic logistic curve optimized for heart rate intensity (FIG. 4). Thereby, the game server 200 may give individual players better incentives depending on the player's fitness level within a given week, month, year, etc. Also, the game server 200 may create artificial handicaps for certain players based on the player's fitness level.

[0061] As shown in FIG. 3, by way of example only, the probability coefficient of battle option generation may be parabolic with its apex (and maximum probability coefficient) aligned with the player's optimal heart rate bpm, e.g., 100 bpm. As shown on the X-axis, the heart rate ranges from a minimum of 80 bpm to a maximum of 220 bpm. As shown on the Y-axis, the battle option generation rate ranges from a minimum of zero to a set maximum. The set maximum may be any desired probability coefficient. For example, the set maximum may be a probability coefficient of 5%, 20%, 50%, 100%, or more. In this example of a parabolic function, a more physically fit player may not receive a greater number of monsters than a less physically fit player. In essence, a physically less fit player is more incentivized than a physically fit player.

[0062] As shown in FIG. 4, by way of example only, the probability coefficients of combat option generation may be modeled using an asymptotic logistic curve, with combat option generation tapering slightly as heart rate intensity increases. Heart rate and combat option generation rate are displayed on the X and Y axes, respectively. In this example, the difference between 180 bpm and 220 bpm is nearly indistinguishable in its effect on combat option generation rate. Thus, more physically fit players are given a greater number of combat options as they enter the high heart rate bpm range, beyond which the generation rate tapers off and the incremental increase in generation rate becomes negligible.

[0063] It should be understood that the element generation module 228 generates in-game elements on the game server 200. Among them, a possible advantage of the element generation module 228 is that the negative impact of cheating by players can be mitigated. Players may not be allowed to input certain parameters such as age, weight, goals, etc., and thus the generation of in-game elements can be independent of counterfeit information input by players. Thus, the system 100 improves the gaming industry in providing fair gaming applications.

[0064] As illustrated in FIG. 5, the element generation module 228 may generate one or more fitness activity summaries and generated results 500, which may then be shown to the player via the player's device 104A-C, 106. In it, the element generation module 228 may indicate the total number of monster rarities and / or the number of monsters generated during the player's fitness activity. The player may indicate the number and rarity of monsters the player has "given," "discovered," or "encountered," which refers to the various monsters in the battle options generated for the player as a result of the player's fitness activity. As illustrated, the element generation module 228 may generate a total of 104 battle options, including, for example, 57 rarity 1 monsters, three rarity 5 monsters, and only one rarity 8 monster, to battle based on the player's fitness activity (FIG. 5). The same or a smaller number of generated battle options may then be listed in a battle queue, as discussed below.

[0065] The combat queue may be generated at least in part based on the fitness data. For example, the combat queue may be generated based only on the heart rate data. Thus, the element generation module 228 may determine the number of combat options to be included in the combat queue based at least in part on the fitness data. In other words, the game module 224 and / or the element generation module 228 may use all of the total number of generated combat options or create a partial number of the total number of generated combat options, where the decision, e.g., inference of the combat options, depends on the fitness data. For example, the combat queue may include fewer combat options than the total number of generated combat options because the player's heart rate during a given fitness activity is lower than average.

[0066] 6-7, the element generation module 228 can make the battle queue and / or one or more battle options therein time-independent or time-dependent. The battle queue can include quantity-based battle options, such as monster rarity, and / or monster-based options, such as monster category or type.

[0067] In some embodiments, the element generation module 228 can generate a time-independent combat queue 600 that is not time-constrained, such that combat options therein do not expire after a set period of time (FIG. 6). It should be noted that the element generation module 228 may or may not generate the combat queue based at least in part on fitness data. As shown, the combat queue 600 displays a queue comprised of quantity-based combat options, more specifically, quantities of monster rarities.

[0068] In some embodiments, the element generation module 228 may generate a time-dependent battle queue 700 (FIG. 7), in which the generated monsters must be fought within a predetermined period of time or they will disappear. The expiration time (i.e., the time remaining until expiration) may depend on the fitness data. For example, the element generation module 228 may generate an initial expiration time, which may or may not be based at least in part on the fitness data. The element generation module 228 may then extend or shorten the expiration time, based at least in part on the fitness data. For example, if the player performs additional fitness activities within a certain period of time, the element generation module 228 may extend the expiration time so that the battle option in the battle queue 700 lasts for more time. The element generation module 228 may also generate an entirely new subsequent expiration time to replace the initial expiration time, based at least in part on the fitness data. The time-dependent battle queue 700 may encourage gameplay, which may encourage more exercise, based on the desire to win and acquire stronger and rarer monsters.

[0069] The notification generation module 230 may notify the player of various in-game events generated as a result of the fitness activity. The notification generation module 230 may comprise any desired hardware and software. The notification generation module 230 may display a summary of the fitness activity, a summary of the combat options and the rarities and / or monsters therein, and a combat queue generated as a result of the player's one or more fitness activities. The notification module 230 may communicate various messages in various manners known to those skilled in the art.

[0070] For example, the notification module 230 may display a fighting icon. The fighting icon may be displayed on the main page of the game. The fighting icon may also open a popover of the generated fighting queue. The notification generation module 230 may further generate an option to select one or more fighting options in the fighting queue via the display of the device 104A-C, 106 as determined by the element generation module 228. This option to select a monster and thereby fight the monster may be independent of the fitness activity associated with the previously collected fitness data. As an example, the notification module 230 may display a fighting queue of degrees of rarity of the monsters to fight. The player may then select which rarity of monster he or she wants to fight. The player may select the rarest monster to fight instead of the less rare fighting option and be incentivized to do more fitness to receive a greater number of rare monsters without having to fight a large number of in-game battles.

[0071] The notification generation module 230 may suppress notifications of generated in-game content from the game server 200 depending on one or more parameters. For example, the notification generation module 230 may notify a player only after the sensor(s) 112 of the devices 104A-C, 106 register a particular heart rate of the player, such as the player's resting heart rate. Thus, the notification generation module 230 may ensure that the player is not distracted during the fitness activity.

[0072] Referring now specifically to FIG. 8, a flowchart of a computer-implemented method 800 according to an exemplary embodiment of the present disclosure is shown. Fitness data may be sensed and thus retrieved by at least one of the one or more devices 104A-C, 106 of the player (step 802). In a background or foreground process, the device 104A-C, 106 may send the fitness data to the network 102 (step 804). The game server 200 may then receive the fitness data (step 806). One or more virtual elements may then be generated by the one or more processors 222 (step 808). For example, the element generation module 228 may generate combat options based at least in part on the fitness data. The one or more processors 222 may additionally generate a rarity value for each virtual element (step 810). For example, the element generation module 228 may use a predefined rarity of monsters that may or may not be based on the fitness data. Additionally, for example, the element generation module 228 may generate a rarity value for each virtual element based at least in part on the fitness data. However, it is contemplated that the method 800 may not include the step of generating a rarity value. The one or more processors 222 may additionally generate combat cues for one or more of the previously generated virtual elements (step 812). For example, the element generation module 228 may generate combat cues for some or all of the combat options such that the player may combat monsters from the combat options. The memory 210 may store the combat cues (step 814), for example, in the game database 212. The combat cues, and / or individual combat options therein, may be stored for a finite or infinite period of time. This allows the player to complete the fitness activity without distraction and freely combat monsters. The game server 200 may transmit the combat cues to the player's devices 104A-C, 106 (step 816).In addition, the game server 200 may also transmit a summary or list of the combat options generated as a result of the fitness activity, so that the player's device 104A-C, 106 may display the combat queue in the fitness game application 118 (step 818).

[0073] In some alternative embodiments, the game server 200 may affect the outcome of gameplay and / or combat itself based at least in part on the fitness data. For example, the fitness data processing module 226 may determine a secondary factor that may increase or decrease the health, defense, and / or attack power of a monster previously generated in a previous combat option. In addition, additional rewards, such as in-game items and / or currency, may be awarded to the player based at least in part on the fitness data. The element generation module 228 may multiply the monster's health, defense, and / or attack power by the secondary factor. The element generation module 228 may also, or alternatively, multiply the player's selected monster that was not generated in a previously generated combat option by the secondary factor. The secondary effect(s) may be stored in the memory 210 and sent to the player's device 104A-C, 106. Such secondary effects may be applied automatically. Alternatively, the player may apply them as an attempt to take a risk. For example, a player can perform an upward swipe gesture to apply a mysterious secondary effect, i.e., an effect unknown to the player, which in turn affects the gameplay of the combat, potentially increasing the probability of success. The fitness game application can quickly apply the secondary effect, thereby reducing the calculation or processing time involved during gameplay. The game application then displays the generated secondary effect and starts the combat. In this way, the player can receive additional benefits when fighting monsters in the combat option by performing additional fitness activities within a certain period of time. This may increase the player's confidence in playing the game and exercising regularly, as it is positively reinforced during multiple in-game stages. This may also create a snowball effect that helps encourage players to engage in fitness activities regularly.

[0074] In some alternative embodiments, the game server 200 may generate time-sensitive incentives based at least in part on fitness data associated with one or more fitness activities of the player. The game server 200 may generate time-sensitive incentives based solely on heart rate data. For example, the fitness data processing module 226 may calculate bonus factors that may provide additional combat options, increased rarity generation, in-game items and / or currency, and / or advantageous secondary effects. The bonus factors, and corresponding bonus effects, may be generated and applied during and / or after the generation of the combat options, rarities, and / or secondary effects. Additionally, the bonus factors may be contingent on completing a particular fitness activity within a given period of time. The bonus factors may be applied automatically. Alternatively, the bonus factors may be applied in a manner similar to the manual application of secondary effects. This may thus increase the player's confidence as it is positively reinforced during multiple in-game stages.

[0075] In some embodiments, the above method steps of method 800 may be performed or implemented in any order, and thus are not limited to the order shown and described. In addition, the method steps of method 800 may be implemented substantially simultaneously to reduce latency and processing time. In addition, some of the method steps of method 800 may be omitted entirely.

[0076] The method steps of method 800 may be performed by executing software code or instructions tangibly stored on a tangible computer-readable medium, such as a magnetic medium, e.g., a computer hard drive, an optical medium, e.g., an optical disk, a solid-state memory, e.g., a flash memory, or other storage medium known in the art. Method 800 may be performed by one or more processors, controllers, and / or any other desired processing devices. As used herein, the term "software code" refers to any instruction or set of instructions that affect the operation of a computer or controller. Such software code may exist in a computer-executable form, such as machine code, which is a set of instructions and data directly executed by a central processing unit or controller of a computer, a human understandable form such as source code, scripts, which may be compiled for execution by a processing unit, controller, or an intermediate form such as object code generated by a compiler. Furthermore, software may include, in non-limiting examples, routines, programs, objects, components, and data structures that perform particular tasks or implement particular data types. The server process may be implemented using a single server or multiple servers operating in conjunction with each other. The server(s), database(s), and software application(s) may be implemented on a single system or distributed across multiple systems.

[0077] Other embodiments that depart from the above described ones may be envisioned by those skilled in the art without departing from the scope of the following claims.

Claims

1. A computer implementation method for generating virtual elements in a fitness-based game, The game server (200) hosts the fitness-based game module (224), The game server (200) receives fitness data from one or more of the user's devices, where at least one of the devices includes one or more sensors configured to sense fitness data. Includes, The aforementioned method, One or more processors (222) generate multiple combat options within the fitness-based game module (224) based at least partially on the fitness data, The one or more processors (222) generate one or more combat queues from the plurality of combat options, A computer implementation method characterized by further comprising sending the battle queue to the user via the game server (200).

2. The computer implementation method according to claim 1, wherein each of the plurality of combat options includes one or more virtual monsters configured to fight in the fitness-based game module (224).

3. The computer implementation method according to claim 2, wherein generating the plurality of combat options includes generating the rarity value of each virtual monster.

4. The computer implementation method according to claim 3, wherein the generation of the rarity value for each virtual monster is determined by a rarity coefficient that is at least partially based on the fitness data.

5. The computer implementation method according to claim 1, further comprising displaying options for selecting one or more of the multiple combat options in the combat queue, wherein the options for selection are independent of the fitness activities associated with the fitness data.

6. The computer implementation method according to claim 1, wherein the battle queue is free from time constraints so that one or more of the multiple battle options in the battle queue do not expire after a set period.

7. The computer implementation method according to claim 1, further comprising retrieving the fitness data by a background process on at least one of the user's one or more devices, wherein the retrieval of the fitness data and the generation of the plurality of combat options are performed after the completion of a fitness activity associated with the fitness data.

8. The computer implementation method according to claim 1, wherein the fitness data includes the user's heart rate, and generating the plurality of combat options includes determining a first coefficient based on the user's heart rate and a second coefficient based on an optimal heart rate, wherein the second coefficient is greater than the first coefficient.

9. The computer implementation method according to claim 1, wherein the fitness data includes the distance traveled and the number of steps taken by the user, and generating the plurality of combat options includes determining a first coefficient based on the distance traveled and a second coefficient based on the user's optimal speed during the fitness activity associated with the fitness data.

10. The computer implementation method according to claim 1, wherein generating the combat queue is at least partially based on the fitness data.

11. A computer-based system for implementing a computer implementation method for a game, wherein the system is The game server (200) comprises one or more computer-readable media (21), one or more processors (222), and a network interface (202), and the game server (200) is It hosts a fitness-based game module (224), The network interface (202) is configured to receive fitness data from one or more of the user's devices, where at least one of the devices is equipped with one or more sensors configured to sense fitness data. The aforementioned game server (200) One or more processors (222) generate multiple combat options within the fitness-based game module (224) based at least partially on the fitness data. The one or more processors (222) generate one or more battle queues from the plurality of battle options, A computer-based system characterized in that the network interface (202) is further configured to transmit the battle queue to the user.

12. The computer-based system according to claim 11, wherein each of the plurality of combat options includes one or more virtual monsters configured to fight in the fitness-based game module (224).

13. The computer-based system according to claim 12, wherein generating the plurality of combat options includes generating a rarity value for each virtual monster.

14. The computer-based system according to claim 13, wherein the generation of the rarity value for each virtual monster is determined by a rarity coefficient that is at least partially based on the fitness data.

15. The computer-based system according to claim 11, further comprising displaying options for selecting one or more of the multiple combat options in the combat queue, wherein the options for selection are independent of the fitness activities associated with the fitness data.

Images