EECS3311语言编程讲解、辅导Software程序、讲解Python设计编程调试Matlab程序|讲解R语言编程

项目预算：开发周期：发布时间：要求地区：

EECS3311 Software Design Fall 2020
Project
Designing and Implementing the Space Defender 2 Game
Chen-Wei Wang and Kevin Banh
Released Date: Monday, November 2
Phase 1 Due Date (Sections A & E): 11:59pm (EST), Wednesday, November 25
Phase 2 Due Date (Sections A & E): 11:59pm (EST), Wednesday, December 9
Policies
– Your (submitted or un-submitted) solution to this project (which is not revealed to the public)
remains the property of the EECS department. Do not distribute or share your code in any
public media (e.g., a non-private Github repository) in any way, shape, or form. The department
reserves the right to take necessary actions upon found violations of this policy.
• You are required to work on your own for this project. No group partners are allowed.
• When you submit your project, you claim that it is solely your work (both the software and the design
document). Therefore, it is considered as an violation of academic integrity if you copy or share any
parts of your Eiffel code or the design document during any stages of your development.
• When assessing your submission, the instructor and TA will examine your code, and suspicious submissions
will be reported to the department/faculty if necessary. We do not tolerate academic dishonesty, so
please obey this policy strictly.
– You are entirely responsible for making your submission in time.
• You are encouraged to submit multiple times prior to the deadline: only the last submission before the
deadline will be graded.
• Practice submitting your project early even before it is in its final form.
• No excuses will be accepted for failing to submit shortly before the deadline.
• Back up your work periodically, so as to minimize the damage should any sort of computer failures occur.
Follow this tutorial series on setting up a private Github repository for your Eiffel projects.
• The deadline is strict with no excuses: you receive 0 for not making your electronic submission in time.
• Emailing your solutions, or links to a cloud drive, to the instruction or TAs will not be
accepted.
– You are free to work on this lab on your own machine(s), but you are responsible for testing your code at a
remote Prims lab machine before the submission.
1
Contents
1 Individual Work 3
2 Cross References to Lab3 Instructions 3
3 Grading Scheme for Phase 1 3
4 Suggested Sequence of Development for this Project 4
5 Getting Started 4
1 Individual Work
As already specified and explained in your course syllabus, only individual work is allowed for the project. Here are
the rationales:
1. Given the inability to gather physically, we want to minimize the disadvantage of those of you who cannot find
a suitable team member and/or who cannot collaborate effectively virtually (over different time zones).
Furthermore, we would like to avoid you encountering issues which are (much) more likely to occur or even
exacerbated in a completely online context: time is wasted between coordinating meeting times and deliverables
among members, there is an unfair distribution of work between members, and/or a contributing member
withdraws from the course at the last moment or becomes non-responsive.
2. We reckon that individual work is the best way for you to learn (and achieve the CLOs) and for us to assess
your understanding and design/implementation skills.
3. Knowing that this course is run completely online this term, this project was developed over the past summer
with the intention for a single student to complete over the five-week period. We also release more starter tests to
guide your development. Moreover, as you can see from the suggested work sequence in the project instruction,
the design problem may be solved most effectively by implementing modules sequentially, rather than being
coordinated between members.
4. Compared with projects in the previous semesters, the current project is made lighter in its scale and difficulty.
But of course it still requires solid work and a steady development process.
We will be actively holding office/TA hours and moderating the course forum to help you complete the project.
Please start early with your development and approach us early.
2 Cross References to Lab3 Instructions
To avoid repetitions (and thus satisfy the single choice principle), here are sections which you would still consult
with from your Lab3 instructions:
– Working on Your Own Machine
– Grading Criterion of this Lab: The grading criterion for the software part of your project (both Phase 1
and Phase 2) will be consistent with that for your Lab3: each acceptance test is considered as passing only
if the output generated by your program is character-by-character identical to that generated by the oracle.
Therefore, it is crucial that you constantly run regression tests on your software.
– Reporting Issues of the Oracle
– Task 1 of Lab3: Required Tutorials (Review how to use ETF if necessary.)
– Developing your ETF Project: GUI Mode vs. Command-Line Mode
– Modification of the Cluster Structure
3 Grading Scheme for Phase 1
The sole purpose of the Phase 1 submission (2% of your course grade) is to ensure that you are making reasonable
progress, so as to minimize the need to rush through your development for Phase 2. See Section 8.1 for details on
the submission. The mark you get is based on the number of starter tests your submission passes. There are 15 tests
provided in the starter folder. Out of the 2%, you will receive:
– 2% if your submission passes at least (≥) 11 starter tests
– 1.5% if your submission passes at least (≥) 9 starter tests
– 1% if your submission passes at least (≥) 7 starter tests
– 0% if your submission passes less than 7 starter tests.
3
4 Suggested Sequence of Development for this Project
– Review how to use ETF if necessary.
– Spend a good amount of time reading through the requirements of the game:
• Section 6
• Text file messages.txt (messages for abstract state)
• Text file errors.txt (messages for errors)
• Example acceptance tests: at001.txt to at015.txt, and their corresponding expected files.
Any clarifications needed for these requirements items, post your questions on the course
forum.
– Implement the game:
• Start by implementing everything outside of the in game state.
• Implement the initial state of the in game state.
• Implement the Starfighter’s movement and pass command.
• Implement the friendly projectiles.
• Add the enemies.
• Add the scoring system.
• Implement the Starfighter’s specials.
• Throughout the above steps, create acceptance tests and test against the oracle.
– Write the design document (Section 7).
5 Getting Started
– First of all, make sure you have already acquired the basic knowledge about the Eiffel Testing Framework (ETF)
which can be found in the tutorial videos and parts of Lecture Series 6.
– Download the system space defender 2.zip file from the course eClass page and unzip it.
– Follow this tutorial video to get started from the downloaded starter file:
https://www.youtube.com/watch?v=pjXjlPNpb5c&list=PL5dxAmCmjv_5q9wBFXV-M4S4VbB1T0EJg&index=9
– In the starter folder, there is a small project starter code, which consists of two classes
• RANDOM_GENERATOR
• RANDOM_GENERATOR_ACCESS
which you are simply expected to re-use verbatim, when implementing the two generated numbers
as described in Section 6.13.7, in the model cluster of your project.
4
6 Task 1 (Phase 1 & 2): Development of the Space Defender 2 Game
6.1 (Informal) Background
Many years have passed since the first battle between the creatures of the Void and humankind. Time changes
everything. With the research branch at work, the current iteration of Starfighter feature customizable parts for
weapons, armour and engine, allowing for specialization based on the battlefield. In addition, salvaged parts (orbment
and focus) from the enemy units have allowed for development of special abilities for Starfighters. The countless
engagements with the enemy monsters allowed for a better understanding of them. So far, five different types of
enemy units have been discovered. First is the generic Grunt. Next is the improved version of a Grunt, the Fighter.
We have the large Carrier which releases a torrent of drones known as Interceptor. The Interceptor’s goal is to simply
absorb projectile damage, serving as a shield to other units. Finally, a massive structure called Pylon which heals
surrounding units. The enemy units appear to behave differently based on how the Starfighter acts and whether
they see the Starfighter or not. Your goal is to update the simulation made in the previous lab to accommodate the
new technologies and information. Unfortunately, time travelling is not one of the special abilities developed for the
Starfighter hence there is no need to keep the undo/redo from the previous simulation.
6.2 Contrast with Lab3
This project asks you to develop a game independent of Lab3, though it has some limited extent of
similarity with the simple game you developed for Lab3. To understand the rules of the game, it is
important that you read carefully the rest of this section. Also note that for this project, you do not
need to implement the undo/redo design pattern.
Section 4 suggests sequence of developments. However, you need to constantly run regression tests on your software
for incremental developments.
6.3 Vocabulary
– Orbment: Can be either a singular orb or a container (focus). Enemies drop orbments when they are destroyed,
and orbment has a different value (score).
– Focus: A container for orbments. Starfighter has one focus with an unlimited capacity. On the other hand,
the focus an enemy drops has a limited capacity, and its score is amplified when filled (see Section 6.15 for how
scoring works).
6.4 Looks of Abstract State
In this section we present some abstract state displays that your design/implementation must support:
– When the software is first launched, we are in the not started state (i.e., the game is not yet started):
state:not started, normal, ok
Welcome to Space Defender Version 2.
– Upon using the play command, the software goes to the setup stage. The setup stage is composed of 5 states:
four of these states are for the Starfighter to select different parts (e.g., weapon, armour), and most states look
similar to below. Commands setup back and setup next are used to navigate between states in the setup stage,
whereas command setup select is used to select options.
Commands setup back and setup next allow you to move back and forth between the five setup state: if you
setup back too far, you will end up in the not started state (as if you invoked the abort command); if you
setup next too far, you will end up starting the game. See Section 6.6 for more details on the setup stage.
->play(5,10,1,1,1,1,1)
state:weapon setup, normal, ok
1:Standard (A single projectile is fired in front)
Health:10, Energy:10, Regen:0/1, Armour:0, Vision:1, Move:1, Move Cost:1,
Projectile Damage:70, Projectile Cost:5 (energy)
5
2:Spread (Three projectiles are fired in front, two going diagonal)
Health:0, Energy:60, Regen:0/2, Armour:1, Vision:0, Move:0, Move Cost:2,
Projectile Damage:50, Projectile Cost:10 (energy)
3:Snipe (Fast and high damage projectile, but only travels via teleporting)
Health:0, Energy:100, Regen:0/5, Armour:0, Vision:10, Move:3, Move Cost:0,
Projectile Damage:1000, Projectile Cost:20 (energy)
4:Rocket (Two projectiles appear behind to the sides of the Starfighter and accelerates)
Health:10, Energy:0, Regen:10/0, Armour:2, Vision:2, Move:0, Move Cost:3,
Projectile Damage:100, Projectile Cost:10 (health)
5:Splitter (A single mine projectile is placed in front of the Starfighter)
Health:0, Energy:100, Regen:0/10, Armour:0, Vision:0, Move:0, Move Cost:5,
Projectile Damage:150, Projectile Cost:70 (energy)
Weapon Selected:Standard
– At the end of the setup stage, a summary of the chosen parts for the Starfighter will be displayed.
->play(5,10,1,1,1,1,1)
... -- first setup state omitted
->setup_next(4) -- move 4 states forward from the current setup state
state:setup summary, normal, ok
Weapon Selected:Standard
Armour Selected:None
Engine Selected:Standard
Power Selected:Recall (50 energy): Teleport back to spawn.
– At any point in time, the two toggle commands may be used. The key command out of those two is toggle debug mode
(which you need to implement to switch the debug mode on or off). The other command toggle RNG out is not
required to be implemented by you.
As an example, here is the output when you invoke toggle debug mode outside of a game:
->toggle_debug_mode
state:not started, debug, ok
In debug mode.
As another example, here is the output when you invoke toggle debug mode when a game has been started:
->toggle_debug_mode
state:in game(0.1), debug, ok
In debug mode.
– When a game has been started, its state is displayed differently according to whether debug mode is on (see
Section 6.14.1 for more details). When the debug mode is on, more information is displayed. Here is an example
game state where the debug mode is off :
->setup_next(5)
state:in game(0.0), normal, ok
Starfighter:
[0,S]->health:70/70, energy:70/70, Regen:1/3, Armour:1, Vision:13, Move:10, Move Cost:3, location:[E,1]
Projectile Pattern:Standard, Projectile Damage:70, Projectile Cost:5 (energy)
Power:Recall (50 energy): Teleport back to spawn.
– The only two commands that can be invoked any time are toggle debug mode and toggle RNG out. All other
commands must be used with constraints (see Section 6.14.2); failing them will lead to error messages. For
example:
->abort
state:not started, normal, error
Command can only be used in setup mode or in game.
6.5 Some Commands to Know
– In order to begin the process of setting up the Starfighter’s equipments, the user first invokes the play command,
e.g., play(10,30,1,1,1,1,1). After the setup process is completed, we say that a game of an indefinite number
of turns begins. Now we discuss the seven argument values of the play command:
• The first two numbers are for specifying the size of the board (in this example, a 10-by-30 board). The first
number represents the number of rows (ranging from 5 to 10), whereas the second number represents the
number of columns (ranging from 10 to 30).
• Each of the remaining five numbers ranges from 1 to 101 and must be non-decreasing (e.g., invoking play( ,
, 101, 101, 60, 60, 1) should trigger an error message). The combination of these last 5 numbers serves
the following purpose: during the end of each turn in a game, a random number generator (RNG) is used
to generate two numbers (and we refer to the first number as i and the second number as j).
Say the number of rows is r and the number of columns is c.
The first number i (ranging from 1 to r) determines which row in the last column of the board an
enemy should spawn (i.e., an enemy should spawn at location [i,c]).
7
The second number (ranging from 1 to 100) is used to determine which enemy spawns:
From an invocation of the play command play( , ,n1,n2,n3,n4,n5), the last five numbers specify
the thresholds for Grunt (n1), Fighter (n2), Carrier (n3), Interceptor (n4), and Pylon (n5). And
these five threshold values suggest six intervals to consider for generating enemies (to see more about
this random generation of enemies, see Section 6.13.7):
· If the second number j is in the interval [1, n1) (i.e., between 1 inclusive and the grunt threshold
n1 exclusive), then a Grunt will spawn.
· If the second number j is in the interval [n1, n2) (i.e., between grunt threshold inclusive and fighter
threshold exclusive), then a Fighter will spawn.
. . . (This pattern continues.)
· If the second number j is is in the interval [n5, 101) (i.e., between pylon threshold inclusive and 101
exclusive), then nothing is spawned.
As an example, consider the invocation of play(6,25,60,60,101,101,101):
If the first number i generated is 5, then the enemy spawn location would be [E,25]. (Recall that rows
are represented by letters, and E is 5th letter in the alphabet.) Here the first interval is [1, 60), meaning
that if the second number j is between 1 and 59, a Grunt will spawn. The second interval is [60, 60)
which is empty, meaning that no Fighter can ever spawn. The third interval is [60, 101), meaning that
if the second number is between 60 and 100, a Carrier will spawn. The fourth and fifth intervals are
both empty (i.e., [101, 101)), meaning that no Interceptor and Pylon can ever spawn. Finally, the sixth
interval is also empty (i.e., [101, 101)), meaning that in each turn, an enemy (i.e., Grunt or Carrier)
will always spawn.
As another example, consider the invocation of play(10,30,1,1,1,1,1):
If the first number i generated is 10, then the enemy spawn location would be [J,30]. Given that the
first five intervals are all empty (i.e., [1, 1)), none of the five kinds of enemies can ever spawn in each
turn. The fact that the sixth interval is “universal” (i.e., [1, 101)) makes sure that the second number j
(ranging from 1 to 100) generated will always fall within this interval and does not spawn any enemy.
That is, regardless of the second number, based on the rules above, no enemies will spawn.
Remark. When you test the correctness of your design, you may try various combinations of these
threshold values.
– The abort command can be used to exit from either the setup stage (before a game starts) or the current turn
(during a game).
– The toggle debug mode command “flips” the debug mode (e.g., to on if it is currently off ). By default, the
debug mode is initialized to off. If in game mode and the debug mode is on, the abstract state displayed shows
more information. Essentially, a normal game should have its debug mode switched off, whereas switching it on
shows everything in that state which allows for a programmer to debug.
When the debug mode is switched off, only the following is displayed:
• basic state information (like state number)
• information about the Starfighter
• a board with information limited by the fog of war mechanics
(i.e., the Starfighter has limited vision on locations on the board; see Vision in Section 6.6)
• whether the game is over
For more information, refer to Section 6.14.
– toggle RNG out: This command is available for use in the oracle provided, but is not required for you to
implement (see Section 6.16 for more details). The purpose is to help you debug RNG (random number generator)
usage. This command can be used anytime and toggles a flag on use. If invoked in a game, the flag is set to true
and the effect will only take place in the next turn. More precisely, in the next turn, there will be an additional
RNG Usage: section appended at the end displaying the two randomly generated numbers (i.e., the row number
and the enemy value) for spawning enemies.
8
6.6 Setup
The software, once launched, has a number of states for its progression. The logical sequence is you begin in a not
started state, move to the setup stage (which itself consists of five states) before moving into a in game state. In the
following, we describe each of these states.
1. not started state: you arrive in this state as soon as you launch the software (e.g., in the interactive mode via
oracle.exe -i).
2. setup stage: Invoking the play command moves the player from the not started state to the beginning of the
setup stage. The setup stage consists of five states, weapon setup, armour setup, engine setup, power setup,
setup summary.
– Navigating between each state in the setup stage is done via the setup back and setup next commands.
Each of these commands has an integer parameter between 1 and 5. Using the setup back or setup next
command moves the state from the current state, respectively, backward or forward by the specified integer
amount of states.
Consequently, going before the weapon setup state (e.g., invoke setup back(2) when the current state is
armour setup, the 2nd setup state) will lead you to back to the not started state. Similarly, going beyond
the setup summary state (e.g., invoke setup next(4) when the current state is armour setup) will lead
you to the in game state.
For example, say after invoking the play command initially, we invoke the following in sequence: setup next(2),
setup back(1), and setup next(5). What will be the intermediate states?
• We start at weapon setup due to the play command.
• By invoking setup next(2), we move to the engine setup state, which is two states ahead of weapon
setup.
• By invoking setup back(1), we move back one state which is armour setup.
• By invoking setup next(5), given that setup summary is 3 states ahead of the current state (armour
setup), we go beyond the setup summary state and arrive in the in game state.
It is also possible to invoke the abort command to exit from the setup stage and go back to the not started
state.
– Except for the setup summary state, each of the other four states of the setup stage allows the player to
choose the equipments (i.e., weapon, armour, engine, and power) for the Starfighter. By default, option
1 is selected for the weapon, armour, engine, and power. By invoking the setup select command. The
setup select command takes as input an integer between 1 and 5 and selects the corresponding option
displayed for that particular state in the setup stage.
Selected equipments are preserved; you can overwrite the selected equipments by invoking the setup select
command; the history of selected equipments is wiped out only when the software is terminated. This means
if a certain equipment is chosen and the setup stage is exited1
, the next time the setup stage is entered,
that certain equipment will be selected by default.
The setup summary summarizes what equipments the Starfighter is entering the game with.
There are 5 different types of weapons, 4 different types of armours, 3 different types of engines, and 5
different types of powers. Weapons, armours, and engines share some common attributes (see below).
Attribute values for each weapon, armour, and engine, along with the error message for selecting an invalid
equipment option, can be found in Section 6.14. Additional information about weapons and powers can be
found in Section 6.7 and Section 6.8, respectively.
The Starfighter’s final attribute values, upon entering the in game state, are the sum of its
parts. Attributes which weapon, armour, and engine share in common include:
• Health: It represents the maximum integrity of the entity (e.g., Starfighter, Grunt), also known as
the total health. An entity’s current health value has the lower bound of 0 and upper bound of this
maximum Health value. If the current health falls to 0, the entity is destroyed. Note that in the game,
for the Starfighter only, it is possible for its current health value to exceed this maximum Health value
by using a power.
1Recall there are three ways for exiting the setup stage: abort, setup back before the weapon state, or setup next beyond the
setup summary state.
9
• Energy: It represents the maximum energy of the Starfighter, also known as the total energy. Note
that the current energy cannot exceed total energy (with the exception of using a power). Energy is
required for the Starfighter to move, to use a power, or to fire projectiles.
• Regen (for regeneration): There are two numbers.
The first number represents the amount of current health the Starfighter gains per turn passively
(health regeneration). Recall that the current health cannot exceed total health, so regeneration
only works up to the total health value (except with the use of a power).
The second number is for energy regeneration and it works the same way as health (with respect
to the Energy value above).
Note. Regen is the base value for the (health or energy) regeneration process to take place.
• Armour: If the Starfighter and a projectile collide, the damage done to the Starfighter is the projectile’s
damage minus the Starfighter’s armour. Armour does not have any cancelling effect on collisions with
non-projectiles.
• Vision: It represents how many spaces away, on the board, the Starfighter can see from its current
location.
For example, if the Starfighter is in [D,1], in normal mode, to see what entity is in [C,3], you need
a vision of 3 (1 vertical + 2 horizontal) or more. Spaces beyond the range of the Starfighter’s vision
are known to be in the fog of war and, in normal mode, are represented by a ? symbol on the board
output.
Note that in debug mode, the fog of war is not displayed on the board output.
• Move: It represents how many spaces away the Starfighter can move from its current location (assuming
it has enough energy). The distance calculation is the same as vision calculation: vertical distance plus
horizontal distance in terms of spaces.
• Move Cost: It represents how many energy unit it takes for the Starfighter to move 1 space. If the
move cost is 5 and we make a move from [A,1] to [D,3], it would cost 25 energy units: 5 spaces (3
vertical + 2 horizontal) × 5.
3. in game state: this is when the game has begun. See later sections.
6.7 Weapon Types
The weapon chosen plays a role in how the Starfighter’s fire command affects the board when used in game. Each
weapon has the shared attributes described above (e.g., health, energy). In addition, each weapon has other attributes
that determine: 1) the health or energy cost to fire the projectiles; and 2) the base damage of the projectiles (when
they collide with other entities). These attributes can also be found in Section 6.14; to complement that section, here
we describe:
– When the Starfighter fires, how many projectiles spawn and where they spawn.
– After spawning, assuming the friendly projectiles are still on the board, every subsequent turn later, how the
friendly projectiles act also depends on the weapon selected.
There are 5 different types of weapons.
– Standard: One projectile is spawned. It appears to the right of the Starfighter. For example, if the Starfighter
is at [A,2], the projectile appears at [A,3]. Every subsequent turn after, the projectile moves 5 units to the right.
– Spread: Three projectiles are spawned:
• The first one is spawned to the top-right of the Starfighter, the second to the right of the Starfighter while
the last projectile is spawned to the bottom-right of the Starfighter. For example:
• If the Starfighter is at [D,4], the projectiles appear at [C,5], [D,5] and [E,5] in that order.
• Every subsequent turn after, the projectiles move 1 unit in the direction where they spawned relative to the
Starfighter when it fired. For example, the projectile at [C,5] will move up right to [B,6] while the projectile
at [D,5] will move to [D,6].
Note. Recall how the Starfighter travels diagonally: vertical first, then horizontal. Contrast this with how
a projectile travels diagonally (which is a real diagonal movement). For example, if there was an entity at
[B,5], no collision will occur from the projectile travelling from [C,5] to [B,6]. On the other hand, if the
Starfighter was to travel from [C,5] to [B,6], it would first travel vertically to [B,5], resulting in a collision.
10
– Snipe: One projectile is spawned. It appears to the right of the Starfighter. For example, if the Starfighter is at
[A,2], the projectile appears at [A,3]. Every subsequent turn after, the projectile moves 8 units to the right.
Note. Unlike all the other projectiles, this projectile travels by “teleporting” to the final location. More precisely,
if there are any entities along the horizontal path to the targeted location, the projectile will not collide with
any of those entities unless there is an entity in the targeted location (which is 8 units to the right of the initial
location).
– Rocket: Two projectiles are spawned. The first one is spawned to the top-left of the Starfighter while the
second projectile is spawned to the bottom-left of the Starfighter. For example, if the Starfighter is at [B,2], the
projectiles appear at [A,1] and [C,1] in that order. Every subsequent turn after, the projectiles move starting at
1 unit to the right and doubling (because it’s a rocket!) in movement each turn.
Note. If the Starfighter is in the first column and they fire, the projectiles will be spawned outside the board
behind them, in which case we still assign ids to them. However, in the next turn, since these projectiles are
already outside the board, we do not keep track of them, meaning that they will not move into the board.
– Splitter: One projectile is spawned. It appears to the right of the Starfighter. For example, if the Starfighter
is at [A,2], the projectile appears at [A,3]. The projectile does not move.
6.8 Specials
There are 5 different kinds of special/power a Starfighter may have. Powers may be used in game via the Starfighter’s
special command. The cost, type of cost, and a brief description of each kind of power can be found in Section 6.14.
Below is a more in-depth description of each power.
– Recall: When you start a game, the Starfighter spawns in a certain location (see Section 6.10). When this
special is used, teleport the Starfighter to that location. Unlike moving, you can still use this command if the
Starfighter is to be teleported to the same location. Make sure to account for collisions at the spawn location.
– Repair: Increase current health by 50 units.
Note. this is the only case that current health may exceed the total health for a Starfighter.
– Overcharge: This is to sacrifice current health for gaining current energy. This is dependent on the amount of
the current health spent. It will use up to 50 current health as long as the Starfighter is not destroyed to convert
to current energy. The conversion is: 1 current health for 2 current energy.
For examples: If you have 1 current health, 0 current health will be converted to 0 current energy. If you have
11 current health, 10 current health will be converted to 20 current energy, and there is still 1 current health
left. If you have 100 current health, 50 current health (hence the up to) will be converted to 100 current energy,
and there is still 50 current health left.
Note. This is the only case that current energy may exceed total energy for a Starfighter.
– Deploy Drones: Clears out all the projectiles on the board. The order of removal is from projectiles that
spawned earliest to latest.
– Orbital Strike: All enemies take 100 damage, reduced by their armour value. Suppose an enemy has 15
armour, they will take 85 (i.e., 100 - 15) damage. The order of taking damage is from enemies that spawned
earliest to latest.
6.9 Enemies
There are various kinds of enemies (described), and they have shared attributes, including:
– health (total health)
– regen (health regeneration per turn)
– armour (which mitigates damage: one point of damage to one point of armour for the collision with a friendly
projectile or an Orbital Strike by the Starfighter)
– vision (which works the same way as the Starfighter’s vision)
11
– seen by Starfighter (whether or not the enemy is within the Starfighter’s vision; only updated in certain
phases of a turn; see Phase 4 and Phase 6 in Section 6.13)
– can see Starfighter (whether or not the Starfighter is within the enemy’s vision; only updated in certain
phases of a turn; see Phase 4 and Phase 6 in Section 6.13)
Enemies may also preempt certain moves depending on the Starfighte

EECS3311语言编程讲解、辅导Software程序、讲解Python设计编程 调试Matlab程序|讲解R语言编程

EECS3311语言编程讲解、辅导Software程序、讲解Python设计编程调试Matlab程序|讲解R语言编程