MySQL Database

The database structure is build up by means of Django models. Three main models are:
- Checkpoint
- Player
- Lobby

Every model is a class with its properties:

Checkpoint:
  • Coordinates
  • Proximity (refers to the number of meters at which the Player has to approach to the checkpoint to get it checked by the application)
  • Name

    • Player:
  • Checked (refers to the number of checkpoints the players has checked during the game)
  • Name

    • For both Checkpoint and Player model is also assigned, by default, an incremental index which is the primary key. Errors, such as a single name for two Players, are managed downstream at gameserver's level.

    Lobby:
  • Lobby name
  • Players
  • Game NRCD
  • Game status
  • Game start date and time

    • For the Lobby model the primary key is the Lobby's name. Players is a Many-to-many relationship with the Player model. Game NRCD stays for the Number of checkpoints, Range of play, start Coordinates and Difficulty, which are parameters of the game to be choosen. Game status is a boolean variable which is True when the game is started but not finished, False otherwise. Game start date and time is trivial.

    GAMESERVER :Developed in python/django, is responsible to the management of the database queries in order to provide the necessary data to the mobile application and thus, to send and retrieve informations with the latter. Follows a subset of the REST API, for the full list and further informations visit our GitHub page.

  • POST PlayerInit/ Creation of a new player, using the username as parameter.
  • POST PlayerUpdate/ Update of the player's name, using the new username and the id as params.
  • POST CreateLobby/ Create and enter a new Lobby, using new Lobby's name and Player's id as params.
  • GET JoinLobby/ Scroll existing Lobbies
  • POST JoinLobby/ Join existing Lobby, using Lobby's name and Player's id.
  • POST SearchForCheckpoints/ Create a new game, using as params: the number of checkpoints, the play range, start coordinates, the difficulty and the lobby the player belongs to.
  • POST GetCheckpoints/ Get checkpoints associated with the previous research, using as param the Player's id.
  • POST Ranking/ Obtain the ranking of the Players in the actual game, using as params the Player's id and the number of checkpoints comlpeted.

    APPLICATION :A first draft of the application was written in Python, but the absence of a GUI was something too bad for the application itself. Kivy would've been a solution, but it was not easy to implement at all. Then, PhoneGap seemed to be the best solution, and it was. After countless tries to install it, we finally succeeded.

    The application is written in HTML5, CSS and JavaScript. The graphical part is made with Ratchet thanks to their CSS files, and the development of the JavaScript functions has been helped by JQuery.

    Most of the pages of the applications are made to create the lobby where the game is hosted and to save each user identifiers on the server. For example, the Settings page is used to set the player's username. This is achieved via a POST request to the GameServer. The application then proceedes to save in local the player's username and it's id. This is achieved thanks to DOM's LocalStorage method.

    In a playing group, one player has to create the lobby, while the other players have to join the so-created lobby. Hence there's a Create Lobby page, and a Join Lobby page. The creator sends his coordinates to the server, along with how many checkpoints for player are needed to win the game, and how big should the range of the game be. Everything is again achieved thanks to POST requests. The creator has then the opportunity to start the game as soon as everyone is in the lobby.

    The game rules are easy: there is a time limit set to 10 minutes and a certain number of checkpoints to achieve: the group has to find them before the time ends. Each time you are near to your checkpoint, another one is set. Checkpoints' names are not given that easily: one letter appears every 5 seconds, so it is crucial to guess where do you need to head to as soon as possible.

    The playing page is composed by many functions called repeatedly. This is easily done thanks to JavaScript's easy usage of asynchrounous functions. The application continues to get the player's GPS coordinates, to calculate the distance between the player and the next checkpoint, to print the riddle for the next checkpoint, to find if the player is going too well (and in this case he needs to be stopped, thanks to some maluses), to ask the server if the game is ended because someone has found the last checkpoint, excetera.

    The whole "intelligent" part is set in the application itself, as it controls if someone needs to be slowed down. The game is playing with you, or better, against you. It can change your checkpoint while you are rushing to it, it can make you stand still for some time, or it can simply reduce your score.

    Last but not least, the application is still in an early stage, as it lacks of beauty and aims to semplicity of usage and efficiency. If we will continue to develop this project (and we all think we will), there will be some great improvements, for example automatic retrieve of checkpoints from Google Maps or Foursquare.