Get your game on is a browser game created in Godot using C#. As such, the game requires at least WebGL 1.0 to run. WebGL 1.0 is supported by all modern browsers released after 2012 [1]. The game is designed to be played with a mouse and keyboard. Touch screen input is not supported.
During development, the game was primarily tested on the following browsers
- Chrome 120, as well as other Chromium-based browsers such as Edge or Opera.
- Firefox 121.0
- Safari on MacOS 17.2
Testing has been conducted on both high-end and low-end hardware. Get Your Game On was found to be very lightweight and should be playable on most devices.
In order to keep the ratings secure and fair, the game is divided into two parts: the client and the server. The client is the game itself, running in the browser.
First, the applicant is authenticated by the server and given a UUID, and then the client is given a token to use for the rest of the session. The client then uses this token to authenticate itself to the server for each request. The server is responsible for storing the scoring results. If, in the future, the game is extended to include randomised scoring, the server will also be responsible for deciding the scores.
he server handles the authentication of the applicant and stores the evaluation results. If the server were also to be developed by Spore Games, it would be written in Java. The server would be hosted on a server provided by HNU. It is responsible for the following tasks
- Authenticate the applicant
- Store assessment results
- Serving the assessment results
These tasks would require a database. A SQL database would be used. The database could be hosted on the same physical server as the server itself, as only a small number of requests are expected.
The database schema would be as follows
- A table to store the applicant's UUID and HISinOne ID. The HISinOne ID would be used for authentication and the UUID would be used to identify the applicant in the database. The UUID would be generated by the server and would be unique for each applicant. The HISinOne ID would be used to authenticate the candidate.
- A table for storing assessment results. The table would contain the applicant's UUID, the assessment ID and the result of the assessment. The result would be stored as a JSON object containing the score and any additional information required for the assessment. For example, the management assessment would include the time taken to complete the assessment and the cards selected by the candidate.
- A table for storing the uploaded files for the Art evaluation. The table would contain the applicant's UUID as well as the file itself. The file would be stored as a binary object or as a reference to a file on the server.
The authentication process depends on how HNU intends to use the assessment. If the assessment is to be used as part of the admissions process, authentication will need to be done via an interface with the HISInOne portal. According to publicly available information [2], HISInOne has a SOAP interface for its data. A more modern REST API may also be available, but this is not publicly documented. The authentication process would then be as follows:
- The applicant logs in to the HISinOne portal as usual and clicks on the link to the game.
- The HISinOne portal redirects the claimant back to the game with a token.
- The game sends the token to the server, which then uses the token to authenticate with HISinOne.
- The server receives the authentication result from HISinOne and sends it back to the client.
- If authentication is successful, the client receives a session token to use for the remainder of the session.
- Authentication may fail if the user is not a candidate or if the candidate has already completed the assessment.
- The server stores only a reference to the applicant's HISinOne ID, such as a UUID generated at login, and stores no personal information other than the assessment results.
- The client uses the session token to authenticate to the server for each subsequent request.
HNU employees can be authenticated in a similar fashion, but instead using the Schibboleth SSO authentication system that is already in place.
Server-to-client communication takes place using HTTPS requests. Most requests are sent as JSON objects. The server only accepts requests that are authenticated with a session token. The server responds with a JSON object containing the result of the request.
The following information is sent to the server
- Information entered by the applicant during the game, such as their specialisation.
- The result of one of the assessments after the applicant has completed it.
- The result of the entire game after the applicant has completed it.
- Optionally, the uploaded file for the Art evaluation. See note below.
The following data will be received from the server:
- The result of the authentication process.
- Already completed scores, if the game was started and then closed before completion.
An example of the JSON for the management task sent to the server:
{
"token": "<session token>",
"assessment": "management-1",
"result": [
{
"points": 32,
"time": 321,
"cards": [
{
"id": 20,
"slot": 1
},
{
"id": 22,
"slot": 3
}
]
}
]
}The server will respond with a JSON object containing the result of the request. In this case its rather simple:
{
"success": true
}In case of an error, the server will respond with a JSON object containing the error message:
{
"success": false,
"error": "Invalid token"
}If the art assessment is to be submitted digitally, the applicant can upload the file to the server. The server will then store the file and the file will be available to HNU for review. Either a PostgreSQL or Microsoft SQL database or a file server could be used to store the file. The database would be the simpler solution as it would not require any additional software to be installed on the server. However, a file server would be more efficient as it would not require the file to be converted to a binary format. The PostgreSQL and Microsoft SQL databases also have a file size limit of 1GB and 2GB respectively, which may be too small for the art evaluation.
The server is responsible for generating the rankings. The rankings will be presented to HNU staff via a web interface, using their HNU account. If the server is developed by Spore Games, the web interface will be built into the game for simplicity.
Results will be ranked by percentile. The percentile is calculated by dividing the number of applicants who scored lower than the applicant by the total number of applicants. The percentile is then multiplied by 100 to give a percentage. For example, if a candidate is in the 80th percentile, this means that 80% of all candidates scored lower than the candidate.
Rankings can be generated for individual assessments as well as for the entire game. Rankings can also be filtered by specialisation. This is done by only including in the rankings those applicants who have selected the given specialisation. If no specialisation is selected, the rankings will include all applicants.
It is also possible to view the results of individual candidates. For example, it is possible to see which assessments the candidate has completed and how they scored on each assessment, including individual results such as the time taken to complete the assessment or specific solutions provided by the candidate.
[1] https://caniuse.com/?search=webgl
[2] https://www.campussource.de/events/e1603dortmund/docs/Wassmann_HISinOne.pdf