Rules

1) Eligibility

  • Attendees from all backgrounds, genders, and nationalities are welcome. There is no age restriction to attend Reality Hack.
  • Hackers under age 18 must have their parents/legal guardian contact the organizers at team@mitrealityhack.com
  • Reality Hack organizers and VR/AR MIT members are not eligible to participate in the Hackathon. They may, however, assist teams as mentors during the hacking phase.
  • Prize winners are responsible for paying any taxes on their prize winnings.

2) Team Formation

Interacting with other hackers before the Hackathon

If you have any questions, please reach out to us at team@mitrealityhack.com or on Facebook/Twitter.

Do

  • Familiarize yourself with tools, packages, SDK's
  • Identify like-minded people in the Facebook group

Don't

  • Create specific project plans, especially in collaboration with potential teammates, or write any code in advance - this is grounds for immediate disqualification.

Examples

  • "I'd love to create an AR tool that puts duct tape on all real-world bananas." This is great! (YES)
  • "Hey potential teammate, that's a cool idea! I had a similar one with masking tape and oranges! Can't wait to brainstorm with you at the Hack!" (YES)
  • "Hey potential teammate, you might be interested to know there's a cool thing out there called Open AR Tool." (YES)
  • "Hey potential teammate, I like that idea too. Let's have a call to discuss the project details." (NO)

Team Formation

  • Teams must have at least two team members and can go up to a maximum of five members.
  • We encourage each team to have at least one designer.
  • Participants who have worked together in a past Hackathon are not permitted to be team members.
  • We want to create a fair competitive environment, so participants who have worked together on past projects together at work/school for more than 1 month are not permitted to be team members. If you believe there is a gray area please contact team@mitrealityhack.com.
  • Hackers must be a member of only one team.

3) Project Development

  • No development may start before the actual date and time of the event. Any teams that violate this rule will be automatically disqualified. Please do not begin hacking before Thursday, March 24th at 8 AM.
  • Any software development tools, game engine, IDE, and/or programming language can be used for the event.
  • Paid Software Assets - You are NOT allowed to purchase paid art/audio assets. Low-cost paid developer plug-ins are okay. Assets, SDKs, APIs, or other tools or components available under a trial license may be used. If you are not sure if an asset is allowed, go to the information desk to make a rules inquiry.
  • Paid Design tools - For paid creation tools such as Adobe Creative and Solid Works, you are allowed to use any platform available to you. We want to enable designers to continue to work in the platform they are most familiar with.
  • Use of Unique Hardware - A list of approved hardware will be published in March. Hardware that is not on the approved list will only be allowed in the Wild West category - a separate track with prizes that allows the use of unique hardware. If in doubt, ask us first at team@mitrealityhack.com or via Facebook direct message.
  • Any intellectual property developed during and within the scope of the hackathon must be open source and licensed under one of the licenses referenced in https://opensource.org/licenses.
  • The license selected by the team must be clearly listed in code (page per page) or a generic page announcing the license the project adheres to. The public code used inside the project should also list the licenses the code is subjected to.
  • A team can use multiple licenses in their project. For example, the public code used could be licensed under the Apache license agreement whereas the code written by the team for their project could be licensed under the MIT license agreement.
  • A team may not build projects that violate the Code of Conduct. For example, racially insensitive ideas for a project will automatically be disqualified.

4) Project Submission

  • All teams should have a team name and will showcase their project on DevPost
  • The project showcase listing should have the following:
    • The team lead must list a mobile phone number
    • All team members with brief biographies.
    • Short abstract of the project
    • The hackathon theme and category if applicable
    • Team location, floor, and room (We need to find you to judge your project)
    • The hardware used and target platform
    • The development tools used to build the project
    • SDKs used in the project
    • APIs used in the project
    • Any assets used in the project
    • Any libraries used in the project
    • Any components not created at the hackathon
    • A link to the team GitHub repository
    • A link to a video of a screen capture of the application on YouTube or Vimeo.
  • All projects should be submitted to the hackathon GitHub account (TBA) before judging begins on Saturday, March 26, 2022, at 2:30 pm. Failure to submit will result in disqualification. Teams should commit regularly to the team repository throughout the hackathon. Team repositories that are committed in their entirety near the close of the hackathon, Saturday, March 26, 2022, will be examined closely and the team may be disqualified for a rule violation. A single GitHub commit made near the end of the hackathon will draw the suspicion that the work was not completed at the hackathon.
  • Project submissions will be randomly code-reviewed. Projects will be spot-checked by code reviewers. All the projects selected by the judges as finalists will be code-reviewed to confirm that the code is original work created at the hackathon and all licensed components and assets conform to the licenses allowed in these rules.
  • After hacking stops, at least one member from each team must meet with the judges for a brief review of their submission and to confirm that the team’s Devpost page is complete.