Post Monday, 18th January 2016, 15:09

Game Design Discussion Guidelines

DCSS has been maintained by volunteers and players as an open source project for nearly a decade. The developers primarily discuss the game's design in ##crawl-dev on Freenode, with additional discussion and planning on crawl-ref-discuss and the devwiki. Many developers and players also discuss the game's design here on the Tavern's Game Design Discussion (GDD) subforum, where posters can propose changes to the game and discuss existing proposals or game mechanics.

In order to keep the conversation respectful and constructive, we ask that posters follow these guidelines in addition to the normal forum rules when participating in GDD:

  • When posting a new GDD thread:
    • Give your thread a clear title and provide as much detail as possible in your OP. Include the reasoning behind your proposed change and how it fits with DCSS's design goals, as well as the specifics of your proposal.
    • Have a narrow scope. Threads that begin by discussing numerous unrelated topics are less helpful than focused threads.
    • Post a complete, finished idea. Brainstorming threads or incomplete proposals should be posted to Crazy Yiuf's Corner for development.
    • Be respectful. The mechanic or feature your proposal changes may be someone else's favorite part of the game, or it may have been designed or coded by one of your fellow posters.
    • Don't post bug reports. They go on Mantis.
    • Crosspost contributions. If your proposal includes a patch, it will receive more attention from the dev team if it is also posted to Mantis or sent through a pull request on GitHub.
    • Expect and be receptive to criticism. If you disagree with your critics, feel free to civilly debate the issue, but overly heated rhetoric or stubborn filibustering is not welcome.
    • Avoid using polls. They rarely provide helpful feedback, and usually encourage discussing the poll itself instead of its contents. DCSS development is not a democratic system, and the game isn't designed by majority rule.
    • The Thank button isn't an "I will do this" button. Don't assume a highly "thanked" post is more likely to get done, or that a dev's "thanks" indicates that they're interested in programming your feature. It's a complicated button.
  • When replying to a GDD thread:
    • Be constructive. Remember that everyone posting on GDD is trying to make Crawl a better game. Excessively personalized or harsh criticism will be removed and may result in sanctions.
    • Offer substantive replies. Use the "Thank" function if you merely agree with the proposal but have nothing to add. Avoid replying if you cannot offer a constructive critique.
    • Focus on the proposal. Replies should be about the core mechanics of proposals, not rhetorical points, semantics, or tangential details. Extended off-topic conversations may be deleted or moved to a more appropriate subforum.
    • Be kind to the newbies. Point them to the advice in the bottom of this post.
    • Don't bikeshed. In the context of DCSS, "bikeshedding" usually refers to spending significant time discussing names and flavor. Unless a thread is specifically dedicated to names or other elements of the game's flavor, please use CYC to discuss these topics.
    • Report, don't escalate. If a post appears to break the rules, use the "Report" button or PM an active moderator rather than replying to the post.
Posts that disregard these guidelines may be deleted, locked, or moved to a different subforum. Repeat offenders may be warned, temporarily banned, or permanently banned from GDD. If you have any questions about these guidelines, contact a moderator for assistance.

Links and Tips for GDD Posters
Spoiler: show
Useful Links:
  • The manual's "Philosophy" section: A brief overview of the game's design goals and principles.
  • The Refused and Rejected Concepts List: Don't propose any of these ideas, because the devs have already dismissed them repeatedly.
  • Changelog: A summary of the changes made in each version, including Trunk. Updated semi-regularly.
  • Cheibriados' Crawl Clone at SZO: Offers another way to look at commits and the source code, including useful search tools.
  • ##crawl-dev logs: The search function is slow, but the logs offer a convenient way to catch up on recent dev discussions about the game.
  • The listgame manual: The complete guide to using !lg, !lm, and other bot commands for Sequell in ##crawl and ##crawl-dev, as well as beem in tileschat.
  • LearnDB: A database of Crawl information maintained on IRC; this web version also includes full monster data. See the documentation for use in ##crawl or search manually using the full text of the database.
  • Objstat: Item and monster generation statistics.
  • Use "site:crawl.develz.org/tavern" in a dedicated search engine to find previous posts if and when the Tavern's search tools fail.
Things to keep in mind when posting on GDD:
  • Proposals are just words until someone codes it. To learn more about coding for Crawl, start with the development documentation and feel free to ask questions in the Coding subforum or on ##crawl-dev.
  • GDD isn't a vote or a census; a proposal's popularity is not a sufficient reason for changing the game. Instead, proposals for significant changes to the game will only be implemented when they align with the design goals of the developers.
  • While good ideas can and do get implemented, even if a proposal is popular and well-thought-through and approved of by developers, someone still has to like it enough to go to the effort of coding it, and Crawl's dev team has a long list of ideas awaiting implementation. Note that pitching in to help implement a proposal is the best way to help changes you like get into the game.
  • Finally, and most simply: no one will read a long proposal. Brevity is infinitely preferable to rambling.

For this message the author archaeo has received thanks: 5
dynast, Hirsch I, njvack, Sar, Tiktacy