Portfolio 5 Tasks

Portfolio Five: Software Engineering, design and development, problem solving and programming task

All of this portfolio is individual work.

In this portfolio, we are assessing the skills you have developed so far in the following areas: 

  • Fundamental knowledge of the theoretical underpinnings of computer science
  • Understanding of standards, formats and tools used in the design of information, multimedia and web-based systems
  • Ability to specify and contextualize a problem and communicate effectively an appropriate solution to a range of audiences
  • Use of software engineering techniques to design, code, test and evaluate a range of software solutions 
  1. Problem Context

As you are aware from the previous PPWeeks, the City of Funderland is holding a local election. These elections are happening in many cities around the country – including Funderland’s twin town Unity City. The citizens of Unity City are anything but united and tension in the city has reached fever pitch as election day is upon us!

With worries of cheating, vote rigging and potential violence, the City of Funderland Council chiefs have offered their support by sending extra security to their twin town to ensure that voting takes place without incident, tampering or any similar threats to democracy.

You have been tasked with identifying and stopping corruption on polling day in Unity City! 

  1. Requirements Specification

PART A

You must create an idle clicker, single playergame for PC (standalone), where the player’s aim is to stop corrupt citizens from entering the polling booth to tamper with the voting system.The game has been partially developed to start you off. The code is provided for you in a zip file (see important notes about working with the Unity zip file in part 3 Suggested Approach).

In the polling station there are 2 available voting booths. Voters arrive throughout the day (7am-10pm) and enter one booth to cast their vote, then leave.

You are a security guard, sent from City of Funderland and stationed in the polling station to identify shifty looking characters and stop them in their tracks! Be on the lookout for anyone who appears dodgy and as they reach the threshold of the booth you should remove them. The table below shows key features that you must work at developing first, followed by suggestions for enhancements you may try to make in your game. 

Key Features

Game Mechanics: Game Flow

·         Idle clicking:The game should involve a minimum of two buttons that relate to the two voting booths in the game. These will be used to capture the corrupt voters as they attempt to tamper with the votes.

·         Press the button associated with the correct voting booth as a corrupt voter moves into position, to eliminate them.

 

·         Score based system:A global score may increment / decrement based on the type of voter. This may also be split to encompass different score types (e.g. number of corrupt voters captured).

·         As a voter is eliminated, a score-based system should update on the screen to reflect this.

 

·         Timer: The election can only last so long, and when the night is over the results will be tallied. It is here where we find out how democratic the citizens of Funderland can be.

 

·         The game ends when the timer reaches zero, or if some other feature has been implemented (e.g. a set of lives).

 

Additional Features/scenarios

These are merely features/scenarios to give you guidance on what you *could* implement to make your game more interesting. The list is not exhaustive, so feel free to get creative and make up your own features!

·         Life system: As corruption increases, cause the player to lose a life!

 

·         Corruption meter: The more corrupt votes that enter the system, the more acceptable corruption becomes in the City of Funderland! When it reaches full, the city is thrown into chaos, causing the game to end.

 

·         Scenario modes (difficulty settings)

o   Totalitarian – The city is run by a harsh dictator. Corrupt votes become valid votes for the dictator, which reduces the number of votes for all other political parties. Define a threshold for the dictator to automatically win.

o   Revolution – Only through revolution can the city be reformed! Add an additional voting booth for a third political candidate (with a third button associated with it).

o   Martial Law – The power of the military has a strong influence on the people. Add a third type of voter that reduces the score of an opposing political party to zero.

o   Rush Hour – As the night continues, more and more citizens are pouring into the voting station. Increase spawn rate and / or voter speed over time.

o   Anything you can think of!

 

·         Added audio

 

·         Imported custom textures

 

You may also wish to add features to enhance gameplay and add overall polish to the game.

·         Overall polish includes features such as main menu screens and a gameover screen. A credits reel could also be implemented

·         The game itself could include feedback for the player such as:

o   visual prompts when button press is available,

o   updates when the score decreases/increases etc

 

Important note:The game has an initial flow but could be turned on its head. For example, perhaps you want to assume the role of a corrupt official that intentionally tampers with the system to give your preferred party the most votes! Any additional features you add should not detract from the core game play, but instead be incorporated to enhance the features already present. 

PART B

As well as developing the above game you must, as usual, demonstrate some aspect of software engineering proficiency and this week the SE task is testing. You will need to demonstrate your approach to structural testing of the above system using an effective set of structural test data.

  1. Suggested Approach 
  1. Reflect on your performance in Professional Practice Week 4 using your own thoughts, your tutor feedback and your response to the tutor feedback. You are advised to use the template so that you make sure you have considered every point we are looking for you to address: subject-specific skills, transferable skills, time and effort spent, additional resources used, reflection on performance – this includes consideration of and reaction to tutor feedback, and finally feedforward response to tutor feedback (and you should explain what you are responding to – do not just say things like “yes the feedback made sense”). The feedforward plan is meant to be your discussion of how you intend to act upon the feedback to continuously improve and shouldn’t be limited simply to the next piece of assessed work. You should do this first of all before you turn your attention to this week’s tasks. (If you have not received your feedback you should speak with the module leader.) This part of the week’s activities is, together with your professional practice (daily logs), worth 15%.
  2. You are encouraged to get feedback on your set of ideas as you develop your system. Remember that there is a minimum/key set of features and an advanced set of features so in particular you should discuss any ideas for further enhancements which will allow you to potentially get higher marks.As with previous assessments, basic marks will be available for completion of basic functionality, then additional marks will be awarded for further complexity and flair that you might demonstrate.
  3. C# programming constructs such as loops, arrays and methods should be used and attention should be given to method signatures, layout and commenting. You may adopt your own naming convention – but stick to whichever one you choose.
  4. As you decide on your system specification you must derive your 3 part structural test plan - i.e. test run (flow) chart, test type descriptions, test case table (planned test cases, not actually carried out). Do not wait until you have coded your system to think about this - you must upload this no later than Wednesday 8pm. Once your system is complete and you finish running your structural tests you will have a completed table which we will examine in the demo.

Important notes about working with the provided zip file in Unity:

  • If you are working on the university machines, you must extract it in a drive with a letter (e.g. H drive) as their student ones don't work. 
  • If you extract the zip and have missing prefabs, scripts etc, you have not extracted it properly. There should only ever be 1 assets folder, otherwise Unity doesn't know where you are storing your scripts etc. 
  • If you right click the zip, hit extract all, and then choose the destination it should work perfectly. 
  1. What to Hand-in

Monday12th March, Tuesday, Wednesday and Thursday by 8pm to eportfolio – your daily log.

Wednesday14th March by 8pm to eportfolio – your planned 3-part structural test plan

Friday 16th March by 8pm - Upload a zip file of your programme to the PPW5 upload link. You should also upload your system to your eportfolio. If the file is very large you may upload a link to an external source.

A schedule will be produced of the times you will demo your system in the final week of term. 

  1. Indicative breakdown of marks

60% for coded system

25% for testing (15 for Structural; 10 for demo/functional)

15% reflection and feedforward plus daily logs