A simulator to Demonstrate an Access Control Process: The Great Kilburn Escape

---

University of Manchester 

School of Computer Science

Third Year Project Report June 2016

A Simulator to Demonstrate an Access Control Process:

 The Great Kilburn Escape. 

Author: T. Raworth

BSc (Hons) Computer Science

Supervisor: Dr. K. Chen

Page 1 of 20

---

Abstract

A Simulator to Demonstrate an Access Control Process:

 The Great Kilburn Escape. 

Author: T. Raworth

This project aims to visualise and demonstrate four main functionalities of an access control

process, those being: 

i. A user may be authenticated;

ii. A user's access request may be granted/denied based on an access control policy;

iii. An administrator can specify access control policies for a set number of users;

iv. Resources at the target of protection can be configured.

Supervisor: Dr. K. Chen

Page 2 of 20

---

Acknowledgements

  I would like to thank my family for the support they have given me during my time at 

university, my supervisor Dr Ke Chen for his help on this project and his support during

my final year and lastly I would like to thank everybody that has had a hand in my 

progression over the years at The University of Manchester. 

Page 3 of 20

---

Contents

Introduction

1.1  Project Overview.

1.2  Project Aim.

1.3  Possible Methods.

1.4  Evaluation of Methods.

1.5  Selected Method.

Design

2.1  Design Environment.

2.2  Type of Game.

2.3  Structure of Game.

2.4  Design of Game.

2.5  Design of Puzzles.

Development

3.1  Time Line.

3.2  Development Issues.

3.3  Project Redundancies.

Evaluation and Testing

4.1  Evaluation.

4.2  Testing.

Conclusion

5.1  Conclusion.

Bibliography

Page 4 of 20

---

List of Figures

2.4  

Kilburn Building First Floor 

http://studentnet.cs.manchester.ac.uk/resources/floorplans/Kilburn_LF.jpg

Page 5 of 20

---

 

Chapter 1

Introduction

1.1 Project Overview.

  Access control by definition is the selective restriction of access to a resource or to a

location [1] It is governed by a set of pre set constraints that determine whether access 

will be granted. These constraints can include (but not limited to) User ID, User Group,

Current Time and many others. Access constraints can be amended by authorised users 

and these “rules” allow a system to be tailored to the needs of the consumer.

1.2 Project Aim.

  The aim of this project is to demonstrate / simulate the basics of access control to an 

average user, focusing on 4 main functionalities.

•

That a user can be authenticated.

•

That a user's access control request can be granted/denied based on an access 

control policy.

•

That an administrator can specify access control policies for a set of users.

•

That resources at the target of protection can be configured.

  The goal of this project is not just a regurgitation of rote learned facts that can roll

of the tongue as easily as your times tables, the expected outcome is a full understanding 

of the methodology and implementation of access control and the ability to relate that 

to real world implementations.

  A true test of the eventual simulator would be the user being able to infer a solution

to a problem they have never seen before by just an analysis of their current situation 

and the knowledge gained from this project.

   

1.3  Possible Methods.

  There are many different ways to demonstrate an access control process. After 

in-depth research these were whittled down to the following approaches.

Presentation.

  In which the user is provided with the pertinent data through a graphical presentation 

on screen. This would showcase the information clearly to the user and require little or

no feedback.

Page 6 of 20

---

Tutorial.

  In which the user is provided some data on access control and then expected to use it

to answer a question or series of questions regarding that topic. This may be by quiz or 

navigating past a blockage using the skills provided.

Test.

 

  In which the user is provided data on access control and then given a test to determine

if the data has been remembered and also understood. 

Game.

  In which the user is expected to infer the rules of access control by playing an immersive  

game where progression relies on understanding and using features of access control to 

overcome puzzles or reach secured areas.

For all these approaches there is also the method of delivery to consider.

Text Based Simulator.

  A command line simulator is rather basic but would provide the needed data and allow

for “text string” feedback from the user. Input and output would only be via text.

Graphical Simulator. 

  A Graphical simulator would give a greater level of realism and immersion than text 

based into which ever method is selected and can illustrate a wide range of situations 

with only a marginal increase in processing cost generating a great benefit to the user. 

 

VR Simulator.

A VR simulator would provide the closest to real word immersion however this would 

be at a much higher cost than either the text based or graphical simulator and may not 

provide as much additional benefit 

  A combination of one (or more) of these approaches combined with a suitable method 

of delivery will provide the most effective way of simulating access control to the user.

Page 7 of 20

---

  

1.4 Evaluation of Methods.

 

  Each of the highlighted approaches show merit, however for an effective solution

each must be evaluated to allow for the best choice to be selected.

Presentation.

  

A presentation can be a great way to deliver headline data to a user. It can disseminate

information to a wide audience quickly and in parallel. However it is largely an inactive 

way for a user to learn about a specific field. A poorly designed presentation, a hot day or 

even just a person with a short attention span can dramatically reduce the level of 

understanding the user takes away at the end. Also most presentation's limit questions

until the end of the talk and that can mean a user participating may not understand a basic

building block of a given subject until it is brought up right at the end. This user would 

then still have a deficit of all the linked data that came after that.

Tutorial.

  A tutorial builds on the basics of a presentation however distributes information in 

smaller packets and then tests the user on the most recent skill discussed. It is possible 

to go over and over a topic you are struggling with and ensures by the end of the tutorial 

that the user will be able to replicate the skills shown to them. Each new test that the 

user is presented with will require the requested knowledge from the most recent packet

of data plus an understanding of all the information that had come before it. Tutorials 

are an excellent method of passing on rules or instruction as they require you to not

only learn the information but also demonstrate that you have remembered it as well.

  However tutorials do have their own limitations one being that they are only able to 

reproduce the pre defined information from the tutorial. You are not forced to understand 

the whole of the issue or provide global solutions to problems to complete a tutorial.

Test.

  A test is a great way to differentiate the level of understanding of a topic between users.

It expects a level of independent study from the user and access to information resources 

on the subject at hand. A test can be applied to multiple users at the same time but it is

hard to show full understanding of a topic without detailed questions that require offline 

marking. The other option is simpler questions with multiple choice answers. 

  However it is a very difficult approach to generate genuine interest in a subject and for 

that reason you can have some users who study “to the test” without a full grasp of the 

underlining topics that are being taught.  

Page 8 of 20

---

Game.

  A game is a more complex method of passing on information to the user as it allows

for skills to be learnt instead of being taught. Playing a game can also be a much more 

rewarding exercise for a user as a sense of achievement comes from solving problems.

  

  In some ways a game is a combination of the some of the previous approaches. From 

the basic set-up and control of the game (Presentation), to the tasks showing you have 

mastered a specific topic (Tutorial) all the way to the quiz of providing a solution to a

puzzle from previously taught data (Test).

  While a game may be a larger investment of time and resources than either of the 

previously mentioned approaches it does engage with the user and provide a way of 

learning “by doing” allowing the user to make mistakes but to understand the full 

implications and possibilities of the given topic.

1.5 Selected Method.

  

After detailed research on the pros and cons of each option and the benefits that

each methodology brings to the project it was determined that the “Game” approach 

was the most suitable in this case. 

For the following reasons.

•

A game encourages the user to learn at their own pace and provides emotional 

feedback that encourages the user to continue learning or to beat a high score.

•

A game can be calibrated to many different users skill sets.

•

A game with integrated global puzzles requires the user to not only remember 

data but be able to use it to infer solutions to larger more complex problems.

•

A game is seen as a challenge and not just a task to be completed.

•

A game is fun.

  The method of delivery selected was the “Graphical Simulator” 

For the following reasons.

•

A Text Based Simulator would not be able to suitably emulate the necessary 

environment for the game.

•

A VR solution while bringing a greater degree on realism to the simulator would

be prohibitively expensive as the cost would significantly outweigh the benefit.

•

A  Graphical solution while available to everyone with a screen requires no extra 

expensive and still provides the needed level of emulation to the project.

•

 The vast majority of people are already familiar with graphical simulations.

Page 9 of 20

---

     

 

Chapter 2

Design.

This chapter of the report contains details of the design process. From initial ideas 

and brainstorming to alternatives design considered and also redundancies planned.  

2.1  Design Environment.

  From the decision in Chapter 1 to create a game using a graphical simulator one of the

largest concerns is what platform the game will be created on. There are many different 

Integrated Development Environments to choose from including:

•

CryENGINE

•

Source

•

Source 2

•

Unreal Engine 4

•

Unity Pro

Each of these IDE's are suitable for running a free standing PC game.

Other options include flash games and mobile phone app games.

Looking at each of the engines in turn I discovered the following. 

•

CryENGINE costs $9.90pm where as most of the other engines are free to use.

•

Source and Source 2 require a Valve game installed on your PC to run.

•

Unreal Engine 4 charge a 5% royalty based on gross revenue over $3000

per quarter. (0% up to $3000 per quarter)

•

Unity Pro costs $1500 flat one time fee or $75 pm (12 month contract)

•

Unity has no real artefact modelling or building features.

•

Unity is more focused at mobile or app games.

•

Unreal Engine 4 has dynamic lighting.

•

CryENGINE has a steep learning curve.

•

While Source is Free Source 2 is only free to Content Developers.

•

Unreal engine allows you to create artefacts.

After a lot of thought and hands on testing of each of the design environments Unreal

Engine 4 was selected for its versatility, low cost, ease of use and ability to manufacture

new game artefacts in engine. The option for dynamic lighting and simple to use but 

fully customizable interface gave it the edge over Unity and the Source engines. 

CryENGINE did not bring anything extra that would have suited the project for its

$9.90pm 

Page 10 of 20

---

2.2 Type of Game.

  When selecting the type of game it is important to understand the kind of information

you are trying to impart the user with and also which systems work best to convey that

information. For example a game of skill may increase hand eye co-ordination or a game

of strategy may increase a persons patience.

  In this case the goal is to impart the user with a full understanding of access control 

and for this reason it was decided that the game would be puzzle based. This would allow

for regular testing of skills learnt during the game and by having a global puzzle at its 

heart users that had completed the game would show a true understanding of the subject

matter.

2.3 Structure of Game.

 

  When selecting the structure of the game there are many requirements to consider.

•

To ensure re-playability the majority of puzzles would need to be modular.

•

As there will be players of varying skill sets the difficulty level should be adjustable.

•

To draw in users there should be a recognisable element to the game.

•

Each user should have a way of comparing their final result to others users.

•

The puzzles should vary in difficulty but each should show an understanding of at 

least one of the four requested deliverables.

•

The global puzzles should be significantly more difficult than the modular ones 

and require a full understanding of how the four deliverables mesh together.

•

There should be a time constraint.

•

There should be enough available information within the game to solve the

modular puzzles however there may not be fully complete information and a 

level of individual thought and ingenuity may be required.

  Taking into account the numerous requirements the following decisions were made.

•

The game will be set within the Kilburn Building at the University of Manchester.

•

The game will be a variant of the “escape the room” genre where the protagonist

(user) will find themselves accidentally locked into the Kilburn Building over the 

Christmas Holidays.

•

The user will have 48 hours (time will be scaled based on game difficulty) to escape.

•

The user will have to navigate themselves around the building to which they have 

limited access and find a way to unlock the main doors.

•

Each game will be different as modular puzzles will randomise on entry.

•

For those who manage to complete the game their run time will be entered onto 

the Great Escaper's record.

•

After considerable thought the game will be titled “The Great Kilburn Escape.”

   

Page 11 of 20

---

2.4 Design of Game.

  

  Given that the basis for the game is the challenge to escape the Kilburn Building

it would be logical to base the framework of the game around the topography of the

 

Kilburn building itself. To that end I spoke to the Student Support Office to find out

if it was possible to use the buildings floor plans to create my game environment.

This was confirmed by Gillian Lester on 3

rd

 of December 2016 and allowed me a 

detailed image to base my level designs.

Here are the plans for the Lower 1

st

 floor of the Kilburn Building.

 Obviously not all the rooms given on the floor plan are required for the game so the 

level constructed was a much simpler and cleaner version on the Kilburn Building 

without losing the overall framework of the building.

Page 12 of 20

Illustration 1: Figure 2.4

---

  The game itself requires a specific set of rooms, rules and equipment to fulfil its initial

requirements. 

These include.

•

Lockable external and internal doors.

•

An administrative office (SSO)

•

A technical services office (I.T. Services)

•

A data storage office (Server Room)

•

A guard feature on each door (RFID Door Locks)

•

A power management room (Security Office)

•

Limited initial access to the majority of these room.

•

The ability to upgrade internal access while inside the Kilburn Building.

•

The need to solve a puzzle or overcome an obstacle to upgrade access.

2.5  Design of Puzzles.

  The basis of the game is to impart access control knowledge in a way that makes 

the user think about its constraints but also its possibilities. The puzzles need to be 

hard enough to require research within the game but not so difficult that the user gives 

up at the first attempt. There are two main types of puzzles in the game. 

These are the Modular and the Global.

Modular Puzzles.

•

These puzzles are randomly selected at game launch and no two games should

share the same modular puzzles with the same solutions.

•

Each modular puzzle will require at least one of the four deliverables to solve.

•

Modular puzzles may not have a priority however some may require previous 

puzzles to have been completed.

•

The location of items and data will be randomised on the start of each game.

•

The higher the difficulty the greater the number of modular puzzles generated.

Global Puzzles.

•

These puzzles are central to the completion of the game and do not change at 

game launch. However the numerical solutions to them do.

•

These puzzles have a specific priority and require a number of modular puzzles

to have been completed before a solution is possible

•

The knowledge required to solve these puzzles requires a depth of understanding of 

access control.

•

There may be more than one way to solve a global puzzle.

Page 13 of 20

---

2.6  Actual Puzzles.

  These are a selection of some of the “Modular Puzzles” available and a brief word on their 

individual solutions.

ID Card Puzzle - A 2

nd

 year Student ID Card is located somewhere within the game 

allowing access to some restricted rooms in the building.

Elevated Access Puzzle - After gaining access to the SSO and locating a post-it with 

a staff members login details you are able to elevate your ID card access up to a

maximum of 3

rd

 year Student

Ground Floor Office Puzzle - To gain access to the Ground floor staff offices you 

require a Staff ID Card or the 4 digit visitor code (Which matches the birth date of

Tom Kilburn) available on a single one of the many pictures of him on the Ground and

1

st

 floor of the Game.

Security Puzzle - Gain access to the security office (which also houses the electrical 

circuit breakers for the building) only with a valid Staff level ID card. 

IT Services Puzzle - Gain access to IT service office and locate the specific rack and 

memory location of your ID cards status (Student 1

st 

year, Student 2

nd

 year, Student 

3

rd

 year, Postgraduate and Staff)

Server Room Puzzle – Gain access to the server room and overwrite the status code 

attached to your ID card account from Student to Staff.

  These are the two main “Global Puzzles” available (on lower levels of difficulty the

Power Puzzle is not present)

Global Door Puzzle - To open any of the external doors over the holidays you must 

have a valid Staff ID card. You must have also restored power to the external electronic 

locks via the Security Office as the circuit breakers tripped. 

Global Power Puzzle - To open the external doors not only must you have a valid Staff

ID card but there must be the correct amount of power feeding the door locks, too low 

and they wont work, too high and they will trip the circuit breakers. The specific fuse 

rated for the external door system is dead and will require a novel reconfiguration of 

the buildings active power to resolve. 

Page 14 of 20

---

Chapter 3

Development.

3.1   Time Line.

  The proposed project timeline was generated at the very start of the academic year 

(September 2015) and while it has changed numerous times the standard framework 

has remained the same.

Initial Time Line (32 week project including holidays)

Set in two week blocks allowing for task flexibility while showing progress in detail.

 

Week 1+2 

  Research project topic. Form general ideas on possible applications.

Week 3+4 

  Evaluate different ideas generated in weeks 1+2. Select application.

Week 5+6 

  Prep work for presentation. Flesh out game story and puzzles.

Week 7+8

  Prep work for presentation. Generate game engine requirements.

Week 9+10

  Give presentation. Test selected game engines for suitability. 

Week 11+12   Pick game engine. Sense check project. Draft design of 1

st

 game level.

Week 13+14   Draft design of 2

nd

 game level. Finalize design of 1

st

 game level.

Week 15+16   Draft design of 3

rd

 game level. Finalize design of 2

nd

 game level.

Week 17+18   Finalize design of 3

rd

 game level. Add connecting links to other levels.

Week 19+20   Alpha testing on game. List bugs and any game engine errors.

Week 21+22   Incorporate Alpha test bug fixes into game. Start Beta testing.

Week 23+24   Incorporate Beta test recommendations and bug fixes into game.

Week 25+26   Possibility of game add on. Polish levels and submit game.

Week 27 to 32   Generate project report and video screen cast.

Actual Time Line

Week 1+2 

  Research project topic. Form general ideas on possible applications.

Week 3+4 

  Evaluate different ideas generated in weeks 1+2. Select application.

Week 5+6 

  Prep work for presentation. Flesh out game story and puzzles.

Week 7+8

  Prep work for presentation. Generate game engine requirements.

Week 9+10

  Give presentation. Test selected game engines for suitability. 

Week 11+12   Pick game engine. Sense check project. Draft design of 1

st

 game level.

Week 13+14   Continue design on 1

st

 game level.

Week 15+16   Continue design on 1

st

 game level. Adjust timetable as required.

Week 17+18   Draft design of 2

nd

 game level. Continue design on 1

st

 game level.

Week 19+20   Continue design on 2

nd

 game level. Finalize design on 1

st

 game level. 

Week 21+22   Finalize design of 2

nd

 game level. Start Alpha testing. List bugs.

Week 23+24   Start Beta testing. Incorporate Alpha test bug fixes into game.

Week 25+26   Incorporate Beta test and bug fixes into game. Submit game.

Week 27 to 32   Generate project report and video screen cast.

  

Page 15 of 20

---

3.2 Development Issues.

  Development had continued to be within planned time line up until Week 15+16 where

the game level design took significantly longer than expected. This was replicated with 

the construction of the next game level taking on average 6 to 8 weeks to replicate a 

level instead of the originally planned 4 weeks. This hold up required a shake up of the

product timeline and it was decided that the planned 3

rd

 game level would be put on

hold (with the option to add it back into the project later on the development cycle if

time permitted.)

  There were other casualties including the loss of the proposed level add on and also 

the revised time line was pushed back 2 weeks.

3.3 Project Redundancies.

  Built into planning “The Great Kilburn Escape” were a series of redundancies put in 

place to mitigate any serious problems with keeping to the pre agreed schedule. 

These redundancies included.

•

Releasing a text based simulator of “The Great Kilburn Escape” which would allow for 

serious problems with the chosen game engine to be mitigated.

•

Only using one floor of the Kilburn Building if level design became prohibitively 

expensive.

•

Having simplified puzzles that required less “design” in the game engine.

•

Removal of the Global Power Puzzle.

  In the end the only redundancy that was used was to reduce the number of levels 

in the game from an initial 3 levels down to the more efficient 2 levels. This reduced 

projected work time by 6 to 8 weeks and allowed the project to adjust to a much more 

time intensive design process than originally scheduled.

Page 16 of 20

---

Chapter 4

Evaluation and Testing.

4.1 Evaluation.

  After generating the Alpha copy of the game I took some time to walk-through the

levels and not only bug fix but note down any improvements I could think of to make

the game more enjoyable and playable.

Some of the parts I highlighted were.

•

The timings on the internal doors were not synced with the standard move speed 

of the standard avatar.

•

Some of the drop points for the 2

nd

 Year ID Card were very hard to see and so were

excluding from the current list of spawn points.

•

The unlocked internal doors were too sensitive to approaching avatar and opened 

in situations were the player was moving away.

•

There was a lot of clutter on the ground floor, resolved by removing the number of

tables and re positioning plants.

•

At a specific point on the ground floor I could walk through the wall (at the edge) 

and enter a secured room. (wall replaced and confirmed solid)

  These notes and bug fixes were incorporated into the Beta build and this version I had

friends and family try it out and give their recommendations plus any bugs they found.

4.2 Testing. 

  The Alpha and Beta testing provided a large amount of data to analyse. From run times 

on different difficulties to common stall points in the game itself. 

Here is some of the more significant information.

•

Once a player spent more than 5 minutes playing the game that player almost always 

ended up completing the game on at least one difficulty level.

•

Initial tests given to Beta players at the start of the game showed that a level of pre 

knowledge of access control was not a significant factor in the speed at which the 

user was able to complete the game.

•

Of the two users who didn't complete the game on the first attempt 50% wanted to 

play again.

Page 17 of 20

---

•

Initial difficulty level mainly effected game run time not the likelihood of successful 

completion.

•

Men were 3 times more likely to chose Hard difficulty on first run through.

•

The two hardest puzzles were the Ground Floor Office Puzzle (surprising) and the 

Global Power Puzzle. (expected)

•

The 48 hour time limit ( Scaled based on difficulty) was sufficient.

•

The main reason given for playing the game more than once or at a higher difficulty 

was that they wanted to either beat their own time or another's score.

The data collected from the Beta testers were as follows.

•

An initial test on access control with multiple choice answers.

•

Run time of each full play though.

•

Time taken to complete each modular puzzle from entry into puzzle area.

•

Difficulty selected.

•

Comments and suggestions from the users after finishing the game.

•

A more detailed test on access control taken directly after user has finished playing.

•

A similar detailed test on access control taken more that 48 hours after test.

 Testing was a great help in the ongoing creation of the game as its highlighted issues 

that I had not noticed and even issues I would not have classed as issues. Your testers 

minds work much differently from your own and can therefore approach problems a 

totally different way. This can lead to confusion as the programmer can think a solution 

is accessible to all where as someone with a different mindset may find it much more 

difficult or even impossible.

  The comments given by the Beta testers showed a diverse range of opinions on the 

game and also how it could be improved. One of the most common comments was that 

the levels seem rather cluttered and items that had no game purpose were used to fill 

all the available space. This issue was resolved immediately by simply reducing the

amount of furniture or foliage on the levels.

Page 18 of 20

---

Chapter 5

Conclusion.

5.1 Conclusion

  In conclusion, the overwhelming response to the game has been positive. With 

all Beta testers selecting the game as their preferred method of training for access 

control. This is also backed up by the data generated showing greater test scores 

after the game and better information retention 48 hours later.

  Over the course of this project I have developed skills in areas that I had not 

previously considered necessary or even compatible with computer science. The 

shear depth of knowledge that is required to complete a project of this size surprised

me, with the research element during the first few weeks showing the huge scope of 

options available and the multitude of resources available. Most of these with little or 

no cost at all to use.

  Another skill I have developed much further during this project is my ability to plan 

redundancies for all major development points. As sometimes even with the best laid 

plans the real world can reduce your working time by more than half. This was well

demonstrated to me during the year when not only did a scheduled task end up taking

4 times the amount of time originally planned but I then became ill and delayed the

project even further.

 If I was to attempt the same type of project again I would give myself the following

advice.

•

Add at least 30% extra time to all scheduled activities.

•

Have multiple redundancies spread out over the full project timeline.

•

Test as early and as often as possible.

•

Sense check at regular intervals (monthly in the case of this project)

•

Gather a wide range of Beta testers especially including those with a non

technical background.

•

Research any project similar to your own and look for common issues or constraints.

•

Start small! Work on a smaller part of the whole until you understand its function and 

role in the bigger project.

•

Ask for help. Often.

•

Try not to overstretch. Instead plan modular add ons that can be produced assuming

the project is up to schedule.

•

External deadlines are deadlines. If you feel you may miss one re evaluate your

schedule.

•

A fresh set of eyes can work wonders on a stalled implementation.

•

And most importantly (to me) if you get stuck on a specific problem for more than an 

hour then file it away and work on something else. A good nights sleep can and will 

provide insight.

   

Page 19 of 20

---

   

Bibliography

[1] RSBAC. (2016). RSBAC Handbook. Available: 

https://www.rsbac.org/documentation/rsbac_handbook/architecture_implementation

.

Last accessed 10th June 2016. 

Page 20 of 20