Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/titledgames/microwave-man/llms.txt

Use this file to discover all available pages before exploring further.

Microwave Man is open source under the MIT license. Contributions of all kinds are welcome, including bug fixes, gameplay improvements, platform support changes, and documentation updates. This page covers how to set up a working fork, submit changes, and what to expect from the automated review process.

​
Repository

The source code is hosted on GitHub. Anyone can fork the repository and open a pull request. There is no contributor license agreement.

​
Opening an issue

Before opening a pull request for a non-trivial change, open an issue first to describe what you want to fix or add. This lets maintainers give feedback on the approach before you invest time writing code. For bugs, include:
  • Godot version
  • Operating system and export target (if relevant)
  • Steps to reproduce
  • What you expected to happen and what actually happened

​
Pull request process

1

Fork and clone

Fork the repository on GitHub, then clone your fork locally.
git clone https://github.com/YOUR_USERNAME/Microwave-Man.git
cd Microwave-Man
2

Create a branch

Create a branch with a short descriptive name. Use lowercase and hyphens.
git checkout -b fix/coin-collection-sound
3

Make your changes

Open the project in Godot 4.6 and make your changes. See Building the project for environment setup instructions.Commit your changes with a clear message describing what the commit does and why.
git add .
git commit -m "Fix coin sound not playing on fast collection"
4

Push and open a PR

Push your branch to your fork and open a pull request against the main branch of the upstream repository.
git push origin fix/coin-collection-sound
In your pull request description, explain what you changed and reference any related issue numbers with Closes #123 or Fixes #123.

​
Automated code review

The repository uses CodeRabbit for AI-assisted code review. CodeRabbit automatically reviews every pull request and posts inline comments with suggestions, potential issues, and style feedback. You do not need to take action on every comment, but addressing substantive feedback before requesting a human review speeds up the process.
CodeRabbit reviews GDScript, configuration files, and workflow YAML. If a comment is incorrect or does not apply, you can reply to dismiss it, and CodeRabbit will acknowledge the dismissal.

​
Dependency updates

Dependabot is configured via .github/dependabot.yml to automatically open pull requests when dependencies have updates available. These PRs follow the same review process as any other contribution. If you notice a Dependabot PR that conflicts with your work, coordinate with maintainers before merging.

​
Code style

Follow the settings in .editorconfig for all files you touch. Key rules include consistent indentation and line endings. GDScript-specific conventions:
  • Use tabs for indentation (standard for GDScript)
  • Keep scripts focused: each .gd file should correspond to a single scene and handle only that scene’s logic
  • Name signals with past tense verbs (restart_game, not on_restart)
  • Constants should use SCREAMING_SNAKE_CASE
Godot 4.6 is required for development. The project uses features and APIs that are not compatible with Godot 3.x or earlier 4.x releases.

​
What to work on

Check the issues tracker for open issues. Issues labeled good first issue are a reasonable starting point if you are unfamiliar with the codebase.

Project structure

Learn the scene and script layout before diving into the code.

Building the project

Set up Godot 4.6 and run the game locally.

Build docs developers (and LLMs) love

Get started for freeTalk to us