Vehicular Ad Hoc Networks (VANETs) are attracting considerable research attention, as they are expected to play a major role for Intelligent Transportation Systems (ITS). Thus, according to a recent survey by ABI Research1, about 62% of new vehicles will be equipped with vehicle-to-vehicle (V2V) communications by 2027. Vehicular networks offer new opportunities for the development of interesting mobile applications for drivers, but at the same time they also bring challenges from the data management point of view. Thus, for example, techniques should be developed to estimate the relevance of the information exchanged among the vehicles and to propagate the relevant data in the network efficiently and effectively. As testing the proposals in a real large-scale scenario is impractical, simulators are often used. In this paper we present Vanet-X, an online multiplayer driving videogame that we have developed to help in the difficult evaluation task of data management strategies for VANETs. The idea behind the proposal is to exploit the potential of players around the world driving vehicles in the videogame to effortlessly collect data that can be used to extract some conclusions and fine-tune the proposed data management strategies. So, for example, the videogame allows to evaluate if a certain data management strategy is able to provide useful information to the driver/player (i.e., if the presented information represents an advantage for him/her). We argue that this videogame can be a good complement for existing simulators. As a proof of concept, we have performed some preliminary tests that show the potential interest of the proposal.
The widespread availability of mobile devices and the
development of wireless communication technologies (such as
Wi-Fi, WAVE, etc.) have encouraged the development of
1http://www.abiresearch.com/press/
v2v-penetration-in-new-vehicles-to-reach-62-by-202.
services for drivers within the context of Intelligent
Transportation Systems (ITS). In particular, Vehicular Ad Hoc
Networks (VANETs) have become an attractive research
area [
However, although VANETs offer interesting
opportunities for the development of data services for drivers, they
also bring new challenges. Thus, several difficulties arise
from the point of view of data management [
A big challenge is how to evaluate the data management
techniques proposed. Evaluating them in a real scenario
with a significant number of vehicles is simply impractical
and expensive. Therefore, simulations are frequently used
in this field. However, even with simulations the
evaluation task can be very time-consuming. For example, many
proposals depend on a number of parameters that can be
fine-tuned for a given scenario (e.g., see [
So, in this paper we propose a complementary approach that can be used in conjunction with the use of simulators. In particular, we argue that we can benefit from players having fun with a driving game to easily collect interesting data that can be used to extract some conclusions and fine-tune the proposed data management strategies. The videogame is inspired by the classic videogame Rally-X (http://www. klov.net/game_detail.php?game_id=9259, videogame released in 1980) but it is a new development, with different goals, game modes, and spirit. So, the basic idea is that the vehicles can receive information through the vehicular network and different data management techniques can be plugged in the videogame (e.g., different data dissemination strategies). Data received from other vehicles, if evaluated as interesting by the local query processor in the car, are shown on a radar and can provide a competitive advantage to the player. During the game, a variety of data are collected (e.g., number of messages received by the vehicles, network overhead, time required by the vehicles to complete their goals in the game, etc.), that can be analyzed later. So, while playing, players contribute to collect data for a variety of scenarios, and these data can be exploited to evaluate the effects of particular data management strategies.
The structure of the rest of this paper is as follows. In Section 2 we describe the high-level architecture of the videogame and its features. In Section 3 we summarize the main behaviors implemented for the computer-managed vehicles. In Section 4 we present some basic aspects about the way the data are collected for later analysis. In Section 5 we present the results of the first experiments that we have developed as a proof of concept. In Section 6 we present some related work. Finally, in Section 7 we present our conclusions and some lines of future work. 2.
Vanet-X is a car videogame that can be played by multiple players connected to the Internet (see Figure 1 for a snapshot showing parking spaces). 2.1
We summarize some features of the game as follows: • Both real (human) and computer-controlled players can participate in the game. Human players can join a game through the Internet. • The game can be configured to execute on a server and create new games when necessary. Alternatively, the computer of any user can play the role of a server and start a new game that other users can join. • Any real map can be used in the game, by selecting and downloading the data of the desired area from OpenStreetMap (http://www.openstreetmap.org/). • To increase the playability, real maps are combined with some extra elements, such as enemy cars, smoke emission devices to disturb enemies (see Figure 2), evolution of events in game time rather than in real-world time, higher maximum speeds for cars controlled by humans, when the driver has a task to go to a certain building he/she has to park nearby and then go by foot to the destination (he/she will be a vulnerable target for enemy cars, that will try to hit him/her, as shown in Figure 3), the car can get damaged and be repaired by paying a certain price (points accumulated during the game), there is infinite or limited fuel depending on the game mode (requiring refueling in a petrol station when running out of fuel in the second case), etc. games where the players have to complete a series of goals in sequence (with tasks such as parking the vehicle, going to a certain building/business or address, etc.) as soon as possible to win the game. As shown in the table, some game modes can be cooperative, competitive, or both. For the tasks implying going to a certain location, the task may require reaching that location with the car, park and then get there by foot, or just park as near as possible (in this last case, the score for completing the task will be inversely proportional to the distance between the parking location and the final destination). Competitive games involves from 1 to 4 teams in the game, being the winner the team that obtains more points during the game.
Game mode Capture the flag (capture 5 flags) Capture the enemy cars (1 or more) Solve tasks (1-3 tasks) Survival (1 or 2 tasks) Park (find one available parking spot)
Possibility to Multiplayer Inmortal get out of the mode car and walk ccoomoppeertaittiivvee no no cooperative competitive yes no ccoomoppeertaittiivvee no yes ccoomoppeertaittiivvee no yes competitive yes yes
Infinite
fuel
configurable
configurable
configurable
no
no
• Some default data management strategies, inspired by
the work performed in the VESPA project [
The basic architecture of the videogame is presented in Figure 7 (the part concerning the collection of statistics about the game is not shown here, as it will be described in Section 4). At a high-level, we can briefly describe the main components as follows: • A client application receives commands from the player, sends them to the server, and receives from the server information about the objects that should be rendered on the screen (see Figure 8). • The server receives the input from the clients, updates the current status of the game (e.g., by considering the movements performed by the vehicles and the tasks that they complete), and generates new goals and events as needed (see Figure 9). The server is multithreaded, with a thread per vehicle that performs a basic cycle of “while a vehicle is alive, perform actions and check for potential collisions”. • An interface IDataManagementStrategy declares the methods that should be implemented by a data management strategy to allow its integration with the videogame (e.g., a method to define the types of events that are interesting for the driver, a method to generate an event, etc.). • Another interface IVehicle is implemented by the vehicles to allow interacting with them (e.g., to obtain a reference to the data manager in the vehicle or to obtain information about the GPS location).
Any data management strategy can potentially be integrated in this framework, as long as it implements the interface IDataManagementStrategy and calls the appropriate methods to inform the vehicles (interface IVehicle). So, we can easily plug in different alternative data management techniques for testing. 3.
We have implemented several behaviors for the vehicles
controlled by the computer, which adapt the steering
behaviors proposed in [
Of course, all the vehicles exhibit the whole set of behaviors at the same time, applying a priority ordering in case several behaviors could be applied at the same time and are in conflict to each other. Based on the previous basic behaviors, we have defined the schema of a normal behavior for different types of vehicles: enemy cars (that try to catch the players or flee from the players, depending on the game mode), ambulances (as representatives of emergency vehicles which may ask the right of way), and traffic cars (that represent neutral cars in the game). As an example, the basic behavior of traffic cars is shown in Figure 10. 4.
In this section, we summarize the strategy applied for data collection during the game and the corresponding exploitation of results. If a certain configuration option that activates the collection of statistics during the game is enabled, several data are collected: data about the scores obtained by the players, the time needed by vehicles (the ones controlled by humans as well as those managed by the computer) to perform certain tasks (such as parking), and other measures about the performance of the data management strategy applied (e.g., events created, events that are considered relevant by each vehicle, etc.). When the game ends, all these data are stored in several files on the game server, along with a file that contains information about all the configuration parameters used in that game (e.g., game mode, configuration parameters used for the data management strategy considered, the wireless communication range simulated, etc.).
To centralize the data collected, it is possible to set up a Statistics Server, which is a process executing continuously on a certain computer. In this way, the clients playing the game automatically connect to the Statistics Server when a game ends, in order to communicate the statistics collected during the game. Besides, it is possible to connect to the Master Server by using a terminal client (called Statistics Client) that allows seeing and modifying the configuration parameters as well as retrieving the statistics files generated. Another option is to avoid the use of a Statistics Server and collect the statistics in the computer that plays the role of a server for a game. If we consider configuration settings where there is a predefined game server and all the clients connect to it to start a new game or join an existing game, this option also keeps the statistics in a single location. However, if there are several game servers then the statistics would have to be centralized manually.
Figure 11 provides an overview of the way the different components of the game, and particularly the Statistics Server, are distributed in a network. Notice that we actually distinguish between a Master Server and a Game Server. The Master Server is executing on the server machine and a client first connects to it (so, it is the entry point for clients); then the Master Server checks if a Game Server is available and if not it creates one; finally, it returns the port number of its Game Server to the client, as the client will interact with the Game Server during the game.
It should be noted that, as we collect information about the performance of human players, the skills of those players with the game will have an impact on the results and this has to be taken into account when exploiting the results. Indeed, directly comparing the achievements of several human players without considering their game skills could lead to wrong conclusions. For example, player1 without a data sharing system could perform better than player2 with a data sharing system, but we should not necessarily conclude that the use of such a data sharing system is harmful. In other words, we should always compare players with the same skills. For this reason, each human player is assigned a certain skill level (which may change along time, as the player improves his/her performance) and the statistics about players are tagged with the skill level corresponding to that player. Besides, players that have a skill level below a certain threshold are (by default) not allow to participate in games with collection of statistics enabled, as performance data about them are assumed to be unreliable and besides their clumsiness could interfere with the normal development of the game. The skill level of a player is computed based on his/her ability to complete missions in the game (tasks per time unit). 5.
We have performed a few preliminary experiments to evaluate the interest of our proposal. As a use case for testing, we focused on the case of available parking spaces, as these are events that represent scarce resources, which implies additional challenges for data management (i.e., the competition among vehicles should be minimized). 5.1
As a data sharing strategy for the vehicles, we considered the following options. 5.1.1
First, we adapted the proposal in [
The EP between a vehicle and an event estimates the likelihood that the vehicle will meet the event, based on geographic computations that estimate the spatio-temporal relevance of the event. For example, the relevance decreases with the distance between the event and the vehicle, with the time since the event was generated (e.g., consider the case of information about an available parking space, which can be unoccupied only for a limited amount of time), and the direction of the vehicle (e.g., if it is approaching the event or not). In particular, the directions of both the vehicle and the event are estimated and several penalty coefficients (α, β, γ, and ζ) are used to weigh the importance of four estimated parameters: the minimum distance to the event over time (Δd), the time until the closest position to the event (Δt), the age of the event at the closest position (Δg), and the angle between the vehicle and the event (c).
So, when a vehicle receives an event it computes its EP and disseminates the event again if the computed EP exceeds a certain dissemination threshold (DT ). The intuition is that vehicles should disseminate data that are relevant for them (as those data are also probably relevant for the neighboring vehicles). Two other thresholds are managed: the storage threshold (ST ) and the relevance threshold (RT ). The ST determines the minimum value of the EP for an event to be stored locally in the vehicle, and the RT the minimum value needed to show the event to the driver.
Besides, the proposal in [
Communicating the availability of a single parking space
to many vehicles could lead to an unfruitful competition
among the vehicles to try to reach the same parking space,
leading to dissatisfaction of the drivers and parking times
that could even exceed those that would be obtained if no
data sharing system were used. For this reason, the work
presented in [
Finally, we also considered an approach where no data sharing strategy is used. In this case, the vehicles receive no information and the only data available for the drivers are what they see with their own eyes. For vehicles trying to find available parking spaces, this will lead to a blind search. 5.2
The basic configuration of the videogame for the
experimental evaluation is as follows. The communication range
considered for the vehicles is 200 meters and a maximum of
50% of the vehicles are assumed to be equipped with a data
sharing application. The penalty coefficients used to
compute the EP for VESPA are: α=1/1500 (Δd ≤ 500 meters),
β=1/180 (Δt ≤ 60 seconds), γ=1/360 (Δg ≤ 120 seconds),
and ζ=1/270 (c ≤ 90◦); these are parameters that can be
considered for a “medium” (not small, not large)
dissemination area, according to [
We have simulated a varying number of vehicles moving in an area of 1 squared kilometer around the street “Sophie Oury” in the city of Valenciennes (France). In this scenario, we measured the time needed by the vehicles to find free parking spaces near certain destinations. In Figure 12 we show the reduction on the average time needed by a human player to find an available parking space near the target. The experimental results show the interest of sharing data among the vehicles (with both VESPA-P and VESPA+P), as these data can later be shown on the radar to provide interesting information to the drivers. Besides, according to these results, using a reservation protocol to avoid the competition problem (VESPA+P) is particularly beneficial.
In Figure 13 we compare the performance of human players (vehicles controlled by humans) and computer players (vehicles controlled by the computer), by showing the reduction on the average time needed to find an available parking space near the target when using VESPA+P. According to these experimental results, we can see that the human players get more benefit from the use of the data sharing strategy. The difference may be due to the way the artificial intelligent behavior of the computer vehicles is implemented. The experimental results obtained correspond to data collected during a total of 14 hours playing the videogame (about 400 parking actions by the human player during this game time). The results are consistent with our intuition and with other experimental results obtained previously by using a simulator. Nevertheless, more tests are needed to validate the results and evaluate other scenarios. For example, we started to obtain some first preliminary results with games played by more than one human player. It is also interesting to perform experiments with other types of events (e.g., accidents, obstacles on the roads, etc.); with information about them, drivers could try to avoid those hazards and so decrease the total travel time. 6.
As far as we know, this is the first attempt to develop a videogame whose hidden purpose is to help with the evaluation of information management strategies for vehicular networks.
Nevertheless, the idea of trying to benefit from human
actions to improve or evaluate a system is not new.
Exploiting the power of people to perform large-scale tasks that are
costly, time-expensive, or hard, is called crowdsourcing [
Particularly relevant for our work with Vanet-X are those
proposals that achieve the crowdsourcing results through the
use of a videogame. A notable example is the ESP game [
There exist some driving videogames that, as Vanet-X, are based on the use of real road maps or city layouts, such as Mini Maps (https://apps.facebook.com/minimaps/) and Push-Cars 2: On Europe Streets (http://www.push-cars. com). However, unlike in Vanet-X, in these games the players do not contribute to any crowdsourcing task or data management strategy evaluation.
Finally, a good number of simulators of vehicular
networks and mobility generators have been developed, such as
TraNS [
We have developed a videogame that can be used to evaluate data management strategies for vehicular networks, as a complement to existing simulators. Whereas the opportunity of crowdsourcing through a videogame is attractive, several challenges arise. Thus, the goal of developing a fun videogame required the introduction of several elements that would not appear in a real scenario (like enemy cars), which could have an impact on the results, but on the other hand this will attract people to play. Moreover, the results obtained can depend not only on the benefits offered by the data management strategy but also on the ability of the specific player. So, whereas the videogame can provide an ideal tool to collect many data for a variety of scenarios, the experimental results obtained have to be judged with caution (e.g., we label the collected data with the skill level of the player). Even with these limitations, we argue that the videogame helps to collect with less effort data that can be used to fine-tune a protocol and/or obtain some initial conclusions, prior to the evaluation in more realistic scenarios.
Additional information regarding the videogame is available at http://sid.cps.unizar.es/Vanet-X/, including a playable version of the videogame, some videos, and screenshots. This is a first step that shows the potential interest of exploiting videogames to evaluate data management strategies for vehicular networks. As future work, we would like to optimize and improve the videogame, as well as to develop a complete methodology and architecture to collect the data, evaluating the interest of the results obtained in other scenarios and in a larger scale. 8.
This research work is currently supported by the CICYT project TIN2010-21387-C02-02 and DGA-FSE. The data management strategy adapted and used as an example in the videogame has been proposed in the context of the VESPA project, and we would like to warmly acknowledge the collaboration with Dr. Thierry Delot in that project.