Much like Ben Stein, many boring things are important, and ultimately fulfilling on a deep emotional level that you don’t yet fully understand. Like it or not, rules are just one of those tedious things that we’ve got to wade through before the fun starts. And if you do what we like to call “pulling a EULA” and just scroll down to the bottom without reading the details, then we can’t be held responsible for when your game gets disqualified on a technicality.

Also see our FAQ Page



Make a playable game in only 48 hours. Face judgment by industry professionals and your peers.

And just to avoid confusion, here’s how ISR defines some of those terms:

playable [pley-uh-buhl] adjective
1. Not broken. The game loads and functions.
2. Bugs are okay, but we should be able to get a general sense of the experience. The more polished, the better.

game [geym] noun
1. A goal-oriented, interactive experience. We’re leaving it at that.

forty-eight hours [fawr-tee eyt ou-ers] timeframe
1. Two days.
2. 2880 minutes.
3. 172,800,000,000 microseconds.
4. A 1982 classic, starring Eddie Murphy and Nick Nolte.

We are very, very serious about the time limit. 


1. The entirety of your game must be conceived, designed, built, and uploaded within your team’s allotted 48-hour window, which begins the moment you’ve registered and hit the “Go!” button during the official specified duration of the contest.

2. Teams can be composed of no more than four people, and no less than one (sorry androids). No work performed by a non-registered team member can, in any form (assets, coding, music, or otherwise), be included in the final product.

***Non programming-related minions associated with competing teams (such as volunteer QA) are allowed and encouraged.

3. Games must incorporate the theme and element randomly assigned to the team after the “Go!” button is pressed. A theme is what your game about be about. An element is something that should appear in your game (read more about this here.) We realize that some can be considered abstract and, while their use must be prominent, it is the team’s sole responsibility to decide how/where to use them in the final product. While use of variables is not built directly into the scoring rubric (we don’t have one of those), it will be the sole decision of each judge to decide how well they were integrated in the final design.

4. Players may only use assets and code from their personal library or publically available engines and frameworks. Everything else is infringement, boys and girls, and infringement isn’t good for anyone. Any violation of copyright will cause instant disqualification.

5. All submitted entries must include the following line during the beginning or end credits:

“This game was developed as part of Indie Speed Run 2015 (”

If you don’t have credits (though we totally think you should – you should always slap your name on your creations) an opening or closing “slide” is acceptable. When in doubt about this (or anything) just ask. We have a Contact Us thingee we’re pretty attached to.


You made it; it’s yours. It’s as simple as that. If you want to sell it, further develop it, package it up into a smart phone app, or convert it into binary and sell designer toilet paper with your hard work expressed in ones and zeros across its top, that’s your business. Indie Speed Run and its select partners do, however, maintain the right to host your entry online, and use screenshots and/or video of gameplay in promotional efforts for the competition. Don’t worry, we’re not trying to shoulder you away from what is 100%, completely, unequivocally, indisputably, incontrovertibly your work, but providing these games free of charge to the community is just sort of our thing.

Join our list to receive relevant ISR news and updates, and to be the first to hear about upcoming jams.

You have Successfully Subscribed!