Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: THEend8_
Assembly Project – CSCB58
A Platform Game
Overview
In this project, you will build a platform game using MIPS assembly. Platformers are a classic genre of
games: you control a character that moves around a map (“level”) by running left or right, jumping on
“platforms” or falling, or climbing up and down ladders, and so on. The goal of the player might be
avoiding obstacles, getting to a specific point on the screen using precise jumps, picking things up,
shooting enemies, not falling off the bottom of the screen, and more. Some have other gimmicks too.
You have some level of freedom in building the game, and we encourage you to be creative in how it
looks and feels. We set up the basic requirements, but it is your game! You can see several classic
examples of such games for inspiration below (click links for videos). You do not need to achieve this
level of polish and sophistication! In particular, we recommend making a “single-screen” platformer,
where the screen does not scroll, but perhaps moves to the next screen once the player has finished
the current level.
Pitfall! Donkey Kong Mega Man 2
(a.k.a Rockman 2)
Celeste
(PICO-8 version)
Bubble Bobble Ori and the Blind Forest
Since we don't have access to physical computers with MIPS processors, you will develop and test your
implementation in a simulated environment within MARS. We will use a simulated bitmap display and
a simulated keyboard input.
The project has two marking stages. In the checkpoint demo, you will demonstrate the basic features
to your TA during your final interview slot at the last week of the term. For the final version, you will
choose additional features to implement from a list of potential additions that change how the game
looks and behaves. You will then submit the completed assembly program (basic features and
additional features) with a video link and TAs will later grade it. Note that projects are individual.
Important Info and Due Dates
• Check the Piazza FAQ post frequently for FAQs and updates.
• Checkpoint: Due during your usual TA interview slot on Week 12 (Jul. 31 – Aug 4).
• Final submission: Due Monday, August 6, 2023, 11:59pm (on Quercus).
(life happens; we will accept late submissions without penalty if they arrive by end of Aug 9)
Version
• Jul. 10, 2022: initial public version.
The Game
Basic Gameplay
The basic format of the game is simple: the player controls a character moves around horizontally
(perhaps it is running left and right) and has a way to move up and down (such as jumping, dropping
down, climbing on ladders, etc.). There are platforms on the screen that the player can reach. There
are also other objects: perhaps enemies or spikes that the player must be careful to avoid and may end
the game if touched by the player. Or perhaps pick-ups rather than enemies that the player must to
collect to finish the game.
Game Controls
The player uses the keyboard to control the character. While the a key is pressed, the character will
move left if it is not at the left edge of the screen. Similarly, the d key makes the character move right.
For vertical movement, it can depend on your choice. A simple choice is to have the w key to have the
character jump, after which gravity pulls it down. Alternatively, perhaps you want to have ladders or
stairs, in which case it is appropriate to use w and s to move up and down. See “Technical
Background” below to see how to read the status of keys.
Note: MARS does not support multiple keys well. If you prefer to allow 8 directions in your
game, you can use the keyboard setup shown on the right →
Additionally, holding a key can work but is not great, and depends on the keyboard repeat
delay and repeat rate set in the user’s operating system.
Basic Demo
Click here for a video demonstration of a basic version of what you are supposed to implement (it also
shows how to set up the MARS simulator for the project). This demo shows the features we expect for
the checkpoint (explained below); for the final submission, you will implement additional features.
Note that the demo explanation says an incorrect minimum framebuffer size, so make sure to use the
requirements in this handout as the main source of truth for this project.
Note it is OK if your game looks and behaves somewhat differently from our demo, as long as the
features are there! For example, Ryan has chosen to develop a game in the style of infinite platformer
where platforms keep scrolling from right to left. You don’t have to do that. You may also decide to
develop a game where players are not able to “fall out of the screen” (the water in the video) – this is
not mandatory, but a choice. See Milestones 1, 2 and 3 for what you’d need to do.
Additional Features
The above only describes the basic gameplay. To get full marks, you will need to implement additional
features from a list. There are many possible additions to the gameplay, and it depends on what kind
of game you have (puzzle platformers, for example, often have no enemies). Here are a few examples:
• Additional screens once the player finishes a level.
• Moving enemies.
• Adding the ability to shoot enemies or jump on their heads to get rid of them.
• Platforms that move around, making it the timing to jump on them difficult.
• Picking up powerups that “repair” your health, freeze enemies, change enemy size and speed,
and so on.
• Gimmicks such as time manipulation, turning the character into a bird that can fly for a short
time, double jumping (jump in midair), etc.
See the list of additional features at the end.
Creativity and Limits
While you are not required to do so, we encourage you to be creative within the framework of the
game and features we have required. Many of the features are defined generally on purpose, to allow
you some freedom. Moreover, you have a lot of control in how the game looks and feels. You don’t
have to emulate our demo!
As you consider your creativity, be aware of the limits of what we are working with. The MARS
simulator is not very fast. This implies there are only so many MIPS instructions you can execute in one
q w e
a d
z x c
second, which limits the complexity of your game and graphics. You may be able to come up with
interesting tricks to make things run faster, but we are not marking you based on this!
Technical Background
You will create this game using the MIPS assembly language taught in class and the MARS. However,
there are a few concepts that we will need to cover in more depth here to prepare you for the project:
displaying pixels, taking keyboard input and system calls (syscall).
Displaying Pixels Using a Framebuffer
To display things on the screen, we will use a
framebuffer: an area in memory shown as a 2D
array of “units”, where each “unit” is a small box
of pixels of a single colour. Figure 1 on the right
shows a framebuffer of width 10 and height 8
units.
Units are stored as an array in memory: every 4-
byte word in that array is mapped to a single on-
screen “unit”. This is known as a framebuffer,
because the buffer (the region of memory)
controls what is shown on the display. The
address of this frame buffer array is the base
address of the display. The unit at the top-left
corner of the bitmap is located at the base address, followed by the rest of the top row in the
subsequent locations in memory. This is followed by the units of the second row, the third row and so
on (referred to as row major order).
To set the colour of a single unit, you will write a 4-byte colour value to the corresponding location in
memory. Each 4-byte value has the following structure: 0x00RRGGBB , where 00 are just zeros, RR is
an 8-bit colour value for the red component, GG are the 8-bits for the green components, and BB are
the 8-bits for the blue component. For example, 0x00000000 is black, 0x00ff0000 is bright red,
0x0000ff00 is green, and 0x00ffff00 is yellow. To paint a specific spot on the display with a
specific colour, you need to calculate the correct colour code and store it at the right memory address
(perhaps using the sw instruction).