For Developers

Bear Traffic Controller - designed with you in mind

Overview

Bear Traffic Controller is written in Java, using the LWJGL and slick2D, and libraries built upon them. These libraries (e.g. jog) can be extended and additional features can be requested to support further development of the game.

The GUI

The GUI has been designed to meet 5 simple objectives (in addition to the functional and non-functional requirements)

Objectives

These objectives set out what we wanted to achieve with the GUI in an easy to understand way. They take into account the user by outlining their experience, but also the developer in highlighting future areas of development.

The GUI must:

  • Be easily expandable - Space should be provided in the GUI for new features, whilst not looking incomplete
  • Be intuitive for the user - Although a user manual will be available, the user should be able to intuitively play the game and use all controls
  • Not be so complex that it intimidates the user - Although realism is important, this should not make the experience intimidating for the user
  • Provide all information and controls required by the user to achieve the goal of safely navigating planes to their exit points
  • Be designed to be easily adaptable to touch input - Where keyboard or special mouse controls (e.g. scroll wheel) are used an on screen button alternative should be provided

GUI report

View the entire GUI report which justifies all of the decisions made during the design of the BTC GUI.

GUI Report

The Architecture

The Architecture has been designed to meet a limited set of requirements (those outlined for Assessment 2). However, careful consideration has also been taken to make sure that it is expandable to meet future requirements. For more details, take a look at the architecture report

Architecture Report

The Architecture report thoroughly explains the design and implementation of the BTC game architecture. For any future developers, this should provide an easy way of quickly picking up and farmiliarising yourself with the project for continued development.

Architecture Report

Testing

BTC has been tested in a variety of ways from code examining white-box testing to game playing alpha testing. The results of these tests have helped to direct development of the game throughout the process, and all of these results are available in our Test Plans and report

Test Plan

This outlines the current test plan and all of our results

Test Plan Integration Testing Requirements Testing Unit Testing

Requirements

Both the GUI and game architecture have also been designed to satisfy a set of functional and non-functional requirements. These are provided below:

Functional Requirements

  1. The game GUI shall display the game airspace and active flights.
  2. The game shall initialise aircraft entering the airspace with static flight plans. The flight plan will be a route passing through waypoints from the planes entry to it's exit point
  3. The game shall allow the player to send orders to aircraft to immediately alter their flight plan.
  4. There shall be at least 3 entry and 3 exit points and the exit points will correspond to given destinations.
  5. The game shall check aircraft separation regularly.
  6. The game shall end when the distance between one aircraft and another is lower than the specified separation rules.
  7. The game shall track an aircraft’s position and speed while it is within the airspace.
  8. The game shall calculate the score as a function of time played and successful flights.
  9. The game shall run on PCs provided in the Computer Science labs.
    • The game shall run on a PC that meets the Windows 7 minimum system requirements (1GHz processor, 2GB of RAM)
  10. The game shall allow the use of the keyboard and mouse as input devices.
  11. The game shall allow for separation rules of aircraft to scale against difficulty.
  12. The game shall provide at least ten fixed waypoints within the airspace.
  13. The game shall allow aircraft to vary the rate at which they climb / descend.

Non-functional Requirements

  1. The game shall incorporate realism where possible/appropriate, but its primary goal is to provide a fun and enjoyable experience to the user.
  2. The game shall be engaging.
  3. The target audience of the game will be students (not necessarily Computer Science students).
    • The game will be appropriate for this market in terms of the graphics and language used.
  4. The graphics of the game shall not be restricted by reality, but will instead aim to provide a fun and engaging experience for the user.
  5. The game GUI shall be updated regularly. The target for this is every 30ms.
  6. The game shall be easy to play and clear instructions will be available when needed.
  7. The game shall be adaptable for touch input.
  8. The game shall use semi-realistic separation rules.
  9. The game shall use units which fit the air traffic control domain, but which are not so obscure as to confuse the user. These shall be:
    • Knots for speed (As this relates closely to MPH and is what is used in real life).
    • Feet for altitude (People have an understanding of feet and it is used in the real world).
    • Feet for separation.