Patent Application
20250090921
The present invention relates to the field of sports-based entertainment, and more specifically, systems and methods for simulating the quarterback experience through game play.
There are a variety of virtual sports games for immersing players in games such as soccer, football, golf, basketball, etc. Most of these games are entirely virtual and the experience is simulated on a screen with the player(s) manipulating one or more virtual player using a gaming console or computer.
There is a need for sports-based entertainment systems that are partially virtual, such that a user is still able to manually execute one or more aspects of the sport, such as manipulating a ball (such as by throwing a football or baseball or kicking a soccer ball or football).
Systems capable of receiving a football include U.S. Pat. Nos. 11,504,593; 11,571,613, which provide drones configured to provide feedback on a pass for the purpose of training players.
However, a need remains for a sports-based entertainment system configured to simulate one or more aspects of the quarterback experience in a game-play scenario.
According to embodiments of the invention, systems and methods are presented for sports-based entertainment, such as for game play simulating the quarterback experience. Systems can comprise user interface(s), control console(s), target/robot(s), and projectile(s)/football(s). According to the systems and methods employed by such systems, the target(s) travel according to predetermined route(s), can be stopped at any point during their travel(s), and/or return to the starting position(s) autonomously. The user can select various game modes and plays. The target(s) move according to the selected route/play for the player to hit. Points awarded to the player may be dependent on the distance traveled down the field in the y-direction away from the starting point. The target(s) may have target statuses, e.g. “covered” and “open” statuses, and the user may have simulated pocket pressure for an enjoyable quarterback experience.
The accompanying drawings illustrate certain aspects of implementations of the present disclosure and should not be construed as limiting. Together with the written description the drawings serve to explain certain principles of the disclosure.
The present invention comprises systems for sports-based entertainment, such as for simulating the quarterback experience.
In embodiments, the system comprises one or more of a user interface 100, one or more docking station(s) 200, and one or more receiver robot(s) 300 configured to move around a playing field 400 (
In embodiments, the system is capable of having the receiver robot(s) 300 travel according to pre-determined route(s), be stopped at any point during their travel(s), and/or return to the starting position(s), such as the docking station(s) 200, (and starting angle orientation) autonomously.
The playing field 400 can be any size and shape, as long as the receiver robot(s) 300 can complete their route(s).
The layout and/or location of the control console 100, docking station(s) 200, and/or receiver robot(s) 300 can be modified.
In embodiments, the shape(s) and size(s) of the receiver robots 300 can be varied. In embodiments, the system comprises one or more receiver robots 300, such as 2, 3, 4, or 5 receiver robots 300.
In embodiments, the system comprises a user interface 100 configured to interact with the system user (
In embodiments, the system comprises a user platform 120 for a user to stand in or on during use. The control console 110 may be attached via a wired or wireless connection to the user platform 120. In embodiments, the user platform 120 contains an interface and/or one or more lights 140, such as LEDs, to be viewed by or to project light toward the user, such as to encourage the player to move about the user platform 120.
In one example embodiment, several LED lights 140 are present in and/or around the user platform 120, such as on the ground or at one or more location on a wall or screen, and at varying distances from the user. The lights 140 may be lit one at a time, beginning with the light furthest from the user. In embodiments, the system comprises multiple lights 140, wherein a light 140 further from the user is green and a light 140 closer to the user is red, and they are lit in order from green to red.
In embodiments, the lights 140 are configured to light up over a pre-determined or random time. For example, the user would be encouraged to move away from a light or sequence of lights (e.g., as a sequence of lights is lit progressively closer to the user, one or more lights increase in intensity or change color, such as from green to red, etc.) to a new location on the user platform 120.
In embodiments, the user platform 120 comprises one or more sensors 130, such as pressure, weight, proximity, motion (such as IR break-beam sensors), or other sensors 130 capable of monitoring the location of the user on the user platform 120. In embodiments, two or more types of sensors 130 are used in combination.
In embodiments, one or more sensors 130, such as IR break-beam sensors, are positioned in a manner to detect if the user has thrown the ball from the user platform 120. In embodiments, the sensor(s) 130 may also be used to measure the direction and/or speed at which the ball was thrown. In embodiments, the sensors to determine the location of the system user (player) can be the same or different than the sensors for determining whether a ball is thrown.
In embodiments, the receiver robot(s) 300 continue to move for a pre-determined amount of time after the user has been prompted to throw the ball to account for the time it would take for the ball to reach the receiver robot after leaving the user's hand.
In embodiments, one or more of the display screens are integrated into the user interface 100. In embodiments, one or more display screens are separate from the control console 110.
The control console 110 provides the user with a means to interact with the system. In embodiments, the user can use the control console 110 to select or input one or more of game mode, player selection, play selection, and/or other player inputs. In embodiments, the control console 110 comprises a touch screen, one or more buttons, remote control, or combination thereof.
In embodiments, the control console 110 may be a wired or wireless controller or device configured to communicate with one or more of the display screens. In embodiments, the control console 110 is integrated with the one or more display, such as via a capacitive touch display.
In embodiments, one or more display screens are configured to display stages of the game, animations, scores, and/or any other feature applicable to the system and/or game.
In embodiments, the user interface 100 is configured to communicate, via serial and/or wireless communication, with one or more of the receiver robot(s) 300, docking station(s) 200, control console 110, server, and/or any additional system components. In embodiments, firmware updates to one or more system components are performed using the serial and/or wireless communication.
In embodiments, the one or more microprocessor(s) are configured to control and/or execute one or more algorithm or system process. In embodiments, the one or more microprocessor(s) are supplemented or replaced with one or more CPU(s).
In embodiments, the control console 110 and/or user interface 100 further comprise one or more sound input(s) and/or outputs, such microphones and/or speakers.
In embodiments, the user interface 100 or control console 110 is replaced by a separate means for communication with the one or more system components. For example, a mobile app can be used to communicate with one or more of the receiver robots 300.
In embodiments, the server is configured to perform one or more functions, such as one or more of data storage, play storage, player accounts and/or information, high scores, firmware updates, OTA DFU to the receiver robots 300 and/or other hardware in the system, etc. In embodiments, the server is local or remote/virtual and may be updated, managed, and/or controlled externally.
In embodiments, the system comprises one or more projectile such as a ball, or a football. The system comprises one or more location configured to detect the ball, such as a docking location and/or a receiving location (
The football can be part of or separated from the user interface 100. There may be a placement for the football to be thrown with sensor(s) for the placement to detect if the football has been replaced and/or removed from the placement. The location for the football placement may be stationary and/or moving, and may be used to project the football, such as shown in
In embodiments, the system further comprises a football retrieving mechanism to return the thrown football to the starting location(s). The football retrieving mechanism may be replaced/enhanced by user or human interactions. In embodiments, other objects may be used in place of the football.
The user interface 100 and control console 110 may be further enhanced by adding visual enhancements in the form of heads-up display, which may be embedded into a wearable for the system user (e.g., integrated into a pair of glasses/goggles, helmet, or another wearable article or device). The added visual enhancements may be used for a variety of purposes (e.g., to show the defender(s) on the playing field 400 that the receiver robot(s) 300 travel on. The defenders may be used to indicate whether or not the robot receivers 300 are “open” or “covered”. The heads-up display may also show where in the “pocket” to move, or where the “defender linemen” are rushing from visually (to step away from).
In embodiments, the system comprises one or more camera to record the user and/or receiver robots 300. In embodiments, the one or more camera is used to provide footage for replays.
There may be one or more sensors 130 on the user platform 120 that can detect the location of the user using for example, pressure/weight and/or IR/proximity, etc. In embodiments, the user platform 120 may be replaced by other types of sensors to detect the location of the user.
In embodiments, the user interface 100 comprises one or more lights 140, such as LEDs. In embodiments, the lights 140 may be used to indicate time is running out for the user to throw the ball or to encourage the user to move around the user platform 120, such as to simulate a defensive player's approach. In embodiments, the lights 140 may be replaced and/or supplemented with other types of indication, such as a wearable with heads up display.
In embodiments, game points may be deducted from the user and/or plays may be ended before the “Make the Play” timer has run out if the player does not move in the proper location. In embodiments, the system can detect if the user has moved into the proper location using the one or more sensor(s) 130 placed in or around the user platform 120. The presence or absence of the user platform 120, the number(s), location(s), and type(s) of sensor(s) 130, and the location, orientation, number, and method of activation of the one or more light(s) 140 can be varied.
In embodiments, there may be a physical barrier between the user and the playing field 400 which the receiver robots 300 are traveling on. The barrier may be robust and be used for additional safety to keep the user safe from the receiver robots 300 and/or other features of the system. The barrier may be additionally supplemented with physical and/or visual (e.g., holographic) entities to represent linemen and/or other methods of protection for the player. The barrier may be used to distinguish from the docking stations 200 (or starting points) for the receiver robots 300 when returning to base (e.g., with a different color, or distance from the receiver robots 300, etc.).
There may be additional sensors, such as pressure or proximity sensors, that are placed on the terrain which the receiver robots 300 travel on, to trigger an event to stop all receiver robots 300 from moving if it is detected that a foreign object and/or person has stepped onto the terrain. The sensors for foreign object and/or person(s) detection may occupy portions or all of the terrain 400 which the receiver robots 300 travel on.
In an embodiment of the invention, the control console 110 comprises a tablet (e.g., a SunFounder 10-inch Touch Screen for Raspberry Pi, controlled by a Raspberry Pi 4, and connected to an EV-BT832F Bluetooth board via UART).
In embodiments, the invention comprises one or more docking station(s) 200.
In embodiments, the docking station(s) 200 mark the starting and ending positions for the receiver robots 300 for each play/round. The docking stations 200 can comprise one or more of a power supply (e.g., a power source for the docking station and its associated components), power management system, sensors and/or indicators, microcontroller(s), serial or wireless communications, and electromechanics. In embodiments, the overall system may operate without the use of docking stations 200.
In embodiments, the power management system provides the appropriate power levels to all components on the docking station 200, and can also contain a method of measuring, and/or charging one or more battery on the receiver robot 300 either wirelessly or with wires/contacts.
In embodiments, sensors and indicators are used to help the receiver robot 300 achieve proper docking. This can for example be infrared light sensing. Additionally, a physical alignment feature (e.g. a ramp or guide) may be used to help the receiver robot(s) 300 dock with the docking station 200.
In embodiments, microcontroller(s) can be part of the docking station 200 to help perform all the tasks and functions needed.
In embodiments, serial and/or wireless communication protocols may be embedded in the docking station 200 to communicate to the receiver robot 300 and/or the control console 110.
Electromechanics (e.g., motor controller(s), motor(s), gear(s), wheel(s), etc.) may be included in the docking station 200 to move the starting point of the receiver robot 300. The location(s) of the docking station(s) 200 may variable depending on the play selection and may be controlled by the control console 110.
In embodiments, the hardware for the target(s)/receiver robot(s) 300 may consist of four main parts: the battery, the main body/base, the gears and the wheels (electromechanics, attached to the base), and upper body (can be the entire target or can comprise one or more visual mark identifying for the user where to hit the one or more target(s) with the projectile) (
In embodiments, the battery is responsible for powering the receiver robot(s) 300, and it may comprise a LiPo battery: light weight, and capable of discharging the high current demand from the electromechanics. In one example embodiment, 11.1V RC LiPo batteries from Zeee may be used.
The main body/base is the most complex portion of the receiver robot(s) 300 hardware. The main body may comprise one or more of a power management system, one or more motor driver(s), one or more encoder(s), one or more memory storage(s), one or more LED, one or more collision and/or other sensors, one or more microprocessor, a housing, etc.
In embodiments, the receiver robot(s) 300 comprise a power management system. This system can comprise component(s) that provide and regulate the various power specifications of the components for the entire receiver robot 300. It may also include a method of charging the battery with wired/contacts and/or wireless method, and/or measure the voltage of the battery to determine remaining charge. LDOs and voltage regulators can be part of the power management system.
In embodiments, the receiver robot(s) 300 comprise one or more motor drivers. The one or more motor driver(s) is meant to control and drive the one or more motor(s) attached to the electromechanics. The one or more motor driver(s) may be capable of driving the motor with various speeds in the forward and reverse directions. Additionally, the one or more motor driver(s) may be used to brake or coast the motors. One example embodiment of one or more motor driver(s) is the Victor 888. The one or more motor driver can be part of another component, such as the MCU.
In embodiments, the receiver robot(s) 300 comprise one or more encoder(s). The encoder(s) are used to measure the travel distance and/or the speed of the robot. Encoders can be used magnetically or optically to measure the rotations of the wheels. The encoders can contain a single or multiple channels, with various number of poles or counts per revolution. An example encoder is the Pololu 3499.
In embodiments, the receiver robot(s) 300 comprise one or more flash memory. This component is used as memory storage for the device. The one or more flash memory can be an internal part of another component on the device, such as within the MCU. The one or more flash memory may also be an external component, such as an SD card.
In embodiments, the receiver robot(s) 300 comprise one or more LED component(s). For example, this component is used as a user interface for various indications. There may be various numbers of LED on the device. The LED component can take the form of LED strip(s) in various colors. The LED may be capable of displaying various patterns and brightness. The LED can be replaced by other methods of User Interface such as an LCD screen. Adafruit 4245 can be an example of LED strip on the device.
In embodiments, the receiver robot(s) 300 comprise one or more collision sensors as a safety feature to avoid collisions. When a collision is predicted, an interrupt is generated for the MCU to stop the motor drivers. Time of flight, proximity, and IR sensors are non-limiting examples of collision sensors for use in the present system.
In embodiments, the receiver robot(s) 300 comprise a BLE MCU as the main microprocessor in the control of the receiver robot(s) 300. Multiple processing components may be included. Alternative wireless and/or serial communication protocol may be used as opposed to, or in addition to, BLE. The MCU and communication component(s) can be a single element or separate components. The MCU and communication component(s) can take form in, but not limited to, module(s) or chip-down designs. In embodiments, nRF52 Bluetooth devices can be an example of the BLE MCU.
In embodiments, the receiver robot 300 comprises one or more IMU used to measure the various forces, orientation, and angular rate of the receiver robot 300 to calculate the location and positioning. Other components serving the function of location and positioning may be used in place of an IMU, such as the Adafruit 9-DOF, based on the Bosch BNO055 chip, which can be an example of the IMU.
Various additional sensors may also be included in the receiver robot 300 to perform various features. For example, an IR sensor can be placed on the device to help with its homing capability to dock at the docking station 200.
The main body/base housing of the receiver robot 300 may be mechanically designed to be low in profile, lightweight for high speed, but sturdy and robust to sustain hits on the upper body (attached to the main body) without losing balance or trajectory.
The electromechanics of the hardware are meant to move the receiver robot 300 in various directions at various speeds. This section can comprise at least one or more of gears, a gearbox, chains, belts, motors, and/or wheels. The wheels may be pneumatic tires to eliminate the need for suspension while driving on uneven terrain. Alternatively, omni-directional (mecanum) wheels may be used. The terrain traveled on may be variable, including but not limited to asphalt, turf, grass, hard floor (e.g. vinyl, wood, etc), etc.
In embodiments, the receiver robot 300 comprises an upper body as the main target (location or visual mark identifying for the user what to hit with the projectile) for the user/player. The upper body may comprise one or more of an upper body frame, sensor(s) to check for hits, and UI (e.g., LEDs). The main upper body is meant to be or comprise the target(s) (and can comprise one or more visual mark identifying for the user where to hit the one or more target(s)/receiver robot(s) with the projectile) and shall be capable of sustaining hits. The upper body may be capable of changing its shape and size, either via physical manipulation by a user or through programming of one or more internal pieces to move. The upper body may comprise piece(s) that are attached to the base and/or connected to target piece(s) with strain relief. An example upper body can be an inflatable punching bag. The sensor(s) to detect hits can have various forms of sensing such as, but not limited to, resistive, capacitive, IR, proximity, acceleration, shock, and vibration. The sensors should be capable of sustaining hits without losing accuracy. The sensor(s) location(s) may also be able to move (e.g. up and down) either by physical manipulation by a user or programmed movement by the receiver robot 300. In an embodiment, an example sensor could be velostat material and/or conductive fabric. The number, location(s), shape(s), and size(s) of sensors on the upper body are variable, as is the upper body. The sensors may cover parts of or the entire upper body.
In an embodiment, the upper body may contain one or more of physical and/or visual entities. The physical representation may serve only as a guide and/or target, but not meant to sustain hits from the football. For example, a loop with IR break-beam sensors to detect if anything has passed through the loop, or where in the loop the passing through has occurred. The loop may be further supplemented with a method to catch anything that falls through the loop (e.g., a net).
Alternatively, the upper body (or the entire receiver robot 300) may be visually represented but not physically present. In this embodiment, the visual representations may take the form of holograms or other means. The visual representation should be able to indicate the status and suggested locations to throw to, much like the physical robot, but with more visual flexibility. The sensors may detect whether the football have passed through the visually represented space (using with IR break-beam sensors for example).
In embodiments, the system employs one or more algorithm to facilitate game play.
The described algorithm is intended to outline the flow for the combined software, firmware, and hardware for all components in the system.
The overall system may contain various modes, such as practice mode, and can contain various difficulty and handicaps. The difficulty and handicap can affect the routes, receiver robot 300 speeds, and other features. The various modes, difficulty, and handicap may be selected by software. The overall system may be controlled by the control console 110 of the system hardware and can be managed with the server.
The typical game may be started by selecting the game mode in software.
In embodiments, the players/users for the game can be added and/or loaded from a previously registered profile saved in the server. Each player/user may also update their handicap and/or game difficulty in the software, or it can be saved and loaded from server. The handicap and game difficulty may alter one or more game parameters, such as one or more of speed and/or scoring variations and/or window of opportunity to hit the receiver robots 300.
In an embodiment, the game may consist of three plays per round per player, with ten rounds total. In embodiments, the number of plays can be any number, such as 1, 2, 3, 4, 5, or more plays. In embodiments, the number of rounds can be any number, such as 1, 5, 10, 15, 20, or more rounds. In embodiments, the number of players can be set to 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, or more players.
In embodiments, the rounds may be eliminated completely and only the throw number would be tracked. The number of players in a game is variable, with the players having the ability to input player names. Additionally, the player may be able to create a profile with their preferred player name in the server and/or system to be loaded. The players may have the option to play as teams (e.g., 2 versus 2 players) and have the ability to input a team name on top of the player names. There may also be ways to save a team profile onto the server and/or system.
The typical flow of the game may be controlled by software as the following: Player Selection, Play Selection, Make the Play, and repeat (goes back to Player Selection or Play Selection depending on the play number).
When the game starts, the starting screen on the display may be the Player Selection screen. The Player Selection screen may display the score board and have options to play or skip the player. Alternatively, a specific player can be selected to play their next throw. The system may require each player to complete their throws before proceeding to the next round. Alternatively, the system may allow the players to skip rounds. There may also include an additional option to call for assistance.
After a user/player has elected to start their round, the play selection screen may be displayed (
In embodiments, artificial intelligence and machine learning may be used to produce the play options, specific to certain situations (such as the player). Alternatively, the player may be able to select the desired play. There may be a timer associated with this screen, the timer may start at 40 seconds. In embodiments, the timer starts at at least 10 s, such as 20 s, 30 s, 40 s, 50 s, 60 s, 70 s, 80 s, 90 s, 100 s, 110 s, or 120 s. When the timer is running low, for example, with 5 seconds left, the highlighted play may be locked in and the player may no longer be able to change their play selection. In embodiments, the highlighted play may be locked in with less than 30 seconds left, such as less than 1 s, 3 s, 5 s, 10 s, 12 s, 15 s, 20 s, or 25 s. When the play selection timer runs out, it would indicate the start of the play.
In embodiments, the system is configured to produce a sound to indicate to the user the play has started.
Optionally, a “Make the Play” screen is displayed (
In embodiments, a play timer counts down. When the play timer is about to run out, there may also be an additional indication, such as sound, to add urgency for the player.
In embodiments, the Play Selection screen can have indications to show when the play may be started early.
After the play has started, a play timer starts and the control console 110 sends one or more commands to the receiver robots 300 wirelessly corresponding to the play selected. Other methods of communicating to the receiver robots 300 may also be used. The play timer may be at 5 seconds but may be different with different plays or modes.
The receiver robot(s) 300 receive the command(s) and perform the actions by, for instance, moving according to the route which was selected. The route selected may already be saved in the memory embedded in the receiver robots 300. The receiver robots 300 may use artificial intelligence and machine learning to create minor variations while traveling the routes (for example, mimicking the speed and movements of players, such as specific players or random players). The receiver robot 300 may use the IMU to measure initial yaw/heading, and periodically check the heading during the route. If necessary, the receiver robot 300 would update the left and right motor speeds accordingly to stay on track to the selected route. The receiver robot 300 may use the measured yaw and an internal controller (e.g., PID controller) to update the speed command given to the wheels to stay on track and/or maintain speed. The receiver robot 300 may use the heading measured along with the encoder steps to calculate the total distance traveled in the x and y directions from the starting location using trigonometry equations. The total distance traveled is updated frequently so that the receiver robot(s) 300 can be commanded to return to the starting position at any point while traveling its route(s).
The player's goal is to throw the football and hit a receiver robot 300 before the play timer runs out.
The player may receive one or more indications to step away from or step towards certain directions in the user platform 120 (or “pocket” where the player would be once they receive the football and while the receiver robots 300 are moving according to their routes) from the start of the Make the Play to when the football is thrown, when a receiver robot 300 has been hit, or when the play timer runs out. The indications may take form in the sense of a stationary platform with LEDs (e.g., green means good, orange is neutral, red is bad, and the user should step away from the LED. Alternative colors, or color shades/intensities may be used instead of different colors for colorblindness accessibility), alternatively, it can take form in the sense of a wearable. Other methods of encouraging or discouraging the player to move (e.g., vibrations in certain areas, etc.) may be used. In certain variations, the player may not be required to move in/on the user platform 120 at all. There may be one or more sensors 130 to check whether or not the player has moved. The player may lose points if they do not move towards the proper (or away from the discouraged) locations on the user platform 120. The Play Timer may end prematurely in certain modes if the player does not move properly. In another instance, the Play Timer may be replaced by the pocket LEDs (e.g., if LEDs from all directions turn red).
In some instances, the target(s)/receiver robot 300 may be a single target that rewards points regardless of where it is hit. In other instances, the target on the receiver robot 300 (such as one or more visual mark identifying for the user where to hit the one or more target(s) with the projectile) may be variable (e.g., either with physically moving the target, or with displaying where on its target to hit, such as up top, down low, etc.) to reward additional points when the indicated location is hit or reduce points when the indicated location is not hit. The receiver robots 300 may include “arms” or mechanisms capable of “catching” the football thrown, such as through the use of sensors to estimate the football position and timing.
When a receiver robot 300 is hit, the hit receiver robot(s) 300 would send one or more messages to the control console 110 and/or other receiver robot(s) 300. Depending on the timing, location, and hit position of the receiver robot 300 (e.g., the position/location of the receiver robot 300 at the time of impact by the projectile), the message sent may be different. When the control console 110 receives a hit message, it sends a command to all connected receiver robots 300 to stop and return to the starting position, ending the play. Alternatively, the hit receiver robot 300 may send one or more messages to the other receiver robot(s) 300 in the system to stop and return to the docking station(s) 200. The receiver robots 300 may use their currently calculated distance traveled, and trigonometry equations to calculate its relative angle and distance from the starting location. Then, it may angle itself to align with its starting location, and travel back using the encoder and IMU to track the angle and distance. The receiver robot 300 may be rotated to face down the field after successfully docking at the docking station 200. Alternatively, other positional sensing and homing methods (e.g., Bluetooth Direction Finding, or a pulling mechanism from the docking station(s) 200, etc.) could be used in getting the receiver robots 300 from their current locations to their starting locations. There may be additional sensors on the docking stations 200, and associating sensors on the receiver robots 300 to said docking station sensors, to assist the receiver robots 300 to get to the starting positions more precisely.
When the play timer runs out, the control console 110 sends one or more command to all connected receiver robots 300 to stop and return to base. Alternatively, there may be sensors to check if the football has been thrown by the time the Play Timer runs out. If the football is thrown, the control console 110 may delay sending the command(s) requesting the receiver robots 300 to return to base. A pre-determined amount of time may be added as a margin after the play clock has run out, before the receiver robots 300 are commanded to stop, in case the football has been thrown and is in the air when the play clock runs out. Additionally, the player may have an option to end the play before the play timer runs out. After all the receiver robots 300 have returned to base, and optionally the projectile has returned to the original location, the control console 110 can be used to start the next play.
If the receiver robot 300 is hit in the proper location(s) while it is “open,” points will be award to the player. The points awarded may be dependent on the distance traveled down the field in the y-direction away from the starting point, which is the distance from the starting point of the receiver robot 300 when hit (see, e.g.,
According to embodiments, if the one or more target(s) are only reporting their specific target status at specific pre-determined locations, then the control console would award 0 points if the target status reported is inappropriate for scoring, and a number of pre-determined points if the status is appropriate for scoring. The control console commands the one or more target(s) which route to travel from the database of routes, the database of routes have their individual locations appropriate for scoring, if the one or more target(s) has specific location(s) appropriate for scoring during its travel, and it reports the appropriate target status when hit by the projectile, then the control console can look up the route to determine the location(s) where the target status is appropriate for scoring, and use that to determine the points awarded (or distance traveled). Other methods to calculate distance of the one or more target(s) may or may not depend or be based on the target status to determine the location and/or distance, but in most cases the points awarded will be affected by the target statuses.
After the play is over, the screen may return to the play selection screen. If the player has already completed all their plays/throws of that round, the screen may go to the player selection screen.
After all the rounds are completed, the highest score player (or team) may be displayed as the winner. There may be a high scores screen to list and display the highest scorers of the game of all time. There may be a summary with statistics including, but not limited to, play by play scores, route types and completion percentages, distance play types and completion percentages, longest completed play distance, etc. The summary and statistics data may be sent to the main server, and players may view their personal statistics from the server at any time with authorization (e.g., creating an account with a password).
Additional embodiments of the invention include a space-confined version of the system in which the target(s)/receiver robot(s) and docking station(s) are omitted. A user throws the ball at a screen or other physical barrier. One or more characteristic of the ball and/or its trajectory is measured, such as speed, location, angle, etc. In embodiments, the measured characteristics of the ball is animated and displayed along with the animated receiver. A successful play can be determined if the animated ball reaches the animated receiver when the receiver is open. If the animated receiver is hit with the animated ball while covered or not hit within a specified amount of time, the play can be deemed unsuccessful. In embodiments, points can be awarded the user based on successful or unsuccessful plays. Optionally, the ball's trajectory is animated on the screen. In embodiments, one or more receiver(s)/target(s) is additionally animated on the screen based on the one or more measured characteristic(s), such as to show the one or more receiver(s)/target(s) catching the ball, dropping the ball and/or moving toward or away from the ball if the ball is underthrown or overthrown.
Any method or algorithm described herein can be embodied in software or set of computer-executable instructions capable of being run on a computing device or devices. The computing device or devices can include one or more processor (CPU) and a computer memory. The computer memory can be or include a non-transitory computer storage media such as RAM which stores the set of computer-executable (also known herein as computer readable) instructions (software) for instructing the processor(s) to carry out any of the algorithms, methods, or routines described in this disclosure. As used in the context of this disclosure, a non-transitory computer-readable medium (or media) can include any kind of computer memory, including magnetic storage media, optical storage media, nonvolatile memory storage media, and volatile memory. Non-limiting examples of non-transitory computer-readable storage media include floppy disks, magnetic tape, conventional hard disks, CD-ROM, DVD-ROM, BLU-RAY, Flash ROM, memory cards, optical drives, solid state drives, flash drives, erasable programmable read only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), non-volatile ROM, and RAM. The computer-readable instructions can be programmed in any suitable programming language, including JavaScript, C, C#, C++, Java, Python, Perl, Ruby, Swift, Visual Basic, and Objective C. Embodiments of the invention also include a non-transitory computer readable storage medium having any of the computer-executable instructions described herein.
A skilled artisan will further appreciate, in light of this disclosure, how the invention can be implemented, in addition to software and hardware, using one or more firmware. As such, embodiments of the invention can be implemented in a system which includes any combination of software, hardware, or firmware. In the context of this specification, the term “firmware” can include any software programmed onto the computing device, such as a device's nonvolatile memory. Thus, systems of the invention can also include, alternatively or in addition to the computer-executable instructions, various firmware modules configured to perform the algorithms of the invention.
According to embodiments, the computing device or devices can include a mainframe computer, web server, database server, desktop computer, laptop, tablet, netbook, notebook, personal digital assistant (PDA), gaming console, e-reader, smartphone, or smartwatch, which may include features such as a processor, memory, hard drive, graphics processing unit (GPU), and input/output devices such as display, keyboard, and mouse or trackpad (depending on the device). Embodiments can also provide a graphical user interface made available on one or more client computers. The graphical user interface can allow a user on a client computer remote access to the method or algorithm.
Additional embodiments of the invention can include a networked computer system for carrying out one or more methods of the invention. The computer system can include one or more computing devices which can include a processor for executing computer-executable instructions, one or more databases, a user interface, and a set of instructions (e.g. software) for carrying out one or more methods of the invention. According to other embodiments, the computing device or devices can be connected to a network through any suitable network protocol such as IP, TCP/IP, UDP, or ICMP, such as in a client-server configuration and one or more database servers. The network can use any suitable network protocol and can be any suitable wired or wireless network including any local area network, wide area network, Internet network, telecommunications network, Wi-Fi enabled network, or Bluetooth enabled network.
The present invention has been described with reference to particular embodiments having various features. In light of the disclosure provided above, it will be apparent to those skilled in the art that various modifications and variations can be made in the practice of the present invention without departing from the scope or spirit of the invention. One skilled in the art will recognize that the disclosed features may be used singularly, in any combination, or omitted based on the requirements and specifications of a given application or design. When an embodiment refers to “comprising” certain features, it is to be understood that the embodiments can alternatively “consist of” or “consist essentially of” any one or more of the features. Any of the methods disclosed herein can be used with any of the compositions disclosed herein or with any other compositions. Likewise, any of the disclosed compositions can be used with any of the methods disclosed herein or with any other methods. Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention.
It is noted in particular that where a range of values is provided in this specification, each value between the upper and lower limits of that range is also specifically disclosed. The upper and lower limits of these smaller ranges may independently be included or excluded in the range as well. The singular forms “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise. It is intended that the specification and examples be considered as exemplary in nature and that variations that do not depart from the essence of the invention fall within the scope of the invention. Further, all of the references cited in this disclosure are each individually incorporated by reference herein in their entireties and as such are intended to provide an efficient way of supplementing the enabling disclosure of this invention as well as provide background detailing the level of ordinary skill in the art.
This application relies on the disclosure of and claims priority to and the benefit of the filing date of U.S. Provisional Application No. 63/583,760 filed Sep. 19, 2023, which is hereby incorporated by reference herein in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 63583760 | Sep 2023 | US |
