I&#x27;m a CS student, and I do attend hack-a-thons several times a year. My policy is to ignore the competitive aspect. I should feel successful no matter what the judges decide.<p>My mindset from the beginning is that I won&#x27;t work on the project at all after the 24 hours allotted. It&#x27;s a throw-away project. This is really freeing. You don&#x27;t have to worry if the code is messy, or even if there is a fundamental problem with your idea (game mechanics, etc.)<p>My goal is to pick a new technology or library to learn and build something with it. Once, I decided I wanted to learn how to use OpenCV, so I made a little game that is controlled by facial tracking. Another time, I had just bought some USB Nintendo 64 controllers, and I wanted to make a game that used them, so me and some friends made a local multiplayer fighting game. (The projects almost inevitably end up as games). Another project we made a multiplayer game with WebSockets to fiddle with lag compensation and clock synchronization. I learned a ton of distributed systems stuff in that short time.
Sometimes, the technical problems take all time, and the finished game just barely counts as playable. Getting OpenCV bindings working with Java took nearly 8 of the 24 hours. Another project, using WebRTC for a peer-to-peer multiplayer game, only came together in the last hour, and stretched the definition of game so much that we won a special award &quot;for challenging perceptions of what games can be&quot; :).<p>It doesn&#x27;t really matter, because my goal isn&#x27;t really to make a great game, it&#x27;s to force myself out of my comfort zone to learn something new. The game is incidental, really. Sometimes, the judges are looking for something more polished, or more business oriented. That&#x27;s OK -- the game isn&#x27;t for those judges. I only invested 24 hours into it. However, I&#x27;ve been pretty lucky, so far -- most hack-a-thons I&#x27;ve been to really celebrate true hacks.<p>I think one thing organizers can do is emphasize the process of writing the code, rather than the result. Ask what challenges the teams faced, the hardest bug they fixed (or didn&#x27;t :). Near the beginning, try to offer workshops on different technologies, so that people can branch out and try something new.
You can also offer categories of judging -- if there is only one category, it&#x27;s hard to decide between an awesome business idea with little technical innovation and an awesome technical achievement with little applicability. No matter which one you pick, someone will be disappointed. But if there&#x27;s a category for best game, best presentation, best app, most innovative, best technical achievement, or whatever categories you pick, then everyone at the hack-a-thon can participate however they like best, and be recognized for it.