Table of Contents
- Project Management
- Team Working Agreement
- Individual Responsibility Agreement
- Project Schedule
- Meeting Notes
- Business Plan
- User Identification and Interviews
- Electronic/Print Advertisement
- Pitch Video with Demonstration
- Software Documentation
- Introduction
- User Manual
- Program Description for Developers
- Final Flowchart
- Discussion
- Conclusions and Recommendation
- References
- Welcome Page
- Table of Contents
- Executive Summary
Executive Summary
After a couple weeks of Matlab we felt pretty confident on our skills, but knew what we were capable of. We hadn’t had any previous experience with coding before so we only knew what we had learned in lecture. With this knowledge We decided we would only be able to code something that was fairly simple as well as run by people with no AI capabilities. With this in mind we decided to create High Low and Tenzi. High Low was a simulation of rolling a die and counting how many attempts it takes to guess the number. The purpose of this was to play a fun simple die game and see how little attempts it takes for a player to guess the number. Tenzi is a game where you roll ten dice and you want to get all of them to be the same number, but you choose what number after the first roll and extract dice as you roll until all of them are the same number. The purpose is to play a fun dice game and see how many rolls it would take to win.
After completing the two dice games, our group was proud. The creation of coding tenzi started with an decent understanding of the flowchart, a harder path of relating the flowchart to the code, and a finale of being able to add a bit of analysis at the end just to see how many times it would have taken to roll all the die on one number to satisfy the user-inputted-number. For the simple dice game, the flow chart was simplistic and the coding wasn’t too difficult. Our spin on the game came into play once the phrases for the reactions of the user’s choices was describable. Both games were fully functional able by the group timeline.
There were several times were programing one of the games would get old and switching off with the two became a thing. If things did get like a rock in a hard place, we would give it a day to come back to it and if all failed there, we would then ask for a TA’s assistance.
A few recommendations for the games would be making the games a bit more flashy and appealing, having them be more interactive with the user, and expressing phrases with emojis to express more than whether the user won or lost the game. Even though we are proud of the classic games we created on matlab, making the games more relatable and exciting could be allow for our goal to be reach even further than we thought we would get with this project. One additional word of advice would be to get help when possible. Rather than just waiting a few days for something to change, there’s no point in waiting around when an answer could be right in front of you.