School of Informatics Informatics Large Practical 20192020 1
Informatics Large Practical
Stephen Gilmore and Paul Jackson
School of Informatics, University of Edinburgh
Document version 1.0.1
First issued on: September 17, 2019 Date of this revision: October 14, 2019
About
The Informatics Large Practical is a 20 point Level 9 course which is available for Year 3 undergraduate students on Informatics degrees. It is not available to visiting undergraduate students or students in Year 4 or Year 5 of their undergraduate studies. It is not available to postgraduate students. Year 4, Year 5 and postgraduate students have other practical courses which are provided for them.
Scope
The Informatics Large Practical is an individual practical exercise which consists of one large design and implementation project, with two coursework submissions. Coursework 1 involves creating a new project and implementing one important component of the project. Coursework 2 is the implementation of the entire project together with a report on the implementation.
Please note that the two courseworks are not equally weighted. There is no exam paper for the Informatics Large Practical so to calculate your final mark out of 100 for the practical just add together your marks for the courseworks.
Courseworks
Deadline
Out of
Weight
Coursework 1
16:00 on Friday 11th October
25
25
Coursework 2
16:00 on Friday 6th December
75
75
School of Informatics Informatics Large Practical 20192020 2 Introduction
The task for the Informatics Large Practical is to develop an autonomous smart component which is to play against a human component in a locationbased strategy game. The smart component is an au tonomous drone which competes against a human player who is acting as the pilot of a remotecontrolled dumb drone which moves only in response to directions from the pilot.
The autonomous drone and the player controlling the remotecontrolled drone are playing a locationbased game where the goal is to collect cryptocurrency coins and power from virtual charging stations which have been distributed around the University of Edinburghs Central Area. Your implementation of the drone should be considered to be a prototype in the sense that you should think that it is being created with the intention of passing it on to a team of developers who will maintain and develop it further. For this reason, the clarity and readability of your code is important. Given that it is based on collecting coins and power, and as we all know, money is power, the game is called PowerGrab.
In the PowerGrab game, the locations of the charging stations are specified on a map. A new map is re leased every day; each map has fifty charging stations. Cryptocurrency coins and power are collected from a charging station by flying a drone close to its location on the map, by which we mean that the drone makes a sequence of short moves to bring their location stepbystep nearer to the location of the charging station. For the purposes of the game, a player will be judged to be close enough to a charging station to be able to collect coins and power from it overtheair if they are within 0.00025 degrees of the charging station. De grees are used as the measure of distance in the game instead of metres or kilometres to avoid unnecessary calculations. As a simplification in the game, locations expressed using latitude and longitude are treated as though they were points on a plane, not points on the surface of a sphere. This simplification allows us to use Pythagorean distance as the measure of the distance between points. That is, the distance between x1, y1 and x2, y2 is just
x1 x22 y1 y22
Charging stations dispense coins in a fictional cryptocurrency called Powercoin; these realvalued coins are collected in order to increase the players score in the game. Charging stations also dispense power which is used by the drone to power its flight. The maximum payload which a changing station can have is a credit of 125.0 coins and 125.0 units of power. However, a charging station can also store debt and negative quantities of power, which cancel out the equivalent positive value stored in the drone. A drone cannot store a negative amount of coins or a negative quantity of power; the minimum which it can have is 0.0 coins and 0.0 power.
For example, if a user with 35.5 coins and 15.0 power comes within 0.00025 degrees of a charging station with 10.2 coins and 20.8 power then afterwards the user will have 25.3 coins and 0.0 power whereas the charging station will have 0.0 coins and 5.8 power.
Transfer of coins and power between the changing station and the drone is automatic; there is no way to prevent the transfer of coins and power from taking place if the drone is within 0.00025 degrees of the charging station. Note that the drone only connects to one charging station at a time and it always connects to the nearest charging station. This becomes significant when more than one charging station is in range.
The initial position of the drone is specified when play starts. At the start of the game, the drone has 0.0 coins and 250.0 units of power. Every move by the drone consumes 1.25 units of power. The game ends when the drone has made 250 moves or has run out of power, whichever comes sooner. The drones final score is the number of coins that it has stored at the end of the game.
School of Informatics Informatics Large Practical 20192020 3
Figure 1: A PowerGrab map rendered by the website http:geojson.io
Maps show the locations of the charging stations and also distinguish positive value charging stations where both coins and power are positive from negative value charging stations where both coins and power are negative. There are no mixed charging stations where one of coins or power is positive, but the other is negative.
The use of colour as in, green for positive, red for negative distinguishes positive from negative charging stations. In addition, the shape of the icon lighthouse or skullandcrossbones is used to distinguish pos itive from negative. Finally, brightness is used to differentiate stations with a lot of value in terms of coins and charge from stations with little value bright green indicates strong positive value; bright red indi cates strong negative value. During gameplay, the drone should try to visit positive value charging stations and try to avoid negative value charging stations.
Maps showing the locations of the charging stations are made available as GeoJSON documents, a JSON format which is specialised for describing places and geographical features. It is difficult for a person to interpret this JSON document directly, but we can render it with some mapping software, such as that pro vided by the http:geojson.io website. Figure 1 shows us what the map from Figure 2 looks like when rendered.
School of Informatics Informatics Large Practical 20192020 4
type: FeatureCollection, dategenerated: Tue Jan 01 2019, features:
type: Feature,
properties:
id: 237d16f857e567fc2d3e1ca1, coins: 15.655206987957596,
power: 40.763427231356744, markersymbol: lighthouse, markercolor: 003800
,
geometry: type: Point, coordinates:
3.1917158579021225,
55.94404781601724
,
type: Feature,
properties:
id: 9fa94a8528d1381ba0d25e75, coins: 123.76819100883893,
power: 74.62785781303182, markersymbol: danger, markercolor: c60000
,
geometry: type: Point, coordinates:
3.190260653365977,
55.94587364601307
,
…
Figure 2: A map with charging stations in GeoJSON format.
School of Informatics Informatics Large Practical 20192020 5
Every map has the same format; it is a FeatureCollection containing a list of Features. Every Feature has Point geometry with two coordinates, a longitude and a latitude1. There will always be 50 Features in the FeatureCollection of each map, each one being a charging station.
The Features in the map have properties which are metadata which tell us information about the charging station, and also markup which tells the geojson.io site how to render the feature as a placemark on a map. Every charging station has a 24digit hexadecimal identifier id which uniquely identifies this station.
All points on every map have a latitude which lies between 55.942617 and 55.946233. All points on every map have a longitude which lies between 3.184319 and 3.192473. This defines the PowerGrab playing area as illustrated in Figure 3. The drone must at all times remain within the playing area.
Forrest Hill 55.946233, 3.192473
KFC
55.946233, 3.184319
PowerGrab
is played here
55.942617, 3.192473 55.942617, 3.184319 Top of the Meadows Buccleuch St bus stop
Figure 3: The PowerGrab play area
The PowerGrab maps are stored as GeoJSON files on a web server. The maps for 2019 and 2020 are avail able at http:homepages.inf.ed.ac.ukstgpowergrab, under the name powergrabmap.geojson, indexed by year, month and day in the format YYYYMMDD. For example, the map for September 15, 2019 is stored at http:homepages.inf.ed.ac.ukstgpowergrab20190915powergrabmap.geojson
The drone cannot fly in an arbitrary direction: it can only fly in one of the 16 major compass directions as seen in Figure 4. These are the primary directions North, South, East and West, and the secondary directions between those of North East, North West, South East and South West, and the tertiary directions between those of North North East, East North East, and so forth.
1In this project, longitudes will always be negative close to 3 and latitudes will always be positive close to 56.
School of Informatics Informatics Large Practical 20192020 6
Figure 4: The 16point compass rose. Original SVG image by I, Andrew pmk, CC BYSA 3.0, https:commons.wikimedia.orgwindex.php?curid2249878
As the drone flies, it travels at a constant speed and consumes power at a constant rate. In each move, the drone consumes 1.25 units of power, and moves a distance of 0.0003 degrees.
Wind speed and direction are not modelled in the game; the drone behaves in the game as though it is flying on a perfectly still day with no wind2. This means that the drone travels the same distance no matter which direction it is flying in. Obstacles such as trees, lampposts and buildings are also not modelled in the game; we can think that the drone is flying high enough that it flies over all the buildings in the George Square area.
When the drone is flying, it is necessary to determine its next location from its current location and the direction of travel. Figure 5 shows the five next possible locations if the drone is travelling North, or East, or some compass direction inbetween. When considering small changes of latitude or longitude, as we are doing here, it is acceptable to approximate the earths surface as a plane. This means that, knowing that the drone travels a distance r , which is 0.0003 degrees, we can calculate the drones next position using either simple arithmetic or simple trigonometry. We consider rightangled triangles with hypotenuse r , width wi , and height hi when travelling NNE, NE or ENE. To get the new longitude, we add the width of the triangle to the old longitude. To get the new latitude, we add the height of the triangle to the old latitude. The respective widths and heights as used in Figure 5 are shown below.
If the drone was instead heading South or West, the latitude or longitude of the drones position would be decreasing, so we would instead subtract the heights and widths of similar triangles.
going NNE
w2
r cos67.5
h2
r sin67.5
going NE
w3
r cos45
h3
r sin45
going ENE
w4
r cos22.5
h4
r sin22.5
2Admittedly, there being no wind is perhaps not very realistic for Edinburgh, but it is a useful simplification of the problem.
School of Informatics Informatics Large Practical 20192020 7
y : latitude
x1,y1x0,y0 r
22.5 NE
x3,y3x0 w3,y0 h3 x3,y3
x4,y4x0 w4,y0 h4
x5,y5x0 r,y0 x5,y5
x2,y2x0 w2,y0 h2
x1,y1
x2,y2
N
NNE
0
r
r
r
67.5 r
45
x4,y4
ENE
r
90
x : longitude
E
x0,y0
Figure 5: The five next possible locations for a drone which is travelling in a northeasterly direction. Starting
at longitude, latitude of x0, y0, the next possible locations are x1, y1 . . . x5, y5.
Finally, the object of the game is simply to collect as many coins as possible.
The implementation task
You are to develop a simulation framework which demonstrates two versions of an automated drone which plays the PowerGrab game as though it was playing against a human player. The first version has some specific limitations and is stateless; this version is suitable for playing against a novice human player. The second version does not have these limitations and is stateful; this version is suitable for playing against an expert human player. A better implementation of the stateful drone is one which collects more coins while still keeping its runtime modest.
In the simulation of the game, each drone has 250 moves in which to grab as much power as possible and achieve the highest score that it can. The moves made by the drone, its location, and the coins and power which it currently has are reported after every move to provide a trace of the drones play in the game.
The simulation framework
You are to develop a simulation framework which loads the PowerGrab map for a specific date and reports the first 250 moves which the drone makes when started at a specific latitude and longitude within the map. Assuming that the simulation framework is stored in powergrab.jar and the simulation is run with the commandline arguments:
15 09 2019 55.944425 3.188396 5678 stateless
School of Informatics Informatics Large Practical 20192020 8
then the simulator should load the PowerGrab map for 15092019 and start the drone at a latitude and longitude of 55.944425, 3.188396. It initialises the pseudorandom number generator with the seed 5678 and chooses the stateless drone. If the final commandline argument was stateful, then the simulator would instead choose the stateful drone.
Your application may write any messages which it likes to the standard output stream but it should also write two text files in the current working directory. These are named dronetypeDDMMYYYY.txt and dronetypeDDMMYYYY.geojson where dronetype is either stateless or stateful depending on which version of the drone was used, and DD, MM, and YYYY are replaced by the day, month and year of the rele vant PowerGrab map for example, stateless15092019.txt and stateless15092019.geojson if these results were obtained when processing the PowerGrab map for September 15th, 2019. Please use hy phens not underscores in the file names and use only lowercase letters. Note that stateful is spelled with only one letter L. The content of these two files is the following.
dronetypeDDMMYYYY.txt Thisfileshouldbe250lineslong.Itcanhoweverbeshorterthan250linesif the drone runs out of power. It contains each move of the drone in terms of the latitude and longitude of the drone before the move, the direction it chose to move, the latitude and longitude of the drone after the move, and the values of the coins and power for the drone after the move. For example, the first line of this file could be:
55.944425,3.188396,SSE,55.944147836140246,3.1882811949702905,0.0,248.75
This says that the drone was initially at 55.944425,3.188396, then decided to move in a south southeasterly SSE direction to 55.944147836140246,3.1882811949702905, and after that move was completed it had 0.0V coins and 248.75 units of power. Compass directions should always be written entirely with capital letters using the abbreviations which appear in Figure 4 of this document.
dronetypeDDMMYYYY.geojson ThisfileisacopyofthePowerGrabmapwhichislocatedatthewebad dress http:homepages.inf.ed.ac.ukstgpowergrabYYYYMMDDpowergrabmap.geojson, with the addition of a trace of the drones flightpath for example, as seen in Figure 6 and Figure 7, using the method for adding lines to a map which will be outlined in the course lectures.
The stateless drone
The stateless drone is intentionally limited in order that it is a more suitable opponent for novice players of the PowerGrab game. Other than its knowledge of its position on the map, the stateless drone has no local state i.e. the class has no fields other than a pseudorandom number generator and hence its strategy for choosing the next move cannot depend on previous moves.
The stateless drone is thus memoryless, and it is limited in another way; the stateless drone only has limited lookahead, meaning that its decision of the next move to make can only be based on information about the charging stations which are within range of the sixteen positions where the drone can be after one move from its current position. The stateless drone is not allowed to scan the entire map to decide where to go next; its decision where to move next must be based on local knowledge and guided by the general PowerGrab gameplay of trying to move towards charging stations with positive value, while avoiding charging stations with negative value if possible.
School of Informatics Informatics Large Practical 20192020 9
When the flightpath of a stateless drone is plotted on the map, as in Figure 6, it shows a jittery path with quite a lot of backandforth motion which sometimes backtracks to positions where the stateless drone has been before because, being memoryless, it cannot remember where it has been. However, the flightpath of a stateless drone is not totally chaotic and random. We can see this because it attempts to avoid negative value charging stations marked with a red skullandcrossbones marker on the map and it attempts to visit positive value charging stations marked with a green lighthouse marker on the map.
Figure 6: A PowerGrab map showing the mostly random path of a stateless drone which starts in George Square Gardens.
The stateful drone
There are no limitations placed on the stateful drone; it can use whatever strategy it likes to play against the human player of the game here, assumed to be an experienced or expert player.
The stateful drone can remember any aspect of the earlier gameplay which it thinks will help it later. Fur ther, it can examine the entire map before making its decision of where to move next. There is no limited lookahead for the stateful drone as there was for the stateless drone.
When the flightpath of a stateful drone is plotted on the map, as in Figure 7, it shows a much more purpose ful path with much less of the backandforth motion that we saw with the stateless drone. The flightpath of the stateful drone shows it seeking out positive value stations marked with a green lighthouse marker on
School of Informatics Informatics Large Practical 20192020 10 the map and attempting to avoid negative value stations marked with a red skullandcrossbones marker
on the map.
When all of the positive value stations have been visited the stateful drone may randomly fly about because
it doesnt know what else to do, or it might adopt a safe holding pattern away from negative value stations.
Figure 7: A PowerGrab map showing the mostly directed path of a stateful drone which starts in George Square Gardens.
Programming language
The programming language for this project is Java. At the time of writing, the version of the Java language which is the default on DICE is Java 8. However, you may use any version of Java which is available on DICE, including Java 10, which provides local variable type inference. Instructions for changing the version of Java used on DICE are available at http:computing.help.inf.ed.ac.ukjava.
Using thirdparty software and libraries
This practical exercise allows you to use free software, but not commercial software which you must pay for or license. One free software development kit SDK which you should find useful is the Mapbox Java SDK which provides classes and methods for parsing GeoJSON maps. Instructions for adding the Mapbox Java SDK to your project are available at https:docs.mapbox.comandroidjavaoverview.
School of Informatics Informatics Large Practical 20192020 11
Informatics Large Practical Coursework 1
Stephen Gilmore and Paul Jackson
School of Informatics, University of Edinburgh
1.1 Introduction
This coursework and the second coursework of the ILP are for credit; weighted 25:75 respectively. Please now read Appendix A for information on good scholarly practice and the Schools late submission policy.
In this project you are creating a Java application which is built using the Maven build system. We will begin
by using Eclipse to create the project structure.
1.2 Getting started
If you are working on your own laptop you should begin by downloading Eclipse, if you do not already have it. Download it from https:www.eclipse.org. On DICE, Eclipse is available via the eclipse command.
Next, create a new Maven project in Eclipse by choosing File New Project . . . , and choosing Maven Project as the option. Leave unchecked the option which reads Create a simple project skip archetype selection; this is unchecked by default. On the following page, choose the archetype mavenarchetype quickstart this is the default. On the final page, fill in the options as shown below:
Group Id: uk.ac.ed.inf Artifact Id: powergrab
Find JRE System Library in the Package Explorer and select Properties. Change Execution environ ment to be JavaSE1.8.
You should now have a working Maven project structure. Note that there are separate folders for project source and project tests. Note that there is an XML document named pom.xml where you can place project dependencies. Two Java files have been automatically generated for you: App.java and AppTest.java.
1.3 Setting up a source code repository
This part of the practical is not for credit, but it strongly recommended to help to protect you against loss of work caused by a hard disk crash or other laptop fault.
School of Informatics Informatics Large Practical 20192020 12
In the Informatics Large Practical you will be creating Maven project resources such as XML documents and Java files which will form part of your implementation, to be submitted in Coursework 2. We recommend that these resources be placed under version control in a source code repository. We recommend using the popular Git version control system and specifically, the hosting service GitHub https:github.com. GitHub supports both public and private repositories. You should create a private repository so that others cannot see your project and your code.
Check your current Maven project into your GitHub repository. Commit your work after making any signif icant progress, trying to ensure that your GitHub repository always has a recent, coherent version of your project. In the event of a laptop failure or other problem, you can simply check out your project e.g. into your DICE account and keep working from there. You may have lost some work, but it will be a lot less than you would have lost without a source code repository.
A tutorial on Git use in Eclipse is here: https:eclipsesource.comblogstutorialsegittutorial
1.4 The implementation task
For this first coursework of the ILP you are to implement a critical part of PowerGrab game, the function which calculates the immediate next position of the drone, given the current position and the direction of flight. Your implementation will be judged on three criteria: correctness, readability, and efficiency.
Your implementation must have a package named uk.ac.ed.inf.powergrab with a class called Direction,
which defines constants:
Direction.N,
Direction.S,
…
and so on for all sixteen compass directions used in this practical. This class does not have any other func tionality.
Your implementation is also to contain another class named Position, as outlined below:
package uk.ac.ed.inf.powergrab;
public class Position
public double latitude;
public double longitude;
public Positiondouble latitude, double longitude …
public Position nextPositionDirection direction …
public boolean inPlayArea …
…
Your class can contain other fields, other constructors, and other methods, but it must contain those listed above, and they must be individually labelled as public so that they are visible outside the current package. Your submission can contain any other classes which you have implemented; these will be ignored in this coursework because our interest here is only in the class Direction and the class Position.
School of Informatics Informatics Large Practical 20192020 13
The method nextPosition in the Position class is to implement the function which returns the next po sition of the drone when it makes a move in the specified compass direction. Refer to Figure 5 for the specification of this function, remembering that the drone travels 0.0003 degrees in a move. I.e. r 0.0003.
The method inPlayArea tests whether or not this Position lies in the PowerGrab play area as specified in
Figure 3 of this document.
To help you with getting the nextPosition and inPlayArea methods correct, a set of unit tests will be made available from the ILP course web page in the file AppTest.java. Your nextPosition and inPlayArea methods should pass all of these tests.
1.5 Preparing your submission
Make a compressed version of your powergrab project folder using ZIP compression. OnLinuxsystemsusethecommand .
On Windows systems use Send to Compressed zipped folder.
On Mac systems use File Compress powergrab.
You should now have a file called powergrab.zip. 1.6 How to submit
Please submit your implementation work from your DICE account using this command:
In order to streamline the processing of your submissions, and help avoid lost submissions, please use exactly the filename powergrab.zip. The archiving format to be used is ZIP only; do not submit TAR, TGZ or RAR files, or other formats.
1.7 Allocation of marks
A total of 25 marks are allocated for Coursework 1 according to the following weighting.
Correctness15marks: Yourfunctionshouldbeacorrectimplementationofthenextpositionfunction for the drone, giving the correct next position for all sixteen possible compass directions.
Readability 5 marks: Your function should be clear and concise. The implementation of the Direction and Position classes should be readable and clear.
Efficiency5marks: ThenextpositionfunctionwillbeexecutedmultipletimesinthePowerGrabgame, and while testing the game, so it is important that it should be efficient. The game development team have not yet decided on the Java compiler which will be used to compile the release version of the game, so the compiler optimisations which will be applied are not yet known. The safest assumption in this setting is to assume that the compiler will not optimise your function at all and that you should explicitly code any optimisations which can be made to the next position function.
zip r powergrab.zip powergrab
submit ilp cw1 powergrab.zip
School of Informatics Informatics Large Practical 20192020 14
Informatics Large Practical Coursework 2
Stephen Gilmore and Paul Jackson
School of Informatics, University of Edinburgh
2.1 Introduction
As noted above, Coursework 1 and Coursework 2 of the ILP are for credit; weighted 25:75 respectively. Information on good scholarly practice and the Schools late submission policy is provided in Appendix A.
This coursework consists of the report, the implementation, and a collection of output files written by your implementation. The code which you submit for assessment should be readable, wellstructured, and thor oughly tested.
2.2 Report on your implementation
You are to submit a report documenting your project containing the following. Your report should have three sections as described below.
1. Software architecture description. This section provides a description of the software architecture of your application. Your application is made up of a collection of Java classes; explain why you identi fied these classes as being the right ones for your application. Identify class hierarchical relationships between classes: which classes are subclasses of others?
2. Classdocumentation.Provideconcisedocumentationforeachclassinyourapplication.Explaineach class as through providing documentation for a developer who will be maintaining your application in the future.
3. Stateful drone strategy This section explains the strategy which is used by your stateful drone to im prove their score relative to the stateless drone. You should explain what is remembered in the state of the stateful drone and how this is used to improve the drones score.
This section of your report should contain two graphical figures similar to Figure 6 and Figure 7 in this document which have been made using the http:geojson.io website, rendering one flight of your stateless drone and one flight of your stateful drone on a PowerGrab map of your choosing. It can be any of the available PowerGrab maps, but make sure that the same map is used for both the stateless drone and the stateful drone.
The maximum page count of your project report is 15 pages, with title pages, table of contents, references, appendices, and all other material included in the page total. You cannot submit reports which are over 15 pages in length, but shorter submissions will be accepted. The choice of font, font size, and margins is up to you but please consider the readability of your submission, and avoid very small font sizes and very small margin sizes.
School of Informatics Informatics Large Practical 20192020 15 2.3 Source code of your application
You are submitting your source code for review where your Java code will be read by a person, not a script. You should tidy up and clean up your code before submission. This is the time to remove commented out blocks of code, tighten up visibility modifiers e.g. turn public into private where possible, fix and remove TODOs, rename variables which have cryptic identifiers, remove unused methods or unused class fields, fix static analysis problems, and to refactor your code as necessary. The code which you submit for assessment should be wellstructured, readable and clear.
2.4 Results from the two drones
In addition to submitting your source code for assessment, you should also submit 48 output files giving the results of trying your drones against the maps on specific days of the year3 while starting the drone at a latitude and longitude of 55.944425, 3.188396. You should submit a ZIP file archive ilpresults.zip containing the following files:
stateless01012019.txt stateless01012019.geojson stateful01012019.txt stateful01012019.geojson stateless02022019.txt stateless02022019.geojson stateful02022019.txt stateful02022019.geojson
. . . . stateless12122019.txt stateless12122019.geojson stateful12122019.txt stateful12122019.geojson
All of the files named stateless. should have been generated using the same version of your applica tion using the stateless drone and all of the files named stateful. should have been generated using the same version of your application using the stateful drone.
2.5 Preparing your submission
Clarification: The powergrab folder which is submitted is the toplevel eclipseworkspacepowergrab. MakeacompressedversionofyourpowergrabprojectfolderusingZIPcompression.
OnLinuxsystemsusethecommand . On Windows systems use Send to Compressed zipped folder.
On Mac systems use File Compress powergrab.
You should now have a file called powergrab.zip.
Placeyour48outputfilesinafoldercalledilpresultsandcompressitinthesameway.Youshould
now have a folder called ilpresults.zip. 2.6 How to submit
Please submit your report and your implementation work from your DICE account using these commands:
In order to streamline the processing of your submissions, and help avoid lost submissions, please use exactly these filenames for the three submissions. The submission format for your report is PDF only; do not submit DOCX files, TXT files, or other formats.
3DDMM2019 where DDMM.
zip r powergrab.zip powergrab
submit ilp cw2 ilpreport.pdf
submit ilp cw2 powergrab.zip
submit ilp cw2 ilpresults.zip
School of Informatics Informatics Large Practical 20192020 16
2.7
2.8
Things to consider
YoursubmittedJavacodewillbereadandassessedbyaperson,notascript.Itisnotawasteoftimeto add comments to your code, documenting your intentions. Your submitted code should be readable and clear.
Your output files .txt and .geojson will be processed by a script, not read by a person. Your text file must be formatted as described above, and your GeoJSON file must be a copy of the input GeoJSON file with the addition of a trace of your drones flightpath.
Logging statements and diagnostic print statements using System.out.println and friends are useful debugging tools. You do not need to remove them from your submitted code; it is fine for these to appear in your submission. You can write whatever you find helpful to System.out, but the content of your output files must be as specified above.
Your application should be robust. Failing with a NullPointerException, ClassCastException, ArrayIndexOutOfBoundsException or other runtime error will be considered a serious fault. An exception to this is java.net or java.io exceptions which are thrown due to unavailability of the Informatics web server which hosts the PowerGrab maps. These will not be considered to be a fault with your implementation.
Allocation of marks
A total of 75 marks are allocated for Coursework 2 according to the following weighting.
Report30marks: Youaretoprovideadocumentdescribingyourimplementation.Yourdocumentshould be a clear and accurate description of your implementation as described in Section 2.2 above. The three sections of the report are equally weighted, with 10 marks for each section.
Implementation 30 marks: Your submission should faithfully implement the stateless and the stateful drones of the PowerGrab game, hosted in a framework which allows the drone to make 250 moves against a map for a particular day. Your application should be usably efficient, without significant stalls while executing. Your code should be readable and clear, making use of private values, variables and functions, and encapsulating code and data structures. Where it is appropriate to do so, your classes should be structured in a way which makes use of the Java class hierarchy mechanism. All else being equal, code with comments should receive a higher mark than code without comments. Everyone thinks that their code is selfdocumenting, but it isnt.
Output15marks: Theoutputfileswhichyousubmitwillbetestedtoensurethatthemovesmadebythe drone are legal according to the rules of the PowerGrab game, and the class of drone which is being used. The quality of the drone strategy implemented will be graded depending on the score which the drone achieves: the higher the score, the better the quality of the drone.
School of Informatics Informatics Large Practical 20192020 17
Appendix A
Coursework Regulations
Good scholarly practice
Please remember the University requirement as regards all assessed work for credit. Details about this can be found at:
http:web.inf.ed.ac.ukinfwebadminpolicies
academicmisconduct
Furthermore, you are required to take reasonable measures to protect your assessed work from unautho rised access. For example, if you put any such work on a public repository then you must set access per missions appropriately generally permitting access only to yourself, or your group in the case of group practicals.
The Informatics Large Practical is not a group practical, so all work that you submit for assessment must be your own, or be acknowledged as coming from a publiclyavailable source such as Mapbox sample projects, answers posted on StackOverflow, or opensource projects hosted on GitHub, GitLab, BitBucket or else where.
Late submission policy
It may be that due to illness or other circumstances beyond your control that you need to submit work late. The School of Informatics late submission policy aligns with the universitys Assessment Regulations which applies the following penalty: 5 percentage points will be deducted for every calendar day or part thereof it is late, up to a maximum of 7 calendar days. However, to this University policy, the School of Informatics also adds the constraint that late submission will only be accepted if no submission in time has been made. For more information, see
http:web.inf.ed.ac.ukinfwebstudentservicesitoadmin courseworkprojectslatecourseworkextensionrequests
The staff of the Informatics Teaching Organisation will approve extension requests up to 7 days in accor dance with the good reasons which are defined in the Universitys assessment regulations.
Please note that things that would not be considered good reasons include among other things lastminute computer problems and loss of work through failing to backup your source code. Frequent commits of your work into a remote source code repository such as GitHub provide an offsite backup of your work which can allow you to continue from where you left off in the case of a disk or other hardware failure, so we recommend committing your work frequently.
School of Informatics Informatics Large Practical 20192020 18
Appendix B The small print
Introduction
This appendix contains some details about the practical which are relevant to know, but are not perhaps the first things that you would think of to ask.
Webserver unavailability. Your simulation framework begins by downloading a map from the School of Informatics web server. In the rare cases where the web server is down or overloaded it will not serve the map to your application. This will cause a Java exception to be thrown and your application will be unable to simulate the game. This will not be counted as a flaw in your application. Your application will be rerun and tested again when the web server is back up and serving maps as usual.
UMLdiagrams.UMLdiagramsareawidelyusednotationfordescribingsoftwaresystems.However, this course does not teach UML diagrams and not all of the students on this course have taken a UML course previously. For this reason, there is no expectation that your documents will include UML diagrams and, consequently, there are no marks allocated to them in the marking scheme.
School of Informatics Informatics Large Practical 20192020 19
Appendix C
Using the Piazza Forum
Details
The Informatics Large Practical has a discussion forum on Piazza. This is available online at the address https:piazza.comed.ac.ukfall2019infr09051ilphome. You can register yourself to this forum at https:piazza.comed.ac.ukfall2019infr09051ilp
Guidelines
Subscribing to the Informatics Large Practical Piazza forum is optional, but strongly encouraged. Questions posted to the forum may be answered by the course lecturers or by another student on the course. Please read the following notes to ensure that you have the best experience with the forum. These guidelines are based on several years of experience with course fora, where issues such as those below have arisen.
Anonymous and pseudonymous posting on the forum is not allowed so please enrol for the course Piazza forum with your own name. Please be aware that, however they may appear to you, posts on the forum are not anonymous to the course lecturers. The forum is available only to students who are enrolled on the ILP this year. The course lecturers reserve the right to delete the enrolment of anyone who is not or appears not to be registered for the ILP.
Especially when commenting on another students work, please consider the feelings of the person receiving your message. Please refrain entirely from comments criticising the progress of another student. Each of us works at our own pace and there are many different possible orders in which to tackle the work of the ILP. Perhaps you finished implementing something in Week 4, but that does not mean that everyone did.
If you find some content on the forum helpful, or think that it is making a useful contribution to the course, please acknowledge this by clicking Good question or Good answer as appropriate; this encourages continued participation in the forum. The course lecturers will endorse answers which they believe to be helpful.
Forumpostingswhichintendtocorrectfactualerrorsorresolveambiguitiesinthepracticalspecifica tion are welcome. If necessary, the course lecturers will update this coursework document to correct the errorresolve the ambiguity.
Whenaskingforhelpwithfixingaruntimeerror,suchasanexception,pleaseincludewhatseemsto be the most relevant part of the diagnostic error message that you receive, but please include as little of your code as possible. The course lecturers may edit or delete your post if you include too much program code.
TheInformaticsLargePracticalisanindividualprogrammingprojectsoyouarenotallowedtoshare your code with others. Please bear this in mind when answering questions on the forum; do not post your solution as an example for someone else to borrow from. Piazza is not StackOverflow: please do not post minimal working examples for others to copy and use.
School of Informatics Informatics Large Practical 20192020 20
Many questions on Piazza tend to be of the form Do we need to do V for Coursework 1? or Are we expected to do W for Coursework 2?. You already have the answers to these questions. This document, the one you are reading right now, contains the definitive statement of what is required for each coursework. It is the coursework specification. If this document does not say that it is necessary to do V for Coursework 1, or to do W for Coursework 2, then you do not need to do those things.
Forumpostingswhichaskforpartofthesolutiontothepracticalarestronglydiscouraged.Examples in this category include questions of the form What is the best way to implement X ? and Can I have somehintsonhowtodoY?
Questions about the marking scheme for the practical are strongly discouraged. Examples in this category include questions of the form Which of the following alternatives would get more marks? and How much detail is required for Z ?
School of Informatics Informatics Large Practical 20192020 21
Appendix D
Document version history
1.0.0September17,2019: Initialversionofthisdocumentissued. 1.0.1October14,2019: Minorrevisionwithtwochanges.
1. Page 10. Change to allow the choice of Java 10 as the version of Java which is used. This is in response to student midcourse feedback which asked to be allowed to use Java 10. Use of Java 8 is still allowed but now use of Java 10 is allowed also.
2. Page15.Clarificationtoidentifyexplicitlythatthepowergrabfolderwhichissubmittedisthe toplevel Eclipse project folder, normally stored as eclipseworkspacepowergrab.