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. It's up to you to use what you've learned to come up with a fun and interesting game.

You will be working individually for this project, but we'll be guiding you along the process and helping as you go.

As part of this project, you'll be required to present your project to your instructors and classmates in a "Science Fair" showcase. Your goal for this presentation is to extract the most important aspects of what went into building your project into easy-to-use language and practice speaking and presenting about your code (and have people play your game!)

Show us what you've got!

Due Dates

Your proposal for this project, as outlined in the proposal section below, must be completed and ready to present for approval by:

Wednesday, September 26th at 9:00 AM

This assignment, as outlined below, must be complete in totality by:

Monday, Ocober 1st at 1:30 PM.

Requirements

Your game website must:

Be a working, interactive, non-trivial game.
Be deployed via GitHub pages.
Include at least one CSS animation/transition fired by a DOM event.
Be styled with CSS.
Use flexbox or (CSS grid) for layout and positioning

Your code must:

Be properly indented
Be written with semantic, camelCase JavaScript variable names
Be written with kebab-case CSS class names (e.g. this-is-the-class-name)
No console.log() or commented out code in final version

Your README must:

Name of your project
Brief description of the game
A link to your deployed game

Bonus

Include a "Tutorial Section" of this landing page (why: instructions help think through the "UX" of your project)

Necessary Deliverables

For the proposal:

A collection of wireframes - hand-drawn or digitally created - outlining the important pages of your site, as well as the critical states of your game (start state, play state(s) win state). As some games have many or infinite numbers of play states and win state, you can just provide a few simplified diagrams to convey the general idea.
A proposal including:
- A description of the game you'll be building with the objective described in non-technical language.
- A list of the main technologies you plan to use.
- An explanation of the major problems you plan to face while implementing this game.
- An explanation of how you foresee yourself solving the aforementioned problems.

For the game:

A git repository hosted on GitHub, with a link to your hosted game, and frequent commits dating back to the very beginning of the project (YOUR APP SHOULD BE LOCATED IN A SEPARATE STANDING REPO. DO NOT build your app in this repository. YOU MUST initiate a new repo on your GitHub account.)
A README file with:
- A link to your live game deployed on GitHub Pages
- An explanations of the technologies used
- Select wireframes
- Additional information including but not limited to - the approach taken, installation instructions, unsolved problems, etc.

For the 3-minute screencast:

- A Quicktime screencast

Suggested Ways to Get Started

Break the project down into different components (data, presentation, views, style, DOM manipulation) and brainstorm each component individually. Use whiteboards!
Use your Development Tools (console.log, inspector, alert statements, etc) to debug and solve problems
Work through the lessons in class & ask questions when you need to! Think about adding relevant code to your game each night, instead of, you know... procrastinating.
Commit early, commit often. Don’t be afraid to break something because you can always go back in time to a previous version so long as it's been saved as a commit.
Consult documentation resources (MDN, CSS Tricks 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.

Project Feedback + Evaluation

Your project will be evaluated using this rubric, assessing the following:

Professionalism
Functionality and Requirements
Quality and Consistency
Workflow and Deployment
Creativity

A Note on Plagiarism

General Assembly has a zero tolerance policy towards plagiarism and cheating. It is destructive to classroom culture, and exhibits a clear lack of respect for classmates, instructors, the company, and the greater community. Any work considered to have been plagiarized will not be accepted and will not count towards graduation requirements. If a project exhibits evidence of plagiarism or cheating, the student will not be able to display the project at a GA-sponsored class “science fair” or “meet & greet.” Any student found plagiarizing or attempting to plagiarize will be disciplined accordingly (including but not limited to removal from class).

Open source code is inherently open and usually available for free use to modify and implement into any non-commercial project. However, please review their license and usage guidelines, give credit to the project and/or author, and do not try to hide or disguise the usage of such code.

You are encouraged to ask others, including students, instructors, and StackOverflow, for help. However, it is NOT ACCEPTABLE TO COPY another person's code and submit it as your own. More importantly, it is detrimental to your learning and growth.

All of the following are considered plagiarism or cheating:

Turning in work that is not your own.
Turning in someone else's work as your own.
Hiring, or paying someone to do your work for you.
Copying words or code without giving credit.
Building or copying someone else’s idea without their knowledge or giving credit.
Giving incorrect information about a source.
Changing words, variable names, etc. but copying the code or files of a source without giving credit.
Copying so many ideas or code blocks from a source that it makes up the majority of your work, whether you give credit or not.
Failing to put a quotation in quotation marks.

In an effort to not plagiarize, credit for this content goes to:

Plagiarism.org, specifically the “plagiarism 101” section. Content was adapted for code. For more information, please see:
Avoiding Plagiarism: Writing Computer Code

mjacobs21 / project-1 Goto Github PK

project-1's Introduction