Contributing to OpenGameBuilder

Thank you for your interest in contributing to OpenGameBuilder.

OpenGameBuilder is a community open-source preservation, reimplementation, and extension of MyGameBuilder.com. Contributions are welcome from former MyGameBuilder users and from people who are new to the project.

A contribution does not need to be code to matter.

Project Status

OpenGameBuilder is in active development. Some architecture, APIs, tooling, and workflows may change as the project grows.

The goal is to keep the project easy to build, test, and contribute to, while also being careful with its preservation work and the history of the original MyGameBuilder community.

Ways to Contribute

Useful contributions include:

  • code changes;
  • documentation;
  • bug reports;
  • testing;
  • UI/UX feedback;
  • accessibility feedback;
  • compatibility testing for games;
  • historical knowledge about MyGameBuilder;
  • archival research;
  • issue triage;
  • community support.

If you are unsure where to start, look for issues labeled good first issue, help wanted, or documentation, or issues with the Bug type. The public OpenGameBuilder Roadmap tracks work, including the Triage status; triage is not an issue label.

Before You Start

For small fixes, documentation improvements, typo fixes, straightforward bugs, and focused cleanup, feel free to open a pull request.

For larger changes, follow Significant Changes before implementation. Private Discord access is not required to contribute.

Development Setup

Development setup instructions are maintained in:

docs/setup/development.md

That document covers setting up the project with Visual Studio or VS Code.

The repository is intended to work smoothly from a fresh checkout. If the setup guide does not work for you, please open an issue with your operating system, editor, installed SDK/runtime versions, and the error you encountered.

Repository Standards

The repository's .editorconfig defines formatting rules. Formatting verification is required; Git hooks are optional and run only after you opt in. Follow development setup for the required validation commands and formatting and optional hooks for applying fixes or enabling the pre-commit hook.

Keep changes consistent with the existing style and project boundaries.

Before opening a pull request, please make sure the project builds and tests pass locally when practical. CI/CD also runs tests for pull requests and protected branches.

Issues

Use the issue forms for concrete work: Bug Report for broken behavior, Compatibility Issue for observed differences from MyGameBuilder (also tracked as Bug), Enhancement for improving an existing capability, and Feature Request for a new capability. Use Discussions for questions and proposals that are still exploratory.

When reporting a bug, please include:

  • what happened;
  • what you expected to happen;
  • steps to reproduce the problem;
  • your operating system and browser, if relevant;
  • screenshots, video, logs, or error messages, if useful.

When reporting a compatibility issue with an archived or recreated MyGameBuilder game, please include:

  • the game title or identifier, if it is public;
  • what behavior seems wrong;
  • what the expected behavior is, if known;
  • whether the problem affects one game or many;
  • screenshots or video, if safe and useful.

Do not include passwords, access tokens, private information, or sensitive archival material in public issues.

Pull Requests

Pull requests should be focused and easy to review.

A good pull request usually includes:

  • a clear summary of what changed;
  • why the change was made;
  • any related issue numbers;
  • notes about testing;
  • screenshots or video for visible UI changes;
  • documentation updates when behavior changes.

Large pull requests are harder to review and more likely to stall. When possible, split large work into smaller, meaningful pieces.

Draft pull requests are welcome when you want early feedback.

Significant Changes

Discuss significant changes before implementation. This includes project direction, architecture, game runtime or editor behavior, compatibility, public APIs, data formats, releases, licensing, archival policy, contributor expectations, governance, and community or moderation policy.

Use a GitHub Discussion for exploratory ideas or an issue for a concrete proposal. Describe the problem, intended behavior, and scope so maintainers can agree on the direction before substantial work begins. Record the decision in the issue, discussion, PR, or a lasting document, including how it affects the restoration or presentation of archived games when relevant.

Preservation and Archive Contributions

OpenGameBuilder includes preservation work related to MyGameBuilder games and historical material.

Before adding games, assets, submissions, or test fixtures, follow the short material-intake and creator-request checklist. Implementation tests use independently created fixtures. The application's Apache-2.0 license does not grant rights to original MyGameBuilder material.

Please handle archival material carefully. The existence of archived material does not automatically mean every item should be public, searchable, or restored without context.

Do not post private, sensitive, identifying, or personal information from archived material in public issues, pull requests, comments, screenshots, or documentation.

Archive-related contributions should consider:

  • preservation value;
  • creator attribution;
  • creator requests;
  • privacy;
  • safety;
  • historical context;
  • technical feasibility;
  • long-term maintainability.

Questions or concerns about archived material should be raised with the maintainers. Sensitive concerns should be reported privately rather than through a public issue.

AI-Assisted Contributions

AI-assisted development is allowed and supported in OpenGameBuilder.

Contributors may use AI tools for coding, testing, debugging, documentation, review, learning, and project exploration. Repository-specific guidance lives in AGENTS.md; tools with their own instruction mechanisms may also use their standard configuration when the repository adds one.

AI use does not lower the quality bar. If you submit AI-assisted work, you are responsible for understanding, reviewing, testing, and maintaining it.

Routine AI use does not need to be disclosed. Agent-authored or mostly AI-generated pull requests should mention that AI assistance was used.

Do not use AI tools to copy, translate, port, adapt, or mechanically rewrite decompiled source code from the original MyGameBuilder Flash client or any other proprietary source.

See AI_POLICY.md for the full policy.

Security and Private Reports

Please do not report security vulnerabilities in public issues or discussions.

Report security vulnerabilities through the private security reporting process. For Code of Conduct reports, privacy concerns, or sensitive archival concerns, use the private contact in the organization-wide Code of Conduct.

Community Standards

All contributors are expected to follow the organization-wide Code of Conduct.

Project governance, roles, and decision-making authority are described in the organization-wide governance document.

Licensing

By contributing to OpenGameBuilder, you agree that your contributions may be distributed under the project’s license.

See LICENSE for details.

Edit this page