Final Project assignment: Survival Backpack
The final project is a chance for you to use all of the skills you have been learning throughout the semester to create several code projects that will help you in a Minecraft world.
Imagine you are going into a brand new Minecraft world. What are your most immediate needs? Brainstorm with a classmate.
Some examples:
- Collect wood
- Find wool
- Find food
- Build a house
- Mine for coal
Then, choose one or more of those needs that can be solved with code. You will get to take your Agent with you, as well as the Builder and the other powerful tools in your MakeCode inventory, but you are limited to just a single project. What are the top four commands that you would want to have?
In addition, your project code must do both of the following things:
- Show something you already know You should demonstrate your knowledge of one or more concepts we have covered in these lessons.
- Show something new You should demonstrate a technique, efficiency, or code block that you went out and learned how to use on your own, either from the documentation, from experimenting, or from another classmate.
Timeframe: Three weeks of in-class work and activities. Code should be complete by the end of the second week, so students can use the last week for a beta testing period with other students.
Due each week:
- 2–3 work logs
- 1 Record of Thinking
Some possible ideas:
| Need | Solution |
|---|---|
| Entertainment | Create a mini-game |
| Lots of paper | Create and harvest a sugar cane farm |
| Better tools | Create an iron-finder |
| Safety | Create an automatic shelter |
| Art | Create something beautiful using code |
Final Deliverables:
- Work Logs
- Record of Thinking entries
- Final Project Code
- Project Narrative
- Video of your project running
- Final project showcase and celebration at the end
Assessment:
- 50% Process (initial proposal, work logs, records of thinking, final narrative)
- 50% Product (project code component, video of code execution)
Teacher Note: This form of assessment places just as much weight on documenting the process of designing the project, as it does on the finished product itself. This is because in my classroom I want to prioritize “sustained effort over an extended period of time” over a project that might have resulted from three all-nighters in the final week it is due.
However, you may decide to assign more or less weight to each of these pieces, and you should certainly feel free to scale up or down the documentation piece as appropriate for your classroom, grade level, and teaching priorities.
While working on the project
The expectation is that students are working steadily on their independent projects for three weeks, testing out ideas, trying different things, getting stuck, and getting unstuck. Because everyone is working on a different project, we can’t assign the same homework to everybody, so besides the project work itself, students are also responsible for documenting the work they are doing on the project using work logs, and reflecting on the process of their learning in a record of thinking. Here are more details on these work items:
Work log
A work log is a short, bullet point list of what you worked on, and how long it took. Stick to just the facts. It shouldn’t take more than thirty seconds or so to write up a work log. Students should do one work log entry for every class period, several times a week. A shared Microsoft OneNote notebook is a great way to keep a work log that students can update regularly. Alternately, you might use a collaborative shared document, or your classroom management system, or even e-mail.
Sample work log:
Backpack Project #1: Cave Exploration System
3/31: Worked on getting Builder to navigate uneven hallways (45 min.)
4/1: Added Say blocks at each point so we could stop it from getting lost all the time (30 min.)
4/3: Completed exploring simple caverns, now working on more complex systems (45 min.)
4/4: Coded for multi-level caves, spawner detection system (30 min.)
Teacher Note: We generally don’t accept late work logs. If a student simply didn’t have time to do any work on their project, he/she should still file a work log, and report that no work got done. Work logs are worth a few points each, so missing one or two isn’t a problem, but if it happens a lot it’s usually time to do a check-in with that student and see where he/she is with the project.
Record of Thinking
A Record of Thinking is like a journal entry (or like the Minecraft Diary you created for each mini-project) that tells the story of your learning throughout the past week. Go through your work logs for the week and look at what you did, where you got stuck, and how you figured it out. Then write a 150 to 300 word Record of Thinking essay each week of the project addressing the following:
- Describe something that surprised you this week as you worked on your project.
- Describe a moment where you go stuck. How did you get unstuck?
- Did anyone help you this week? Who and how?
- Choose an adjective that describes how you are feeling about your project this week. Explain why you chose this word.
- What are you working on next week? (for weeks 1 and 2)
- If you had more time to work on this project, what would you add? (for week 3)
Sample Record of Thinking Excerpt:
Week of April 6:
I finally figured out why my code wasn’t working. I had the wrong for loop nested inside the other one, and so it was executing way more times than it was supposed to, and that was why the Agent kept going off track. Once I created another variable to keep track of the number of times the Agent came back to the Home row, and checked this variable each time during the loop, everything worked the way it should. I only was able to figure this out because I took each function apart separately and ran it without that function in order to track down where the problem was. That was useful. I have to remember to try this first next time.
Teacher Note: A Record of Thinking is not an expanded work log! Students will sometimes just write a more detailed list of all of the tasks they completed over the week, and that’s not the point of the Record of Thinking. The Work Logs are to show WHAT you did. The Record of Thinking is to show HOW you learned how to do it. Unlike Work Logs, I will accept late Records of Thinking as long as they come no later than the due date for the next week’s Record of Thinking. It is an important form of documentation of the learning process.
Turning in the Final Project
When you turn in the final project, you should turn in your code, and a final narrative. To turn in your code, you can Share the code by clicking the Share button in the top menu bar:
You acknowledge that you consent to share your project by clicking Publish project, and then MakeCode will display a unique URL that you can copy and paste to submit as your project code.
You also need to create a written final narrative to accompany your code. You have worked for the past three weeks to propose, design, and test an original Backpack of Minecraft Code as your final project. I am looking for an honest, accurate assessment of your work over this time.
Please go back and read through all of your Work Logs and Records of Thinking. Then, compose a comprehensive narrative that tells the story of the development of the various projects in your Backpack, and your progress toward your goals along the way. How you tell the story is up to you, but you might consider following most, if not all, of the following questions:
- How did you start the process of designing the project and meeting your goals?
- What did you hope to learn?
- What challenges did you face? How did you overcome them?
- What was the outcome?
- What did you learn in the end?
- Who in the class provided help to you along the way? How?
- What were you proud of?
- What would you do differently next time?
Throughout your narrative, you must cite evidence from your work logs and records of thinking (e.g., Record of Thinking 4/17, Work Log #3, Conference notes, etc.) You may use footnotes for this or add it in parentheses after the material you are citing.
I will read this carefully and grade it along with your final project code and average it with the total of your work logs and records of thinking to come up with your final grade for the project.
Sample Final Narrative
It’s clear to me now that in the second week, I was a little lost and confused with the direction my project was taking. I can see now that in my chats with Mr. Kiang and with classmates (Conference Notes 4/3) I was not being very precise in my questions, and I didn’t totally understand what he was explaining.
Looking back, one of my goals was to meet more regularly with my table mates. Hopefully I would be a lot less confused and at least this time when I got stuck, we would be able to solve it together. I wrote about this in my Record of Thinking (Record of Thinking #2) but I am surprised that things cleared up for me so quickly once we did start meeting together. This allowed me to get past something that was really bothering me, specifically adding and removing things from an array, and I was able to complete that in less than a day after having been stuck for more than a week (Work Log #4).
Once I started to get a little more clear on what to do, I was able to get more effective help from my classmates. Specifically, Jordan helped me a lot with figuring out how to use the different mask options with the clone block . He also showed me some helpful MakeCode sample projects and examples. I think if I could do this over again, I would have scheduled more time earlier to meet with Mr. Kiang and/or found a better way to share the different bits of code I was working on with my table mates because we all were trying to figure out basically the same things, only in different projects. I didn’t even find out until the end that you could jump into JavaScript to make changes to the code, and it makes it all with the right blocks when you go back! (Beta Testing notes) That would have saved me a lot of time.
In addition to the project narrative, please provide a short (less than 2 minutes) video of your code in action.
Beta Testing
Beta testing is an important part of testing the final projects to uncover bugs or design issues that could make the projects difficult to use. One way to test the projects is to ask all students to come in to class on a specific day with the URLs of their projects ready to test, and give their classmates a chance to test the code in their own Minecraft worlds. This is not the final deadline, but projects should be “feature-complete” i.e., all features need to be incorporated into the code, and the construction of any Minecraft elements of the project needs to be done or almost done.
Students can take turns presenting their projects to the entire class, or they can work in pairs to take turns trying their partner’s project out and offering feedback. Students who are being critiqued should take beta testing feedback notes and turn them in as part of their final project narrative.
Final Showcase
Have a celebration of your students’ hard work and hold an event at your school for parents, administrators, and other community members to appreciate all of the hard work that went into making each of the final projects.
We have found that a “science fair” format works nicely, with students sitting at tables where they can demonstrate their projects, show the videos, and answer questions. You might also consider setting up a YouTube channel where your students can publish walkthroughs of the various MakeCode for Minecraft code examples they have come up with, and publish URLs to the shared code, as well. Either way, a little public recognition of all of your students’ hard work goes a long way!
Assessment
Competency scores: 4, 3, 2, 1
Code (Show what you know)
4 = Code very effectively demonstrates the use of previous concept(s). Variable names are unique and clearly describe what information values the variables hold. Code is highly efficient.
3 = Code somewhat effectively demonstrates the use of previous concept(s). Variable names are generally unique and clearly describe what information values the variables hold. Code is reasonably efficient.
2 = Code mostly ineffectively demonstrates the use of previous concept(s). Variable names may be unclear. Code could be more efficient.
1 = Code doesn’t demonstrate use of previous concepts, and/or variable names are unclear or ineffective, a number of places where code could be improved.
Code (Show something new)
4 = Code very effectively demonstrates the use of new concept(s). Variable names are unique and clearly describe what information values the variables hold. Code is highly efficient.
3 = Code somewhat effectively demonstrates the use of previous concept(s). Variable names are generally unique and clearly describe what information values the variables hold. Code is reasonably efficient.
2 = Code mostly ineffectively demonstrates the use of new concept(s). Variable names may be unclear. Code could be more efficient.
1 = Code doesn’t demonstrate any new concepts, and/or variable names are unclear or ineffective, a number of places where code could be improved.
Work logs
4 = All work logs submitted on time, and accurate.
3 = One late or missing work log and/or work logs not accurate nor sufficiently detailed.
2 = Two late or missing work logs and/or work logs not accurate nor sufficiently detailed.
1 = More than two late or missing work logs and/or not accurate nor sufficiently detailed.
Project
4 = Reflection piece describes:
* Development Process
* Something new
* Something proud of
* Future mods
3 = Reflection piece lacks 1 of the required elements.
2 = Reflection piece lacks 2 of the required elements.
1 = Reflection piece lacks 3 of the required elements.