Deadlines
| Assignment | Tasks | Deliverable | Points | Due Date |
|---|---|---|---|---|
| Project 5A | - Partnerships - Setup - Design Document |
Pre-Project Google Form | 5 | Mon, Nov 17 11:59pm PT |
| Design Document | 20 | |||
| Project 5B | - World Generation | World Screenshots on Gradescope | 20 | Mon, Nov 24 11:59pm PT |
| Project 5C | - Task 1: Main Menu - Task 2: Interactivity - Task 3: HUD - Task 4: Saving and Loading - Task 5: Ambition Features |
Code on Gradescope (0 pts, but required for checkoff) |
0 | Mon, Dec 1 11:59pm PT |
| Live Checkoff with TA (Checkoffs will happen 12/01 – 12/05) |
150 | |||
| Post-Project Google Form | 5 |
Project 5A: BYOW (Design)
In this project, you’ll design your approach for Build-ing Your Own World (BYOW).
Before getting started, please read the Project 5B: World Generation and Project 5C: Gameplay specs. You won’t be able to begin either task without understanding the BYOW spec first!
Technical Design Doc Refresher
Recall from Project 4B: What is a technical design document?
A technical design document (TDD) describes an approach to a specific technical problem. In the context of software engineering, it serves as the blueprint and specification for a software program or feature. TDDs are useful in both communicating and organizing your approach, while also being dynamic drafts that encompass the abstract details of the project.
TDDs are living documents. Software developers iterate on them as project demands change or new issues present themselves. While you’re only expected to submit a snapshot of your TDD for Project 5A, we encourage you to use this document as a platform for brainstorming high-level ideas for the rest of Project 5B and 5C.
TDDs are inherently collaborative. They act as a forum for communicating your ideas/solution to others on your team and to yourself, whether to manage complexity or to offload ideas for future reference. While this is an individual project, assume your audience is a group of 61B peers with similar programming knowledge as you.
It may be useful to include snippits of psuedocode or other portions of plain-text outlining your ideas. Don’t get too carried away with this. If you find yourself writing every method line-for-line in psuedocode, you’re likely straying away from the high-level brainstorming process that a TDD is meant for.
For this class, TDDs will consist of the following components:
- Data
- Data Structures
- Algorithms
- Complexity
- Questions
Data
What data will you be using? What does the data consist of and how will you parse it for your program? How will your program use the data? Consider the process of saving/loading. If applicable, discuss how data might be used in your ambition features.
Data Structures
What data structures will you be using? How will your data structures use the data? How will your program use the data structures?
Algorithms
What algorithms will you be using? How will your algorithms use the data structures and data? How will your program use the algorithms?
Complexity
What is the input? How does the time and space complexity change with the input? What are the bounds? Consider the runtime of your world generation process and/or any ambition features that may be computationally demanding.
Questions
Open Questions
What questions have come up while brainstorming your design? Consider asking them in assignment section or office hours!
Closed Questions
Move questions here once you’ve found an answer. Designing software is a collaborative process. Logging your decision-making process provides essential context for others wishing to understand/contribute to your work.
As mentioned earlier, design docs are living documents. You (the designer) might not understand the entire project scope while drafting, and that’s fine. Including a section for questions can help track your thoughts for future iterations.
A “Questions” section is useful for collaboration. Your collaborators may want to understand which assumptions you made or questions you had when designing.
Example
For an example TDD based on the Percolation mini-Project, see this example.
Task 1: Writing Your TDD
We have provided a template for you to use if you’d like. See the Project 5A: BYOW Design Template, which is also linked in the assignment below.
Write a TDD for BYOW and submit it to the Project 5A: BYOW Design assignment.
For BYOW, the complexity of your program is not as important.
On the other hand, the data of your program is. What type of data do you expect to save and load?
If you expect to work on this project during office hours, we may ask to see your design document to help understand your approach. As such, please put effort into this assignment! Grasping project requirements in the design phase will help immensely during the later implementation phases.
Design Tips
We’ve included below a few questions for you to consider while brainstorming your design:
General Questions
- Look through the provided code:
- Notice what’s already built for you. What may be useful for your implementation?
- Notice what isn’t. What gaps does your implementation need to fill?
- Where do tasks overlap? Are there opportunities to reuse methods across different cases? Think about opportunities for helper methods.
- Can you find groups of data structures and methods that serve a similar, clearly defined purpose? If so, consider moving them to a separate class. Building abstraction barriers may be helpful for managing code complexity.
World Generation
- What are the core components of each world? Does it makes sense to have a separate class for each component?
- How will you ensure that every generated world is valid?
- Will you decide on a layout first, validate it, then build the world after?
- Or, will you gradually generate the world, ensuring that only valid components are built as you go?
- Ultimately, each world is a 2D grid of values, each representing a Tile. What data structures would be helpful for tracking the state of the world on top of this grid? Representing specific aspects of your world with data structures may be helpful for building ambition features later.
Interactivity
- Read through the StdDraw library documentation. This library acts as the bridge between your implementation and what is outputted on screen (e.g. the
/tileengineimplementation uses library methods to draw to the screen).- Can you find methods for drawing on the screen, not specifically for tile drawing?
- Can you find methods for soliticiting user inputs?
- Rendering video is much like a classic film projector, in that by rapidly rendering images, we can create the illusion of motion. Video games are essentially the same, except that user inputs can alter what’s displayed in the next frame. (Read about common paradigms for implementing video games and graphics engines here)
- Does your implementation clearly separate the steps of collecting, processing, and displaying the result of user inputs?
- Consider that your computer can compute thousands of instructions each second. If your implementation has real-time elements (i.e. timers, slow-motion movement, NPCs moving at user-like speed, etc.), how can you adjust the speed of your event loop to match real-time?
Ambition Features
- Most importantly, which ambition features are you most excited about building?
- For each feature, determine where it fits within your current abstraction barriers:
- Does it require fundamental changes to the process of generating and representing worlds?
- Does it alter the process for collecting user input?
- Does it change the process for rendering the world state?
- Do any features span multiple domains of this project? If so, consider creating separate classes to contain their complexity.
- How could you structure your core project implementation (world generation and interactivity) to make feature integration seamless?
You aren’t bound to the ambition features you choose to write about within your design doc. That said, certain features (especially primary ones) are better aligned with certain implementation choices in the world generation and interactivity tasks. It’s important to think about this early!
Submission
Submit your design document on gradescope: Project 5A: BYOW Design (5 points)
Don’t forget to add your partner to the submission!
The score you receive on Gradescope is your final score for this assignment (assuming you followed the collaboration policy).
While we’re unable to give detailed individual feedback for each TDD, we’ll agregate common mistakes we notice and showcase them (as well as implementation hints…) in assignment section during Week 13 (11/17-11/21). As always, come to office hours if you want specific feedback from 61B staff!
A note on grading, we are looking for thoughtfulness and effort. In other words, you do not have to be correct in your design or your complexity analysis, but we expect you to have put in considerable time into designing your approach. As long as you attempt to describe your approach for the components in the rubric, you’ll receive full credit.
For the TDD, we have provided the rubric we’ll be grading submissions on below for your reference.
- Data (10%): Describes how the data will be used.
- Data Structures (40%): Describes what data structures will be used with the data.
- Algorithms (40%): Describes what algorithms will be used with the data structures and data.
- Complexity (10%): Describes the expected time and space complexity of the program.
This spec was written by Daniel Wang and Ronnie Beggs as a new assignment in Fall 2025. The provided template was created by Kanav Mittal and Stella Kaval in Spring 2025 and edited by Daniel Wang.