Statistics Server

Component Documentation

Documentation for each component is linked below.

• Vegetable Assassin Overview
• Microcontroller Docs
• Websockets Docs
• Statistics Docs

Server-side Communications

The server receives messages and facilitates communication between the sword and web client via WebSocket.

Getting Started

Prerequisites

We assume you have Python 3.5+, Django 1.11+ and Channels 2.0 installed already. You should also install Docker in order to install and run Redis.

Installing

First, clone the git repo:

$ git clone https://github.com/TypingKoala/Vegetable-Assassin-Server.git

Config

You will need to change the directory routing to your own root or folder name in Vegetable-Assassin-Server/mysite/settings.py in the fields STATICFILES_DIRS and STATIC_ROOT.

Do the same thing for database directories listed at the top of these files: Vegetable-Assassin-Server/chat/get_access_id.py and Vegetable-Assassin-Server/chat/collisions.py in the variables id_db and scoreboard_db, respectively.

Running

You can run the application inside the Vegetable-Assassin-Server directory by running the following line in your terminal:

$ python3 manage.py runserver 0.0.0.0:80

Document Details

In case you want to change the game specs on your local system, this section will provide a brief overview of important files and their functionalities.

mysite

settings.py contains all the Django settings for the project, which is currently called mysite. Here, you can change allowed hosts of the site (which is currently game.vegetableassass.in), specify installed applications, databases, time zones, languages, and static file options. Explore the full documentation for more details on settings configuration.

routing.py tells websockets where to route url address to, in our case, it leads to a url routing file in the chat directory with specified urlpatterns.

urls.py contains a list of urlpatterns that routes URLs to views. Views are written out in separate documents and imported into the file. Here, we specify routes for the endpoints getid, leaderboard/username, leaderboard, multileaderboard/teamname, multileaderboard. Note that for two url patterns that start with the same root, the longer one with arbitrary user queries always comes first. Django checks the urls in the list in order.

chat

views.pyreturns HttpResponse objects in specific functions called on by url patterns. Currently, it generates endpoints for leaderboards on both single player mode and multiplayer mode, supporting both general queries and or requests to display all scores for a specfic username/teamname. These responses are called by the web client, and thus are presented with Cross-Orgin Resource Sharing (CORS).

urls.py currently contains an empty list of urlpatterns. Change this if you want specific access ids to display different views/functionality.

routing.py contains a list of websocket urlpatterns, which currently contains one url for any arbitrary user input (the access id in this case), and creates a new ChatConsumer for that channel.

consumers.py uses asynchronous functions to connect, disconnect, receive, and send messages through a websocket. Alter this code if you want to have different functionality upon receiving or sending specific message content.

collisions.py uses sqlite to create databases for single (scoreboard.db) and multiplayer (multiscores.db) leaderboards, updates those leaderboards every time a game is over, and queries the top 10 scores from the database when requested by the web client. Change the methods in this file if you want to alter the content or order of the leaderboard.

get_access_id.py creates a database (access_id.db) to keep track of all used 5-digit access ids, and generates distinct new ids upon a get request. Change this implementation if you want a different form of access ids for your game.

** Note: Django channels work relatively well for low volumes of game traffic, but has limitations supporting high connection levels on the performance of websocket messages because of the necessity of databases. Therefore for multiplayer and high numbers of single player game connections, we migrate to Node.js to support asynchronous functions more efficiently.