Week 12 • GitHub Collaborations: HTML5 Game Dev
To Do This Week
Come up with a concept for your final project and develop logic steps.
In-Class
Core Git Concepts
- Repository (Repo): Project folder with files and version history
- Clone: Local copy of a repository
- Commit: Saved snapshot of changes
- Push: Upload local commits to GitHub
- Pull: Download and merge changes from GitHub
- Fetch: Check for updates without merging
Branching and Structure
- Branch: Parallel version of the code
- Main Branch: Stable primary version
- Feature Branch: Branch for a specific task or feature
- HEAD: Current commit you are working on
Collaboration
- Pull Request (PR): Proposal to merge changes
- Merge: Combine branches
- Review: Feedback on a PR
- Fork: Copy of a repository
- Origin: Default remote repository name
- Upstream: Original repo you forked from
Conflicts and Fixes
- Merge Conflict: Conflicting changes that must be resolved
- Rebase: Move commits onto another branch
- Stash: Temporarily save changes
- Diff: Shows changes between versions
Project Management
- Issue: Task, bug, or idea
- Milestone: Group of related issues
- Project Board: Task organization board
- README: Project description file
Files and Tracking
- .gitignore: Files Git should ignore
- History / Log: Record of commits
Set-up README file
README files should be written in Markdown (README.md). Get AI help with this.
- Project Overview (what the game is, concept, goals)
- Team & Roles (who is responsible for what)
- Game Structure (levels, stages, and overall flow of the game)
- Core Systems (shared logic and architecture used by all levels)
- Folder Structure (how files and assets are organized)
- Setup Instructions (how to run and test the project)
- Git Workflow (how the team collaborates using branches and pull requests)
- Naming Conventions (rules for naming variables, files, and functions)
- Style Guide (visual design rules: color, UI, sprites, typography)
- Commit Guidelines (rules for writing clear and consistent commit messages)
- Game Design Rules (shared gameplay rules: controls, difficulty, interactions)
- Code Structure Rules (how code should be organized and written)
- Communication Protocol (how the team communicates and shares updates)
- Testing Guidelines (how to check that features work before sharing)
- Integration Rules (how individual parts are combined into the main project)
- Merge Conflict Strategy (how to resolve overlapping code changes)
- Assets Management (how images, audio, and files are named and stored)
- AI Usage Policy (how AI tools can be used and documented)
- Documentation Requirements (what students must explain about their work)
- Roadmap / Milestones (timeline and major development steps)
- Known Issues / Bugs (list of current problems to fix)
- License (how the project can be used or shared)
- Credits (who contributed and any external resources used)
Final Project Workshop:
In class, we will work on final projects. Students will present their game concepts and logic steps, and receive feedback from peers and the instructor.
In this project you will use a new meta-prompt starter - JS Mentor Pro - to get assistance with your game development.
Final Project (25%)
Over the final four weeks of the course, you will design and build an original JavaScript-driven work for your portfolio. It should be interesting, well made, and eye-catching, something you would be proud to show a future employer, client, or graduate program.
Your project can take one of these forms:
- A web app: a tool, utility, API-driven project, or interactive experience people would use
- An educational site: an interactive explainer, tutorial, or learning experience
- A game: a browser-based canvas game, built with the techniques from this course
- A work of generative art: code-driven visual, sonic, or text-based art
How You Work Is Up to You
- Solo: You build the whole project yourself in your own GitHub repository.
- Partner or small group (up to 3): You may propose your own idea or choose from a list of team-ready project ideas I will provide. Teams share a single GitHub repository for collaboration.
There will be a GitHub refresher. This will be a brief overview of GitHub features and best practices for collaborative development.
Scope should match your team size. A solo project can be focused and polished. A group project should be more ambitious in features, content, or complexity.
If a team stops working, talk to me early. Members can split and continue individually with an adjusted scope.
Development Schedule
- Week 12: Choose solo or team, set up your GitHub repository, and share with me (on Slack) your concept, design sketches, logic steps, and roles (for teams). BY THE END OF THE WEEK: Send me a Slack message with your idea and design description.
- Week 13: Development sprint I. Show a working prototype at a short check-in. Share to the Slack channel.
- Week 14: Development sprint II, integration, and testing. Show a feature-complete version at a check-in.
- Week 15: Polish, final testing, documentation, and presentation
Project Requirements (Everyone)
- An original JavaScript-driven work in one of the four forms above
- At the top of the script tag and commented out: project statement, clear logic steps and AI documentation (links to chats)
- At least two substantial JavaScript techniques discussed in the demos for the front-end modules (fetch, canvas, animation, video/audio, SVG interaction, p5.js, etc.)
- Thoughtful visual design, usability, and interaction design
- Tested, organized, and commented code
- A GitHub repository with regular commits throughout the project
- A live, published version (for example, GitHub Pages)
- Project statement, logic steps, and complete AI-use documentation
- If you use AI for development, all of that work must be done with the JS Mentor Pro metaprompt (see below)
- Check-ins in Weeks 13 and 14. There will be project benchmarks.
- Final presentation in Week 15
Additional Requirements (Teams)
- Regular, identifiable commits from each member in the shared repository
- Clear division of team roles
- An individual contribution statement from each member, describing what they built and how they collaborated
Using AI in Your Project
You may use AI in this project, but the rules depend on what you are using it for.
- Research and content: You may use any AI tool to research your topic, gather content and information, and brainstorm ideas. Check facts against reliable sources before they go into your project.
- Assets: You may use AI tools to create or adapt images, sprites, audio, and other assets. Check each tool's terms of use and note where every asset came from.
- Development: If you use AI to plan, write, or debug your code, you must use the JS Mentor Pro metaprompt. Upload it at the start of every AI chat about your project's code and make sure the AI displays the start signature before you continue. Using AI for development without JS Mentor Pro is not permitted.
JS Mentor Pro is designed to help you build something ambitious faster while keeping you in charge of the idea, the logic, and the design. It can generate scaffolding and difficult or repetitive code once you can explain what that code needs to do. I expect you to be able to explain how the major parts of your project work at the check-ins and in your presentation.
Document all AI use: which tools you used, what they contributed, and how you evaluated, changed, and extended what they produced. For development, keep links to or exports of your JS Mentor Pro chats and include them with your documentation. Commit history will be considered for everyone. For teams, individual contributions will also be assessed through contribution statements and check-ins.