Java代写:CS416 Location based Strategy Game Part 1

代写一款Location-based game,这次是第一部分的工作。

Location-based game

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 Edinburgh’s 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.

Charging stations dispense coins in a fictional cryptocurrency called Powercoin; these real-valued coins are collected in order to increase the player’s 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 drone’s final score is the number of coins that it has stored at the end of the game.

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 http://geojson.io/ website. Figure 1 shows us what the map from Figure 2 looks like when rendered.

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 latitude. 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)

The PowerGrab maps are stored as Geo-JSON files on a web server. The maps for 2019 and 2020 are available, under the name powergrabmap.geojson, indexed by year, month and day in the format YYYY/MM/DD.

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.

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 earth’s surface as a plane. This means that, knowing that the drone travels a distance r , which is 0.0003 degrees, we can calculate the drone’s 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.

If the drone was instead heading South or West, the latitude or longitude of the drone’s position would be decreasing, so we would instead subtract the heights and widths of similar triangles.

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 drone’s 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

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, with the addition of a trace of the drone’s 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.

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).

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 2019-2020 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 doesn’t know what else to do, or it might adopt a safe holding pattern away from negative value stations.

Programming language

The programming language for this project is Java. At the time of writing, the version of Java which is available on Dice is 1.8.0. This means that your Java source code should be compatible with version 1.8, and run on a version 1.8 virtual machine.

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 https://docs.mapbox.com/android/java/overview/.