Some may be quick to point out that review bombing will have the same effect on every project in the event. This is obviously an incorrect statement as some projects receive less ratings than others due to incompatible platforms, a steeper learning curve, or general randomness, meaning a review bomb will have far worse effects on projects with less ratings. 

Even if a participant is trying to vote ethically, it is effectively impossible for them to make a completely fair vote. In large scale events, a participant may have dozens or even hundreds of projects to choose between and even if they wanted to, they simply would not have the time to carefully review every project. Soft barriers such as a lack of thumbnail images or tutorial or hard barriers like platform incompatibility can hinder a participant's attempt to test and rate a project. The limited amount of time to review projects ultimately leads to votes being determined by first impressions instead of overall functionality. Logical biases such as the familiarity and availability heuristics can cause participants to be biased toward projects made by teams working near them. Ultimately all of these factors combined lead to biased results not caused by nefarious intent but by the imperfection of human nature.

The best and most obvious solution, the one that the majority of hackathons have implemented, is simply not to use peer voting. This was and still is the case in MelonJam and in essentially every hackathon not affiliated with Hack Club.  

In extremely large scale events such as the GMTK Game Jam, the number of submissions makes a pure judging system extremely impractical, and purely voted results would contain all the issues mentioned above. Instead, GMTK uses a hybrid system where entries enter a round of community voting and the top 100 games in the jam, and the judge will play those 100 games to determine 20 winners. 

When peer voting is absolutely required, actions can be taken to improve the fairness of the process. These actions include but are not limited to: requiring votes to include a review of the project, allowing organizers to disqualify projects that are asset or template rips, and automatic detection and removal of review bombs.

However, in smaller events such as Daydream Global and smaller satellite hackathons, there really is no excuse to not involve judges in some part of the process other than "we don't want to". MelonJam is judged entirely by current and former members of the Cupertino Game Development Club. Each officer is assigned a set of games to judge and told to pick three favorites. The selected projects are combined to enter a final discussion with all judges, and winners are selected. Daydream Global could have easily been professionally judged with even a small team (say eight judges judging 25 games each) of judges, bypassing all of the inevitable problems of peer voting. Instead, we got a single category of judge prizes with the vast majority of prizes being determined by a fundamentally flawed system.

Professional judging may not be a perfect system, but it's the best system we have for determining the highest quality projects.