KR20030080218A - Integration of real-time data into a gaming application - Google Patents

Abstract

Real-world data is integrated into gaming experiences that affect game and player actions. The game module creates game elements from real world data related to the place. Weather conditions are simulated based on weather information for other observation sites in the world, and traffic conditions are likewise simulated. In a flight simulator game, the game integrates real aircraft and real weather conditions as if the player's aircraft navigates the world.

Description

INTEGRATION OF REAL-TIME DATA INTO A GAMING APPLICATION}

In conventional computer gaming, players are deeply immersed in a closed environment run by an application developer. Even in games simulating real world locations, environmental conditions, actors, and objects are predefined and only vary according to predetermined parameters or algorithms, or at most use virtual random changes. The player's experience is limited to the boundaries of the application developer's thinking and the player's own choices. Conventional game configurations are designed using only the known conditions under which the game will be executed, and are not designed to account for new or randomly changing elements of the real world.

Conventional games do not give players the variability and stimulus that real-world conditions provide. For example, in a flight simulator game, players typically select different weather conditions, traffic conditions, and other characteristics of the game environment. Such an application creates a simulated environment that follows these parameters. For example, a conventional simulator can "simulate" external data, but this data does not reflect current weather or traffic conditions in the real world. Conventional flight simulator add-ons can also update the cloud data before starting the game, allowing the flight simulator to provide cloud coverage reflecting real world conditions at update time. However, the in-game environment is updated only once, pre-executed, and time, so it does not change during the game and real-time data cannot be reflected in game play. In contrast, in the real world, the weather can change suddenly and unexpectedly, air traffic can be unexpectedly bad, machine breakdowns can occur, airports can be closed, and planes can sometimes crash, which is why Ilot must apply these conditions. However, none of these events are modeled in a typical game, or even if they are modeled, they occur in some non-random pattern or only upon selection by the user. Even if these conditions occur in a virtual random pattern, the player quickly learns the range of possible conditions, and still feels the excitement that the condition in which the player is flying is "real" which can provide a large difference in the player's level of enjoyment. I can't give it.

Thus, if you provide players with a true simulation of real-world experiences and provide additional excitement to participate in real-world events when they happen, you need a new game configuration that can incorporate real-world events, environments, actors, and objects during gaming. Shall be.

FIELD OF THE INVENTION The present invention relates to electronic games, in particular games that use real world data to simulate game play.

1 is a block diagram of a system for using real time data in accordance with the present invention.

2 is a more detailed block diagram of a game data server in accordance with the present invention.

3 is a block diagram of a game system in accordance with the present invention.

4 is a block diagram of another weather manager of the present invention.

5 is a block diagram of a weather component dependency in accordance with the present invention.

6 is a diagram of a camera path in accordance with the present invention.

7 is a diagram illustrating interpolation by place in accordance with the present invention.

8 is a diagram of a cloud object grid in accordance with the present invention.

9 is a block diagram of a traffic manager system in accordance with the present invention.

In accordance with the present invention, real-world information is integrated into the virtual environment provided in the game. In an embodiment of software production, the application module receives a place selection from the player. Place selection selects the geographic place where the game will take place, for example San Francisco. The application then retrieves real world information. Real world information may vary depending on the nature of the game. In a flight simulator game, real-world information includes not only weather information such as cloud cover, rainfall, wind and fog, but also traffic data including the location of other planes near the player, modified routes of other planes and airport conditions. For the selected place, information is needed for the time at or near that time. After receiving the real world information, the application module creates a simulated real world construct in response to the real world information. For example, in a flight simulator game, the composition may include clouds, wind, rain and air traffic. Clouds, for example, are created in a virtual environment corresponding to the location and characteristics of the clouds as identified in the real-world database. Air traffic, that is, another plane flying near the player's plane, is created corresponding to the actual location of the real-world plane. In a car racing embodiment, vehicle traffic on a simulated street is made corresponding to real world vehicle traffic on a corresponding real world street. Therefore, the real world is simulated with respect to the player in accordance with the present invention to provide the player with the inherent unpredictable excitement of the real world.

In one embodiment, the application module determines whether information about the place has changed since the last time it was retrieved, or if the player was moved to a new place. In either case, the simulated construct is reproduced in response to the information, or the simulated construct is made in response to an interpolation procedure. This allows real world information to be used even in game environments where real world information cannot be used continuously. For example, at present, air traffic information is available only every two to three minutes, so traffic displayed on the player can be stored in the previous heading and flight plan information until new information is received into the real-world information database. Interpolated based on Weather data is not available at every location and therefore weather data is simulated for places where real world data is not relevant. In addition, all weather elements that may be shown do not appear in the weather database and therefore must be estimated from the available data to represent these weather elements. Therefore, the present invention allows real world data to be communicated with the player. Therefore, if the traffic is bad on a certain day, the player must fly in bad traffic conditions, and if the weather is bad, the player must use his skills to fight poor weather conditions. In response to actual weather or traffic, everything happens in the world at the current location of choice. Therefore, systems, methods, and applications are provided for integrating real-world data into a database to obtain a player's ongoing gaming experience.

Although the description herein uses a flight simulation game as an exemplary embodiment to illustrate the subject matter of the present invention, the present invention is not limited thereto and may be easily car racing, ship racing, cycle racing, skiing or any other game of outdoor game gaming. It can be extended to various games such as shapes. In flight simulator embodiments, two real-world conditions that are useful to integrate into the game are weather and air traffic. Weather and air traffic are both collected by third parties and made available as publicly accessible databases. The database stores information about specific weather conditions for certain places around the world (referred to as "observation places") and stores traffic information including the location, the location of the aircraft, the headings, and the form. The present invention uses this information to enable an exciting, realistic and unexpected gaming experience for the players of the game made in accordance with the present invention.

Referring to FIG. 1, game data server 108 continuously collects “real time” data from traffic and weather data provider systems 100 and 104. Upon request, game data server 108 allows data to be available to games 112 and 116 and players 120 and 124. Data providers 100 and 104 are located at a distance and are typically accessed via the Internet or other communication means (e.g., satellite or rental lines). Data providers 100 and 104 collect and encode observations (weather, aircraft traffic, etc.) relating to the world as they were conventional, and then process them in real time (as soon as possible) in known formats and structures. Available). The game data server 108 of the present invention accesses the data and passes the data to the database storage area. By sending “snapshot” data from the provider 100, 104 to the game data server, a major load of data access from the games 112, 116 is handled between the game and the game data server 108 and associated with the game. Do not process between providers.

One example of the weather data provided includes temperature, wind direction, wind speed, cloud cover and shape, and rainfall type at some altitudes. Examples of air traffic may be location (altitude and latitude), speed, headings, lights and flight plans for each aircraft within a geographic area (eg, the United States). The real-time nature of the data relates to the rate of change of the process being monitored and the frequency available for updating. Weather data is normally updated by, for example, physical (by human) or electronic means in the METAR database and is available once an hour, which is sufficient to capture the normal rate of change in weather conditions. In special cases (in the case of hurricane storms or very bad weather), weather data can be updated even more often. In this regard, real time may be considered once an hour, or sometimes as needed, to reflect the perceived rate of change in the real world. Domestic air traffic control systems typically update traffic data every three minutes to capture aircraft position, heading and speed changes. This is very fast enough to allow the position of the aircraft to be interpolated in accordance with the present invention to provide a realistic simulation of the aircraft's flight path.

If the player 120 controls a gaming unit, such as an aircraft, a car, etc. within the game 112, the game 112 may be moved from the game data server 108 as needed to provide a realistic environment for the game. Request data. The data requested by the game 112 includes data such as weather reports or air traffic in the direction in which the player 120 adjusts the vehicle within the game 112. Therefore, game 112 requests data based on the time and current location of the player gaming unit. Time information may be provided explicitly or implicitly. The period of the data request of the game is preferably in accordance with the period of update of the data in the database maintained by the provider (100, 104). This allows the game 112 to provide the player with the real-time appearing in the world and the vehicle of the world at the fastest speed possible. Alternatively, the request can be made asynchronously, requesting a large amount of data and using it for a longer period of time. The game data server 108 processes the data request of the game 112 and provides the data requested for the game 112 to the rendering and simulation in the game 112. The multiplayer 124 can play different copies of the game 116 and can access the game data server 108 for data corresponding to regions of the same or different world as the player 120. Moreover, the second player 124 can play a game 116 (eg, a car racing game or a football game) that is completely different from the game 112 being played by the first player 120. . However, other games 116 may request the same type of data (eg, weather) as the first game 112. The constructs of the present invention can be broad, to match the data requirements of other games. For example, in addition to weather reports, road racing games can create and use a database that stores real-time data about car traffic. Marine games can collect and store real-time data on sea conditions that can be used in games.

Referring to FIG. 2, game data server 108 has its own air traffic and weather database 200, 204, using the data requested from external air traffic and weather providers 100, 104 as described above. have. In order to control the request form and the period of data made up of the external data system 100, 104, the game server 108 initiates a data request by the timer processors 208, 212. At startup, or upon complete reset, timer processes 108 and 212 instruct data requestor 216 and 220 to request all current data available with respect to weather and traffic. This snapshot of data is used by the data update process 216, 220 to begin to populate the database 200, 204. After the databases 200, 204 are completely filled, then the timers 208, 212 instruct the data request process 216, 220 to request data and for each database 200, 204 for individual data. Update to the best update cycle and duration. As described above, in the example of the weather data, it is performed once in an hour for about 10 minutes. In the case of air traffic data, it is carried out approximately every three minutes. The update time and period used by the timers 208 and 212 are selected to be best according to the update time and period of the data provider 100 and 104.

When player 120 plays computer game 112, the game will request air traffic and weather data in response to a change in the location and time of the player's gaming unit. Requests for data are preferably made through individual air traffic and weather request processes 224, 228. The game 112 requests data in the form of specifying the required data. For example, the game 112 may specify the current position (latitude, longitude and altitude), state heading, and speed of the game aircraft in a flight simulation game. The request for data by the game 112 is made in response to selection and control input by the player 120, for example how and where the player 120 will fly the plane in a flight simulation game. The game data request creates data queries for each traffic and weather database 200, 204 by the air traffic request process 224 and the weather request process 228.

For example, in one embodiment, in order to determine the best appropriate data, the request process 224, 228 may be performed by the aircraft's performance (747vs, Piper cub), state (cruise, landing, day off, taxiing), Consider current aircraft data (position, heading, speed and direction) and previous request data (position, heading, speed and direction). The aircraft state contains the position of the aircraft control (for example, the landing state speeds below 120 kts, gear down, flap> 15 for 747-style aircraft) and the position of the aircraft (4000 feet below and within 10 miles of the airport). .

The request process 224, 228 collects data in the direction of movement of the aircraft and its aircraft appropriately and periodically. In the previous example of landing 747, the request process 224, 228 requests data within 30 miles of the circle around the aircraft at a low rate (once every 10 minutes) because the plane position changes less periodically than when in full flight. . When in the close state, the 747 typically flies more than 400 miles an hour at 35,000 feet. In this case, request processes 224 and 228 request data every 5 minutes within an oval that is 200 miles wide and 400 miles long, with the long length indicating the aircraft's current heading. Of course, other parameters for the data request can be used according to the present invention. Thus, game 112 processes a subset of a larger database 200, 204 that describes the data (weather or aircraft) that the game aircraft emerges but is filtered with respect to the location or route of the aircraft. One advantage of the process described above is that the data required to return to the game is minimized, thus saving time and bandwidth.

In the case of aircraft data, the subset may consist of a list of aircraft data (eg, identification, air route, heading, altitude, and speed) that determine that the request process is within the determined area. In the case of weather, the recovered data constitutes a weather report (temperature, wind direction, dew point temperature (cold), precipitation, etc.) in the area where the weather request process algorithm is determined. The traffic and weather request process 224, 228 may have their specific needs (eg, traffic is only needed within 50 miles of the traffic process 224 to work well, while the weather process 228 works well). (Data may be required within 100 miles).

Referring to FIG. 3, a game system 107 is shown and shown using an object oriented design. These specialized objects preferably store their own data, request data from other objects as needed, and provide data when other objects request them. 3 shows the connection between traffic manager 300, weather manager 304, aircraft manager 308, world manager 312, rendering engine 316, and player control 328. Since all these processes request data from each other, they can be expected as they are on the bus architecture. Other game processes, audio engine 320 and force feedback engine 324 are less tightly coupled and can be input solely from aviation manager 308 and traffic manager 300.

The traffic manager 300 maintains an internal database of real-time traffic in the world that the user experiences. The air controller also simulates the movement of traffic and its control. Based on the state and location and the player aircraft type, received from the player control / game state process 328, the traffic manager 300 may transport traffic from the game data server 108 that will be in a predetermined geographic area around the player's aircraft. Request data. The data is stored in an internal database located in the player's computer that is continuously updated by simulating traffic by these requests and the traffic manager's internal process.

Traffic manager 300 subsequently processes requests for air traffic data locations (places, headings, altitudes, speeds and identifications) from rendering engine 316. The rendering engine 316 may be any conventional rendering process. This data is used to display the aircraft into the world on the game display. The traffic manager 300 also simulates communication of air traffic into the game world based on real time data. Its external realization is the commands sent to the audio engine 336 via communication. The audio engine 336 uses these commands to output realistic audio communication messages to the user (e.g., voice communication from the ATC and aircraft) based on the player's state and other aircraft phases in the game. These messages include messages between ATC and other aircraft and between ATC and player 120. Voice is simulated using conventional techniques as known in the art.

The weather manager 304 maintains an internal database of real-time weather in the world that the user experiences. Based on the player aircraft state data (place, heading, altitude and identification) received from the player control / game state process 328, the weather manager 304 will be in close proximity to the player's aircraft from the game data server 108. Request weather data. The data is stored in an internal database of players that are continuously updated by simulating the weather by a process based on these requests (based on the rate of change of weather data and the speed of aircraft movement) and weather manager rules. The weather manager 304 continuously processes the request for the weather state (temperature, wind, rainfall, visibility) on the general area from the rendering engine 316. This data is used to display real-time changing weather into the world on the game display.

The weather manager 304 also simulates realistic weather changes based on real-time weather feeds within the weather manager 304 and processes that perform according to predefined rules (rule-based processes), Weather effects that cannot be provided by the available real-world data, such as gusts, thunderstorms, cloud movement speeds, slight rainfall intensities, and the like. Rule-based processes that respond to weather changes and trends that depend on distance and time, such as gusts, are called micro level processes. Micro-processes describe trends that can be caused by daily or calendar trends. Examples of micro-level processes are those occurring during the day (thunderstorms tend to occur late in the afternoon) or during the year (heavy stratus and thunderstorms do not tend to occur in the US during winter) It includes. Weather changes are presented to the user through the rendering engine 316. Therefore, using micro and macro processes, since their presence depends on the weather in the real world, it is possible to extend real world data information to create new random game conditions. In addition, these processes are weather effects that will interact with the player's game player when a thunderstorm or storm can significantly affect the driver's ability to drive an airplane in a flight simulation game or drive a car in a car racing game. Make

Micro process

Once the weather data is updated once an hour, one embodiment of the present invention uses microprocess rules to reflect shifts and changes to world data between these updates per hour. These rulesets use simple rules developed to show how data typically changes over time and reflect where the real world data obtained can change over time until the next update is received.

Wind micro process

Wind is reported and indicated as direction, speed and gusts (winds with gusts of 360, 10 kts and 20 kts). This data is typically updated every hour by each reporting station. The weather manager 304 keeps weather observation data for each reported place for the current and previous times. The wind micro process compares the wind direction, speed and gust values of these observation areas and actively changes the wind conditions the player experiences over time.

Change Game Weather to Current Observation Weather

When a new observed weather is obtained, the weather manager 304 changes the wind slowly so that the player knows the location over the next ten minutes. Even if the wind can change rapidly, changing the value over a reasonably short period of time makes the environment more reliable. In one embodiment, game 116 changes the values of direction, speed, and gust by about 10% per minute. For example, the current game weather for a place is direction 180, speed 5, gust 10; Suppose the new observations in the same place are direction 150, velocity 10 and gust 15 at time t. In one embodiment, the wind micro process calculates the difference between the current and new observations as follows.

Direction -30 (150-180), Speed +5 (10-5), and Blast +5 (15-10)

The wind micro process then reflects over the next few minutes that the wind at this location changes by this amount to match the observed value. The weather manager 304 gives 1/10 (approximately the nearest integer) of the reflected change to each value per minute over the next 10 minutes. The value the player sees will change approximately as follows;

: 00 direction 180, speed 5, gust 10

: 01 direction 177, speed 5, gust 10

: 02 direction 174, speed 6, gust 11

: 171 direction 03, speed 6, gust 11

: 04 direction 168, speed 7, gust 12

.......

10 directions 150, speed 10, gust 15

Reflecting weather trends

After a 10 minute period in which the game weather gradually changes to match that of the real weather, the game micro process acts to change the weather for the rest of the time in the direction of the perceived trend. The process calculates a random gradient within the range of the change, and then changes the weather in time to match the change.

For example, an observation reported for a location at time t-1 is direction 200, velocity 5, gust 10, and an observation reported for the same location at time t is direction 1500, velocity 10, gust 15. The wind micro process then calculates the difference between the two observations; Direction -50 (150-200), speed +5 (10-5) and gust +5 (15-10). The wind micro process then selects a random value within the range of change (eg -20, 3, 2) and adds the current weather value to the next reflected weather: direction 120, speed 13, gust 17. The weather manager 304 preferably gives 20% (around the nearest integer) of this reflected change for each 10 minutes until the next temporal update. These changes are as follows;

10 directions 150, speed 10, gust 15

20 directions 146, speed 10, gust 15

: 30 directions 142, speed 11, gust 16

40 direction 138, speed 11, gust 16

50 direction 134, speed 12, gust 17

: 60 directions 130, speed 13, gust 17

Therefore, the present invention actively creates weather effects based on real-world conditions in controlling the gaming experience using wind micro processes.

Macro process

As previously described, the macro process acts to fill or reflect data in time when there is no data. The macro process operates in time between data updates. On the other hand, the macro process acts on a larger scale to add information to the weather data where it is, but this doesn't help much with simulation.

Cycle of Thunderstorm Macro Process

In one embodiment, the macro process is used to calculate thunderstorm cycles in the area. Weather observations for specific areas only list the degree of thunderstorms and their relative severity (reported as severe or not severe). In this embodiment, the present invention augments this data by using simple rules that typically have more thunderstorm clouds or cells within a given area where thunderstorms are occurring in the summer months rather than in the fall or winter. For example, if cloud information occurs in areas where thunderstorms are reported, the program averages the base level of three thunderstorm clouds per sector generated over a year. During the summer months in the Northern Hemisphere (between June and August), additional warming causes more frequent thunderstorms.

In assigning a thunderstorm to a sector, the macro process determines the month the player is currently playing in game 112. This information is readily available from some source or external database, including the player's computer. Between June and August, the process adds a random number to the baseline average, which can cause as many as twice as many thunderstorms per given region. In this way, game 112 causes weather changes corresponding to the current date date and also time of year, providing the player with a different experience based on a realistic process.

Referring again to FIG. 3, the aircraft manager 308 processes and stores information about the player's aircraft and internal systems. The aircraft manager 308 controls input from the player control process 328 (movement of the aircraft, control of the system). The aircraft manager 308 then provides a weather manager 304 for real-time weather information (e.g. rainfall, wind, temperature) that may affect the operation of the aircraft, and a traffic manager providing a display of real-time traffic within the cockpit display. 300 and a world manager 312 for navigation and physical information about the world. The aircraft manager 308 provides aircraft specific information about the aircraft to the rendering engine 316. The aircraft manager 308 also outputs instructions to the audio engine 320 and the force feedback engine 324 as needed to simulate the sound and real-time feel of the aircraft as known in the art.

World manager 312 maintains information about the physical state of the world as known in the art. This includes topography, ground cover, hydrology, building, road and navigational characteristics. The world manager 312 inputs in real time from the weather manager 304 (temperature, rainfall) which can affect the appearance of the terrain. World manager 312 provides navigation and terrain information to traffic manager 300 and aircraft manager 304. World manager 312 also provides information to rendering engine 316.

The rendering engine 316 displays the interior (cockpit) and exterior (territory, weather, other aircraft) states of the game to the user via the display 332 using conventional techniques. The audio engine 320 is a conventional engine that produces realistic aircraft, communication, and world sounds to the user. Based on inputs from the aircraft manager 308 and the traffic manager 300, the event based sounds and spoken communication are output to the user via the audio system 336. Event-based sound (eg, engine noise, cockpit switch movement, or aircraft crash) is generated by the audio engine 320 in response to an event sent to the audio engine 320 by the aircraft manager 308. These sounds are output continuously until they are output once in the case of switch movement or until they change (in the case of an engine drone).

The audio system also produces conversational audio messages generated by the traffic manager 300 from other aircraft and air traffic controllers (ATCs) audible to the user. Acceptable phrases in the game (eg, "turn left to heading 350" or "Roger, left to 350") come first for all positions (ATC, virtual aircraft and player aircraft). These are placed in a database that can be found by the command. A voice actor is any word or number contained within every phrase performed at that location (e.g. words: turn, left, right, to, from, heading). (heading), 0, 1, 2, 3, 4, 5, etc. have been recorded by the person controlling the ATC controller. They are placed in the database so that they can be found by location and word.

When a communication command is received by the audio engine 320, all the information that is specified and needs to be populated within the phrase: location (ATC, player aircraft, virtual aircraft), command (e.g. TURN-TO-HEADING) and phrase ( Direction: left, Heading: 350) contains some specific data needed to fill it. The audio engine 320 then finds a phrase for that location, finds voice data of the word data recorded for that location, and uses the conventional process called " stitching " with the command indicated by the phrase. Output from the audio speaker.

The force feedback engine 324 provides force feedback information to the user through haptic hardware contained within the joystick, as known in the art. Feedback information is generated in response to input from the aircraft manager 308. Examples of this feedback include vibrations caused by control pressures, wheel spin vibrations, touchdown bumps or aircraft engine problems.

The player control / game state process 328 controls the start and execution of the game from selection and control information from the user and provides current information to other engines for the gaming units controlled by the player. It also keeps data about the state of the game and the world.

Joystick 340 allows a user to enter the game through player control / game state process 328. These inputs may include control information (shifting, pitch, roll), throttle position, function selection (eg, lowering gear or flap control). The user also receives appropriate force feedback information from the game via force feedback engine 324. Keyboard 344 is a standard computer keyboard. Players use coded key presses and macros to control the game structure and aircraft.

Therefore, the present invention provides a system for integrating real-world data into a game and influences the player's experience of the game in a realistic and random way (to the extent that the real world is random), so that real-world weather and traffic data affects the game's outcome. To influence.

The following description describes two key elements in a flight simulator embodiment of the present invention: a weather engine and a traffic manager.

I. Weather Engine

4 shows a relationship between the weather engine 400 and the weather manager 304. The weather engine 400 receives weather input data (observation values) from the weather manager 304 and performs current weather state calculations when the weather manager 304 requests the data. As mentioned above, the weather manager 304 stores weather data that is used to describe the weather around the aircraft or some other viewing position required for the game. In a preferred embodiment, the weather engine 400 is an independent module that performs interpolation for weather simulations. When the actual real world data is not available every time and place where the player is playing the game 112, the game 112 interpolates the data based on the real world data to control the game play.

The input of the weather engine 400 is preferably a set of weather observations with specific location and time values. The output of the weather engine 400 is an interpolated weather status for some specific place and time value. The weather engine 400 then changes the weather in-game to smoothly bring the player 120 a realistic real-time weather experience when the player's aircraft moves from one place to another, or when the player's aircraft moves in time. to provide. In addition, the weather engine 400 creates both "point" weather phenomena for most weather elements and "environmental" phenomena for some clouds. The weather engine 400 is coupled to a weather element database 404 that stores attribute information for various weather elements that can be used to generate interpolated weather.

Weather elements

The following is an exemplary list of weather elements stored in weather element database 404.

·cloud. Clouds are divided by cloud form and cloud layer. Clouds are characterized by the following properties: cloud shape, bottom elevation, top elevation, and density (range).

·wind. The wind is separated into layers, and the wind changes linearly between layers. Wind is specified by the following attributes: height, direction, and speed. Also, gusts and local squalls can be specified.

Visibility. Visibility is specified by the number of miles visible horizontally. Limit visibility is achieved by displaying haze and fog.

·Temperature. The temperature is specified in degrees Celsius.

·pressure. The pressure is previously specified.

Precipitation. Supported rainfall is rain, snow and hail that can coexist. Rainfall is characterized by density.

Thunderstorms . Thunderstorms are characterized by power.

Icing . The possibility of icing is expected depending on other weather factors and is described below.

·turbulence. The possibility of turbulence is expected depending on weather factors.

Dependency of weather elements

A viewpoint is a set of weather data collected and reported in a weather database prepared by weather data provider 104. Some weather components are determined at the viewpoint, while others are synthesized according to different weather components. For example, "icing" and "turbulence" are not specified at the viewpoint, and are therefore calculated according to the presence and extent of other weather elements. 5 is a block diagram showing different elements, their output and other elements (if necessary) on which they depend. Different weather elements require different outputs. Rainfall, for example, requires rendering and audio and is synthesized based on cloud and temperature information. Icing is synthesized based on temperature and visibility factors. However, the clouds themselves are also rendered, which are based on actual data for a given viewpoint or interpolated when the current location of the gaming unit is between the locations of observation.

A. Weather Element Interpolation

The main goal of weather interpolation is to smooth the weather when moving from one place to another, or moving to the current place and time of the player's gaming unit in time based on the time and the interpolation of weather elements for these observations close to the place. To change. The following algorithm is an example in which weather interpolation is performed by time and place quantum using observation points with actual weather data.

Step 1. Filter weather observation by place

The first step in weather interpolation is to select the relevant observation site to be used for interpolation. 6 shows the process of the recurring selection block, where the observation location is selected. All observations are stored as blocks, which are specified by latitude and longitude values. The task is to select, in time and space, an observation location close to the player's current location. First, the weather engine 400 processes the block surrounding the location of the aircraft to determine if the block includes an observation location. Then, if the block does not include a viewpoint, the weather engine 400 processes the blocks around the block that contain the location of the aircraft, as shown in FIG. However, FIG. 6 includes blocks closest to the current location by increasing the radius of the search if there are no observation points in the location of the aircraft. The weather engine 400 then processes the next nearest block in the next pass, as shown in FIG. The weather engine 400 stops on any pass if any viewpoint is found within the pass. These observation points are used for interpolation.

Step 2. Interpolation by Time

The second step in weather interpolation is to select relevant observations based on the current time value. For each of the observation sites selected in the first step, the observation place closest to the current time value (closest to the minimum and maximum time values) is selected.

The following cases may occur.

All observation places found in step 1 are in the past. In this situation, the weather engine 400 will select the last observed location in time by interpolation.

All places of observation are in the future. In this example, the oldest viewing place is selected.

Observation sites exist in both the future and the past. In this case, the weather engine 400 selects the last observation site in the past and the nearest observation site in the future, and an interpolated observation site is created based on the weather elements for each observation site. In one embodiment, the interpolated observation location is selected linearly according to the current time value and the selected observation time value.

Step 3. Interpolation by Place

Next, interpolation observations for the camera locations are made according to all observation sites selected and interpolated in the previous step. 7 illustrates one embodiment of an interpolation mechanism, where Di is the square of the distance between the camera location and the observation location #i; Unstandardized weight for observation #i is calculated as 1 / Di; The total weight of normalization is calculated as the sum of the unstandardized weights: {S = 1 / D1 + 1 / D2 + 1 / D3 ....}, and the standardized weight for observation #i totals the non-standardized weight Division by weight: Calculated as 1 / (Di * S).

A special case exists when there is one or very dense observation site (Di is about zero). In this case, the closest observation place in time is selected as the observation point for the camera place.

Step 4. Calculate undefined elements

Some weather elements will not exist for the selected location of observation. In this case, the values should be calculated after interpolation of the current weather component according to the specific weather component rules. For example, pressure is calculated through a standard pressure reduction table. Icing is calculated taking into account rainfall, cloud shape and temperature at that location.

Step 5. Interpolation by Height

Some weather components are defined as layers (eg wind), but are calculated as specific camera height locations (wind and then temperature, icing and turbulence). For these elements, the weather element values must be linearly interpolated between the nearest layer values. In addition, wind calculations at certain heights take into account gusts that can cause random changes in wind speed and direction.

B. Cloud Interpolation

Important cloud ranges in flight simulation games are also preferably interpolated in accordance with the present invention. In one embodiment, the cloud object is executed in a grid that moves as the player's aircraft moves. The cloud parameters are calculated according to the real world observation data that is interpolated for each vertex of the grid. 8 shows the cloud object for the about 2/8 cloud range. Each cell in the grid contains one cloud object. The location of the cloud object is random in each cell, but larger clouds (larger cloud range) will have fewer places "freedom". Therefore, for the full range, each cloud object is exactly within the grid vertex. The size of the cloud object is calculated according to the current cloud range value as obtained from the observation data. In one embodiment, random values (both positive and negative sizes) are added to provide more realistic simulations. Each cloud object has a corresponding seed value to shape the cloud. Seed indicates the amount of cloud swirling up per cycle. The seed value is preferably smoothly changed over time to emulate realistic changes in cloud form. In addition, each cloud object has a random random value that does not change over time. The yaw value is determined by the angle from the vertical to which the cloud swirls.

Cloud grid generation

Cloud grids are generated for each cloud layer and for each new aircraft. For each grid vertex (cloud object), the following values are generated during grid generation.

Size variation coefficient, size variation ranging from minimum cloud size variation to maximum size variation

Offset variation, range from 0 to 1

Initial seed value, in the range from 0.0 to 255.0

Cloud grid handling for moving aircraft

The cloud grid is always aligned with the cloud grid step value. Therefore, when the aircraft moves to a new position, some grid rows and / or columns may be deleted and new grid rows and / or columns may be added (when the movement is large enough). In this case, the memory block (moved to the vertex but still exists) is moved and a new vertex (cloud object) value (as defined in the previous section) is generated.

Vertex value calculation

The value for each vertex is also recalculated for each weather cycle in one embodiment. In this embodiment, the following values are recalculated.

size

The cloud size is calculated according to the cloud range (Cloud Density, a value in the range 0-1), such as Cloud Density * cloud grid step * Size variation. The calculated cloud size is in the range of 0 to cloud grid step. This value is adjusted for overflow cases.

Cloud height

The height of the cloud is the current height of the cloud layer at the place.

offset

The cloud offset from the grid vertex is calculated as (cloud grid step-cloud size) * offset variation.

Seed value

The seed value is calculated according to the deleted time value (time_t, seconds) as Current Seed + Time Elapsed * CLOUD_SEED_CHANGE (CLOUD_SEED_CHANGE is the subject of fine-tuning, and a value of 0.2 can be assumed first).

C. Icing Module

In a preferred embodiment, the present invention uses real time data to simulate icing conditions on the aircraft. Icing conditions are not provided by real-time data but are weather effects that occur and occur by real-time data. Icing conditions are also weather effects that have a direct effect on the player's gaming experience, as severe icing tides can malfunction and even crash the plane. In one embodiment, the icing module is a module included in the weather engine 400. The icing module is taken as input information about the weather that determines the presence and severity of the icing. The icing module also receives configuration information about the aircraft, including the phenomenon of the deicing system on the aircraft. The icing module calculates and stores the icing presence and level on the aircraft based on weather, aircraft configuration, aircraft location and pilot action. It can reflect the differences in the severity and severity of the icing and the effects of different aircraft configurations. The output of the icing module is the maximum level (0.0 to 1.0) percent of icing for some major sections (windshield, side window, wing, fuselage, and engine intake) of the aircraft that have been badly resulted by the icing. This data is used by other modules in the aircraft system model (dynamics, engine), resulting in realistic changes in aircraft performance and handling. This data is used to display the realistic effects of icing (icing on airframes, reducing the visibility of the iced window) to the user.

1. Icing high level process

In one embodiment, at the highest level, the icing module is represented by a loop consisting of:

1. Enter the aircraft and world current state

2. Icing accumulation calculation

3. Icing Decomposition

4. Updated state output on the aircraft's eye

5. Repeat

Because this model takes as input some variables that are acted upon by the user, the module is well planned and runs at a rate that allows the user to see changes in icing. However, since ice does not freeze or melt at high speed, it is usually sufficient to run the module once every 5 seconds.

2. Icing common variables

From game state control 328:

Aircraft location (latitude and longitude)

Aircraft altitude (feet)

Windshield_deice-on (Boolean indicating whether the windshield deicing system is currently running)

Wing_deice-on (logic indicating whether the wing deicing system is currently running)

These variables will be FALSE on aircraft that do not include these systems. In one embodiment, the system may be FALSE even if the user moves control to TRUE by disabling the system.

From weather manager 304:

· Ground temperature at current location

OAT (outside air temperature), which is calculated using a standard decay calculation of 3 degrees above 1000 feet from ground_temperature (specified at 70 ° F ground_temperature). Can be.

Cloud_range (cloud_range at its location and altitude). This is represented by a number between 0 (no clouds) and 1 (full range) at that altitude in the weather weather rectangle that contains the location.

3. Icing specific variables

The following variables are stored by the icing module and are available for other models. The variable can have a value between 0.0 (no ice) and 1.0 (fully iced).

Windshield_Icing (Icing level of visible windshield on the front of the aircraft)

Side_Window_Icing (Icing Level on Side Window)

Wing icing (Icing level on the wing)

Fuselage_Icing (Icing Level on Fuselage)

Engine_Suction_Icing (Icing Level of Engine Suction)

Each of these variables can change their levels to other levels based on the aircraft's platform and configuration.

4. Icing Processing:

Approximation of the effects of icing on aircraft in the real world is used by the present invention to calculate the icing effect.

I) input state data

Access and read game state and weather data with icing modules

ii) icing accumulation calculation

Icing on the aircraft accumulates according to various surface variables when the aircraft is in visible moisture (clouds) and the outside temperature (OAT) is within temperatures (10 and 30 ° F) where moisture can freeze upon contact. Warm temperatures will melt the icing. At cold temperatures, moisture will not melt on contact.

For example, higher rates of accumulation can occur in cloud ranges (clouds that can flow through) that are higher than severe percentage ranges. This speed may also vary depending on aircraft configuration and icing type or altitude.

In one embodiment, the algorithm below is used to calculate the icing accumulation.

((Cloud_range> =. 1) and (cloud_range <.7)), and ((OAT> = 10 and (OAT = <30)).

Windshield icing = Windshield icing + .01

Side_Window_Icing = Side_Window_Icing +.005

Wing Icing = Wing Icing +.01

Fuselage_Icing = Fuselage_Icing +.01

Engine Suction Icing = Engine Suction Icing +.01

(Cloud_range <.7), ((OAT> = 10 and (OAT = <30)).

Windshield icing = Windshield icing + .02

Side_Window_Icing = Side_Window_Icing +.01

Wing Icing = Wing Icing +.02

Fuselage_Icing = Fuselage_Icing +.02

Engine Suction Icing = Engine Suction Icing +.02

iii) Icing decomposition calculation (melting by air or dice equipment

Dissolution by atmospheric effect

There are two ways to remove icing in the real world. One is to fly to warmer areas or altitudes because temperatures can melt the icing sufficiently. This may be an OAT greater than 32 ° F. However, even though the pilot may fly from an icing condition that will no longer accumulate icing, the OAT may not be warm enough to melt the ice.

One algorithm that calculates deicing based on flying to warmer areas is

(Cloud_range <.1), and (OAT = <32).

Windshield icing = Windshield icing-.01

Side_window_icing = side_window_icing -.005

Wing Icing = Wing Icing -.01

Fuselage_Icing = Fuselage_Icing -.01

Engine_Suction_Icing = Engine_Suction_Icing = Engine_Suction_Icing -.01

iv) deicing by use of aircraft equipment;

Another way to remove icing is to use deicing equipment. Icing equipment is often unreliable and difficult to apply consistently and efficiently. If the pilot does not apply this equipment frequently, ice builds up and the icing equipment cannot dissolve the ice. For example, the deicing value may be set to half of the total amount if the equipment is not used with enough icing equipment.

Although the deicing equipment can work effectively, the deicing equipment does not cover all aircraft. The deicing equipment is finally also possible at a higher level of accumulation period during the icing condition and cannot be kept deiced.

One algorithm for calculating deicing using deicing equipment is

If windshield ice-on

Windshield icing = windshield icing-.01

If wing_icing_on

Wing Icing = Wing Icing -.01

The first algorithm emulates icing dissolution by warming the temperature sufficiently and not having the aircraft in the cloud. The second algorithm emulates ice removal by having either a windsea deicing on or a wing deicing on.

Therefore, for each loop (cycle in the game), the deicing equipment will attempt to remove ice from the wings and windshields. However, as mentioned above, the deicing conditions of the present invention offer the possibility that in practice the icing will overwhelm the equipment and / or aircraft if the pilot does not fly away from the icing state.

v) output state of the icing variable

The input state of the icing variable is modified by the accumulation and decomposition model. The result is available to other modules and external modules. Some examples of how these variables are used are described below.

a) aircraft system model

The aircraft system model is a conventional model that simulates the flight of an aircraft.

1.Calculation of the lift

Ice buildup on the wing reduces the lift produced by the wing by half. Therefore, the icing model adjusts the aircraft system model as follows: lift = lift * (wing_icing * .5).

2. Calculation of drag

Ice buildup on the wings and fuselage adds more than 25 percent drag on aircraft performance. Therefore, in this example, the aircraft system model is adjusted as follows: drag = drag * (1 + (.125 * (wing_icing + fuselage_icing))).

3. Calculation of weight

Ice buildup on the wings and fuselage can greatly increase the weight of the aircraft (up to 25% or more in this example). The adjustment is,

Aircraft_weight = aircraft_weight * (1+ (1 + (. 125 * (wing_icing + fuselage_icing)))).

4. Calculation of engine performance

Engine intake icing can affect engine performance by limiting the amount of air available. The adjustment is,

Thrust = Thrust-(Drust * Engine_Suction_Icing).

5. Calculation of effects on aircraft equipment by fuselage icing

Icing may also have an effect on the operation of aircraft gears, flaps and mechanisms (icing covers):

(Body_icing> .6), flap-actuation = FALSE);

(Body_icing> .7), gear-actuation = FALSE);

(Body_icing> .8), static_mechanical-actuation = FALSE);

b) Icing Render Model

These are examples of render decisions that can be achieved by the results of the icing model. The renderer displays to the user a view of the outside world and the aircraft. This includes windshields, side windows and generally aircraft.

1. View from Windshield

The view from the windshield is generally clear. In the icing condition, the visible amount is reduced by the windshield icing amount. Here, the lined icing windshield display may be pre-rendered and displayed based on the windshield icing value.

Windshield panel = windshield icing panel [windshield icing]

2. View from the side window

The view from the side window is not clear by the percentage of window_icing indicated by that variable. Here, the lined icing window display may be pre-rendered and displayed based on the window_icing value.

Window_panel = window_icing_panel [windows_icing]

c) aircraft rendering

The aircraft itself as seen by the user is changed in accordance with the values relating to windshield icing, window icing and fuselage icing. Preliminary rendering, which shows the effect of icing at various levels of substantial accumulation, is added to the aircraft model according to the values of these variables. The user sees this accumulation when viewing the window as well as when the external view is selected. This includes a number of arrays and calculations as shown above.

Therefore, the icing module provides a realistic and exciting gaming experience based on current and actual weather conditions using real world data as a base for generating icing effects that interact with the rendering of the aircraft and the control of the player's aircraft in accordance with the present invention. .

II. Traffic manager

Referring to FIG. 9, the traffic manager 300 is composed of several independent processes that perform each function. The traffic engine 900 creates, manages, and updates all aircraft in the player's game 112. The traffic engine 900 first requests player aircraft data (position, altitude, heading, speed and configuration) from the player control / game state engine 328. This data is used to formulate a request to the game data server 108 for aircraft traffic around the player aircraft as described above. The traffic engine 900 uses the returned data to create an aircraft in the game 112. The traffic engine 900 uses the traffic database 904 to manage this data, which includes a list of all active aircraft near the player aircraft, including the player aircraft. The information stored in each database entry typically includes an aircraft identification number (eg, TWA714) and a single pointer to the virtual and player aircraft objects generated later by the traffic engine 900 in the process. The traffic database 904 is also used to identify and access traffic objects by other processes in the game 112.

In addition to adding the traffic database 904 to the aircraft entry, the traffic engine 900 also manages the database 904 by removing entries from the database 904 that are now outside the player's region. In one embodiment, the traffic engine 900 removes entries from the traffic database 904 for any aircraft that has not received a report for three update cycles. As mentioned above, updates to the database 904 are accepted for aircraft within certain geographic area of the player's aircraft. Therefore, the absence of a report indicates that the landed aircraft or its location is now far enough away from the player's aircraft, so the aircraft is already having nothing to do with the player's game 116.

The traffic engine 900 first creates a single ATC process 908. The ATC process 908 appears to the player as the actual ATC controller because the ATC process 908 controls and communicates with the virtual aircraft process 916 and the player aircraft process 932. The ATC process 908 also includes a link with the traffic database 904 to access data of all relevant aircraft (eg, current speed, heading, altitude).

The traffic engine 900 then creates a virtual aircraft process 916 for each playerless aircraft once information about the new playerless aircraft is entered into the traffic database 904. The traffic engine 900 also continuously sends data report updates on the actual aircraft to the virtual aircraft process 916. This data is used by the virtual aircraft process 916 to match the location and configuration of the virtual aircraft with the location and configuration of the actual aircraft. Each virtual aircraft process 916 appears and acts on the player 120 as a real aircraft in the world. Virtual aircraft data includes position in the world (x, y position, heading, speed and altitude), aircraft identification and state (gear position, flap position, etc.). This data is maintained internally and can also be issued in response to data requests from other game processes such as ATC process 908 and rendering engine 316. The communication / control link with the ATC process 908 is also established during creation. This link allows the virtual aircraft process 916 to create a communication command and respond accordingly to the ATC process 908. Audio communication generated by the virtual aircraft process 916 is accomplished by sending a communication command to the audio engine 320.

The traffic engine 900 also creates a player aircraft process 912 that is externally linked to the player control / game state engine 328 and internally to the ATC process 908. This allows the ATC process 908 to be monitored to talk to the player. Information and intentions about the player aircraft may access the ATC process 908 through a process that reflects data from the player control / game state engine 328 to the player aircraft process 312. The ATC process 908 also preferably communicates with the player through a conversational communication command sent to the audio engine 320 (finally listening). The player responds to and interacts with the controller through the interface provided by the player control / game state engine 328 (control, menu, and keyboard commands).

A. Virtual Aircraft Process Algorithm

Each virtual aircraft process 916 preferably includes separate modules, simulation execution units and a common database that handle communication, navigation and control, and rule-based decisions. The simulation runner plans the execution order of the individual modules. In one embodiment, after startup, the process execution order is:

1. Communication module (new data and command input)

2. Rule-Based Logic Modules (Respond to Update Data)

3. Navigation and control module (moving aircraft according to current aircraft target)

4. Communication module (data and command outputs)

5. Repeat

Common database

The common database is used to store reports received from the traffic engine 900.

2. Communication module

The communication module manages all communication between the virtual aircraft process 916 and other external processes. It uses a common database as a locale to store new data and messages, or to send data to external processes. Data input by the communication module includes an update report from the traffic engine 900, a command from the ATC process 908, and a data request by another process. The communication module outputs data to an external process based on a message guided by another module. Data output by the communication module includes messages for the ATC process 908 and the audio engine 328, data requests for other modules, and location updates for the rendering engine 316 and other processes.

3. Rule based logic module

The rule-based logic module controls the actions of the virtual aircraft in response to the change state of the virtual aircraft and the world of change around it. If real-time data received by the virtual aircraft is changed by date, location, and weather, it interacts with these rules to provide an impact of real-time data on the player's experience in the game. Examples of these preprogrammed and flexible action rules include those that react to the aircraft's change position, ATC communication and control, and the player aircraft's position (as controlled by the player). For example, one rule that responds to the location of the aircraft includes the need to inform the air control process 908 that the virtual aircraft is within 50 miles of the airport and is already ready for landing. This can also be an audio message that the player can hear.

One example of a rule is:

If the (x, y) location is within 30 miles of the destination airport,

(Notification of proximity to the airport, aircraft_id, location, altitude) to the atc_controller

(Notification of proximity to the airport, aircraft_id, location, altitude) may be sent to the audio engine .

The virtual aircraft also responds to commands by the air traffic controller. If the aircraft is close enough to the airport, the ATC controller instructs the (virtual) aircraft to stop along the path of the actual aircraft and then to land. The virtual aircraft reacts by changing the navigation module to follow the ATC command and, according to the command, notifies the ATC process 908 of receiving the command and informing the same command via audio.

One algorithm that achieves this behavior is:

atc_control = FALSE,

When we receive (turn-left-heading, 350) from the atc_controller,

set atc_control to TURE state,

Normal navigation stops,

(Turn_left_heading, 350) to the navigation and control process,

(Notifies turn, left, heading) to atc_controller,

(Notifying turn, left, heading) to the audio_controller.

The virtual aircraft 916 can also respond to the movement of the player aircraft. The virtual aircraft 916 may include rule-based logic that monitors for any upcoming aircraft and moves away from it (eg, if the player aircraft attempts to collide). If this happens, the virtual aircraft rule-based logic can instruct the aircraft to stop normal navigation, fly away from the position of the player aircraft, and send a complaint message to the ATC. An example of an algorithm that achieves this behavior is:

If Player_Aircraft (Location) <1 mile,

Normal navigation stops,

Move away from (player_airplane (location)),

(Closer aircraft complaint) to atc_controller,

Send (closest aircraft complaints) to the Audio_EngineWill.

If the player aircraft moves away from the virtual aircraft, the following rules revert to normal operation of the virtual aircraft:

Player_air (location)> = 1 mile

Home with normal navigation

(Aircraft left) to atc_controller,

Sends (left aircraft) to Audio_Engine.

B. Navigation and Control

The navigation and control module includes the functionality of a conventional autopilot. Using the prior art, the virtual aircraft can be navigated and controlled by subsequent report updates stored in a common database. However, in accordance with the present invention, the navigation and control module may also follow the navigation commands issued by an internal rule-based logic module or an external ATC process 908.

The navigation and control module uses report updates to match the virtual aircraft's aircraft position, altitude, speed and heading to those of the actual aircraft. Once the report data (location, heading, speed and altitude) is updated by the traffic engine 900 about every three minutes (as described above) in one embodiment, the navigation and control module can track the movement of the aircraft between these updates. Estimate its own data, which is described in more detail below. Interpolation of the virtual aircraft's current position, heading, altitude, and speed is sent to the rendering engine and made available to other processes in the game.

In addition to matching the movement of the actual aircraft, the navigation and control module may also respond to certain navigation commands. These commands may be issued by the ATC process 908 or by a rule based logic module. Examples of these commands include the following:

Turn (left or right) to a specific heading.

Altitude (falling, rising or holding)

Speed (increase or decrease) with some value

Fly directly to the point (x, y position and altitude)

Hold at a point (circulate at a specific x, y position and altitude)

Approach and land at the airport

Move from position (slightly x, y)

Normal navigation (stop, restart) (update report next time)

Cleared for approach

Cleared to land

These commands are in a simple format that can be easily passed between processes (eg, a command for "turn left to heading 350" may appear as (turn_left_to_heading, 350).

C. Navigation and Everaging Between Aircraft Observations

In order for a virtual aircraft to operate in a reliable fashion, it must transition smoothly between location reports. These reports include reported headings, speeds, altitudes, and X, Y (latitude, longitude) positions. A virtual aircraft is first created at the location (X, Y latitude, longitude) of the most recent report for the actual aircraft that initially represents the aircraft. It is also generated from the aircraft's heading and airspeed at the actual aircraft altitude. The virtual aircraft is then "driven" forward from the location using the heading, speed and altitude. The change in position of the virtual aircraft is calculated internally by the output to the aircraft agent and rendering engine 328. This continues until the next report (latitude, longitude, altitude, heading and speed) is received from the actual aircraft. The virtual aircraft process 916 then compares the difference between the position of the virtual aircraft and the position of the actual aircraft in the game 116. First, process 916 calculates a vector that includes headings, speeds, and elevation changes that move directly toward that location (the aircraft can thus catch up to the actual location of the aircraft). Then, add the vector (using vector addition) to the heading, altitude, and velocity vectors of the report from the actual aircraft (the vector of the actual aircraft reflects where the aircraft wants to go). The virtual aircraft process 916 then instructs the virtual aircraft to change the course, heading, and speed to match the vector. Therefore, the composite vector reflects not only the actual aircraft position, but also the changes necessary to better reflect the movement along the actual course.

Finally, in accordance with the present invention, the autopilot is programmed for heading and highly smooth turns and transitions. Rather than commanding a fast move to a change in the vector, the autopilot manages the change in about 30 seconds. After the virtual aircraft is stable in the vector, it continues to move along the vector until the next update where the process is repeated.

D. Avoid player aircraft

Another issue in integrating real-time data in the game is controlling the interaction between the player aircraft and the virtual aircraft. In one embodiment, rules are used to land the virtual aircraft on the player controlled circuit. First, the virtual aircraft flies away if the player aircraft is in range of the virtual aircraft and moves quickly toward it. Second, if the player aircraft approaches at a slower speed, the virtual aircraft does not move away from the player aircraft. Third, as long as the player aircraft approaches at a sufficiently slow speed, the virtual aircraft allows the player aircraft to fly close (within maximum range). Fourth, as the player aircraft moves to the maximum sole range, the virtual circuit attempts to fly away from the player aircraft. These rules allow the player aircraft to interact with real-time virtual traffic without causing a collision. The player can then develop the skills of the flight formation by making slow movements to the virtual aircraft. The player also intentionally attempts to fly with a virtual aircraft, forcibly leaves the course, or flies to a ground object or mountain. In one embodiment, if the virtual aircraft and the player aircraft collide with other objects, the colliding objects explode and the game session ends.

The following is an embodiment of an algorithm that achieves the above rules:

Calculate distance _{PS to P} , closure rate _{PS to P} and avoidance vector _{PS to P}

The distance from the virtual and player aircraft is calculated as the cube root of the squares of X and Y and the square of the altitude difference. For each, X and Y are converted from latitude and longitude to pit from 0 latitude and 0 longitude point. Altitude A is expressed in feet.

Distance _{PS to P} = (X _PS -X _P ) ² + (Y _PS -Y _P ) ² + (Z _PS -Z _P ) ² ) ^1/3

Where P is the value from the player aircraft and PS is the value from the virtual aircraft.

The ratio _{PS to P} of the closure is calculated by comparing the value of the distance _{PS to P} from one calculation cycle to another. Once the distance is calculated for each second, the rate of closure per second over the period becomes the previous distance value _{PS to P (t-1)} minus the current distance value _{PS to P (t)} . For example, if the previous value is 1400 feet and the current value is 1200 feet, the closure rate would be 200 feet / second.

Evasion vector

The virtual aircraft monitors the player _PS 's distance _{PS to P} and the closure's rate _{PS to P} (about once per second) for each game cycle.

If the distance _{PS to P} <1500 feet, and the closure rate _{PS to P} > = 25 feet / minute, the virtual aircraft

a. Autopilot turn off (for example, stop next location report)

b. Sends a randomized audio message every minute with the effect that "the aircraft is too close to me"

c. Evasion vector at twice the rate of closure _{PS to P} In the direction of, move away from the player aircraft to 1500 feet / minute or maximum allowed by aircraft performance.

This algorithm refers to the situation where the player aircraft starts moving towards the virtual aircraft at high speed. If the closure rate _{PS to P} is 25 feet / minute and the distance _{PS to P} > 50 feet and the virtual aircraft autopilot is off, then the virtual aircraft process 916

a. Autopilot turn on.

b. Restart normal navigation.

c. Move the virtual aircraft back to its original course.

d. In one embodiment, "Who is in normal flight with us" will output the audio message as an effect.

This algorithm refers to a situation in which the player aircraft moves rapidly toward the actual aircraft, but has been slowed down at a reasonable closure rate.

If the distance _{PS to P} <50 feet, the virtual aircraft process 916

a. Autopilot turn off (for example, stop next location report)

b. Send a randomized audio message every 15 seconds with effect "You are getting too close"

c. Evasion vector at twice the rate of closure _{PS to P} In the direction of, move away from the player aircraft to 1500 feet / minute or maximum allowed by aircraft performance.

This algorithm refers to a situation in which a player aircraft flies close to the virtual aircraft (normally) and then begins to move towards the virtual aircraft intentionally or by mistake.

If a virtual aircraft collides with any other object on the ground or player aircraft,

a. The virtual aircraft outputs a random audio message.

b. Virtual aircraft explodes.

c. The game session ends.

If the distance _{PS to P} <10 feet (indicating that the aircraft is probably crashing),

a. The virtual aircraft outputs a random audio message with the effect "it is a dumb".

b. Virtual aircraft explodes.

c. Player aircraft will also explode.

d. The game session ends.

D. ATC Process Algorithm

The ATC process has a similar configuration as the virtual aircraft process 916. The ATC process includes a simulation execution unit, a common database, individual modules that handle communication, and rule-based decision units.

The simulation runner plans the execution order of the individual modules. After startup, the process execution order is:

1. Communication module (new data and command input)

2. Rule-based logic module (responds to updated internal and external data)

3. Communication module (data and command outputs)

4. Repeat

1. ATC Common Database

The ATC common database is used to store data about the aircraft under control and internal target data and the state of the ATC process 908 itself (eg, how the aircraft will be controlled). The common database is also used to provide a common communication configuration for other process modules. Changes to the database are entered and activated by the module.

2. ATC communication module

The basic operation of the communication module is similar to that used in the virtual aircraft module. The ATC communication module manages all communication between the ATC process 908 and other external processes. Storing new data and messages, or sending data to external processes, uses a common database as a local. Data input by the ATC communication module includes location reports from the virtual aircraft and player aircraft processes 912 and 916, requests and responses from the virtual aircraft and player aircraft processes 912 and 916. The ATC communication module outputs data to an external process based on a message guided by another module. The data output by the ATC communication module includes a message for the virtual aircraft process 916, a player aircraft process 912 and an audio engine 328, and a data request for the virtual aircraft and player aircraft processes 912, 916. .

3. ATC rule based logic module

The ATC rule-based logic module controls the actions of the ATC process 908 in response to the changing state of the world's aircraft. The ATC process 908 responds to changes in the fish's flue by the date, location, and weather the game is played in, and therefore provides realistic real-time responses to real-time traffic and weather conditions. The rulesets in this module operate to simulate the active control of the main airport flying in the airspace that the player can select. The ATC process 908 interacts with the aircraft flying or taking off from the airport.

E. inbound aircraft control

An aircraft that is scheduled to land at the airport (virtual and player) must communicate with the ATC process 908 and speak this intent within 50 miles of the airport. The virtual aircraft does this automatically, but the player must do this communication manually. When the aircraft makes this communication, they are added to a landing queue. The ATC process 908 uses this queue to manage real-time traffic as needed to manage communication with the aircraft and also sequence player aircraft for landing. The landing queue consists of the aircraft's first in, first out (FIFO) in contact with the ATC process for landing. The data contained in this queue for each aircraft includes the sequence order, the identification ID for that aircraft, and the altitude initially assigned when taken under control and sent to the initial access point, which point is currently authorized.

This queue is used to simulate control of the aircraft's approach and landing at the airport by rule-based logic. This includes control and commands passing through several points in the access area that are issued to the aircraft. Points from the airport runway, their location and the issues in question are as follows:

point location Issued Command

Aircraft first proceeds to> 50 miles IAP from aircraft in contact with ATC

20 miles FAF clearance from the aircraft arriving at the aircraft IAP

Approve 10 miles from the aircraft to the FAF

2 miles landing permit from the aircraft arriving at the aircraft access point

If the aircraft is under control, the aircraft detects where they are and follows the commands of the ATC rules that send them to the next point. An example of a rule that uses data in a queue is:

(Position from airport AC1) <= position (permit in points),

Send a message (FAF grant) to AC1,

Set Permitted Point to FAF.

When the aircraft lands, the aircraft is removed from the inbound aircraft queue. The aircraft is removed by traffic engine 900 as soon as data therefrom disappears.

1. Maintain the aircraft at the Initial Approach Point (IAP).

When traffic is busy bound at the airport, it means when more aircraft are waiting for access and landing than they can accommodate. (Only one aircraft is allowed a Final Approach Fix (FAF) at a time, which aligns the aircraft smoothly.) This can also happen when the player aircraft chooses to access the airport. The ATC process 908 adapts well to this by asking the aircraft to keep the IAP before it is granted a FAF.

If the aircraft is initially IAP approved, it is said to maintain altitude. This altitude is created using a sequence order in the queue that determines the offset from the base altitude. Altitude separation prevents aircraft from colliding. For example, if the aircraft approach is the fourth aircraft in the queue and the base altitude of the IAP is 10,000 feet, then the aircraft will be granted 10000 + (4 * 1000) = 14,000 feet to the IAP. If the number of sequences exceeds 10 and the total number of aircraft in the queue is less than 10 (indicating that some aircraft is licensed), the number of aircraft sequences is reset to one. From this it can be seen that the next aircraft will be authorized at 11,000 feet (10,000 + (1 * 1000 feet). The retirement of aircraft maintained by the FAF is permitted and the next aircraft maintained by the IAP is granted FAF.

2. Outbound Aircraft

The aircraft leaving (taking off) the airport is added to the takeoff queue when it sends a communication message to the ATC process 908 informing the takeoff ready. This message is automatically issued by the virtual aircraft when the virtual aircraft has been generated by the traffic engine 900 and is at the airport and their flight plan has not yet taken off. This message also occurs when the player aircraft is at the airport and wants to take off. The takeoff queue stores the number of sequences, IDs for the aircraft, and points that are permitted to take off as data. There are three points involved in the takeoff logic.

point Place Issued Command

First, aircraft ACT contact runway

One-mile navigation resumes from Runway Sequence Point Airport

50 miles "Goodbye" message sent from takeoff licensed airport

When the aircraft makes a takeoff request, the aircraft is added to the takeoff queue. If the ATC process 908 allows for safe takeoff (any previous aircraft arrives or moves past the runway sequence point), the aircraft is allowed to take off. Otherwise, the aircraft is required to maintain and allow takeoff when the point is granted. When the aircraft reaches the sequence point, ATC process 908 issues a command to the aircraft to restart normal navigation, but does not allow the aircraft to leave the queue. The aircraft can then start following the report and match the actual aircraft route. As the aircraft travels past 50 mile points, the aircraft is removed from the queue and sends an acoustic farewell message.

3. Keep aircraft on the ground

There may be situations where there are aircraft that want to take off more than they can accommodate, such as in a landing queue. This can often happen when the airport is busy when the player aircraft requests takeoff. In this case, when the aircraft sends a takeoff ready message, the aircraft is informed to keep. When the aircraft in front of the queue departs, the aircraft is actually allowed to take off. Unfortunately, it does not limit the take-off queue to the number of aircraft that can be maintained, reflecting real life.

4. Dealing with Rogue Aircraft

The landing and takeoff queues also serve a secondary purpose of allowing the ATC process 908 to monitor the airspace for aircraft that are not under control (especially player aircraft). If the ATC process 908 determines that the player aircraft is within 50 miles of the airport and is not in contact with the ATC process 908, the ATC process 908 sends an audio message until the aircraft lands. Responding to the unconfirmed aircraft, asking for confirmation of the aircraft, asking what the intention is, or asking for a similar message. The same process is used for the player aircraft if the player aircraft proceeds and takes off on the runway without requesting permission. The ATC process 908 will detect that the aircraft is on the runway without requesting a takeoff permit (not in the takeoff queue) and will send the appropriate series of audio messages until the aircraft has passed 50 miles.

5. Use real-time weather data

The ATC process 908 may also use real time weather data as described above for the airport under control as the pilot requests weather data (eg, what the wind direction is). This data is also used by the ATC process 908 to command the aircraft to select the most appropriate runway and to generate realistic rendering of the CN part based on real time conditions.

Therefore, systems, methods and apparatus have been described to influence and operate a gaming experience with the use of real-time data. Although the flight simulation application is described in some detail in the preferred embodiment, the content of the present invention may likewise be extended to other games such as car or ship racing games or other sporting events. Many further modifications can be made in the apparatus described above without departing from the true spirit of the invention. In particular, even if a particular function belongs to the different steps of the above-described method and the module of the above-described circuit, these functions may be performed by a different order and a different module as known to those skilled in the art.

Claims (33)

As a method for simulating a real world environment within a virtual world represented in a game, Receiving a place selection from the player at a verifiable time; Interpolating simulated environmental conditions within the virtual world for the selected place in response to real world information associated with the selected place from a time different than the identifiable time; Generating a simulated environmental condition in-game in response to the interpolated simulated environmental condition. As a method for simulating a real world environment within a virtual world represented in a game, Receiving a place selection from the player, Interpolating simulated environmental conditions within the virtual world for the selected place in response to real world information associated with the selected place and other places; Generating a simulated environmental condition in-game in response to the interpolated simulated environmental condition. As a method for simulating a real world environment within a virtual world represented in a game, Receiving a place selection from the player at a verifiable time; Interpolating simulated environmental conditions within the virtual world for the selected place in response to real time information associated with the place other than the verifiable time and the selected place; Generating a simulated environmental condition in-game in response to the interpolated simulated environmental condition. As a method for simulating a real world environment within a virtual world represented in a game, Receiving a place selection from the player, Determining whether real world environmental condition information is relevant to the selected location; In response to determining that the real world environmental condition information is associated with a selected place, generating the simulated environmental condition within the virtual world for the selected place by applying the real world environmental condition information. 5. The method of claim 4, further comprising responsive to determining that the real world environmental condition information relates to the selected place, analyzing the surrounding place of the selected place to determine whether the surrounding place is related to the real world environmental condition information. How to. As a way to integrate real-world data with a gaming experience, Determining a geographic location of the gaming unit controlled by the player, In response to the current real-world data being made available at a location of the gaming unit, applying the current real-world data to simulate a portion of the gaming experience; In response to current real-world data that is unavailable to a location of the game unit, simulating a portion of the gaming experience by interpolating real-world data based on current real-world data associated with a location close to the location of the gaming unit. Way. 7. The method of claim 6, wherein the gaming experience is a flight simulation game, the gaming unit is aircraft simulation, and the real world data includes weather data or traffic data. The method of claim 6, wherein the gaming experience is a flight simulation game, the gaming unit is an aircraft simulation, and the real world data includes weather data, The method further includes generating a simulated weather condition for the place based on real world data regarding other weather conditions for the place. 9. The method of claim 8, wherein the simulated weather condition is icing and the generation of the icing condition is determined based on real world data regarding temperature and rainfall. The method of claim 6, wherein the gaming experience is a flight simulation game, the gaming unit is aircraft simulation, and the real world data includes ambient aircraft data, The method further includes generating and displaying representations of the real world aircraft as part of the gaming experience based on real world data identifying the real world aircraft. 11. The method of claim 10, further comprising selecting and displaying a real world aircraft as an aircraft located within a predetermined radius of a location of the aircraft simulation. As a method for simulating a real world environment in a virtual world represented in a game, Receiving a place selection from the player for a gaming unit controlled by the player at a verifiable time; Generating and displaying the shape of a game unit in the game in response to a real-world unit associated with a location close to a selected location of the player controlled gaming unit at the identifiable time. 13. The method of claim 12, wherein the game is a flight simulation game, the gaming unit is an aircraft, and the generating the shape is in response to an actual aircraft associated with a selected location of the player controlled gaming unit at the verifiable time. Creating and displaying a shape of an aircraft in the game. The method of claim 13, wherein the shape of the aircraft corresponding to the actual aircraft is displayed in a location corresponding to the location where the actual aircraft is located in the real world. 15. The method of claim 14, wherein the location of the shape is updated taking into account the change in position of the actual aircraft. 15. The method of claim 14, further comprising the steps of determining if there is new data about the location of the actual aircraft that is displayed in the game, In response to determining that there is new data regarding the location of the aircraft, updating the location of the shape responsive to the new data. 17. The method of claim 16, further comprising in response to determining that there is no new data regarding the location of the aircraft, interpolating a new location for the shape of the aircraft based on the most recent data about the aircraft. 18. The method of claim 17, wherein the most recent data includes speed and heading information of the actual aircraft. 15. The method of claim 14 wherein the gaming unit corresponding to the real world unit moves away from the gaming unit controlled by the player in response to the gaming unit of the player moving within a predetermined radius of the gaming unit corresponding to the real world unit. The method of claim 13, wherein the air traffic controller process keeps information about the location of the player aircraft and the real world aircraft and changes the player aircraft with respect to the movement of the real world aircraft. 21. The method of claim 20, wherein the air traffic controller emulates radio traffic experienced by the real world pilot by delivering an audio message to the player aircraft regarding movement of the real world aircraft. As a system for integrating real-world data into games, A real world data manager for requesting selected groupings of real world data from a comprehensive real world database for use in games, A real world data database connected to the real world data manager, for storing selected groupings of data relating to real world events; The interpolated game data connected to the real world data manager and the real world data database, receiving a request for interpolated data from the real world data manager, retrieving selected data from the real world data database, and interpolating game data to be used for execution of the game. A system comprising a real-world interpolation engine for generating. 23. The system of claim 22, wherein the game is a flight simulation game, the real world data is weather data, and the interpolation engine is a weather engine for interpolating weather data to be displayed during execution of the game. 23. The system of claim 22, wherein the weather engine simulates weather conditions based on analysis of other real world weather conditions. 25. The system of claim 24, wherein the weather engine simulates icing conditions based on analysis of temperature and rainfall data. 27. The system of claim 25, wherein the weather engine changes the icing condition in response to a player using the deicing application in the game. 23. The system of claim 22, wherein the game is a flight simulation game, the real world data is traffic data, and the interpolation engine interpolates traffic data to display another aircraft during execution of the game. A computer readable medium for incorporating real world data into a game, The computer readable medium may include a processor, Display the gaming unit in response to player input at a viewable time, Retrieve real-world data about the location of the real-world unit at a time close to the identified time at which player input is received, And store instructions for displaying a shape of a real world unit in response to data retrieved in the game. The processor of claim 28, wherein the processor is configured to: Determine if real world data exists for the real world unit that is currently displayed for the moment selected in time, In response to determining that no real-world data exists for the moment selected in time, interpolating a location for the real-world unit, And instructions for displaying the real world unit at an interpolated location. 30. The computer readable medium of claim 29, wherein the game is a flight simulation game, the gaming unit is an aircraft, and the instructions cause the processor to augment the position of the real world aircraft based on heading and speed information. A computer readable medium for incorporating real world data into a game, The computer readable medium may include a processor, Display the gaming unit in response to player input at a viewable time, Retrieve real-world data about environmental conditions at a time close to the identified time at which player input is received, And store instructions for displaying a shape of an environmental condition in response to data retrieved in the game. 32. The processor of claim 31, wherein the instructions for the processor to retrieve real-world data regarding environmental conditions are further provided by the processor: Retrieve weather data for a place corresponding to a place of the gaming unit, A computer readable medium for displaying a shape of an environmental condition based on the retrieved data. 33. The method of claim 32, wherein the indication is performed by the processor; Determine whether weather data exists for the place of the gaming unit, In response to determining that the weather data is not present, analyze surrounding places until real-world weather data is found, And interpolate the shape of environmental conditions for the location of the gaming unit in the game from the found real world weather data.