Computer Organization Spring 2022 Programming Project: NS-Shaft
(Deadline 11:55PM, May 15 Sun via Canvas)
1 Introduction
NS-Shaft https://youtu.be/-SksNwLmSSE is a platform video game created in 1900 by Nagi-P SOFT Co.,Ltd. from Japan. In this game, the player moves left and right, trying to dive deeper into the cave. You will implement a simplified NS-Shaft Game with MIPS assembly!
Copyright By PowCoder代写 加微信 powcoder
Figure 1 shows several snapshots of this game. The game displays a deep cave, where several platforms are placed at different positions. The platforms move upward while accelerating slowly. There are spikes at the top of the screen.
The goal is to fall from platform to platform rapidly enough to not be hit by the spikes, but slowly enough not to fall off the bottom of the screen. You can control the player by the keyboard, press key ”a” to move left and press key ”d” to move right.
The player will die if he/she jumps too fast and falls off the bottom of the screen, or he/she jumps too slow and hits the spikes at the top of the screen. The player will also die if he/she runs out of ”life.” The ”life” value is displayed on the upper left corner of the screen. The ”life” value decreases when the player touches spike platform and recovers when the player stands on a normal platform.
Fig. 1: Screenshots of NS-Shaft Game
There are 5 types of platform in the cave:
1. The stable normal platform : when the player stands on it, the ”life” value will recover by one until maximum.
2. The unstable flip-able platform : when the player jumps to it, the platform flips after a moment.
3. The rotating platform which keeps rolling to one direction: when the player jumps to it, the player will move left or right with a constant speed until he/she leaves this platform.
4. Theelasticspringplatform :Whentheplayerjumpstoit,theplayerkeeps bouncing on it vertically.
5. The spike platform which is paved with sharp spikes: when the player jumps to it, the ”life” value will decrease by one. The color of the player will turn to red for a few seconds.
The player wins the game when he/she reaches 20 layers deep in the cave. When
the player wins the game, a text message ”You win!” will be displayed over the game screen, a ”game win” sound effect will be played and the game will finish. If the player fails to finish the game, a text message ”You lose!” will be displayed over the game screen, a ”game lose” sound effect will be played and the game will finish.
2 Coordinate System
The game canvas is of 300 ⇥ 600 pixels as illustrated in Figure 2. The top-left corner pixel is (0, 0) and the bottom-right corner pixel is (299, 599). The player is represented by a rectangular image of 20 ⇥ 30 pixels. The platforms are represented by rectangular images of 100 ⇥ 15 pixels. The location of each object is referenced by its top-left cor- ner coordinates. When the player is running rightward on the platform, his/her x speed is positive and y speed is negative.
Programming Project: NS-Shaft
(100, 60) (50, 100)
(150, 165)
Fig. 2: The coordinate system
3 Game Objects
There are two types of game objects: player and platform.
3.1 Player
Table 1 lists the variables and attributes of the player object. We need to update the editable variables to implement the game.
The speed player speed and location player locs are updated constantly during the game. 1) If the player is standing on a platform, the player speed is first updated ac- cording to the keyboard input. Then, the player speed is further updated according to the type of the platform (e.g. the rotation speed for the rotating platform and the jump- ing speed for the spring platform). Finally, the location of the player player locs is updated according to the final player speed. 2) If the player is falling, the player speed is first updated by increasing the y speed by gravity. Then, the player locs is updated according to the player speed.
The appearance of the player is determined by direction and hurt status, which can be edited via syscall. You can press ”a” or ”d” in the keyboard to let the player turn left or right, respectively.
variable/attribute
player size
player move on platform speed player falling x speed
player locs player speed
life value direction (in Syscall) hurt status (in Syscall)
-1 (20, 30) 8
(x loc, y loc) (x speed, y speed) 0-10
0 or 1 or 2
description
the shape of player
the running speed of player the x speed of falling player
top-left coordinate
the speed of player the life value of player 0: left, 1: right, 2: front 0: normal, 1: hurt
Table 1: The information of the player object.
The information of all the platforms in screen is stored in a variable platforms. Each platform has four attributes: (id, x location, y location, type index). The attributes of the platforms are demonstrated in Table 2. Table 3 lists the variables and attributes of all platform objects.
Programming Project: NS-Shaft
3.2 Platform
type index
normal 0 flip-able 1 spring 2 spike 3 left-rotation 4 right-rotation 5
description
life value +1
breaks after 0.5s
player bouncing, y speed = -6 life value -2
player moves left, x speed -1 player moves right, x speed +1
Table 2: The type and index of the platform objects.
variable/attribute
platform size platform num initial platform data
(100, 15) 10 array
description
platform size
total number of platform objects info of initial platforms
editablecurrentplatformaddress address addressofthecurrentplatforminplatforms
platform y speed < 0 y speed of all platforms platform rotation speed 1 or -1 the rolling speed of the current platform
Table 3: The information of the platform objects.
Game Details Game initialization
array of platform info
Before the game starts, we first initialize the game via procedure init game. First, the information of all the initial platforms are generated and stored into platforms. The player object and platform objects are created via syscall. Then, the life value, layer number and the vertical speed of platforms are initialized. Finally, the game screen is refreshed via syscall.
Programming Project: NS-Shaft
4.2 Collision detection: player and platform
The interaction between different game objects depends heavily on collision detection. It is required to decide whether the player hits any platform when he/she is falling. Although the images of the game objects may seem irregular, we consider two objects collide with each other when their rectangular images intersect for simplicity. The rule is simple: when the border of the game object overlaps with another object’s border, they collide. You will implement the collision detection in procedure check platform exists. You can find detailed hints in the skeleton file to further figure out the logic.
4.3 Wining and losing conditions
The player must jump to more than 20 layers deep to win the game. When the player jumps to a platform with object id greater or equal to 20, he/she wins the game im- mediately. For the losing condition, the player will lose the game when his/her life value reduces to zero. This may because the player touches too many spines, or because he/she moves out of the screen.
5 Game Implementation 5.1 Game Loop
After the game initialization, the game will proceed in a main loop. In each game itera- tion of the main loop, the following steps are executed sequentially:
1. Check if the player wins or loses the game: jal check game level status. If the game ends, process wining or losing tasks.
2. Get the current time: jar get time.
3. Process the player movement: jal player movement. 1) If the player is falling: jal
player falling. 2) If the player is on a platform, jal process move input to process the keyboard input for player running left and right.
Note: Holding down the key generates a sequence of keystrokes, which moves the player object continuously. For MAC users, if it does not work, enable it by entering the following command in the Terminal application: defaults write -g ApplePres- sAndHoldEnabled -bool false. Replacing false by true in the command will produce the opposite effect.
4. Process the platform movement: jal platform movement. 1) Destroy and generate a new platform when needed. 2) Move the platforms upward. 3) Increase the moving speed of the platforms.
5. Check the player hurt status and recover the player when time up: jal player hurt recover.
6. Check the status of the unstable platform and break the unstable platform when
time up: jal unstable platform break.
7. Refresh the game screen to reflect any screen changes.
8. Take a nap: jal have a nap. Sleep for time sleep=100ms as the interval between
two consecutive game iterations. 9. Gotostep1.
Programming Project: NS-Shaft
5.2 Code Organization
The skeleton file has been partitioned into five sections:
1. Data structure.
2. Main loop and initialization.
3. Player related procedures.
4. Platform related procedures.
5. Timing and keyboard input related procedures.
All codes are sorted in this order. The player and platform related procedures imple- ments the logic and behavior of all game objects. Therefore, most programming tasks are player or platform related procedures.
6 Programming Tasks
When you code with a high-level programming language, you always go through prob- lem specification, algorithm design/workflow analysis, coding, debugging and docu- mentation. Coding with low-level assembly programming language is pretty much the same.
The NS-Shaft game in MIPS assembly is challenging, but you won’t start everything from scratch. The user interface is handled by modified Mars (copyright: COMP2611 teaching team). The MIPS code mainly works on the logic of the game. The program- ming assignment package already includes a skeleton file for you to start with.
The tasks of the programming assignment include a reading task (Task 0). You will need to read through the skeleton and grasp a big picture of the code structure. The remaining tasks (Task 1-8) are coding tasks. You will focus on implementing a few MIPS procedures with well-defined interface.
6.1 Task 0: Reading Task
Spend a few hours to read the skeleton code. You should 1. understand the data struc- tures used in the skeleton; 2. trace the game loop 3. figure out the functionality of each procedure.
Show your understanding of the big picture of the project by drawing a flow chart (https://en.wikipedia.org/wiki/Flowchart) with necessary comments or explanations. Feel free to draw the flow chart withdrawing tools or by hand. Your flowchart should:
– include major procedures used in the program;
– include proper details but not too much, so that the flowchart can be fit in one page
of A4 paper, drawn by hand or by computer;
– have good layout so that it’s easy to trace and understand.
player move right
Task2: check boundary Task3: process landing
on new platform
check platform exist
Task5: update player life value
Task6: destroy and create platform
Task7: check game level status
Task8: lose
$v0: 0 if no platform, 1 if platform exists
$v0: 0: continue play- ing; =1: win; = 2: lose.
Table 4: Programming tasks
Description
Set the horizontal speed and the direction of the player object.
Check if the player exceeds the horizontal boundaries.
Take different actions when the player lands on different plat- forms.
Check if the player object is standing on a platform.
Update the life value of the player.
Destroy the first platform and create a new platform in ”plat- forms.”
Check the status of the game to continue, win or lose the game.
Implement the losing proce- dure.
$a0: 0 for reduce life value, 1 for recover life value.
Programming Project: NS-Shaft
$a0: the address of the new platform in ”plat- forms
6.2 Task 1-8: Programming Task
After reading the skeleton code and understanding how it works, try to understand the data structures used in the skeleton too. Complete the following MIPS procedures.
– You should not modify the skeleton code but only add your code to those proce- dures. Table 4 lists all the programming tasks you need to implement.
– You can see detailed instructions on how to implement each task in the skeleton file.
– For some programming tasks in the skeleton code, you need to remove the code in the answer space and write your own code.
– Pseudo instructions are allowed as long as it is supported by the Mars.
Before implementation, when you execute the skeleton code, you will find that the player can only move left and cannot fall down from a platform. The player will also exceed the left boundary when it keeps running left. To complete the game, you are encouraged to finish the tasks in the given order as shown in Table 4. This allows you to test your implementation after finishing each task. Many tasks has no input and output. For those tasks, you need to operate on the variables given in the data section.
Note: You are encouraged to read the whole code, but you do not need to understand every single detail of the skeleton code. You can discuss with your friends if you have
Programming Project: NS-Shaft
difficulty in understanding it. But every single line of your code should be your own work (not something copied from your friends).
7 Syscall Services
We have implemented a group of additional syscall services to support game related functions (e.g. object movements). For your code to work, you should use the modi- fied MARS ( S-shaft.jar) provided in the project section of our course website. Table 5 lists all the provided syscall services to implement the game.
Note that not all the new syscalls are necessary in your code, some are described here for you to understand the skeleton. Syscall code should be passed to $v0 before usage.
8 Submission
You should *ONLY* submit the file comp2611 project yourStudentID.s with your com- pleted code for the project. Please write down your name, student ID, and email address (as code comments) at the beginning of the file. As a good programming habit, comment your code properly and use registers wisely.
Submission is via COMP2611 Canvas. The submission deadline is 11:55PM, May 15 Sun. Try to avoid uploading in the last minute. If you upload multiple times, we will grade the latest version by default.The deadline is a hard deadline. -1 point out of 100 points will be deducted for every minute late, until 0 point is reached.
Your project will be graded on the basis of the functionality listed in the project de- scription and requirements. You should ensure that your completed program can run properly in our modified MARS.
COMP2611 Spring 22
Service Code Create game screen 200
Create player
Create platform
Create game text
Update level 204 Set player direction
Refresh screen 206 Set Location 207
Destroy platform 208 Play sound 209 Update life value 210 Random x location 211
Random platform type 212 Player hurt recover 213
Programming Project: NS-Shaft
Parameters
A new player object of the given ID is created. The loca- tion of the player is set to the given x- and y- coordinates.
A new platform object of the given ID is created. The loca- tion of the platform is set to the given x- and y- coordinates.
A new text object of the given ID is created. The location of the text is set to the given x- and y- coordinates.
Update the current level.
$a0: id, $a1: x loc, $a2: y loc
$a0: id, $a1: x loc, $a2: y loc, $a3: type
$a0: id, $a1: x loc, $a2: y loc
$a0: level
$a0: id, $a1: x loc, $a2: y loc
$a0: sound id
$a0: life value
$a0: last platform x loc, $a1: screen width
$a0: id, $a1: hurt status (0: recover, 1: hurt)
Table 5: Syscall Services
$v0: new platform x loc $v0: type of new platform
$a0: id, $a1: direction (0: left, 1: right, 2: front)
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com