https://github.com/r-lyeh/gamebook

:books: A unified game design document convention (CC0, Markdown)
https://github.com/r-lyeh/gamebook

design gamedev

Last synced: 27 days ago
JSON representation

:books: A unified game design document convention (CC0, Markdown)

• Host: GitHub
• URL: https://github.com/r-lyeh/gamebook
• Owner: r-lyeh
• License: cc0-1.0
• Created: 2014-04-13T12:42:45.000Z (over 10 years ago)
• Default Branch: master
• Last Pushed: 2022-05-30T03:13:13.000Z (over 2 years ago)
• Last Synced: 2024-11-02T18:05:21.213Z (about 1 month ago)
• Topics: design, gamedev
• Language: JavaScript
• Homepage:
• Size: 423 KB
• Stars: 30
• Watchers: 6
• Forks: 8
• Open Issues: 1
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

• AwesomeCppGameDev - gamebook

README

        
The gamebook convention

=======================

- The `gamebook` is an unified document where product, players and whole devteam is reflected in chronological order, *from player's point of view*.

## Contents

1. The gamebook has no chapters per se, but may have an optional index.

2. First pages cover anything that happens *before the game is run*: marketing, ads, gamecons, reviews, webs, videos, landing pages, websites, press kits, app-store views, kickstarter, trials, purchases, downloads, installation, dependencies, setup, etc...

3. Middle pages cover anything that happens *until game is over*: menus, login, loading screens, tutorials, levels, stages, rewards, bosses, credits, etc...

4. Final pages cover everything that happens *after game is over*: extensions, dlcs, uninstalling, app-store reviews, blog comments, and regular post-activity once game is finished. Everything that makes a player to reinstall and replay the game applies here too.

## Format

1. Every pair of landscape pages features a stage (inside or outside the game) that the player has *to experiment* (left page), and also how developers are going *to make it possible* (right page).

2. On every *left page* (player's view) there are images, storyboards, hand-drawn sketches, pictures, screenshots, huds, etc... that explain, in *visual language*, what the player has to do/experiment from his/her own point of view. Arrows, bubbles, hand-made annotations, etc are allowed; flows, charts and diagrams are not.

3. On every *right page* (developer's view) there is all required information for the left page to happen: implementation details, required tech, algorithms and code approaches, artwork directions, upcoming difficulties, routes to take, time estimations, budget constraints, what to do, and not to do, etc etc... Any kind of info is allowed as long as it provides valuable information to the team: richtext, urls, mails, comments, text chats, charts, diagrams, flows, source code, external references, etc...

4. Left page is *unaware*, and it does not care, of what it happens or reads *on the right page*.

## Result

Page after page, we uncover the whole game from a very focused player's point of view while we explain all marketing-artwork-design-technical hints/constraints we may have during development. The whole book is read in choronological order, exactly as player would experience our game from the very beginning until the end.

## History

- Revision #3 - Updated to Python 3 (16/May/19) (@NBurley93)

- Revision #2 - English version (04/Feb/15) (@r-lyeh)

- Revision #1 - Initial commit, Spanish version (03/Nov/14) (@r-lyeh)

## License

- CC0 license :) 

- https://creativecommons.org/about/cc0