50 direct answers about the work.

ZombieRidge is CloudRaven's browser-native 3D game prototype lab. It combines three playable zombie-game variants with an authenticated, code-gated room flow, animated characters, and experiments in hand, face, head, touch, keyboard, mouse, and controller input. It is working software, but it is not yet a finished public game platform.

No. ZombieRidge is in private alpha, and no public release date has been announced. The three modes and core room flow are implemented, while real-device, controller, companion-phone, and signed-in multiplayer acceptance still need a final structured human pass before broader access.

The marketing site is public, but game access is being coordinated as a private alpha. The current game flow uses sign-in and code-gated rooms. Prospective players, studios, and partners can request a private walkthrough or discuss an alpha session through CloudRaven rather than assuming open public access.

There is no published player price, paid release, or generally available subscription offer today. Private-alpha access and prototype demonstrations are coordinated directly. Coins, rewards, subscriptions, and commerce surfaces found in the evolving product are prototype features and must not be treated as a finished real-money economy.

Classic Survival is a wave-based defense loop. Zombie Slapper is a first-person close-range mode built around optional hand gestures and slap feedback. Zombie Runner is a continuous escape course where head movement can steer, change pace, jump, and dive. The modes share a product shell but intentionally test different mechanics.

No. Controllerless input is an optional experimental path, not a requirement. Keyboard, mouse, touch, and gamepad fallbacks remain available where the mode supports them. Intentional conventional input briefly takes priority over shared movement or look axes so camera input does not fight the player.

Classic Survival is centered on keyboard and mouse with gamepad support. Zombie Slapper adds browser hand tracking to keyboard, mouse, touch, and gamepad fallbacks. Zombie Runner uses camera-observed face and head movement—not phone motion or gyroscope data—for its controllerless path, with touch, keyboard, and gamepad fallbacks. The modalities are mode-specific, not universally interchangeable.

No. Camera access remains behind the browser's permission gate, although a camera-oriented mode may enable or start its tracker as part of the mode flow. A player can deny or withdraw permission and use a supported fallback. Tracking benefits from good front lighting, and current device coverage is too limited to promise equal quality everywhere.

ZombieRidge is built for a modern WebGL-capable browser. Desktop Chrome is the primary documented multiplayer and controllerless test environment. A comprehensive browser, webcam, GPU, and controller compatibility matrix has not been certified, and the remaining real-hardware acceptance work is one reason the product is still private alpha.

Phone-sized game sessions are routed into the touch-safe Zombie Runner experience; Classic Survival and Zombie Slapper remain desktop-oriented. A same-account iPhone can also act as an optional companion camera for a laptop, desktop, or TV session. The companion path is implemented but still needs broader two-device acceptance.

The current UI has authenticated, code-gated rooms configured for up to four and synchronizes presence, zombies, shots, and combat events. The room flow is not yet a hardened confidentiality boundary and should not carry sensitive information. Zombie Runner remains a local course run, and two-client acceptance is not complete enough for a broad production claim.

The public product page does not require an account. Creating or joining a code-gated room and entering the current audience-facing game flow uses Google sign-in backed by Amazon Cognito. Account data is used to identify the player, manage room access, and retain the profile and related game state described in the privacy policy.

ZombieRidge is not intended for children under 13. It depicts zombie survival and combat, but it does not yet have a published rating from a formal ratings board. Parents, educators, and event organizers should review the private-alpha content directly before treating it as suitable for a particular audience.

Controllerless Game Camp is a proposed hands-on lab built around the ZombieRidge prototype. Attendees would inspect a prepared scaffold, choose one controllerless mechanic, tune or build it with a coding-agent workflow, deploy it on AWS, connect a device or room, and finish with a small live playtest.

No. AWS participation, AWS for Games solution-architecture support, venue, credits, lab accounts, branding, and co-marketing are discussion points only. CloudRaven has proposed a focused AWS-supported pilot, but neither an AWS event nor an AWS endorsement should be represented as confirmed until both organizations approve the details.

The leading concept is a small 2–3 hour hands-on lab rather than a presentation-only meetup. A shorter talk or demonstration is also possible. The first pilot would intentionally constrain audience size, mechanics, infrastructure, and facilitation so the team can validate the format before considering a larger engagement.

The proposed outcome is one focused controllerless mechanic that the attendee has tuned or implemented, deployed, and exercised in a small playtest. The exact starter state, take-home repository, support materials, and post-event access policy are not final and must be defined before registration opens.

The concept is aimed at game developers, designers, technical creators, and AI-assisted builders who want a practical browser-game lab. Required experience, supported laptops and phones, account prerequisites, accessibility accommodations, and instructor-to-attendee ratio still need to be set for a real event.

No. The working ZombieRidge repository is private, and a public workshop scaffold has not been released. Publishing a bounded open-source starter is part of the proposal, not a current capability. Its contents, license, secrets strategy, sample data, and separation from private product code still require review.

The current backend uses AWS Amplify Gen 2, Amazon Cognito, Amplify Data and AWS AppSync, DynamoDB-backed models, Lambda-backed functions, and AppSync Events for companion control frames. Browser rendering, physics, and camera interpretation remain client-side. The exact workshop subset would be narrowed for time, cost, and teaching clarity.

Not in the current backend definition. The repository contains a future plan to store original generated images in S3, but no Amplify Storage or S3 resource is provisioned for the current product path. S3 should therefore be described as a possible next architecture step, not as a live ZombieRidge service.

No. The prototype currently uses an AppSync and Amplify Data coordination model for small, code-gated rooms. Amazon GameLift Servers, or another authoritative-server design, is an explicit evaluation point for higher concurrency, stronger simulation authority, anti-cheat needs, or broader operational scale—not a deployed component today.

That has not been confirmed. Temporary lab accounts, AWS credits, spending limits, cleanup automation, and cost guardrails are items CloudRaven wants to resolve with a prospective host before a pilot. Attendees should not be promised credits or asked to deploy open-ended infrastructure until those controls are documented.

No. There is no confirmed date, venue, registration page, Luma event, partner branding package, or co-marketing plan. Those decisions follow validation of the pilot format and written agreement from the organizations involved. Any current event artwork should be treated as concept material unless it is explicitly approved.

Yes, CloudRaven is open to a working conversation about a private demo, bounded community pilot, technical review, venue support, or a later paid advanced workshop. Scope, fees, responsibilities, branding, intellectual property, participant data, and support expectations would be agreed separately; no standard sponsorship or workshop package is currently published.

ZombieRidge is a working codebase with three game variants, a browser 3D runtime, authenticated room flows, multiplayer models, companion pairing, and deployed AWS resources. Some marketing images are AI-generated concept artwork and are labeled as visualizations; CloudRaven is adding separate gameplay and tracking captures as product evidence. Working software does not mean production readiness, and important acceptance work remains.

No. Controllerless gaming and computer-vision input are not new. ZombieRidge is an applied prototype lab exploring how familiar browser, camera, phone, and cloud components can be combined into approachable mechanics and developer workshops. The claim is about the current implementation and learning format, not invention of the category.

The implemented tracking path processes camera frames locally in the browser or companion phone. Raw camera pixels are not persisted or sent to the game. When the companion path is used, the phone publishes bounded normalized control frames rather than images or video. A separately recorded marketing video is, of course, an intentionally published media asset.

The companion protocol can send compact normalized fields for presence, gestures, movement or look axes, actions such as attack, slap, jump, or dive, and monotonic action sequences used to consume an action once. Those control signals travel through an authenticated AppSync Events channel; they are not raw frames or a camera recording.

No identity-matching feature is implemented. Face and hand tracking are used to derive pose, direction, gestures, and gameplay actions, not to identify a person. That technical purpose does not replace a jurisdiction-specific privacy or biometric-data review before a wider launch or a workshop in a regulated setting.

The product may store sign-in profile information such as display name, email, profile image, and account identifier, plus gameplay and application state including profiles, lobby membership, room presence, rewards, trade records, and progress needed to operate the service. Exact handling is governed by the published ZombieRidge privacy policy.

Yes. Camera access is permission-based, tracking can be stopped, and browser camera permission can be denied or withdrawn. Companion links expire, can be revoked, and fall back to local controls after revocation, heartbeat loss, or stale transport. The current pairing link is short-lived and requires the same signed-in account.

The published privacy policy says CloudRaven does not sell Google user data, use it for advertising, or use it to train generalized AI models. Google-linked data is used for user-facing functions such as authentication, account identification, lobby access, and saved settings, subject to the policy's operational and legal disclosures.

A user can contact the site operator through the published support or CloudRaven contact path to request account or profile data removal. The privacy policy says data is retained as reasonably necessary to operate and secure the service, resolve disputes, and meet legal obligations, then deleted or de-identified when retention is no longer necessary.

No independent security certification or production-security audit is claimed. The implementation uses Cognito, owner-oriented write rules, short-lived hashed companion tokens, and authenticated events, but code-gated rooms and companion channels are not yet hardened confidentiality boundaries. Authorization, observability, rate limits, transactions, and abuse controls need more work before broader access.

Not to the standard of a competitive production game. Parts of the current multiplayer flow use host authority, and some sensitive operations have backend functions and ledgers, but browser clients and AppSync-backed state still carry substantial responsibility. Strong anti-cheat or high-stakes play would require a more authoritative simulation and further security work.

The design preserves conventional fallbacks so controllerless input is not the only path. Keyboard, mouse, touch, and controller options vary by mode, and camera input can be disabled. CloudRaven has not claimed formal accessibility conformance, completed assistive-technology testing, or validated that every mode serves every access need.

MediaPipe-based computer vision derives optional hand and face controls locally. Authenticated, optional image-generation and live-operations briefing requests send their submitted prompt or context to OpenAI-backed functions. Those generative features are separate from the deterministic core rendering, physics, and combat loop; unfinished AI or automation surfaces are not autonomous production systems.

The repository uses Next.js App Router, React, TypeScript, React Three Fiber and Three.js for the 3D scene, Rapier for browser physics, Zustand for central game state, and MediaPipe Tasks Vision for camera tracking. The game is a web application rather than a Unity, Unreal Engine, or native mobile build.

They run in the player's browser. The React Three Fiber scene, Rapier physics, input interpretation, and local presentation stay close to the player. AWS is currently used for identity, durable application and room models, functions, subscriptions, and bounded companion-input transport rather than for streaming rendered frames.

The browser uses a shared MediaPipe tracker in a module worker, then derives stable, bounded game-control fields from detected hand and face landmarks. Slapper assigns movement and action roles to hands; Runner derives steer, pace, nod-jump, and shake-dive from camera-observed head movement, not device motion sensors. Calibration, deadzones, cooldowns, and fallback ownership reduce accidental input.

A signed-in host creates a five-minute link. The backend validates ownership, stores a SHA-256 hash rather than the raw token, and returns the raw token once. A same-account iPhone claims the seat, tracks locally, and publishes normalized frames to an authenticated AppSync Events channel. Expiry, revocation, heartbeat loss, or staleness restores local input; channel isolation and production security review remain open work.

Amplify Data models and AppSync subscriptions coordinate lobbies, members, match sessions, presence, zombies, shot requests, damage, and combat events. The browser sync layer uses state deltas, minimum intervals, and heartbeats instead of writing every render frame. AppSync Events carries normalized companion controls; authorization hardening remains part of the pre-broader-access work.

The current wave multiplayer path gives the host important zombie, route, hit, and combat-resolution responsibilities, while guests submit bounded requests and interpolate shared state. Some value-bearing operations use backend functions and claim ledgers. It is still a prototype authority model, not a fully dedicated server simulation or a transactional game economy.

AppSync and Amplify Data are being used for small authenticated rooms and an inspectable prototype, not claimed as an unlimited real-time game server. Before broader concurrency, high-frequency position and zombie state should move to AppSync Events or a purpose-built transport; stronger simulation authority, anti-cheat, and operations require an authoritative-server evaluation.

That evaluation should happen when small-room coordination is no longer enough—especially for higher concurrency, authoritative physics and combat, competitive integrity, matchmaking, fleet operations, latency control, or predictable session hosting. GameLift is one option named for that boundary, but no migration design or deployment has been completed.

It defines Cognito authentication, Amplify Data models for player profiles, lobbies, room members, match sessions, presence, zombies, combat, rewards, trades, scores, and companion pairing, plus Lambda-backed AI, reward, coin-claim, and pairing operations. AppSync Events provides a Cognito-authorized companion channel namespace.

Static game and marketing assets are served with the web application, while durable application records live in Amplify Data's DynamoDB-backed models. The current backend does not define Amplify Storage or an S3 bucket. A planning document recommends S3 for original generated images later, but that ingestion and persistence path is not implemented.

The documented path installs npm dependencies, configures local environment values and Amplify sandbox secrets, runs the Amplify Gen 2 sandbox to generate backend outputs, and starts the Next.js development server. TypeScript, lint, gameplay checks, production builds, and focused two-client or two-device human tests form the current validation path.

Not today. The working repository is private, no public workshop scaffold has been released, and there is no supported ZombieRidge SDK or stable public gameplay API. Developers interested in review, contribution, or a pilot should contact CloudRaven directly. Existing licensing artifacts also need an audit before any public code distribution or open-source announcement.