Informatics Large Practical 留学生程序辅导、 java程序写作

”

Informatics Large Practical 留学生作业辅导、 java作业写作、java程序作业辅导

School of Informatics Informatics Large Practical 20192020 1
Informatics Large Practical

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.
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%
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.
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 location-based strategy game. The smart component is an autonomous
drone which competes against a human player who is acting as the pilot of a remote-controlled
(dumb) drone which moves only in response to directions from the pilot.

The autonomous drone and the player controlling the remote-controlled drone are playing a location-based
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 released
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 step-by-step 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 over-the-air if they are within 0.00025 degrees of the charging station. (Degrees
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
q
(x1 x2)
2 +(y1 y2)
2
Charging stations dispense coins in a fictional cryptocurrency called Powercoin; these real-valued 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 https://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 skull-and-crossbones) is used to distinguish positive
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 indicates
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 Geo-JSON 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 provided
by the https://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 Geo-JSON 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 24-digit 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 KFC
(55.946233,3.192473) (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 Geo-JSON files on a web server. The maps for 2019 and 2020 are available
at https://homepages.inf.ed.ac.uk/stg/powergrab/, under the name powergrabmap.geojson,
indexed by year, month and day in the format YYYY/MM/DD. For example, the map for September 15, 2019
is stored at https://homepages.inf.ed.ac.uk/stg/powergrab/2019/09/15/powergrabmap.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.

1
In 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 16-point compass rose. Original SVG image by I, Andrew pmk, CC BY-SA 3.0,
httpss://commons.wikimedia.org/w/index.php?curid=2249878
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 in-between. 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 right-angled 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.
going NNE w2 r cos(67.5) h2 r sin(67.5)
going NE w3 r cos(45) h3 r sin(45)
going ENE w4 r cos(22.5) h4 r sin(22.5)
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.
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
x : longitude
y : latitude
0

22.5
45
67.5
90
r
r
r
r
r E
ENE
NE
NNE
N

x4, y4

x3, y3

x2, y2

(x5, y5)
(x1, y1)
(x0, y0)
(x1, y1) = (x0, y0 +r )
(x2, y2) = (x0 +w2, y0 +h2)
(x3, y3) = (x0 +w3, y0 +h3)
(x4, y4) = (x0 +w4, y0 +h4)
(x5, y5) = (x0 +r, y0)
Figure 5: The five next possible locations for a drone which is travelling in a north-easterly 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
command-line 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 15/09/2019 and start the drone at a latitude and
longitude of (55.944425,3.188396). It initialises the pseudo-random number generator with the seed 5678
and chooses the stateless drone. (If the final command-line 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 dronetype-DD-MM-YYYY.txt and
dronetype-DD-MM-YYYY.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 relevant
PowerGrab map (for example, stateless-15-09-2019.txt and stateless-15-09-2019.geojson if
these results were obtained when processing the PowerGrab map for September 15th, 2019). Please use hyphens
(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.
dronetype-DD-MM-YYYY.txt This file should be 250 lines long. (It can however be shorter than 250 lines if
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 southsouth-easterly
(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.
dronetype-DD-MM-YYYY.geojson This file is a copy of the PowerGrab map which is located at the web address
https://homepages.inf.ed.ac.uk/stg/powergrab/YYYY/MM/DD/powergrabmap.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 pseudo-random 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
look-ahead, 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 back-and-forth 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 skull-and-crossbones 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. Further,
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 purposeful
path with much less of the back-and-forth 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 skull-and-crossbones 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 https://computing.help.inf.ed.ac.uk/java.
Using third-party 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 Geo-JSON maps. Instructions for adding the Mapbox Java
SDK to your project are available at httpss://docs.mapbox.com/android/java/overview/.
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 httpss://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 maven-archetypequickstart
(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 environment
to be JavaSE-1.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 ( httpss://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 significant
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: httpss://eclipsesource.com/blogs/tutorials/egit-tutorial
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 functionality.

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 Position(double latitude, double longitude) { … }
public Position nextPosition(Direction 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 position
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.
On Linux systems use the command zip -r powergrab.zip powergrab .
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:
submit ilp cw1 powergrab.zip
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 Allocat”