Samurai Card Game

A Bevy ECS card game project built from the Codex Project Template.

https://samuelasherrivello.github.io/samurai-card-game/latest/

The static web build is exported and hosted when a GitHub Release is published. Versioned releases live under /releases/<version>/, and /latest/ points at the newest release.

DeckScreen currently owns one deck named Deck 01 with 12 cards. All library cards start in the deck, so the Library starts empty; the Shop tab is visible as an empty state for future work. Card modals support Back, Move To Library, and Move To Deck 01; Transfer Out remains visible but disabled until that feature is specified.

Reusable DeckScreen UI concepts include TopNavigationViewBundle for page navigation and DeckViewBundle for deck tiles rendered from the existing card back asset plus the deck name.

Keep gameplay changes small and spec-driven. Reusable system-level behavior belongs in bevy/crates/shared; card-specific geometry, card models, pointer mapping, smoothing, DebugHUD composition, inspector UI, and view reload behavior belongs in bevy/crates/game. Use bevy/crates/template-crate as the proper reference for Bevy crate folders, representative files, assets, and Rust coding standards.

Keep .github/workflows/export-web-build-to-github-pages.yml as the only GitHub Pages deployment workflow. Do not create a branch-based Pages action; it can fight with this custom export workflow.

Choose one setup option:

The GitHub Actions display names are:

Use GitHub Releases as the publishing boundary. Normal commits do not publish the project. To publish, run the PerformRelease workflow manually.

VERSION.txt is the release source of truth. It stores the public project version without the tag prefix, such as 0.01. Release tags add v, such as v0.01.

The release workflow uses this version style:

Each published release builds the public Bevy web target for GitHub Pages.

If the Pages workflow is run manually, leave the release version input blank to use the current VERSION.txt. Enter a value like v0.01 only when redeploying a specific release folder.

The reusable release web export script is scripts/other/ExportWebRelease.ps1. It calls the standard web build, writes 404.html, and validates the expected web bundle and card type assets before deployment workflows upload the result.

The Pages workflow stores release folders on the pages-releases branch, then deploys them through GitHub Pages Actions. Keep the repository Pages source set to GitHub Actions, not a branch.

The VPS workflow uses deploy.vps.env for public, reusable deployment settings and GitHub repository secrets for private SSH access. The default remote app path is /srv/apps/samurai-card-game, with release folders under /srv/apps/samurai-card-game/releases and a current symlink pointing at the active release.

Public deployment settings:

To make VPS deployments immediately browser-visible, install the shared static app router once on the VPS:

sudo bash scripts/vps/InstallStaticWebRouter.sh <deploy-user>

This installs Nginx, serves /srv/www publicly on HTTP port 80, and lets each project expose its active release through a symlink like /srv/www/samurai-card-game -> /srv/apps/samurai-card-game/current. The public URL for this repo is http://<vps-host>/samurai-card-game/.

Port 80 is public web traffic. Do not place private admin tools, API credentials, wallet files, server notes, or other secrets under /srv/www or deployed app bundles.

For this static Bevy game, DEPLOY_STATIC_PATHS=target/run-app-web/site|/ means the exported web bundle is the only folder packaged for deployment, and it is served at /samurai-card-game/. Additional browser-visible folders can be mapped with comma-separated entries, such as target/docs|/docs/. Do not map server binaries or private files into DEPLOY_STATIC_PATHS.

The VPS deploy publishes three browser URL shapes for public static builds:

Required GitHub repository secrets:

The VPS workflow validates these five secrets and runs a pinned-host-key SSH preflight before installing Rust tooling or building the web bundle. Missing secrets, an invalid port, malformed SSH key material, host key mismatch, connection timeout, or public-key login failure should fail near the start of the job.

The deploy user should only have write access to the configured app directory. If REMOTE_SERVICE_NAME is set, allow that user to restart only that one service with sudo systemctl restart <service>.

Add the secrets in GitHub under Settings > Secrets and variables > Actions > Repository secrets. Use New repository secret once for each name above. Do not put secret values in deploy.vps.env, commit history, issues, pull requests, screenshots, or README text.

Use a dedicated SSH key for this repository deployment. Store the private key content in VPS_SSH_PRIVATE_KEY, and install only the matching public key in the deploy user's authorized_keys file on the VPS. The deploy user should not be a personal admin user.

Create VPS_KNOWN_HOSTS from a trusted terminal after verifying the server identity out of band:

ssh-keyscan -p <ssh-port> <vps-host>

Copy the resulting host key line into the VPS_KNOWN_HOSTS repository secret. Do not replace this with automatic host-key trust in the workflow; the pinned host key helps prevent deploying to an impersonated server.

Public configuration belongs in deploy.vps.env; private access belongs in GitHub repository secrets:

Created by Samuel Asher Rivello.

Provided as-is under MIT License.