6.1 KiB
Project #1: The Game
Overview
Let's start out with something fun - a game! Everyone will get a chance to be creative, and work through some really tough programming challenges – since you've already gotten your feet wet with Tic Tac Toe, it's up to you to come up with a fun and interesting game to build. You will be working individually for this project, but we'll be guiding you along the process and helping as you go. Show us what you've got!
Technical Requirements
Your app must:
- Render a game in the browser
- Switch turns between two players
- Design logic for winning & visually display which player won
- Include separate HTML / CSS / JavaScript files
- Stick with KISS (Keep It Simple Stupid) and DRY (Don't Repeat Yourself) principles
- Use Javascript or jQuery for DOM manipulation
- Deploy your game online, where the rest of the world can access it
- Use semantic markup for HTML and CSS (adhere to best practices)
Potential Project Ideas
Connect Four (seperate markdown file with directions)
Blackjack (seperate markdown file with directions)
Make a one player game where people down on their luck can lose all their money by guessing which card the computer will deal next!
Self-scoring Trivia
Test your wits & knowledge with whatever-the-heck you know about (so you can actually win). Guess answers, have the computer tell you how right you are!
Suggested Ways to Get Started
- Wireframe Make a drawing of what your app will look like in all of the stages of the game (what does it look like as soon as you log on to the site? What does it look like once a player enters their name? What does it look like while the player is playing? What does it look like when the player wins / loses?).
- Break the project down into different components (data, presentation, views, style, DOM manipulation) and brainstorm each component individually.
- Use your Development Tools (console.log, inspector, alert statements, etc) to debug and solve problems
- Work through the lessons in class for help and inspiration! Think about adding relevant code to your game each day - you are given 5 days so that you can work on it in small chunks, COMMIT OFTEN. We will be looking at your commit dates and comments are part of your scoring.
- Commit early, commit often. Don’t be afraid to break something because you can always go back in time to a previous version.
- Consult documentation resources (MDN, jQuery, etc.) at home to better understand what you’ll be getting into.
- Don’t be afraid to write code that you know you will have to remove later. Create temporary elements (buttons, links, etc) that trigger events if real data is not available. For example, if you’re trying to figure out how to change some text when the game is over but you haven’t solved the win/lose game logic, you can create a button to simulate that until then.
Deliverables
By the time the project is over, we will expect the following from you:
- A working game, built by you, hosted somewhere on the internet
- A link to your hosted working app
- A git repository hosted on Github and frequent commits dating back to the very beginning of the project
- A
readme.mdfile with explanations of the technologies used, the approach taken, a link to your live site, installation instructions, unsolved problems, etc.
Most importantly a technical demonstration of your app which:
- Is 5 minutes in length
- Shows off all features of the app
- Explains the technical details
- Explains the technical challenges
- Explains which improvements you might make
Project Week
Attendance
You are required to be present by 10:00 am EDT each day during the project.
Standups
We will have student-run stand-ups each morning at 10:15 am EDT where you will answer the following questions:
- What did I work on yesterday
- What am i trying to get done today
- What is preventing me from getting this done.
This meeting should take no longer than 15 minutes.
If you have ideas on how you can help a fellow-student with work that they are stuck on, please follow-up with information AFTER the stand up.
Meetings with instructors
Your instructor will contact you to setup a meeting time
Tuesday, June 7
15 minute meeting to get your project approved.
Wedesday, June 8
15 minute progress check-in
Thursday, June 9
Whole class instruction on how to deploy your project to the world wide web.
Friday, June 10
15 minute check in to see where you are before you go into the weekend. Help you to decide what to finish and what features should be stretch goals.
Where to go for help during project week
- Seek out help online
- Seek out help with your classmates
- Seek out help with Derek (TA)
- Submit a Github issue to receive help from an instructor
Formatting your GitHub Issue to ask for help
PUSH OFTEN! Your code on GitHub should be up to date. Submiting an issue and linking us to old, out-of-date code will hinder the process.
- WHAT YOU ARE TRYING TO SOLVE:
- Write a detailed explanation of the feature or user story you're working on.
- DETAILED DESCRIPTION OF THE BUG/ERROR:
- A detailed description of the problem, the bug, and/or the error. This means: the full steps to reproduce, a link to the file on github, and the line number of where the relavent code is. The error(s) returned, copy and pasted/typed out/screenshot, not paraphrased.
- If there is other code in a different file that is also essential to the functioning of the code that currently works point us to that and explain the relationship.
- WHAT I'VE TRIED
- List everything you've done to solve the bug on your own in detail. list all resources you've looked up and tried to implement and provide links. Providing code if you have it surrounded by the md syntax to display nicely is very helpful.
- QUESTION
- After going through all this what is your questions specifically, more specifically than how can I make this work?