Arcade is a game where you get prizes for building, documenting, and shipping projects.
The spirit of Arcade is for you to build stuff in a hacker mindset. Start a project, push it to an MVP as fast as possible, publish it, then iterate quickly. We have rules and standards for review, but the ultimate thing those rules are trying to get at is "are you doing real work on personal projects in a hacker mindset".
This is the first draft of a living document defines "what counts" for the Hack Club Arcade. It should be a short and sweet reference for Arcade players and reviewers alike. Comments, pull requests, and questions are welcome.
Arcade has three essential phases:
- Build projects and log your hours with
/arcade - Document progress in a git-based versioning system
- Ship a shareable version in #scrapbook when it's ready
After you ship, you'll get a ticket for every hour that passes review. Spend these tickets with /shop
A project is a self-directed creative effort toward an output that other people can meaningfully experience.
Fine Print
- leetcode or similar challenges do not count
- Homework or work done for a job/commission are not self-directed and therefore don't count
- Projects started (but not finished) before Arcade are okay, but only the work done during Arcade can be logged
- Tutorial projects that are 1:1 copies of the tutorial do not count. If you're doing a tutorial, you need to "make it your own" in some way
The journey of each project must be shared in a public git repository, with at least one update committed per hour logged.
Fine Print
- Every update needs a link to the git commit for that hour
- For code or other text-based content, put the actual code in the repo. For everything else, images or videos are fineβin the repo though!
- Any git-based system is allowed, but GitHub is preferred. Many of our review automations are built around GitHub, so other systems may be more annoying for you to use.
- When submitting a single session scrapbook, you are required to include 2 mini-scraps throughout the session to help our reviewers clearly understand your progress. It is a progress update (not necessarily a git-commit) showing your progress through this part of the session. This could be screenshots of art or CAD or product of your code, or git commits, multiple times throughout your session and sent in the thread.
A shipped project must be shared in a way that other people can experience to the greatest possible extent.
Fine Print
- Your repo needs a README
- Ships must be shared in the Hack Club Slack with a post in #scrapbook. They also need a screenshot or video or URL to experience the thing
- There must be a component of the ship that can be experienced by people in Slack
- For digital but non-code projects, a fileβand, for some online tools, a linkβof the "most native" type for the project must be included. STL and .blend for Blender, PNG and project link for Figma, Gerber file and CAD file for PCBs, STEP export and STL for CAD (with a link for OnShape projects), PNG for and source file (PSD, XCF, etc) for digital artβ¦
Some examples of "native" websites diffferent types of projects are below. Keep in mind, this isn't an exhaustive list, but a big part of "shipping" a project is getting others to experience it & this is a good way to do that.
- 3D printing files
- Blender files
- Games
- Web projects
- https://vercel.com (if a website)
- https://github.com (Using GitHub Pages)
- Game mods (different for every game)
- https://www.spigotmc.org (for Minecraft mods)
- https://modrinth.com (for Minecraft mods)
- https://hangar.papermc.io (for Minecraft plugins)
- https://www.moddb.com/ (for source games)
- Discord bots
In particular we find python projects are often the hardest to ship. A couple approaches you can take:
- If you have a package, you can publish it to PyPi
- If you make a game or executable, you can publish it with pygame or pyinstaller
- If all else fails, you can publish it to GitHub and include a
requirements.txtfile & apoetry.lockfile & cut a release
Many python projects end up being just a script.py file in a repo, which isn't a real project because it may only work on your machine. Keep in mind that the goal is to make your project accessible to others & everyone has different versions of python and different dependencies installed.
The gray areas of "what counts" are ultimately resolved with a vibe check. Here are some vibey questions we may ask ourselves when assessing whether something counts for Arcade:
- How technical is this project?
- Is this person pushing themselves?
- Does this project feel wholesome?
- Is this a highly self-directed project?
- Is this a good story?
- Am I amazed?
These are not criteria or requirements, they are just vibes. But when a project is in a gray zone, these vibes guide our decisions.
- This is a living, changing document. Rules have changed and will continue changing. For practical reasons we have to enforce whatever the latest rules are, even for hours that were submitted before the change.
- You can't bank more than 25 hours at a time, because of arcane technical reasons, but also because you should be shipping and iterating on a loop tighter than 25 hours
- If you use an AI tool to generate code, explain broadly which tool and how you used it at the top of the file. Using AI is fine but we are going to make a judgment call on how much we consider it to be "your work". Undeclared AI is considered plagiarism, so please be honest
- If we think you have knowingly submitted something fradulent, we will either give you negative hours or just ban you outright
- Nothing that breaks the law or facilitates breaking of laws, please
Build stuff, get stuff, repeat. All summer. (ends August 31st)
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent