CS 61B Spring 2024

Home Calendar Course Info Staff
Labs Homeworks Projects
Project 0: 2048
Project 1A: LinkedListDeque61B
Project 1B: ArrayDeque61B
Project 1C: Deque61B Enhancements
Project 2A: Ngordnet (NGrams)
Project 2B: Ngordnet (Wordnet)
Project 2C: Ngordnet Enhancements
FAQ – Project 3: BYOW
Checkoff – Project 3: BYOW
Common UI Bugs – Project 3: BYOW
Search CS 61B Spring 2024
Ed OH Queue
Projects / Project3:BYOW
Project 3: BYOW
Each assignment will have an FAQ linked at the top. You can also access it by adding “/faq” to the end of the URL. The FAQ for Project 3 is located here.
Introduction
In Project 3, you will create an engine for generating explorable worlds. This is a large design project that
will require you and one partner to work through every stage of development from ideation to presentation. Rendering
The goal of this project is to teach you how to handle a larger piece of code with little starter code in the hopes of emulating something like a product development cycle. In accordance with this, the grading of this project will be different from other projects. Since there is no notion of “the correct answer” when it comes to world design and implementation, you will be assessed much like a performance review you might receive at an internship or job in addition to a very general autograder. While this means you will be graded slightly subjectively, we promise to be pretty nice bosses and will respect you as any boss should respect their hardworking employees. Please talk to us if you feel the grading scheme feels unfair.
This project will require you a great deal of exploration and experimentation. Searching the web for answers (not solutions from past semesters) should be a regular activity throughout this process. Please know that there are no right and wrong answers, as this is a very open-ended project. However, there are some implementations and ideas that are better than others. It is ok and expected that you will go through several iterations before settling on something that you deem good. That is, this project is about software engineering.
You’re not required to use any of the fancy data structures or concepts from class (A*, MSTs, Disjoint Sets, etc.). This project is about software engineering, not about data structures or algorithms. The data structures and algorithms we’ve learned about in class will make your code significantly simpler and more efficient, but please don’t use things just because we learned about them in class. Only use these tools if you feel comfortable using them in your implementation.
A video playlist (from Spring 2018) discussing tips for working on this project can be found at this link. A walkthrough of the new skeleton code is also available here.
Please also note that since the structure of the project has been changed, Phase 1 will refer to part 3A of the project.
Deliverables
Project 3 is worth 125 points. There are several key deadlines for this assignment:
• Team formation (2 pts): Due 4/3 at 11:59 PM
• You must submit the Project 3 Partnerships Form. You will not be able to change your partner later.
Read and understand the partnership guidelines before starting the assignment.
• When group repos are released, you must accept your GitHub invitation, otherwise they will expire
after a week.
• Project 3A (19 pts): Due 4/15 at 11:59 PM
• World Generation Autograder (3 pts): Due on Gradescope
• Asynchronous Manual Review (6 pts): Due at 3A Asynchronous Review Form
• 3A Partner Reflection (10 pts): Due at 3A Reflection Form
• Project 3B (9 pts): Due 4/22 at 11:59 PM
• Interactivity Autograder (9 pts): Due on Gradescope
• Project 3C (95 pts): Due 4/22 at 11:59 PM
• Ambition & Demos Checkoff (85 pts): Due at Ambition Checkoff Form
• 3BC Partner Reflection (10 pts): Due at 3BC Reflection Form
Notice that Project 3B & 3C are due on the same day. However, since you need to be manually checked off for the “Ambition” part, we made a division between “Interactivity” and “Ambition & Demos”. In your Gradescope submission for 3B, your code should also have “Ambition” features because we will be asking for your Gradescope submission ID from 3B in the 3C Form.
You cannot submit Project 3B & 3C late, as it will be graded during a lab checkoff with a TA. We strongly discourage submitting 3A and the supporting labs (Lab 9 and Lab 10) late, as Project 3B & 3C builds upon these assignments, so it is unlikely that you will be able to submit these assignments late and still complete Project 3B on time.
Now on to the assignment spec!
Your task for the next few weeks is to design and implement a 2D tile-based world exploration engine. By “tile-based”, we mean the worlds you generate will consist of a 2D grid of tiles. By “world exploration engine” we mean that your software will build a world, which the user will be able to explore by walking around and interacting with objects in that world. Your world will have an overhead perspective. As an example of a much more sophisticated system than you will build, the NES game “Zelda II” is (sometimes) a tile based world exploration engine that happens to be a video game:
The system you build can either use graphical tiles (as shown above), or it can use text based tiles, like the game shown below:
We will provide a tile renderer, a small set of starter tiles, and the headers for a few required methods that must be implemented for your world engine and that will be used by the autograder. The project will have two major deadlines. By the first deadline, you should be able to generate random worlds that meet the criteria below. By the second deadline, a user should be able to explore and interact with the world.
The major goal of this project is to give you a chance to attempt to manage the complexity that comes with building a large system. Be warned: The system you build probably isn’t going to be that fun for users! Three weeks is simply not enough time, particularly for novice programmers. However, we do hope you will find it to be a fulfilling project, and the worlds you generate might even be beautiful.
Project Setup
Group Repository Setup
You’ll be working exclusively in a group repository for this portion of the project. To set this group repo up on your local computer, follow the instructions below (these are also in the spec):
• Go to your email and accept the GitHub repo invite that you should have received. Please do this as soon as you receive the invite, as they will expire within 7 days. If your invite has expired, please make an Ed post.
• Log in to Beacon, and click on the “Groups” tab. You should have a group listed here.
• Click the “View Repository on GitHub” link.
• You’ll now be taken to your new repository on GitHub. You will have an empty repository. Copy the clone link shown in the text bar (blacked out in the screenshot).
• Open a new Terminal window, and navigate to the directory that you store your CS 61B files in (usually, students have a directory called cs61b ).
Starting Your Program
Requirements
Design Document
Design Document Guidelines
3B: Interactivity
UI (User Interface) Appearance
UI Behavior
Saving and Loading
Interacting With Input Strings
3C: Ambition & Demos
21 Points Primary Features
7 Points Secondary Features
Requirements Summary
Introduction Deliverables Overview Project Setup
Group Repository Setup
Skeleton Code
3A: World Generation
Tileset and Tile
Ambition Demos will be held in person during lab sections the week that Project 3BC is due. All group members must arrive on time, otherwise a 20% late penalty will be applied to the group.
Beware: you cannot submit Project 3B & 3C late without extenuating circumstances. We do not have the same extension policy as previous assignments, so get started early.
THE SETUP FOR THIS PROJECT IS DIFFERENT THAN THE OTHER LABS / PROJECTS. PLEASE DO NOT SKIP THIS STEP!
IMPORTANT: Do not cd into your sp24-s**** repo! You should not be cloning the group repo inside of your personal 61b one.
• Type the following commands into your terminal, and hit Enter after each one:
git clone cd sp24-proj3-g*** // Replace the *** here with your group repo number
git remote add skeleton https://github.com/Berkeley-CS61B/proj3-skeleton-sp24.git
git pull skeleton main –allow-unrelated-histories
Once you’ve completed the above steps, you should see your new group repo called sp24-proj3-g*** in your local files, and if you open this repo, you’ll see the proj3 skeleton folder. From here, you and your partner can proceed as normal, by adding, committing, pushing, and pulling from this repo as you would otherwise.
Skeleton Code
A walkthrough of the new skeleton code is available here.
Use git pull skeleton main in your group repo to pull the skeleton code. The skeleton code contains two key packages that you’ll be using: TileEngine , Core and Utils . TileEngine provides some basic methods for rendering, as well as basic code structure for tiles, and contains:
• TERenderer.java – contains rendering-related methods.
• TETile.java – the type used for representing tiles in the world.
• Tileset.java – a library of provided tiles.
The other package Core contains everything unrelated to tiles. We recommend that you put all of your code for this project in the Core package, though this is not required. The Core package comes with the following classes:
Do NOT change TETile.java’s character field or character() method as it may lead to bad autograder results. Additionally, if you add new floor or wall tiles, make sure to modify
isBoundaryTile and isGroundTile so that the autograder recognizes your tiles.
AutograderBuddy.java – Provides two methods for interacting with your system. TETile[][] getWorldFromInput(String input) simulates the game without rendering by returning the world that would result if the input string had been typed on the keyboard. You should fill this out for autograder.
Main.java – How the user starts the entire system. Reads command line arguments and calls the appropriate function in World.java .
World.java – YOUR WORLD!
This is an open-ended project. As you can see, we gave you just one file called World.java where you can do necessary things to create your world! The aim of this project is to give you freedom to create your own world with different desing choices. You can create any other classes if you want. Primarly, you can use
World.java for the logic behind your world creation.
The last package Utils contains everything that you might need to implement your World.java class.
• RandomUtils.java – Provides handful of functions that might be useful.
• FileUtils.java – Library of simple file operations. You can find related APIs here and here. Be sure to
look at lab09 for a refresher on how this works.
This project makes heavy use of StdDraw , which is a package that has basic graphics rendering capabilities. Additionally, it supports user interaction with keyboard and mouse clicks. You will likely need to consult the API specification for StdDraw at some points in the project, which can be found here.
Your project should only use standard java libraries (imported from java.*) or any libraries we provided with your repo and library-sp24 . Your final submission for 3B and 3C should not use any external libraries other than the ones provided in the skeleton.
3A: World Generation
As mentioned above, the first goal of the project will be to write a world generator. Your world must be valid and sufficiently random The requirements for these criteria are listed below:
• The world must be a 2D grid, drawn using our tile engine. The tile engine is described in lab 9.
• The generated world must include distinct rooms and hallways, though it may also include outdoor
• At least some rooms should be rectangular, though you may support other shapes as well.
• Your world generator must be capable of generating hallways that include turns (or equivalently, straight hallways that intersect). Random worlds should generate a turning hallway with moderate frequency (20% of worlds or more).
• Dead-end hallways are not allowed.
• Rooms and hallways must have walls that are visually distinct from floors. Walls and floors should be
visually distinct from unused spaces.
• Corner walls are optional.
• Rooms and hallways should be connected, i.e. there should not be gaps in the floor between adjacent rooms or hallways.
• All rooms should be reachable, i.e. there should be no rooms with no way to enter.
• Rooms cannot clip off the edge of the world. In other words, there should be no floor tiles on the edge
of the world.
• The world must not have excess unused space. While this criterion is inherently subjective, aim to populate above 50% of the world with rooms and hallways.
Sufficiently Random
• The world must be pseudo-randomly generated. Pseudo-randomness is discussed in lab 9.
• The world should contain a random number of rooms and hallways.
• The locations of the rooms and hallways should be random.
• The width and height of rooms should be random.
• Hallways should have a width of 1 tile and a random length.
• The world should be substantially different each time, i.e. you should NOT have the same basic layout
with easily predictable features.
As an example of a world that meets all of these requirements (click for higher resolution), see the image below. In this image, # represents a wall tile, a dot represents a floor tile, and there is also one golden colored wall segment that represents a locked door. All unused spaces are left blank.
Once you’ve completed lab 9, you can start working on your world generation algorithm.
It is very likely that you will end up throwing away your first world generation algorithm. This is normal! In real world systems, it is common to build several completely new versions before getting something you’re happy with.
You’re welcome to search the web for cool world generation algorithms. You should not copy and paste code from existing games or graphical demos online, but you’re welcome to draw inspiration from code on the web. Make sure to cite your sources using @source tags. For inspiration, you can try playing existing 2D tile based games. Brogue is an example of a particularly elegant, beautiful game. Dwarf Fortress is an example of an incredibly byzantine, absurdly complex world generation engine.
Tileset and Tile Rendering
The tile rendering engine we provide takes in a 2D array of TETile objects and draws it to the screen. Let’s call this TETile[][] world for now. world[0][0] corresponds to the bottom left tile of the world. The first coordinate is the x coordinate, e.g. world[9][0] refers to the tile 9 spaces over to the right from the bottom left tile. The second coordinate is the y coordinate, and the value increases as we move upwards, e.g. world[0][5] is 5 tiles up from the bottom left tile. All values should be non-null, i.e. make sure to fill them all in before calling renderFrame . Make sure you understand the orientation of the world grid! If you’re unsure, write short sample programs that draw to the grid to deepen your understanding. If you mix up x vs. y or up vs. down, you’re going to have an incredibly confusing time debugging.
We have provided a small set of default tiles in Tileset.java and these should serve as a good example of how to create TETile objects. We strongly recommend adding your own tiles as well.
The tile engine also supports graphical tiles! To use graphical tiles, simply provide the filename of the tile as the fifth argument to the TETile constructor. Images must be 16 x 16, and should ideally be in PNG format. There is a large number of open source tile-sets available online for tile based games. Feel free to use these.
Any TETile object you create should be given a unique character that other tiles do not use. Even if you are using your own images for rendering the tile, each TETile should still have its own character representation.
If you do not supply a filename, or the file cannot be opened, then the tile engine will use the unicode character provided instead. This means that if someone else does not have the image file locally in the same location you specified, your world will still be displayed, but using unicode characters instead of textures you chose.
The tile rendering engine relies on StdDraw . We recommend against using StdDraw commands like setXScale or setYScale unless you really know what you’re doing, as you may considerably alter or
damage the a e s t h e t i c of the system otherwise. Starting Your Program
Your program will be started by running the main method of the Main class. You will see that this method will render your program and will provide interactivity for you in the future. On top of that, in order to test your world, for 3A, your project must support getWorldFromInput . Specifically, you should be able to handle an input of the format “N#######S” where each # is a digit and there can be an arbitrary number of
# s. This corresponds to requesting a new world ( N ), providing a seed ( # s), and then pressing S to indicate that the seed has been completely entered. The logic between your world generation in Main class and getWorldFromInput method should be similar. While you should render your program in Main , you should not do that in getWorldFromInput since this will be used for Autograder.
Finally, we recommend that you make minimal modifications to the core.Main class. It is a much better idea to delegate all the work of the program to other classes you will create.
When your core.Main.main() method is run, your program must display a Main Menu that provides at LEAST the options to start a new world, load a previously saved world, and quit. The Main Menu should be fully navigable via the keyboard, using N for “new world”, L for “load world”, and Q for quit. You may include additional options or methods of navigation if you so choose.
After pressing N on the keyboard for “new world”, the user should be prompted to enter a “random seed”, which is a long value of their choosing. This long data type will be used to generate the world randomly (as described later and in lab 12). The UI should show the seed value that the user has entered so far. After the user has pressed the final number in their seed, they should press S to tell the system that they’ve entered the entire seed that they want. Your world generator should be able to handle any positive seed up to 9,223,372,036,854,775,807. There is no defined behavior for seeds larger than this.
The behavior of the “Load” command is described later in this specification.
If the system is being called with core.AutograderBuddy.getWorldFromInput , no menu should be displayed and nothing should be drawn to the screen. The system should process the given String as if a human user was pressing the given keys using the main() method. For example, if we call
getWorldFromInput(“N3412S”) , your program should generate a world with seed 3412 and return the generated 2D tile array. Note that letters in the input string can be upper or lower case and your engine should be able to accept either keypress (i.e. “N” and “n” should both initiate the process of world generation). You should NOT render any tiles or play any sound when using getWorldFromInput .
If you want to allow the user to have additional options, e.g. the ability to pick attributes of their character, specify world generation parameters, etc., you should create additional options. For example, you might add a fourth option “S” to the main menu for “select creature and create new world” if you want the user to be able to pick what sort of creature to play as. These additional options may have arbitrary behavior of your choosing, however, the behavior of N, L, and Q must be exactly as described in the spec!
Requirements
For 3A, you should be able to run Main.main by providing an input String, and have your program create a world, that adhere to the requirements mentioned above along with our randomness requirements mentioned in the Submission and Grading section below. Note that you should render the world to check your code by writing your own main method, but for the autograder, getWorldFromInput should not render the world, only returning the world as a TETile array. Worlds should be visibly different for different seeds provided to the program.
Design Document
Since we did not provide you with any significant skeleton code for Project 3, and since the project is very open-ended, we expect that BYOW implementations will vary a fair amount between students. We recommend that you have a design document that reflects the current state of your project.
Before you begin writing any code, use the guidelines listed here to create a plan for every feature of your BYOW program, and convince yourself that your design is correct. Writing a design document is an iterative process. After coming up with your initial design, you may find some flaws in it, requiring you to revisit your design and update its description according to your new findings.
You may find the software engineering lectures helpful for learning how to manage the complex and collaborative nature of this project.
Design Document Guidelines
The design document’s main purpose is to serve as a foundation for your project. It is important to think and ideate before coding. What we are looking for in the design document:
• Identify the data structures we have learned in the class that you will be using in your implementation.
• Pseudocode / general overiview of your algorithm for your implementation.
You may use the following format for your BYOW design document. You may create a design doc with your own format, or use this template.
Design Document Sections
1. Classes and Data Structures
Include here any class definitions. For each class, list the instance variables (if any). Include a brief description of each variable and its purpose in the class.
2. Algorithms
This is where you describe how your code works. For each class, include a high-level description of the methods in that class. That is, do not include a line-by-line breakdown of your code, but something you would write in a javadoc comment above a method, including any edge cases you are accounting for.
3. Persistence
You should only tackle this section after you are done with 3A. This section should describe how you are going to save the state of a world, and load it again, following the requirements in the spec. Again, try to keep your explanations clear and short. Include all the components your program interacts with – classes, specific methods, and files you may create. You can check out lab 9.
3B: Interactivity
In the second part of the project, you’ll add the ability for the user to actually interact with the world, and will also add user interface (UI) elements to your world to make it feel more immersive and informative.
The requirements for interactivity are as follows:
• The user must be able to control some sort of “avatar” that can moved around using the W, A, S, and D keys. By “avatar”, we just mean some sort of on-screen representation controlled by the user. For example, in my project, I used an that could be moved around.
• The avatar must be able to interact with the world in some way.
• Your system must be deterministic in that the same sequence of key-presses from the same seed must result in exactly the same behavior every time. Note that a Random object is guaranteed to output the same random numbers every time.
• In order to support saving and loading, your program will need to create some files in your proj3 directory (more details later in the spec and in the skeleton code). The only files you may create must have the suffix “.txt” (for example “save-file.txt”). You will get autograder issues if you do not do this.
Optionally, you may also include game mechanics that allow the user to win or lose. Aside from these feature requirements, there will be a few technical requirements for your system, described in more detail below.
UI (User Interface) Appearance
After the user has entered a seed and pressed S, the world should be displayed with a user interface. The user interface of your project must include:
• A 2D grid of tiles showing the current state of the world.
• A “Heads Up Display” (HUD) that provides additional information that maybe useful to the user. At the bare minimum, this should include Text that describes the tile currently under the mouse pointer. This should not be flickering, if it flickers you won’t be able to receive credit.
As an example of the bare minimum, the simple interface below displays a grid of tiles and a HUD that displays the description of the tile under the mouse pointer (click image for higher resolution):
You may include additional features if you choose. In the example below (click image for higher resolution), as with the previous example, the mouse cursor is currently over a wall, so the HUD displays the text “wall” in the top right. However, this HUD also provides the user with 5 hearts representing the avatar’s “health”. Note that this world does not meet the requirements of the spec above, as it is a large erratic cavernous space, as opposed to rooms connected by hallways.
As an example, the game below (click image for higher resolution) uses the GUI to list additional valid key presses, and provides more verbose information when the user mouses-over a tile (“You see grass-like fungus.”). The image shown below is a professional game, so we do not expect your project to have this level of detail (but we encourage you to try for some interesting visuals).
For information about how to specify the location of the HUD, see the initialize(int width, int height, int xOffset, int yOffset) method of TERenderer or see lab 9.
UI Behavior
After the world has been generated, the user must be in control of some sort of avatar that is displayed in
Do NOT use static variables unless they have the final keyword! In 2018, many students ran into major debugging issues by trying to use static variables. Static non-final variables add a huge amount of complexity to a system. Additionally, do not call System.exit() in getWorldFromInput as this will cause the autograder to exit and fail.
For 3A, you do not need to have a Main Menu screen.
We will not be grading this document, but you will need to complete it in order to receive help online and in office hours.
Project 3: BYOW

Programming Help, Add QQ: 749389476
This site uses Just the Docs, a documentation theme for Jekyll.
the world. The user must be able to move up, left, down, and right using the W , A , S , and D keys, respectively. These keys may also do additional things, e.g. pushing objects. You may include additional keys in your engine. The avatar should not move when attempting to move into a wall and the program should not error.
The system must behave pseudo-randomly. That is, given a certain seed, the same set of key presses must yield the exact same results!
In addition to movement keys, if the user enters :Q (note the colon), the program should quit and save. The description of the saving (and loading) function is described in the next section. This command must immediately quit and save, and should require no further key-presses to complete, e.g. do not ask them if they are sure before quitting. We will call this single action of quitting and saving at the same time “quit/saving”. This command is not case-sensitive, so :q should work as well. Additionally, : followed by any other letter should not do anything.
This project uses StdDraw to handle user input. This results in a couple of important limitations:
StdDraw does not support key combinations. When we say :Q , we mean : followed by Q .
It can only register key presses that result in a char. This means any unicode character will be fine but
keys such as the arrow keys and escape will not work.
On some computers, it may not support holding down of keys without some significant modifications; i.e. you can’t hold down the e key and keep moving east. If you can figure out how to support holding down of keys in a way that is compatible with getWorldFromInput , you’re welcome to do so.
Because of the requirement that your system must handle String input (via getWorldFromInput ), your engine cannot make use of real time, i.e. your system cannot have any mechanic which depends on a certain amount of time passing in real life, since that would not be captured in an input string and would not lead to deterministic behavior when using that string vs. providing input with the keyboard. Keeping track of the number of turns that have elapsed is a perfectly reasonable mechanic, and might be an interesting thing to include in your world, e.g. maybe the world grows steadily darker with each step. You’re welcome to include other key presses like allowing the user to press space bar in order to wait one turn. The real time behavior is for the autograder. Feel free to ignore real time requirement for 3C and modify your code for that.
Saving and Loading
Sometimes, you’ll be exploring your world, and you suddenly notice that it’s time to go to watch a CS 61B lecture. For times like these, being able to save your progress and load it later, is very handy. Your system must have the ability to save the state of the world while exploring, as well as to subsequently load the world into the exact state it was in when last saved.
Within a running Java program, we use variables to store and load values. Keep in mind that when your program ends, all the variables will go out of s