STDIO Game Jam 2017, Aug 19th and 20th

The STDIO Game Jam is a weekend-long hackathon to create a large set of small, fun, text-based games that beginner programmers can study. These games use only “standard io” text-streams for input and output, making for easy-to-understand source code that beginners can study. Every language and operating system supports stdio text, so running these games isn’t hindered by platform differences or frustrating framework installation processes.

The hackathon takes place at the Museum of Art and Digital Entertainment, Oakland’s video game museum and globally through the Internet.

  • Where: The Museum of Art and Digital Entertainment, 3400 Broadway, Oakland, CA [map] and globally online
  • When: Saturday, August 19th, 2017 from 6pm to midnight and continuing Sunday, August 20th from 10am to 7pm
  • Registration: Tickets are $12. $8 early bird rate before August 17th. See below for financial aid waiver.

Register to attend this event on Meetup.com (or participate online for free)

Help us bring together more game makers by sharing this page: TwitterFacebookG+

Contact al@themade.org if you’d like to volunteer and help the MADE put on this event.

The STDIO Game Jam is heavily influenced by David Ahl’s 1978 book, “Basic Computer Games”. This book listed the source code for a hundred games in BASIC. Readers could play these games, then study their source code to see how they worked. It was widely popular, and the first computer book to sell over a million copies.

It’s time to create an updated compilation in modern languages. Programming tutorials are still stuck rehashing the same “Guess the Number” and “Logo Turtle” examples. By compiling a set of open-licensed games, we can give exciting examples of programs for new coders to study and play with.

At the start of the game jam on August 19th, create a folder for your team in the GitHub repo. See the “Submission Process” section below.

Schedule

Saturday, August 19th, 2017:

  • 6pm – Doors open, team formation, snacks and drinks provided
  • 6:30pm – Welcome keynote
  • Midnight – Closing for the night

Sunday, August 20th, 2017:

  • 10am – Doors open, coffee and pastries provided
  • 6pm – Game submissions closed
  • 6:30pm – Judging complete and point totals announced
  • 7pm – Doors closed

Online Game Jam

You can still participate even if you’re not in the bay area! The online game jam is free and runs all weekend until Sunday, August 20th, 6pm PDT. The same GitHub-based submission process will be used for online participants. (See below.)

Also, the STDIO Game Jam will be streaming live from the museum on Twitch.

In-person and online attendees are welcome to post their games, questions, and discoveries on the /r/stdiogamejam subreddit.

Rules and Judging Criteria

The aim of the STDIO Game Jam is to create simple, text-based programs with compelling game mechanics or interesting artistic merit. As such, the points are awarded to encourage this.

Submitted programs are required to:

  1. Be under 256 “significant lines of code”, as measured by CLOC.
  2. Only use stdio text streams (i.e. for example, in Python, only print() and input()). This means no graphics and programs can’t move the text cursor to X, Y coordinates on the screen. Keyboard input will block program execution until the player presses Enter. (e.g. Games can’t respond to single key presses like roguelikes do.)
  3. Use only the language’s standard library and not require installing additional frameworks, libraries, or modules.
  4. Ideally use UTF-8 for the source files, but only output characters compatible with the Latin-1 (CP-1252) charset so programs can run on Windows. This means many accented characters are okay, but not unicode snowman.
  5. Be released under an open license, preferably MIT License. (These games are to be used to help others create programming tutorials and courses, including commercially.)
  6. Run on Linux, Mac, and Windows without modification.
  7. Include a file named readme.txt with the names (or handles) of each team member, with a short description (a few paragraphs at most) of the game. Put this file in only when the game is complete and ready to be judged.

Submitted programs are encouraged to:

  1. BE ORIGINAL! 😀
  2. Have the game be runnable in a “Try [language]” website, such as PythonAnywhere, TryRuby.org, or Execute PERL Online.
  3. Fit into one file (except for “data files”).
  4. Have “data files” for, say, level data in plaintext and ideally JSON files. (Plaintext makes games more hackable for beginners.) Data files don’t count towards the 256 SLOC limit. Data files should be used to provide a way for players to edit the game without modifying the code, not to just circumvent the 256 SLOC limit.
  5. Use a modern language that runs on Linux, Mac, and Windows.
  6. Be “well-commented” so that beginner programmers can understand them.
  7. Avoid advanced programming techniques like threads, reflection, self-modifying code, etc. Keep it simple.
  8. Use full names for variables, etc (e.g. “stringCompare” instead of “strcmp”).
  9. Follow a standard style guide, or at least have a consistent code style.
  10. Be reasonably bug free.
  11. Handle errors reasonably and not have empty `catch` blocks.
  12. Do reasonable input validation: don’t let the program crash just because the player entered the wrong kind of text.
  13. Have in-game “how to play” help screens as part of the program, rather than documented elsewhere.
  14. Assume the terminal is 80 x 25 characters.
  15. Remove any unused variables and functions before submitting.
  16. Not require an internet connection, or at least not rely on the player to set up a server.
  17. List in the source which license the game uses, rather than the full license text.
  18. Not be a “choose your own adventure” or interactive fiction game with no game mechanics.

Points are awarded according to the following rubric:

  • 1 point for each submitted program that meets the requirements and is deemed by the judges to “have merit”. (See “What Counts As Merit” below)
  • +2 for programs under 128 SLOC or +3 for under 64 SLOC, as measured by CLOC.
  • +1 if the game is “well-commented”. (This is subjective, but in general maybe 1 useful comment for every 6 to 10 lines of code.) Comments won’t add to the SLOC count.
  • +2 for original game mechanics. (This is subjective, but we want to encourage new programs, not just another rehash of “guess the number”.)
  • +10 “Spotlight Award” for an exceptional game. This is awarded at most once per team. (This is subjective, see the “Ideas, Tips, and Best Practices” for details.)

Further, teams can get two points for refactoring other teams’ code or providing bug fixes. The refactoring must be more than just style changes. A team can only get two points per game they refactor, not per PR.

It is considered completely fair game for teams to reimplement other teams’ game ideas, especially to port it to a different programming language. However, these games won’t be eligible for the +2 original game mechanic or +10 Spotlight Award points. Please credit the original team in the source code.

But of course, the objective of the game jam is to produce a large compilation of readable programs for beginners to learn from and try to create for themselves. This is truly more valuable than points.

What Counts as “Merit”

The point of the game jam is to create a collection of games that new programmers can view the source code for to become better programmers. To prevent attendees from gaming the system by flooding the judges with low-quality programs, there is a “has merit” requirement for submissions.

This is purposefully subjective, but is meant to be a low bar to prevent submissions that wouldn’t be publishable as educational examples. For example, programs that lack merit would:

  • Be a game with little or no player interaction. (Artistic programs without interaction, however, are fine.)
  • Be a simple derivative of other submissions (for example, Tic Tac Toe with Xs and Os, another with As and Bs, another with 1s and 2s…)
  • Be plagiarized in whole from other creators.

This is just an anti-spam measure. If your program has a very simple game mechanic, or is your original creation based on an existing game (like Tic Tac Toe), or seems overly short, these programs are still fine for submission.

Submission Process

Both game jam attendees and online participants first must sign up for a (free) GitHub account and clone this git repo on their GitHub account: https://github.com/stdiogamejam/2017STDIOGameJam

Add your game using the following folder layout in the repo:

/[team_name]/[game_name]/[your_program.py]
/[team_name]/[game_name]/readme.txt
/[team_name]/[game_name]/refactors.txt

Submissions are made on the master branch (this is the default branch). Game jam staff can help attendees with git. GitHub also has a short tutorial. You won’t need to know anything about branching and merging to submit.

The [team_name] should be the GitHub username that will make pull requests against the STDIOGameJam repo, regardless of what the team calls itself or who is in it.

The [game_name] should contain a readme.txt file when it is ready to be judged. Judges will add an X-points.txt file where X is the number of points it was given and contain any notes. Judges will be awarding points throughout the game jam, not just at the end. You may appeal the points awarded if you feel they were tallied incorrectly.

The folder can also have a refactors.txt listing teams that contributed accepted Pull Requests for refactoring the code or bug fixes. These teams will be awarded two points.

Look at the sample programs under the asweigart folder for examples.

Ideas, Tips, and Best Practices

The wiki for this repo has an ideas page where game jam attendees can find (and add) ideas for games to make: https://github.com/stdiogamejam/AboutSTDIOGameJam/wiki/Ideas

Working with only stdio text introduces several constraints:

  1. Programs have no graphics beyond ASCII-art.
  2. The text cursor cannot be moved back up or to arbitrary XY coordinates on the screen.
  3. Programs are necessarily turn-based, waiting on the player to finish typing and press Enter.
  4. Programs are single-threaded.

But these constraints can also drive creativity. Text streams might be old-school, but your game design can be completely modern: if you can create a text-version of Portal 2, go for it!

There will be a board with post-its at the game jam where attendees can help each other with tips and best practices they’ve discovered, such as:

  • Remember: There’s plenty of types of games you can make with just text besides Zork-style text adventure games.
  • If the player must enter coordinates, display an ascii-art board with coordinate numbers running along the four sides.
  • Try to make games based on simple game mechanics, rather than spending time on scripted stories or elaborate level design.
  • Present numbered menu items so players don’t have to type full commands in.
  • Let players enter multiple moves at once. For example, instead of redrawing a maze after each move, let the player type “uurd” to move up, up, right, and down in one go.
  • Make input short and case-insensitive.
  • You can create cool ASCII-art text with Figlet
  • Making two-player games is probably easier than making computer AI opponents.
  • (This list will be updated during the game jam as new ideas come up.)

Spotlight Award

The 10-point “Spotlight Award” is given to games that have game mechanics that are simple, original, and compelling. The prime example of this is Hamurabi [sic] from David Ahl’s Basic Computer Games book. Hamurabi is a bare bones city management game with mechanics that connect three resources: population, grain, and land. The three resources have simple interactions but create an original and compelling game that became a classic:

  • Grain is used to maintain the population and prevent starvation.
  • Growing grain requires a balance of both land and population for best efficiency.
  • Land can be bought or sold with grain at a price that randomly fluctuated each turn.
  • Population slowly grows each turn with a random number of immigrants.
  • Rare, random plagues cut the population in half. Rats randomly eat grain stores.
  • The player can’t let more than 45% of the population starve in one turn.
  • The goal is to have as large of a population as possible at the end of 10 turns.

The game had random elements but didn’t rely on luck, avoided straight-forwarded strategy (as in rock-paper-scissors), and had a playtime of a few minutes. Repeated plays allowed the player to figure out how the mechanics worked and form new strategies. This is ideally what a “Spotlight Award” game would have.

Game Program Compilation Book

The MADE is a 501c3 nonprofit and will be producing a book compilation of the games made at the game jam. The book will be freely available online under a Creative Commons license, while copies are also sold for the benefit of the museum.

Financial Aid

We don’t want the registration price to block attendance. Please email al@themade.org if you’d like to attend the game jam but request the fee be waived.