Patent Application
20100197406
The illustrative embodiments generally relate to a system and method for ad-hoc networking for the purpose of playing games between a plurality of traveling vehicles.
Mobile ad-hoc networking may include a plurality of mobile nodes, which together form a network. Because nodes are free to leave and enter a given network, and the makeup of the network may depend on the nodes that are present, these networks are often referred to as ad-hoc networks.
An ad-hoc network can be contrasted with a traditional network wherein router topology may be static. In ad-hoc networking the routers may be mobile, and they act in concert to form a temporary network.
Ad-hoc networks may also include one-hop networks and multi-hop networks. In a one hop network, a given device can network with any devices in transmission range. Thus, in this type of network, all devices in a given network are communicating with all other devices in the given network.
In multi-hop networking, certain routers may serve to connect devices not in communicable range of each other. For example, if device A is one hundred feet from device B and two hundred feet from device C, and if device B is one hundred feet from device C, then (assuming that the devices have a transmission range of greater than one hundred feet and less than two hundred feet) device B can serve to pass data from A to C in a multi-hop network. In this manner, a multitude of devices that are out of transmission range of each other can be part of the network, provided there are intermediary devices to pass along the signal.
In one illustrative embodiment, a vehicle communication system includes a computer processor in communication with persistent and non-persistent memory, and a local transceiver operable to communicate with a remote transceiver of another vehicle communication system and in communication with the processor.
This system can be used for playing a multi-player game over an ad-hoc network, and the processor, in conjunction with the persistent and non-persistent memory, may maintain a game state, including a player character. The player character is a representation of the user playing the game.
Because ad-hoc networks often shift makeup, and will likely do so quite often in a vehicle-based networking scenario, the processor is further operable to detect that a transition to a new game has occurred. The processor is also operable to determine whether one or more players from a previous game are present in the new game, and, for at least one of the players no longer present, to determine whether or not that player should be replaced in the new game by a computer-controlled player.
When a game shift to a new game occurs, it is likely that one or more previously present players will no longer be present in the new game. Accordingly, if the processor determines that a no-longer present player should be replaced by a computer controlled player, the processor is operable to create a computer controlled player in place of the no-longer present player. This aids in the seamlessness of the game transition experience.
In another illustrative embodiment, the processor is further operable to detect when the player character has entered a new game and to determine if there are any existing computer controlled characters in the new game. Since a game can have one or more computer controlled characters in it, it may be desirable to replace one of those characters with a new player, as opposed to adding another player. Consequently, the processor is operable to replace an existing computer controlled character with the player character who has just newly entered the game.
In a further illustrative embodiment, the local processor is operable to detect that a signal strength of a communication with the remote transceiver has fallen below a certain threshold. Since a first vehicle may be communicating with a second vehicle that is rapidly separating from the first vehicle, it is useful to be able to track signal strength.
The local processor is also able to determine that a second remote transceiver has a stronger signal strength. This allows the local processor to find a stronger signal to which to connect. The local processor is further able to detect that a remote processor, connected to the second remote transceiver, is running an instance of the same game presently being run by the local processor.
If there is a better connection available to play the same game, the local processor is operable to automatically connect to the second remote transceiver and to join the instance of the same game being run by the remote processor.
Other aspects and characteristics of the illustrative embodiments will become apparent from the following detailed description of exemplary embodiments, when read in view of the accompanying drawings, in which:
The present invention is described herein in the context of particular exemplary illustrative embodiments. However, it will be recognized by those of ordinary skill that modification, extensions and changes to the disclosed exemplary illustrative embodiments may be made without departing from the true scope and spirit of the instant invention. In short, the following descriptions are provided by way of example only, and the present invention is not limited to the particular illustrative embodiments disclosed herein.
In the illustrative embodiment 1 shown in
The processor is also provided with a number of different inputs allowing the user to interface with the processor. In this illustrative embodiment, a microphone 29, an auxiliary input 25 (for input 33), a USB input 23, a GPS input 24 and a BLUETOOTH input 15 are all provided. An input selector 51 is also provided, to allow a user to swap between various inputs. Input to both the microphone and the auxiliary connector is converted from analog to digital by a converter 27 before being passed to the processor.
Outputs to the system can include, but are not limited to, a visual display 4 and a speaker 13 or stereo system output. The speaker is connected to an amplifier 11 and receives its signal from the processor 3 through a digital-to-analog converter 9. Output can also be made to a remote BLUETOOTH device such as PND 54 or a USB device such as vehicle navigation device 60 along the bi-directional data streams shown at 19 and 21 respectively.
In one illustrative embodiment, the system 1 uses the BLUETOOTH transceiver 15 to communicate 17 with a user's nomadic device 53 (e.g., cell phone, smart phone, PDA, etc.). The nomadic device can then be used to communicate 59 with a network 61 outside the vehicle 31 through, for example, communication 55 with a cellular tower 57.
Pairing a nomadic device 53 and the BLUETOOTH transceiver 15 can be instructed through a button 53 or similar input, telling the CPU that the onboard BLUETOOTH transceiver will be paired with a BLUETOOTH transceiver in a nomadic device.
Data may be communicated between CPU 3 and network 61 utilizing, for example, a data-plan, data over voice, or DTMF tones associated with nomadic device 53. Alternatively, it may be desirable to include an onboard modem 63 in order to transfer data between CPU 3 and network 61 over the voice band. In one illustrative embodiment, the processor is provided with an operating system including an API to communicate with modem application software. The modem application software may access an embedded module or firmware on the BLUETOOTH transceiver to complete wireless communication with a remote BLUETOOTH transceiver (such as that found in a nomadic device). In another embodiment, nomadic device 53 includes a modem for voice band or broadband data communication. In the data-over-voice embodiment, a technique known as frequency division multiplexing may be implemented when the owner of the nomadic device can talk over the device while data is being transferred. At other times, when the owner is not using the device, the data transfer can use the whole bandwidth (300 Hz to 3.4 kHz in one example).
If the user has a data-plan associated with the nomadic device, it is possible that the data-plan allows for broad-band transmission and the system could use a much wider bandwidth (speeding up data transfer). In still another embodiment, nomadic device 53 is replaced with a cellular communication device (not shown) that is affixed to vehicle 31.
In one embodiment, incoming data can be passed through the nomadic device via a data-over-voice or data-plan, through the onboard BLUETOOTH transceiver and into the vehicle's internal processor 3. In the case of certain temporary data, for example, the data can be stored on the HDD or other storage media 7 until such time as the data is no longer needed.
Additional sources that may interface with the vehicle include a personal navigation device 54, having, for example, a USB connection 56 and/or an antenna 58; or a vehicle navigation device 60, having a USB 62 or other connection, an onboard GPS device 24, or remote navigation system (not shown) having connectivity to network 61.
Further, the CPU could be in communication with a variety of other auxiliary devices 65. These devices can be connected through a wireless 67 or wired 69 connection. Also, or alternatively, the CPU could be connected to a vehicle based wireless router 73, using for example a WiFi 71 transceiver. This could allow the CPU to connect to remote networks in range of the local router 73.
As one non-limiting example, vehicle 207 and vehicle 205 can communicate to play a game in a one-hop network. Both vehicles can serve as independent nodes for the network, and both vehicles can store a game state. As information is transferred between the vehicles, the respective game states can be updated. If, however, only one-hop networking is allowed, vehicle 207 cannot communicate with vehicles 201 or 203 as long as the shown vehicle arrangement is maintained.
One reason why it may be desirable to limit games to one hop networking is that if vehicle 205 were to accelerate, then vehicle 207 would fall out of effective range of all three remaining vehicles, removing a corresponding player from the games of those vehicles. If, however, maintenance of a game state were desired, the player being removed from a given state could be replaced by a computer controlled player. This would allow players in each vehicle to see a representation of the removed player(s).
On the other hand, multi-hop networking would allow more games with more players to exist, since vehicles could chain through each other to reach players further down the road. For example, in the illustrated configuration, all four vehicles could engage in a game over a multi-hop network. If one vehicle left the network, then the game states in the leaving vehicle and in the remaining vehicles could be appropriately adjusted. This adjustment could include adding computer controlled players (“robots”) to each of the games to replace removed players, or simply removing players from the relevant game states, or any other suitable adjustment.
In an exemplary illustrative non-limiting first person shooter game, the players hunt each other in a maze environment shown in game 301. Because a given player may not be able to observe the entire game space represented in 301 at any given time, the player may not know how many enemies are present in the game. Or, the player may know enemies in his/her proximity (using, for example, radar). Alternatively, a counter may show how many players are currently in the game.
In the progression shown in
Player 1's game state now also contains the new second player, player P2b 311. This player represents a second player who had been playing the game into which player 1 transitioned.
For example, as previously noted, a robot player may replace a real player in one instance of transitioning.
In
Contrast this with player 3 P3427, who is not within P1's sight lines, and thus can be removed from the game without replacement if P1 transitions to a new game. P2b 423 is also added to the new game, since P2b is a real player present in the new game space. Since R1 is not within the line of sight of P2b, the sudden appearance of R1 should not disrupt P2b's game experience overmuch. If R1 were in the sight line of P2b, a decision would need to made as to whose game experience should be disrupted, since either P2a would need to vanish from P1's screen or R1 would need to appear on P2b's screen. This decision could go either way, depending on a developer's desire.
In
In
Again, all of these possible transition rules are exemplary. Different rules can be made and applied to different situations as desired, with at least one general aspect of making game state transitions smooth for players playing the games. At a minimum, some transition rules may be needed because in a vehicular ad-hoc network situation, it is possible that network configurations will not remain for extended periods of time.
Initially, a present connection to at least one other vehicle is tested. This test may need to be performed for each connection to a vehicle engaged in an instance of a game. Further, a determination may need to be made as to whether or not to switch to a new instance of a game. Such a determination can be based on a variety of factors, and may vary depending on how many vehicles are participating in a particular game.
In the illustrative example shown in
In this illustrative embodiment, the vehicle-based computing system first tests a present connection with another vehicle based computing system 501. If the signal strength (or other parameter) is above a predetermined threshold 505, the system does nothing other than continue to retest the connection.
If the signal is below a predetermined threshold 505, the system will then check to see if a counter is above a limit 507. In this illustrative implementation, a counter is used to determine that a signal has been low for at least a period of time before a transition is made. This prevents temporary dips in signal strength from causing transitions to new games. On the other hand, a transition could be made whenever a signal drops below a threshold, however briefly.
If the counter is not above a certain limit 507, the counter is incremented 503 and the test is performed again 501. Otherwise, the system checks to see if a new connection is available 509. If no new connection is available, the system will persist with the present game 515 for as long as possible with the current connection. While this may cause some hiccups in game play, this will still allow a user to continue playing until either a new game is available or until the signal is entirely lost.
If a new signal is available, the system checks to ensure that the new signal is stronger than the old signal. Even if a weak signal is causing a possible transition consideration, the transition would preferably be made to a game with a stronger signal. If the only other existing signal is a weaker signal, that signal may be added to a signal queue for later examination, but the system will not transition to connection with that signal in this illustrative embodiment. Instead, the existing game state is maintained.
If there is a new, stronger signal available, then the system adds the player to the new game 513 corresponding to the stronger signal.
In certain illustrative embodiments, other considerations may occur before adding a player to a new game. For example, if there was a total player cap on a game, then the player might not be able to be added to the game. In an instance such as this, the player might be added to a queue, such as a FIFO queue, so that the player can be added if a spot is freed up in the game. Until the player is added, the player can continue playing the game with the system with which that player's vehicle-based computing system has a weaker connection.
In this illustrative embodiment, the transitioning player is added to the game state 601. The game play may hesitate for a second while the other decisions are made, or the game may begin immediately. While the transition is made, the system considers whether or not other player(s) were present onscreen 603(or in a transitioning player's field of view, or potential field of view, etc.). If there were no players on-screen, then in this illustrative embodiment, the system proceeds to assimilate the new game information 605 and proceeds with the game. If there were player(s) on screen in the old game, the system then considers if there are any players that will be onscreen in the new game 607.
If there are players that will be on screen, the system does not add any robot players, and instead just assimilates the new game information and begins the game. If there are no players in the new game that will be on screen, then the system substitutes robot players to represent one or more players from the old game 609, adds those players to the game 611 (so that other players in the new game have the information for the robot players) and assimilates the information for the new game and begins play.
If a system running the desired game and having the strongest signal is available, the player is added to the game 803. Otherwise, the vehicle-based computing system moves down a list of available systems running the desired game 805, checking to see if the next-strongest signal is available each time 807.
While the invention has been described in connection with what are presently considered to be the most practical and preferred embodiments, it is to be understood that the invention is not to be limited to the disclosed embodiments, but on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.
