The goal of this Game Development Competition is more about providing the right kind of motivation to get you to actually sit down and build a game than it is to prove you're a better coder than everyone else. As such, these rules are pretty light, and pretty casual. If one or more rule doesn't suit your needs, feel free to be a Competition Rebel, break the rule, and enjoy the competition anyway.
These rules are tentative. If you want to suggest a change to the rules, post a comment below and we can talk about it as a community.
Picking Goals
Because the focus of the competitions are to get things done on a game, the competition doesn't prescribe how much or what parts of a game you should make. Instead, you must choose a specific goal for yourself.
There is a preference for process goals over target goals. The following are target goals:
- I'm going to complete a game in the 31 days of the competition.
- I'm going to add networking to this game I've been working on.
- I'm going to build enough of a game that I can start play testing it with others.
These are good goals, and the competition doesn't discourage using these types of goals, but…
These are process goals:
- My problem is that I keep doing other things instead of working on my game. My goal is to dedicate at least 6 hours every week to working on my game so that it can actually progress.
- My problem is that when I sit down to work on my game, I get distracted by other things. My goal is to eliminate my distractions when I program by turning on my Strict Workflow Chrome extension to block Facebook, YouTube, etc., close Discord, and put my phone in the other room while I'm working on my game.
- My problem is that I put my life on hold when I start working on a game and burn myself out by doing nothing but game dev. So my goal is to get at least 8 hours of sleep and spend 30 minutes taking care of other life responsibilities before moving to game dev.
Target goals are not bad. We eventually want to get that first game out there. But software development is extremely difficult to predict. Something comes up and suddenly, your target goal is out the window and you lose motivation for continuing because you can't hit your target anymore.
This is what makes process goals better. Process goals are way less prone to surprises happening. The outcome of a process goal is nearly always the result of your own efforts and decisions, not some external surprise.
A key part of the competition is picking one or more goals to aim for during the competition. Process goals are preferred, but target goals are also acceptable.
Another key part is continually re-evaluating your goals. You are not only allowed to change your goals during the competition, you're strongly encouraged to re-evaluate them and decide if they need to be adjusted. (This is commonly done as a part of our weekly sprint cycle.)
Rules
1. You must choose goals for yourself. Since the competition doesn't prescribe exactly what you must complete on a particular game, the burden is on you, the participant, to decide what you need to accomplish during the competition. Pick one or more goal for the competition and list it in your forum thread or elsewhere that people can track your progress. Process goals are preferred to target goals, but both or either are allowed.
2. Show your work. To count as a "win", you must show your progress to the other participants. The most common way to do this is by creating a forum thread for your game in the competition's section of the forum. In your thread, you can post status updates, screenshots, and even downloads for the game. (Even source code, if you want to make the game open source.) Some people post daily updates or weekly updates, but at a minimum, final results are required to meet this requirement.
At least weekly updates are strongly encouraged, as the community tends to have a weekly sprint/cycle/cadence. A week is usually enough time to show some amount of progress, and keeps you moving forward one week at a time. For most people, this ends up being Sunday evening or Monday sometime.
3. Making sellable games is strongly encouraged. Not that you have to actually attempt to sell it, and not that if you tried to, somebody would pay money for it, but you should be carefully watching licensing agreements an avoid copyrighted material (or get permission from the copyright holder). For anything that requires attribution, the copyright holder should be listed in the credits.
Beginners can have an exception to this rule. If you've never made a very large project before, it is probably better to start by cloning a really simple game first (Tic Tac Toe, Pong, Breakout, etc.) to start to figure out how to build functioning games before tackling the magnum opus floating around in your head.
4. No restrictions on team size. While most people tend to work alone, working in a team is allowed and encouraged. If you don't have a team, post a message in the competition's section in the forum and ask for people to join you or express your interest in being a part of a team.
5. No restrictions on tools, engines, frameworks, languages, etc. The competition doesn't prescribe any particular language or engine. Use whatever you think is best for you and your game.
These rules are quite different from earlier competitions, so if you have questions, comments, or suggestions to improve them, comment below.