GiveGigs Aquatic
A detailed guide to Aquatic Agents: its animated task world, exploration, inventions, programmable helpers, local multiplayer, and current boundaries.
GiveGigs Aquatic, presented in the app as Aquatic Agents, is an interactive world where a player can explore a generated landscape, work with a visual task graph, collect materials, make game inventions, configure small automated helpers, and join a locally hosted multiplayer session. Its identity comes from bringing planning into the world: tasks can be represented as a Mermaid graph, while the player explores the surrounding land and water. The game is available at /aquatic/.
Aquatic is an evolving software project rather than a finished simulation of the physical ocean or a general-purpose robot platform. The present game combines deterministic local systems, saved settings, selected AI-assisted features, and multiplayer services with explicit boundaries. This article separates those implemented mechanics from design proposals and future work, because a roadmap description should not be mistaken for a feature already available to players.
The word “Aquatic” describes the setting and visual world, while “Agents” points to the small actors that can follow rules and help carry out bounded in-game work. The broader aim is to make planning tangible. A task graph is a visual representation of work: nodes can stand for steps, and relationships can show dependencies or sequences. Instead of treating that graph as a document that sits outside the experience, Aquatic places it alongside movement, exploration, crafting, and shared play.
The world is also a place for experimentation. Players can test a plan, see how materials and tools behave under the game’s rules, and observe the consequences of automation in a contained setting. The setting borrows the language of ecology, exploration, engineering, and cooperation, but its outcomes are game outcomes. A simulated yield or impact is not a laboratory result, and a virtual blueprint is not a construction plan.
Aquatic is one part of GiveGigs’ collection of work and creativity tools. It can connect ideas about planning and collaboration with the wider GiveGigs environment, including GiveGigs Code and organizational spaces. In a challenge, a lobby may organize participants around a short project and link a submission to a deployed website or other work product. These links let the game serve as a shared starting point for a task rather than a separate island.
The game should still be understood on its own terms. A GiveGigs account or a connected feature does not turn every in-game action into a real-world job, nor does an agent in the world automatically have authority to act on a person’s behalf. Players remain responsible for reviewing AI-generated content, choosing what to share, and deciding whether to save or submit anything. Access, collaboration, and participation depend on the particular feature and its current controls.
Open /aquatic/ in a supported browser and follow the on-screen guidance to enter the world. The game uses a keyboard-focusable canvas and provides spoken control guidance; focus the game area before using its keyboard controls. Settings include game, graphics, camera, and audio options stored on the current device. Exact controls can evolve, so the instructions shown in the current build should take precedence over an older guide.
A new player can begin by moving around and learning the relationship between land, underwater areas, resource pickups, and points of interest. The interface may also present the Mermaid task graph, world or lobby controls, a workbench, and automation tools. Each of these is a separate layer: movement changes the player’s position; graph edits organize a plan; crafting consumes game inventory; and multiplayer controls share a world session under its host’s authority. Start with one activity and learn its save and sharing behavior before combining several systems.
The five landscape themes offer distinct visual and activity contexts. Alpine Taiga suggests snowy high ground, forest, streams, and valleys; Ocean Beach emphasizes a shoreline between dunes, shallows, and deeper water; Glacial Arctic uses a cold, sparse environment; Volcanic Caldera frames play around ash, rock, warm springs, and hazard cues; Summer Glade uses meadow, forest, flowers, and paths. Biome decoration and the professions selected for visitors are seeded, so changing the world seed can produce a different cast.
These are game environments. Their colors and props do not model the full climate, geology, ecological relationships, or safety conditions of the real places they evoke. The human-fauna design proposal describes a broader goal: give people distinct roles and safe routes, have them respond to wildlife without treating people as prey, and make their activities legible through simple interactions. Parts of that proposal are implemented; the document itself lists remaining work such as richer terrain forms, more interactions, reduced-motion controls, and cross-biome checks.
The Mermaid graph is Aquatic’s planning surface. A player can express a project as connected tasks and use the graph to make work easier to inspect, sequence, and discuss. A node can represent a bounded step, while a connection communicates a relationship between steps. A readable graph is useful even when no automated worker is involved: it makes assumptions, dependencies, and unfinished work visible to the people coordinating the project.
Some tools can turn a graph into a task map for a swarm of bounded workers. In that flow, nodes are assigned work and returned notes can inform later steps. A graph is not proof that a plan is correct, and a successful response from one worker does not mean the whole project is complete. People should define acceptance criteria, check evidence, and decide how to handle blocked or ambiguous tasks. In local multiplayer, the host can choose to share the current task map with lobby members; that sharing option is off by default.
Land and water create different movement and exploration spaces. The design combines environmental decoration with resources, animals, and places where human visitors can appear. Aquatic’s ocean theme supplies a memorable frame for exploration, while biome selection broadens the game to forests, ice, volcanic terrain, and meadows. A convincing game ecology depends on more than adding species names: habitat, movement, visibility, interaction rules, and performance all affect whether the world feels coherent.
The fauna proposal outlines a shared seeded depth function for shelves, kelp corridors, open water, caves, and a darker trench; it also proposes explicit diets, habitat constraints, and soft population responses. That document is a design proposal with a partial implementation update, not evidence that every proposed food web or terrain feature is already in the game. When documenting ecology, distinguish visible scenery and currently playable interactions from the planned systems that remain open.
A first in-scene human-fauna slice is implemented. Players can select one of the five biomes, and up to ten emoji visitors move between safe stations on land and the underwater shelf. Their profession pool changes with the biome, they are excluded from predator prey lists, and they retreat to a marked shelter when sharks or predatory marine life approach. Visitor count and biome choice are stored in local game settings.
The larger proposal describes people as researchers, rangers, restoration workers, pilots, visitors, and other roles whose activities fit their surroundings. It proposes safe habitat masks, bounded movement, readable states such as observe, greet, help, warn, and evacuate, and interactions that let people give wildlife space. It also calls for controls over agent count, emoji size, interaction density, ambient motion, and reduced motion. Those broader ideas remain at different stages; consult the implementation-status note in the proposal before describing any one behavior as available.
Players can gather materials and discover resources across the environment. Wood, stone, and coral are used by the current invention workbench, while specialized utility pickups can provide in-game charges. Geothermal vents are represented as natural-gas pickups. Materials also support the bot-pack and construction loops: players can transfer selected resources or a crafted device into a bot’s equipment, and deposited materials can feed scripted building and technology upgrades.
Exploration is tied to practical questions: what can be collected, which tools can use it, how far a bot can operate, and what happens when it runs low on fuel. These are game rules and inventories. A virtual coral pickup is not a recommendation to remove coral from a real reef, and the game’s simplified resource loop is not an ecological or economic forecast. A useful play session can nevertheless make resource dependencies visible: a plan may require gathering, crafting, equipping, and returning before its automation can continue.
The invention workbench is a deterministic local CAD and gameplay prototype. A player gathers wood, stone, and coral, chooses a name and category, and configures a material, shape, dimensions, edge angle, and grip length. Some alloy recipes consume stone and coral. Crafting consumes the required inventory and equips the resulting item. The preview estimates properties including nominal mass, cross-section, bending load, swing energy, buoyancy, corrosion index, harvest yield, projectile speed, pressure, and arena impact.
Those figures are editable game estimates, not validated engineering results, manufacturing instructions, or safety certification. The prototype maps a selection to available game behavior; it does not perform a general physical simulation. Current documented gaps include custom part-by-part geometry, joints, collision testing, material failure simulation, blueprint export, and durable inventory saves outside the supported world snapshot. Players should treat an invention as an in-game object and avoid using its estimates to make real fabrication or safety decisions.
A crafted device or gathered resource units can be transferred into each of four Screeps-style bot packs. Tools influence gathering yield; weapons influence projectile, hitscan, and melee damage; and deposited materials supply scripted building and technology-upgrade actions. Pack transfers are currently described as lasting for the active game session, while durable inventory saves are future work. The multiplayer world snapshot separately supports host-owned saved workshop inventory, equipped blueprint, and four bot equipment, fuel, and control configurations.
This distinction matters when a player returns to a world. Some state is session-local, while selected host world data can persist through a revisioned snapshot. The snapshot schema is validated before it is saved, and joining players load the state from that snapshot. A guide should not promise that all inventory or every transient state item follows the same persistence rule. Check the interface and the current implementation notes for the particular item or action in question.
Aquatic’s bots are game agents that can follow ordered rules to gather, explore, report, defend, build, and respond to conditions. They operate in bounded simulation loops and have limited equipment, fuel, sensors, movement speed, and communication modes. A player can deploy up to four copies under the current BotScript documentation. The system is designed so a rule program can be reviewed and interpreted by the game without granting it arbitrary access to the player’s device or account.
A bot is not a general autonomous agent with unrestricted control of a computer. Its actions are limited to supported conditions and game commands. In multiplayer, the local host runs the bot schedules and resolves guest attack intents, then shares validated state snapshots over the lobby’s private realtime channel. This host authority avoids each guest independently simulating the same bot logic. The documented implementation still has boundaries and should be read as a specific playable automation layer, not unrestricted parity with other sandbox games.
GiveGigs BotScript v1 is a portable JSON format for player bots. It is data rather than Lua, JavaScript, or another general-purpose executable language. A program has a version, a name, and an ordered list of rules. Each rule combines a condition such as enemy.nearby, resource.nearby, unknown.nearby, health.low, or fuel.low with a supported action such as defend, collect, explore, report, or return to base. The first matching rule generally wins, with a documented emergency override for low fuel and return-to-base.
Version 1 accepts at most 24 rules and 8 KiB per program. The game validates commands and runs them in a fixed local simulation loop. Scripts cannot access files, browser APIs, network requests, arbitrary code execution, GiveGigs accounts, or provider credentials. These restrictions are central to the format: a script describes a small set of game decisions, rather than serving as a mechanism for arbitrary computer control. The full project guide is linked in Sources and further reading.
Bots can harvest and collect biome resources, explore eight sectors, report discoveries and inventory, build persistent blocks from inventory, recover grass or coral by terraforming player blocks, and upgrade through Tech Mk 3. The documented bot rules run in Creative, Peaceful, Survival, and Hardcore modes. Weapon actions distinguish traveling foam rounds, instant line-of-sight shots, a close strike, and a close-area blast. The close-area blast takes its bot offline for a rebuild delay.
Combat and movement are simulations, not training for real weapons or wildlife encounters. Player attacks and bot attacks use distinct rules for line of sight, obstruction, armor, impact, recovery, and knockback. The interface provides keyboard and mobile attack controls. These details can change with game development; a current control label is more reliable than a static key list. In peaceful play, the intended experience centers on exploration and building, while harder modes add bounded game danger.
Bots can use guide-by-wire, powered-by-wire, remote radio, satellite relay, or autonomous control. These modes trade range, latency, and susceptibility to spectrum disruption. Wired control has short range but resists jamming; wireless and satellite links extend command range but can be interrupted by abstracted jammer zones unless hardened; autonomous bots continue their scripts. Relay masts extend wireless range. Reserves add fuel capacity, and a refueler can transfer fuel to a nearby stranded bot.
Bots consume one selected fuel unit per 12 active seconds, or 24 seconds when powered by wire, according to the workbench documentation. Four loadouts have configurable sensor radius from 8 to 40 meters, cruise speed from 50 to 200 percent, and return-to-base thresholds from one to four units. A wider sensor radius can improve awareness; faster travel consumes fuel sooner. These are exposed game tuning ranges, not claims about real radio engineering, endurance, or robot safety.
The visual automation builder lets a player compose and reorder rules while keeping the portable JSON source visible and editable. Rule order is meaningful: the first matching rule wins, except for the emergency low-fuel return behavior described in the BotScript guide. Seeing both the visual rules and their serialized form makes it easier to inspect what a bot will do and to share a compact, portable program.
A sensible workflow is to add a protective or return rule, add the main work rule, then add exploration and reporting behavior. The player can review the rule order before starting the bot and check whether fuel, sensors, equipment, and control range match the intended task. A script that is syntactically valid can still express a poor plan. Observe the bot in the world, adjust a rule if it behaves unexpectedly, and keep a human responsible for deciding when an automated run should continue.
Aquatic offers both deterministic automation and an explicit AI-assisted BotScript drafting action. The GG VoidMind starter is the no-model option: its ordered rules run locally and deterministically without a model request or microMoney charge. An AI draft is a separate signed-in action through GiveGigs-managed model service. The response is checked against the expected schema and ranges, then left paused for the player to review. It does not start automatically.
When a request uses GiveGigs-managed provider credentials, the application reserves and settles microMoney (mM) through the shared quota system. A user-provided provider key bypasses the platform model-call charge. Keys must not be exposed, logged, or broadcast. Model-generated content remains a proposal: review the program and its settings before applying or starting it. The local BotScript interpreter itself is deterministic code and does not make a model call. This distinction keeps ordinary gameplay separate from metered AI assistance.
Aquatic lobbies can be public or private and use a local-hosted world. The host’s device maintains the session, so the host must keep the Aquatic page open. Players can browse public lobbies or join a private world through an invitation flow. Private lobbies also check the friends-only requirement; an invite code alone does not bypass that check. A lobby can use a selected biome and may have a shared task graph. Sharing the graph is opt-in and starts off.
The host owns the current world session and its authoritative simulation. In documented bot multiplayer, the host runs schedules, resolves attacks, and publishes validated state to guests. A revisioned world snapshot can preserve selected progress, such as robot state and workshop configuration, for rejoining players. The current app documentation says that lobby membership and challenge records sync, while live player movement and shared code editing still need a realtime/WebRTC delivery step. Cloud-hosted worlds are not available in this implementation. Always read the live lobby panel for current status.
A lobby host can start a one-hour Challenge Mode round. The supported challenge formats include Best HTML Website, AI-assisted unsolved mathematics, and HTML Animated Movie. Participants can work as one cooperating group, as competing teams, or individually. Team assignments are fixed for the round; new lobby members may enter the world but need the host to start another round to compete.
For website and movie formats, the submission flow asks for a public HTTPS URL and checks that the deployment returns a live HTML page. For mathematics, participants submit the problem, reasoning, and evidence; an AI-assisted candidate remains unverified until independently checked as a proof. A participating organization can optionally receive a hackathon announcement linking GiveGigs Code and Aquatic, subject to the forum and membership controls. Challenge records and public showcase status are separate from a claim that every submitted result has been independently validated.
Aquatic provides local game, graphics, camera, and audio settings. The canvas can receive keyboard focus and the game supplies spoken control guidance. The human-fauna proposal identifies additional accessibility work: controls for visitor and wildlife counts, emoji size, interaction density, ambient motion, and a reduced-motion mode, plus screen-reader labels for profession and activity. Some items are a roadmap rather than a current control.
Accessibility is part of whether a world can be used, not a cosmetic finishing step. Controls should be discoverable, visual states should remain legible, and important actions should not require precise timing or color recognition alone. Performance matters too: a world full of animated agents can become difficult to use on modest devices. The proposal suggests pooling sprites, capping agent counts, pausing distant activity, and respecting low-graphics settings. Verify each control in the shipped build before documenting it as implemented.
Aquatic state can live in several places. General game, graphics, camera, and audio preferences are stored on the current device. Lobby world data is owned by the local host, and selected game state is saved through a revisioned world snapshot. Some crafted transfers currently last only for the active session. A host’s snapshot and a player’s browser settings therefore have different owners and lifetimes.
Before relying on progress, check what the particular screen says will be saved and who controls the save. Rejoining a lobby restores documented robot progress, but scripts are left paused until a player reviews and starts them again. This is a deliberate review point for automation. A player should not infer from one successful save that all inventory, graph edits, or temporary session state is durable. Persistence capabilities are feature-specific and can evolve as the game develops.
Aquatic’s bounded systems are designed to constrain what game automation can do. BotScript runs only supported commands inside the game loop. It cannot read local files, access browser APIs, initiate network requests, or use account credentials. A shared task graph is not enabled by default in a lobby, and the invitation controls distinguish private access from public discovery. The host serves as the authority for a local world session.
AI-assisted features have a different data path from deterministic gameplay. A player explicitly requests a draft, and a server-side handler applies authentication, quotas, and validation. Do not place secrets in scripts, graph descriptions, public submissions, or chat. Before sharing a graph or a challenge URL, consider what it reveals. These safeguards describe the design and current contracts; users should follow the visible privacy controls and GiveGigs policies for the latest details.
Aquatic is an active prototype with working systems and known gaps. The workbench does not yet provide general part-by-part assemblies or validated material simulation. BotScript is a small command set, not unrestricted game scripting. Multiplayer is local-hosted, not cloud-hosted; the host must remain online and keep the page open. Shared code editing and live movement delivery are still listed as future realtime work. Some inventories are session-only, and challenge verification depends on the submitted format.
The fauna proposal also lists uncompleted elements, including larger biome-specific terrain forms, all five wildlife food webs, safe-route validation, richer interactions, reduced-motion controls, and fixed-cadence simulation checks. This status is useful context for interpreting product pages and roadmaps: “planned” or “proposed” describes direction, not a released guarantee. The implementation may change, and the in-app interface and current source documentation are the best place to confirm a specific capability.
Treat Aquatic’s outputs as game content. The invention preview’s mass, pressure, strength, buoyancy, damage, and yield figures are not certified engineering data. Bot behavior is a bounded local simulation, not a real robot controller. Biomes and fauna are stylized and should not be used as field guides. An AI-generated rule is a draft that needs human review. A math challenge response is not a proof until its reasoning has been independently verified.
When collaborating, share only information you intend lobby members or challenge reviewers to see. Respect other participants’ work and agree on how a team will make decisions. If an experiment produces an unexpected result, record the configuration and conditions before changing several variables at once. Such habits make it easier to understand game behavior without confusing a virtual result for evidence about the physical world.
The project documents point toward richer terrain, more complete biome identity, safer navigation, additional ecological relationships, custom invention assemblies, collision and material testing, blueprint export, and expanded multiplayer collaboration. The automation roadmap emphasizes understandable rules, bounded actions, reviewable AI drafts, and persistent world state. Accessibility proposals call for reduced motion and better controls over visual density. These directions share a practical goal: make complex systems visible enough that players can understand and influence them.
Future features should preserve clear distinctions between a suggestion, a user-approved change, and an action that has actually run. They should also make saved state and sharing boundaries legible. An article about an evolving game benefits from regular revisions: remove details that are no longer accurate, add links to released controls, and mark proposals with their implementation status. The official project documents in the sources list provide the deeper technical context for the systems described here.
Aquatic Agents: The GiveGigs interactive game world described in this article. Mermaid graph: The visual task graph used to plan and share bounded project steps. Biome: A selectable landscape theme that changes terrain presentation, decoration, and seeded profession pools. BotScript: A validated JSON rules format interpreted by the local game simulation. GG VoidMind: The no-model deterministic starter bot. mM: microMoney, the GiveGigs unit used by its quota system for eligible AI model calls. Local host: The player’s device that maintains a hosted lobby and owns its current world session. Revisioned snapshot: A validated saved version of selected host world data. Proposal: A documented design direction that may be partially implemented or not implemented yet.
Open /aquatic/ to enter the current game. Read the linked BotScript guide for supported conditions, actions, and multiplayer behavior; the invention workbench guide for crafting, estimates, and persistence; and the human-fauna proposal for implemented slice and remaining design work. GiveGigs Wiki pages can be revised as the application changes. When updating this entry, name the version or date of a behavior if it is likely to change, cite the project source that describes it, and identify proposals clearly.
Reading the play interface
Aquatic brings together a 3D play surface and compact controls around it. The toolbar identifies the active mode and exposes common operations: switch between land and water play, ride the drone, place blocks, enable the bot arena, deploy a configured war party, attack when battle mode is active, select a biome, adjust the visitor count, scan for treasure, inspect game-only balances, choose a block, and undo the last placement. Additional controls are conditional. Snow collection and throwing appear in Glacial Arctic; attack buttons and the health display are relevant in combat; the robot workshop and BotScript studio supply configuration controls. The exact text in the current page is the authoritative label for the build being played.
The world overlay reports whether the avatar is swimming, building on land, or piloting the sky drone; the current camera view; controller presence; block count while building; and task-worker progress when agents are present. In combat, it shows hearts and difficulty. Contextual instructions explain the controls for the current movement mode, and selected Mermaid nodes open a detail panel that can be dismissed. Field reports from robots appear in a live log. Status messages describe collected loot, crafting, placement, and related actions. These layers are designed so a player can understand which mode is active before acting.
Keyboard-and-pointer controls
The world canvas accepts keyboard focus and its accessible label summarizes core controls. In water, WASD or the arrow keys steer forward, backward, and sideways; Space rises and Shift dives. Dragging with the pointer changes the look direction. In land mode, WASD walks, Space hops, and Shift crouches. When riding the drone, WASD steers, Space and Shift climb or descend, and dragging changes the view. The on-screen touch pad maps the same forward, strafe, and vertical axes to press-and-hold buttons, releasing on pointer-up or pointer-cancel. A connected game controller can navigate the world; the interface shows whether a controller is detected.
In battle mode, F fires the ranged attack, E makes a quick melee swing, and holding then releasing V charges and releases a heavy swing. The Arctic-only G action throws a collected snowball. The mouse can place a selected block by clicking terrain and remove a placed block with the secondary click; the toolbar’s Undo block control reverses the most recent placement. Touch users get a visible undo action because a secondary click is unavailable. The toolbar also supplies Fire and Light swing buttons and a hold-to-charge heavy attack control for touch and mouse users. Focus the canvas before using keys, and use the visible instruction text if browser or operating-system shortcuts interfere.
Swimming, walking, and the player avatar
Aquatic has distinct swimming and land movement states. Swimming gives vertical control in the water column, while land play moves along traversable island and causeway routes. The player may cross between these environments and explore the terrain around task nodes. The avatar can be inspected up close from the toolbar. The default player appearance is the MattyJacks Tuxedo Chad; optional appearances are a bone skeleton and a gold skeleton. Skeleton appearance exposes a stylized skeletal-form selector, age slider from 18 through 99, and height slider from 145 through 210 centimeters. The UI explicitly describes this as an educational stylized rig, not a medical model or an X-ray-based reconstruction.
Movement and look sensitivity share a multiplier control from 0.5× to 2×. This makes input more or less responsive without changing the world’s geometry. The player can change from third-person to first-person view at any time. Inspection and focus buttons animate the camera toward the player or a selected graph feature, while reset restores the initial framing. The game also reports health as hearts when the selected difficulty uses combat. A defeated player can respawn or dive again; the respawn action restores the current difficulty’s health and advances the game round counter.
The sea-plane drone and evacuation
The sky-piloting mode lets the player ride a small sea-plane-inspired carrier drone above the terrain and water. Valley Mermaid rides in a clear water-filled aqua pod attached to the drone, with a visible lift cable and retrieval rig. In drone mode, horizontal movement follows the camera-relative forward and strafe directions, vertical input changes altitude, and the drone is bounded to the world’s horizontal area and a permitted altitude band above the terrain. The camera follows the rig from behind in third-person view or can be switched to first-person.
“Evacuate to a new lake” animates the drone lowering its retrieval net and bringing Valley aboard, then creates a new conversation lake in the current project set. A lake represents a planning conversation and task graph; moving between lakes preserves a path back to earlier work. This is a metaphorical transition in the application, not a destructive reset of the project. The task context is moved forward through the new lake workflow, and the UI guide explains where to find the previous lake. Evacuation is disabled while another evacuation is active or a WebGL rendering error prevents using the 3D scene.
Mermaid graph syntax and rendering
Aquatic’s 3D task reef accepts a deliberately small Mermaid flowchart grammar. A graph begins with flowchart and a supported direction: TD, TB, LR, RL, or BT. Individual nodes use an identifier beginning with a letter and a label in square brackets, round parentheses, doubled square brackets, or braces. Edges use arrows with an optional label. Comment lines beginning with %% are ignored. The parser does not accept the full Mermaid language: unsupported declarations, styling directives, HTML, arbitrary shape syntax, and complex chained edges can produce a repair message.
Node labels are rendered onto textures with a bounded number of visible text rows so the 3D scene remains legible. Nodes become reef objects connected by visible relationships; shapes provide a simple visual distinction between ordinary work and decision-like nodes. Clicking a node selects it and displays its identifier and full label in an accessible status panel. If WebGL cannot render, a two-dimensional SVG fallback shows the graph. If the source graph is malformed, the page reports that it needs repair and can expose a repair-in-progress state. The map is both a planning artifact and a navigable visual environment, but its layout is a view of the graph, not an execution engine by itself.
Fish workers and task progress
When a Mermaid worker swarm is associated with the graph, fish-like agents provide a visible status for task nodes. A worker can be pending, working, complete, failed, or blocked. The toolbar and 3D scene report the completed count and percentage; a glow can draw attention to a completed worker. A node’s graph identity maps to its fish so progress remains attached to the matching step. On completion, an agent may send a data courier toward an active recipient fish or the repository area. The courier is a visual event representing a result handoff. A task label and dependency notes help describe what was delivered.
The metaphor does not change the worker’s authority. Each swarm worker receives one assigned step, relevant completed dependency notes, and bounded context. It returns a concise draft note; it does not edit files or perform an external action. A completed status means the worker returned a response, not that a human accepted the work or that the real-world task is done. Failed prerequisite tasks block dependent tasks. The player should inspect notes, verify claims, and update the graph when assumptions change.
World seeds, graph size, and generated layout
The Three.js scene uses the graph and game settings to determine important dimensions and positions. Seeded values help place selected environmental details consistently for a given graph and context. The graph itself gives the reef its node count, labels, and connectivity, and the world presents the plan as a series of physical landmarks under the waterline. Terrain and spawn positions use bounded formulas so the player and agents have room to move. A seeded choice can make a layout repeatable without guaranteeing that every animation frame, multiplayer pose, or browser rendering will be byte-for-byte identical.
The world is not an infinite ocean. The scene has finite bounds; swimming and drone navigation are clamped, and land walking is constrained to safe routes. Some points of interest sit around a central island or near the perimeter. Objects that leave a valid play area may be returned to their home position or hidden until a respawn timer elapses. In a lobby, the host’s seed and biome are part of the shared world configuration, while device graphics and camera preferences remain local. These distinct scopes matter when comparing two players’ views.
Reef geometry, water, and atmosphere
The scene combines a waterline, seafloor, reef or island terrain, vegetation and rock-like decoration, labeled task nodes, resources, fauna, player-built blocks, and atmospheric effects. The ocean shader changes how the surface looks from above and below water. Underwater fog and surface fog respond to camera position. A sun-shaft effect is adjusted for whether the camera is submerged. Bubbles rise through the water column; the selected graphics preset changes the number, from a small handful at minimum quality to a dense field in Cinematic mode. Small emoji sprites stand in for many animals and props, keeping the scene visually expressive while avoiding the cost of a fully modeled creature for every ambient actor.
Water clarity is an editable visual parameter ranging from 0.002 to 0.012. The UI describes the extremes as crystal and hazy, with a middle clear state. Changing clarity affects visibility and atmosphere, not the underlying resource count or a scientific measure of water quality. The ambient sound is procedurally generated ocean hush. Browser audio is only started after the player asks for sound, and volume has a bounded control. Palette, fog, camera, shader effects, and decorative particles together define the look of the dive.
Graphics presets and performance
The graphics selector offers Potato, Low, Balanced, High, Ultra, and Cinematic. Potato trims resolution and scene detail; it is intended for a minimum rendering load. Cinematic enables screen-space ambient occlusion, bloom, and volumetric light shafts. The game explicitly notes that browser WebGL does not provide hardware ray tracing through this setting. Other presets change the number of bubbles, ambient creatures, decoration, and some visual effects. The marine-life density slider ranges from 40% to 150% and scales how many decorative fish and land creatures are instantiated, subject to the preset’s minimums and maximum counts.
These settings control presentation and local performance. Lower visual density does not necessarily change the logical graph, workshop data, or hosted world snapshot. The player can adjust them to suit hardware, temperature, battery life, comfort, or preference. Because the scene contains a continuously animated 3D renderer, practical frame rate also depends on browser, device, GPU, window size, and other open workloads. If WebGL initialization fails, the application shows an error and a simpler diagram fallback where supported. Graphics changes are stored in browser settings on the current device.
Palettes, field of view, and camera
Three reef color palettes are available: Lagoon, Moonlit, and Coral. They adjust the overall color treatment of the environment. Field of view ranges from 45° to 100°, changing how much of the scene fits in a view. Third-person follow distance ranges from 4 to 14 units, and the default is seven. These controls work alongside first-person and third-person mode, look sensitivity, zoom in, zoom out, and reset. Focusing or inspecting the avatar gives a closer view; following the player keeps navigation centered.
Camera values affect presentation and comfort rather than the map itself. A wide field of view can make more of a scene visible while changing perspective near the edges; a narrower one can feel more zoomed. Follow distance can change how much of the avatar and nearby terrain are visible. In a 3D graph, zoom and orbit controls can help inspect distant nodes or crowded connections. Controller input, touch movement, and pointer dragging may feel different, so the settings let players tune the view to their device. These values are validated when loaded from local storage, so malformed or out-of-range saved settings are ignored.
Local preferences and browser storage
Aquatic stores validated preferences in browser local storage under a versioned key. Saved settings include view mode, difficulty, graphics quality, color palette, biome, sensitivity, marine-life density, visitor count, clarity, field of view, camera distance, ambient volume, avatar appearance, skeleton settings, and whether the metal detector is active. Individual world keys are used for several local gameplay collections, including placed blocks, Arctic snowballs, and the agent-loot ledger. A browser that blocks storage or runs out of space can still allow a temporary visit, but changes may not persist across reloads.
These records are tied to the browser/device unless a feature explicitly uses account storage or a lobby snapshot. Clearing site data removes local preferences and collections. Local storage is not a cloud save, shared multiplayer channel, or secure vault for secrets. The app validates basic types, ranges, lengths, and counts before trusting saved values. If a saved object is invalid, the game falls back to safe defaults instead of loading it as executable instructions. Keep provider keys and other credentials out of local game fields, task labels, scripts, and public challenge entries.
Biome reference: all five landscapes
Alpine Taiga uses evergreen trees, snow and forest-edge props; its visitor pool includes a field biologist, park ranger, climber, forestry worker, and fisher. Land fauna include moose, deer, foxes, bears, rabbits, and owls. Ocean Beach uses palms, coral, and shells; visitors include a marine biologist, safety diver, lifeguard, surfer, and coast caretaker. Beach fauna include crabs, turtles, seals, lizards, eagles, and doves. Glacial Arctic uses ice, snow, conifers, and a penguin decoration; visitors include a climate researcher, expedition guide, rescue guide, community fisher, and field medic. Arctic fauna include seals, penguins, polar bears, foxes, seabirds, and eagles.
Volcanic Caldera uses volcanoes, rock, and warm-spring symbols; visitors include a volcanologist, geologist, rescue crew, sensor technician, and landscape observer. Its land fauna include lizards, bats, eagles, beetles, and butterflies. Summer Glade uses deciduous trees, flowers, butterflies, sunflowers, and bees; visitors include a community gardener, ecologist, cyclist, picnic visitor, and ranger. Its land fauna include deer, rabbits, foxes, frogs, butterflies, and bees. These names and roles are game presentation. The seed chooses variation from the relevant pool; the displayed profession and emoji are lightweight sprites, not a detailed human character simulation.
Marine-life catalog
The underwater sprite catalog includes shrimp, several small-fish looks, pufferfish, crabs, shells, jellyfish, squid, dolphins, seals, turtles, and octopuses. The internal roles are prey, predator, or ambient. Reef prey include shrimp and small fish that are described as feeding on algae or plankton. Kelp habitat includes fish and shrimp. Ambient bottom dwellers include crabs and shells, with detritus or algae in their simple diet labels; jellyfish occupy midwater; turtles are ambient reef visitors. Predators include squid in midwater, dolphins and seals in open water, and octopuses near the bottom. Their abbreviated in-game diets name small fish, larger fish, fish, crabs, or combinations.
These roles drive simple behaviors and visual movement rather than a complete ecological model. Creatures have home positions, headings, fear values, respawn timing, a role, habitat, speed, and diet label. Small prey may flee, predators can pursue eligible targets, and ambient species move through their assigned area. The implementation contains repeated display entries to produce the target population; this is not a species census. It uses emoji sprites and approximated habitat bands. The fauna proposal’s richer food-web interactions and continuous population dynamics should be considered planned work unless specifically present in the current build.
Land-fauna reference by biome
The first six entries of each biome’s species pool determine which small land-fauna sprites can appear, subject to graphics quality and the life-density slider. Taiga entries are moose and deer (prey), fox and bear (predators), rabbit (prey), and owl (ambient flying fauna). Beach entries are crab (ambient), turtle (prey), seal (ambient), lizard (prey), eagle (flying predator), and dove (ambient flyer). Arctic entries are seal and penguin (prey), polar bear (predator), fox (prey in this simple roster), a seabird (ambient flyer), and an eagle (flying predator).
Caldera entries include lizards (prey), bats (ambient flyers), eagles (flying predators), beetles (ambient), and butterflies (ambient flyers). Glade entries include deer and rabbits (prey), foxes (predators), frogs (ambient), butterflies (ambient flyers), and bees (ambient flyers). The role field is an in-game behavior category, not a statement about the actual species’ ecology. Sprite locations are seeded near biome-dependent land routes and may fly above them. The game’s paths and species are stylized, and the roster changes if graphics settings cap the number of sprites. For precise physical animal behavior, consult wildlife sources rather than using this game table.
Visitor professions by biome
The visitor slider lets the player choose zero through ten human visitors. Zero hides visitors; other values show randomized roles from the selected biome. In Taiga, the five available roles are field biologist, park ranger, climber, forestry worker, and fisher. At the Beach they are marine biologist, safety diver, lifeguard, surfer, and coast caretaker. In the Arctic they are climate researcher, expedition guide, rescue guide, community fisher, and field medic. In the Caldera they are volcanologist, geologist, rescue crew, sensor technician, and landscape observer. In the Glade they are community gardener, ecologist, trail cyclist, picnic visitor, and park ranger.
Each visitor spec also contains an emoji and a short activity, such as checking a trail, watching a safe swimming zone, following a beacon, reading a sensor, recording frog calls, or tending a pollinator patch. Visitors are lightweight, seeded actors with home and shelter positions, movement phase, and speed. The implemented slice gives them safe stations and makes them retreat when a nearby predator approaches; people are not part of the predator prey list. A fuller state machine and richer profession-specific tasks are described by the proposal, not guaranteed by the current implementation.
Human and wildlife behavior boundaries
Aquatic intentionally distinguishes people from ordinary prey and predator agents. Visitors use a bounded set of positions and retreat toward a marked shelter when sharks or other predatory marine life approach. Their displayed work is ambient, low-detail activity. They are not intended as targets in the basic ecology loop. This rule supports a nonviolent presentation of field work and keeps the world’s human characters separate from its animal combat systems.
The design proposal would give each person a stable profession identifier, biome affinity, habitat layer, preferred spawn zone, movement speed, awareness distance, work schedule, and interaction tags. It describes actions such as idle, walk, observe, work, greet, help, warn, and evacuate, along with routes constrained by safe ground and shelters. It proposes interaction cues, respectful distances, reduced-motion controls, and additional simulation validation. The proposal explicitly leaves work open, including larger terrain forms, all five wildlife food webs, route validation, richer human interactions, reduced motion, and fixed-cadence simulation. Do not describe every proposed capability as shipping today.
Creative, Peaceful, Survival, and Hardcore
Aquatic offers four difficulty choices. Creative and Peaceful are safe modes in which no shark attacks occur. Survival has three hearts and two sharks in the scene. Hardcore begins with one heart and four sharks; the UI describes it as one life. A player who loses all health can respawn through the visible control, which restores the mode’s maximum health and advances a round counter. Changing difficulty resets health to the selected mode’s starting amount: one for Hardcore and three for the other modes.
The safe-mode indicator says “Peaceful waters” and explains that marine life is friendly and shark attacks do not occur. Survival and Hardcore show hunting-shark guidance. Difficulty controls the threat layer, while visual life density and graphics are separate settings. Combat is a game mechanic with readable enemy movement, health, attack effects, and respawn; it is not a depiction of recommended behavior around real sharks or other wildlife. A player can use Creative or Peaceful to explore, build, and study the scene without the shark pressure of the harder modes.
Sharks, hazards, and player health
Shark count is mode-based: zero in Creative and Peaceful, two in Survival, and four in Hardcore. Sharks move through the water and can hunt the player in the harder modes. They carry simulation data for health, armor, hit mass, hit-stop, knockback, last-hit time, and respawn delay. On a successful attack, health changes and a visual response communicates damage. Threat movement and retreat create a gameplay hazard while keeping the safe modes available for players who want to explore without combat.
The Caldera theme includes volcano, rock, and hot-spring imagery, but hazard props do not form a physical emergency simulator. Likewise, the Arctic snowball mechanic is a playful, low-stakes interaction rather than a combat substitute. If the player runs out of health underwater, Dive again or Respawn restores health according to the selected difficulty. The surrounding UI reports hearts accessibly and updates live. Difficulty, player health, and enemy population are separate state variables; an ambient creature count change should not be interpreted as changing the difficulty setting.
Battle mode, aim, and attack selection
The Play bots control activates the bot arena mode and exposes player combat controls. Fire uses F or the button and follows the camera’s aim line. Shots stop at world obstructions and use tracers, high projectile speed, armor penetration, impact stun, and physical knockback. The aim line does not magnetically snap to the nearest target. A light melee swing uses E or its button. Heavy melee charges while V is held and swings on release; a charge shorter than 0.16 seconds cancels, so tapping V does not emit a weak heavy attack. Mobile users use the corresponding tap and hold controls.
Melee checks a forward arc and obstruction, then calculates reach, cleave falloff, target hit mass, armor, weapon penetration, stagger, recoil, hit-stop, and recovery time. Ranged attacks and close attacks use different impacts. These separate rules help give the player and bots readable roles in the arena. Battle mode is an optional activity, not required for swimming, collecting resources, graph exploration, or biome viewing. The controls are hidden when the arena is off, reducing clutter during quiet play.
Weapon actions and impact model
Player-crafted weapons can be manual or utility powered. The design distinguishes traveling projectile weapons from hitscan shots and close-range melee. The workbench’s air-injector mode is a close-range bubble-impact effect for a spear or knife concept, not a long-range air rifle. The game has four distinct bot attack actions: projectile, hitscan, melee, and self-destruct. Projectiles travel through the world; hitscan applies an immediate line-of-sight shot; melee uses a close attack arc; and self-destruct damages nearby targets, then disables that bot for a rebuild delay. Obstructions and cover affect attacks.
The shared combat-physics module uses a bounded estimate. Melee impact is influenced by crafted mass, swing energy, base damage, armor penetration, charge, weapon length, target mass and armor, hit index, and shape. A charged hit increases its power and recovery burden. Axes and hammers can cleave more targets than a spear or drill; shields and plates can hit a smaller group. Projectiles consider damage, armor, penetration, and velocity. All values are game tuning constants. They are not measurements for real products, combat advice, or a validated physical simulation.
Arctic snowflakes and snowballs
Glacial Arctic enables a small snowball loop. Snowflakes can be collected by walking close to them. The player sees a snowball count, and G or a button throws one when inventory is available. At open water, a thrown snowball splashes and dissolves. The count and current world key are stored in browser local storage, so it is a local game collection. This interaction provides a biome-specific object that can be picked up and used without changing the core project graph or crafting inventory.
Snowballs are distinct from workshop materials and bot ammunition. They do not become wood, stone, coral, compressed air, electricity, or gas. The number shown in the toolbar is the current usable stock. A disabled button indicates there is no snowball available. Switching biomes changes the scenery and makes the Arctic-only control disappear. The snowy props and snowball behavior are stylized gameplay; they do not simulate snow chemistry, packability, weather risk, or cold exposure.
Gathering resources and harvest timing
Three workshop construction materials are gathered in the world: wood, stone, and coral. Utility pickups can supply compressed air, electricity, and natural gas. The natural-gas representation is geothermal vent pickup; these are abstract game items, not instructions to collect fuel. A player approaches a visible gatherable object, and the callback adds a bounded amount to the relevant workshop inventory. If a tool is equipped, its harvest-yield estimate can affect the collected amount; human Emerald gem bonuses can also increase gathering within their cap.
Resources can disappear when collected and return after a cooldown. Their sprite may bob while available. A collection action is range-limited; standing near the resource can be enough to collect it without a separate inventory menu. Gathered materials support invention costs, bot equipment, fuel, and building plans. If a player lacks enough of any required ingredient, crafting reports that more material is needed and leaves the design uncrossed. Inventory quantities are part of game state. They should be treated as finite within a session or snapshot according to the relevant save feature.
Seabed treasure and metal detector
The metal detector button toggles a scan for buried pirate flags on the seabed. The interface calls out the 🏴☠️ flag search, and shells can conceal gems. A treasure key ensures the same cache is not awarded repeatedly within a world ledger. When a cache is found, the game records the gem type and quantity, updates the treasure notice, and refreshes the displayed human-gem totals. The detector state itself is stored in local settings, while opened treasure keys and balances live in a separate per-world loot ledger.
Treasure is a game reward system and is unrelated to commerce or real-world currency. The search is deterministic for a given generated context and cache key; it is not a map of actual shipwrecks or valuable objects. Shell sprites are both scenery and clues. The detector’s scanning state helps communicate the player’s current mode, and the status message reports whether a gem haul was recovered or the search returned no gems. Game balances do not convert to dollars, platform credits, or microMoney.
Agent coins, human gems, and loot bags
Aquatic shows separate visual balances for agent coins, human gems, and loot bags. A completed agent task can issue a bounded coin packet to an agent data courier and award a human gem chosen from the task label. Launch, release, final, milestone, breakthrough, and critical language map to a white diamond; harvest, resource, ecology, wildlife, plant, and garden language map to an emerald; combat, weapon, defend, or attack language maps to a ruby; share, message, sync, data, communication, coordinate, research, knowledge, and agent language map to amethyst; other labels default to blue sapphire. The mapping is keyword-based and game-only.
A human gem can influence a limited game modifier: Emerald improves human resource gathering by 10% each, Ruby improves human combat damage by 8% each, and Amethyst speeds agent couriers by 15% each, up to three of each. White diamonds are rarer and add 20% to each human-gem effect, capped at five diamonds for the multiplier. Blue sapphires fill the basic human-currency pool. Loot bags are computed from the lesser of agent coins and total human gems in groups of three. The UI explains that these are game-only balances, separate from GiveGigs microMoney and API quotas. No in-game item is a payment balance.
Data couriers and delivery flow
When an agent fish reaches a completed state and the world’s loot ledger is ready, the scene may create a courier to carry its result toward a receiving fish or the repository marker. The courier uses the associated task label to select a human gem and the result’s UTF-8 payload size to determine an in-game coin packet, bounded between one and twelve coins. A receiver can be another active fish that is working or complete; otherwise the courier heads to the repository. The receiver briefly flashes and grows when the delivery arrives. In colder northern positions the courier uses a forward walking style; elsewhere it uses a sideways style.
The visual reward is distinct from the worker output itself and from any platform quota. Repeated delivery is prevented with a world-and-task reward key. The local ledger retains a bounded history of rewarded task keys and opened treasure keys, keeping each event from granting duplicate rewards. If storage is not available, loot remains usable for the current visit but may not persist after leaving. The courier animation is a playful visualization of an agent passing useful data; it is not evidence of data being published to a public repository or external service.
Block building, removal, and limits
Block building can be toggled independently from combat. Choose grass, stone, wood, glass, or coral, then click a permitted point on land or the seabed to place a block. A right-click breaks a placed block; the undo button removes the last placement. The UI shows current placements out of a maximum of 300. Touch users use Undo because touchscreens do not provide a right-click gesture. The implementation checks block data for integer coordinates and an allowed material before restoring saved placements. Terrain interactions can therefore be bounded to a manageable local collection rather than an unbounded voxel world.
Selected material may be chosen directly from the toolbar or from a crafted material invention. Blocks can provide landmarks, platforms, cover, or structures in the local game. Robots may build from their own carried inventory, while the player’s placed-block list is a different state collection. In multiplayer, host-owned shared blocks can be saved through the world snapshot path; local single-player blocks use a world-specific browser record. Removing a block is reversible with the appropriate undo only while it remains the latest action. A visually placed coral block is not a real coral fragment and should not be used as ecological guidance.
Block material reference
The player’s build palette has five options. Grass supplies a green, land-like block. Stone is a gray solid block. Wood is a brown solid block. Glass is a blue-toned block. Coral uses a reef-themed material. These build types are not identical to all world material categories: lava, water, gems, spawn markers, and goals exist in a separate generic GiveGigs world-builder schema, but the Aquatic in-scene toolbar currently exposes only grass, stone, wood, glass, and coral for placement. The different schema should not be mistaken for a second in-game Aquatic palette.
In-world edits are intended to be bounded and quick. The player chooses one active material, clicks to add one block, and can undo or remove blocks as needed. Placed blocks can influence movement and simple obstruction. Robots can use their material inventory to build, terraform, or create cover under their rule set. A block operation should remain within the supported play area and the placement cap. Build mode is a toggle, and its current state is visible in the toolbar and HUD. If the user is focused on moving rather than building, turn building off to avoid accidental placements.
Invention categories and design fields
The workbench offers three categories: tool, weapon, and material. A design has a name, a material, a shape, a power source, a weapon mode, length, head width, thickness, edge angle, and grip ratio. Materials are wood, stone, coral, or alloy. Shapes are axe, hammer, spear, drill, shield, and plate. Power is manual/kinetic, compressed air, electricity, or geothermal gas. Weapon action is either a ranged projectile or a close air-injector effect; selecting the air-injector automatically requires compressed air. The name is limited to 40 characters and each numeric field has a bounded range enforced by the world-save schema.
The initial workshop inventory is three wood, three stone, two coral, and no utility charges. Players can gather supplies before crafting. The default blueprint is “Reefline Field Tool,” a manual wooden axe-like tool with a 72 cm length, 14 cm head width, 4 cm thickness, 24° edge angle, and 0.72 UI grip ratio. The measured model clamps some internal values to its own design rules. The screen presents a dimensioned orthographic SVG sketch that updates with the shape and dimensions. This is a configurable game concept, not CAD suitable for fabrication.
Workshop shape reference
The six shapes provide different game profiles. An axe and hammer support heavier swing behavior and can cleave several targets; an axe presents a cutting edge and a hammer a striking head. A spear extends reach and supports a pointed profile. A drill has a visibly marked tip and a specialized shape factor. A shield represents a broad defensive or plate-like device, and a plate provides a flat material profile that can also support a larger contact area. Shape is one input to the estimated cross-section, volume, joint factor, swing speed, attack behavior, and preview drawing.
The shape list is an enum, not a user-defined mesh editor. The workbench does not yet provide multi-part assemblies, joints, general collision testing, stress fields, or exportable manufacturing blueprints. A “shield” field in the design model does not promise that every category can be used as armor in every mode; actual interaction depends on category and supported game code. The simple sketch helps compare broad dimensions and silhouettes. Its visual symmetry and dimensions are approximate and should not be treated as tolerances for real construction.
Workshop materials, alloys, and costs
The design estimates use internal constants for wood, stone, coral, and a stone-plus-coral alloy. In the model, each material has a density, strength, and corrosion factor. A shape and its dimensions are converted into a simple shaft and head volume; that volume is multiplied by the selected density to estimate mass. Material strength and the shape’s joint factor influence a nominal bending load. Alloy recipes require both stone and coral, while a non-alloy design consumes its chosen base material. A powered weapon also consumes two units of the selected utility in the cost preview.
These costs affect whether a craft button is enabled. Crafting checks the relevant supplies, subtracts the cost, creates a device record, and equips it. Tool, weapon, and material slots are distinct when transferring equipment to bots, so each bot can hold one device per category. The utility names correspond to compressed air, electricity, and natural gas. A gas pickup is styled as geothermal. Inventory and cost values describe a balancing model for a game loop. They do not represent market prices, resource extraction quantities, or physical manufacturing estimates.
Workshop properties and their limits
The preview calculates nominal mass, cross-section, bending load, swing energy, buoyancy force, corrosion resistance, harvest yield, attack damage, armor penetration, projectile velocity, operating pressure, and material costs. Length, head width, thickness, grip length, selected material constants, shape, edge angle, and power source all contribute. Attack damage and harvest yield are clamped to small game ranges. Power source affects projectile speed and compressed-air pressure; electricity and natural gas add different velocity increments in the game formula.
These outputs are useful for seeing how one slider or material changes a virtual design, and they make tradeoffs visible to the player. They are simplified estimates from a deterministic formula, not validated engineering or scientific conclusions. The workbench documentation explicitly cautions against fabrication use or safety claims. Real-world materials vary, and dimensions, joins, loads, corrosion, buoyancy, and operator ergonomics require qualified analysis and testing. An AI design rationale is also not certification.
AI co-design and design briefs
The workbench has two AI-adjacent pathways. Copy AI design brief places the current design, measured game properties, and available inventory in a brief that a player can paste into an assistant they choose. It remains available without a GiveGigs model call. AI co-design sends the design through a signed-in server route to refine the blueprint. The route validates category, material, shape, power source, weapon mode, dimensions, and other enumerated fields; it asks for a short rationale and up to four relevant failure modes. The revised design is checked against the schema before the client applies it.
The AI route uses the platform’s AI quota policy when GiveGigs-managed credentials are used, and the UI reports the mM charge and tokens. The model is instructed to stay within game ranges and avoid fabrication instructions or safety certification. A returned blueprint is still a proposal to review. The UI states when review is in progress, displays notes when returned, and leaves the existing blueprint unchanged if the request fails. Do not treat a model’s plausible-sounding failure-mode list as a validated hazard analysis.
Bot equipment slots and transfers
Aquatic exposes four bot packs. Each has one tool, one weapon, and one material-device slot; selected crafted equipment can be given to a compatible empty slot. A tool can change gathering yield, and a weapon affects projectile, hitscan, and melee damage. A material device can influence bot construction or upgrades in supported paths. If the selected category’s slot is already occupied, the transfer button is disabled. The crafting inventory and each bot’s carried materials are shown separately. Players can transfer one unit at a time from wood, stone, coral, compressed air, electricity, or natural gas, subject to available inventory and bot fuel capacity.
Device and supply transfer currently lasts for the active game session according to the workbench documentation, while an authenticated host snapshot supports durable copies of the workshop inventory, equipped blueprint, and bot equipment/fuel/control configuration. Robot runtime state can also be captured as validated coordinates, orientation, activity, action, material inventory, power inventory, discoveries, and technology level. The difference between equipment configuration and transient interaction matters when rejoining: a saved tool list does not imply that every animation, target, or script state is resumed.
Bot fuel, reserve, and refueling
Each bot selects one fuel supply type from compressed air, electricity, and natural gas. The fuel status shows current charge and capacity; a stranded label appears when a bot can no longer operate. By default the capacities and starting supplies depend on the bot runtime setup. The bot consumes one chosen fuel unit every 12 active seconds, or every 24 seconds when powered by wire, as described by the invention workbench notes. Increasing cruise speed can make travel use fuel sooner. The return-at control sets the low-fuel threshold from one to four units.
A reserve attachment costs game materials and adds eight units of reserve capacity, with a validated upper limit of 80. A refueler can transfer fuel to a nearby stranded bot. The player can donate the selected fuel type one unit at a time from inventory, unless the bot is already at capacity. Bots that run low can follow the explicit fuel.low / return_to_base rule, an emergency override that is prioritized by the local interpreter. These systems make logistics part of planning: range, payload, speed, and reserve are tradeoffs. Fuel values are not comparable to a real battery or engine’s energy density.
Bot networks, range, and countermeasures
A bot can use guide-by-wire, powered-by-wire, remote radio, satellite relay, or autonomous control. Wire links resist abstract spectrum jamming but have short range. Powered wire also extends the time between fuel consumption. Remote and satellite links provide longer reach and simulated latency, but jammer zones can interrupt control. A spectrum shield hardens a bot against this disruption; a relay mast extends wireless range. Autonomous bots continue to follow their script when the player cannot directly command them.
Battle-arena spectrum pylons create jammer zones and EMP pulses. These are abstract gameplay effects, not a real radio-frequency model. Hardened links and autonomous control have different responses by design. Relay, shield, reserve, and refueler each consume inventory during installation and appear as installed/not installed states in the bot pack panel. Network mode is independent from the BotScript language: the script specifies decisions; the control mode changes how direct control and communication behave. The panel notes signal-jam vulnerability, extended range, and whether a refueler is present so the player can understand the configuration.
Bot sensor radius and cruise speed
Each of the four bots has adjustable sensor range, cruise speed, and return threshold. Sensor radius runs from 8 to 40 meters in whole-meter increments. It affects awareness of nearby resources and enemies and can also influence discovery of unknown areas. Cruise speed ranges from 50% to 200% in five-point increments. Faster movement can complete a route sooner but burns fuel sooner. Return-to-base threshold ranges from one to four units, allowing a player to reserve more fuel for the trip home. The default values are a sensor radius of 18 meters, 100% speed, and a return threshold of one unit.
These values are hardware-tuning suggestions for the simulated bot, not a change to the player’s swimming speed or the bot’s rule syntax. An AI draft may suggest tuning alongside the BotScript, but the player must explicitly apply it. Tuning and validated programs are part of the host-owned saved world snapshot, so joining players can see the host’s configuration after a revision. A well-designed mission should account for the sensor radius, route length, chosen link mode, payload, and fuel reserve before deploying multiple copies.
BotScript conditions and actions
BotScript v1 allows six conditions: always, enemy.nearby, resource.nearby, unknown.nearby, health.low, and fuel.low. Its thirteen action values are defend, projectile, hitscan, melee, self_destruct, harvest, collect, build, terraform, upgrade, explore, return_to_base, and report. A rule can include an allowed material (grass, stone, wood, glass, coral) and an optional radius between 1 and 64. The JSON object requires version 1, a non-empty name of at most 32 characters, and one to 24 rules. The UTF-8 source is limited to 8,192 bytes.
Rules are evaluated in order, and the first matching rule is selected in the normal cycle. If fuel is low and the script contains a fuel-low return-to-base rule, the interpreter prioritizes that rule as an emergency override. Conditions are observations supplied by the game; they do not let a script query arbitrary website data. Actions use the game’s internal fixed scheduler with a bounded actions-per-minute allowance. Empty or invalid programs fail validation with a helpful message instead of being evaluated as code. A portable JSON script can be authored by a person or an AI and then validated before use.
BotScript starter presets
Starter programs demonstrate different priorities. GG VoidMind returns when low on fuel, defends near an enemy, collects nearby resources, explores around an unknown area, then reports. Reef Scout attacks a nearby enemy, returns when low on fuel, collects resources, explores, and reports. Fuel-Conscious Scout prioritizes returning, then defending and collecting before exploring and reporting. Harvester collects nearby resources through harvest behavior and otherwise explores and reports. Reef Guardian uses hitscan near an enemy, builds stone when health is low, and reports.
Cavern Striker uses melee near enemies, collects resources, and explores. Demolition Diver uses self-destruct near an enemy, harvests resources, and reports. Four-Style Fighter lists projectile, hitscan, melee, and self-destruct rules for an enemy condition; because rules are ordered, the first matching one generally wins instead of issuing all four at once. Field Builder collects resources, explores unknown surroundings, builds with wood, and upgrades. Presets are editable demonstrations, not ideal choices for every mode or configuration. Add the fuel rule where desired, check required materials and power, and understand the first-match order before starting.
BotScript action reference
Defend reacts to nearby threat without choosing a specific named attack. Projectile, hitscan, and melee select distinct attack behaviors. Self-destruct creates a close-area blast that damages targets with distance falloff, checks solid blocks for cover, applies armor reduction and mass-aware knockback, and strands the bot for a rebuild delay. Harvest and collect gather different kinds of nearby game resource. Build spends bot-carried material to place a supported block. Terraform changes player-placed terrain to recover grass or coral under the documented rules. Upgrade consumes resources to progress a bot’s technology tier.
Explore moves toward a target or unknown area, optionally constrained by the rule’s radius. The bot can visit eight sectors and report discoveries. Return to base heads back toward its recorded base position to refuel or avoid becoming stranded. Report generates a short field report about state, inventory, or discoveries. Some actions require a specific device, resource, nearby target, or mode. If a command cannot proceed, the runtime may select a target, wait for availability, or produce a report rather than executing an unbounded action. The supported set is fixed in BotScript v1; arbitrary user-defined action names are rejected.
Bot runtime, action scheduler, and inspection
Each bot runtime tracks position, vertical position, heading, activity, current action, material inventory, power inventory, discoveries, and technology level. It also maintains a rule cursor, next-action time, attack cooldowns, fuel schedule, refuel timing, rebuild time, target, base position, and status flags. The local scheduler is bounded and interprets validated rules without calling a model. Actions may have cooldowns; a bot cannot repeat an attack every frame. Sensors define how far it can notice a resource or enemy. Host-side simulation determines live bot behavior in a multiplayer lobby.
The BotScript studio exposes code and visual rule composition, while the arena shows the deployed robot and its current action. Field reports are announced in a log. The workbench exposes the four packs’ equipment and fuel state. A player can pause all running bots, apply a new program, change a setting, and redeploy. Saving a script does not mean it will automatically start after a reload: restored scripts are intentionally paused until reviewed and restarted. This gives the player a clear inspection point before resumed automation changes the shared world.
Bot building, terraforming, upgrades, and sectors
Bots may carry grass, stone, wood, glass, and coral. Their build action can place a block when the selected material is available, while terraform can recover grass or coral from player blocks under the supported rule. Bot building is distinct from player building: the player chooses a material from the toolbar and clicks a surface, while a bot spends its own material inventory according to a BotScript action. Bots can upgrade through Tech Mk 3, consuming game supplies at each step. The runtime reports its technology level as a bounded integer.
Exploration can cover eight named or indexed sectors. Each bot tracks discoveries and reports them; the saved runtime accepts at most eight unique discovery labels of bounded length. Unknown-nearby observations can trigger an Explore rule. The AI docs describe eight sectors, but the visual effect and sector labels are part of the game UI and can change as the world evolves. A full real-world survey map is not produced. Persistent block writes use the authenticated local-host world snapshot endpoint, whereas other live changes are synchronized over the private short-lived lobby channel. Players should understand which operations alter durable shared state.
AI BotScript drafting and quota
The AI BotScript drafter is an explicit player action. It requires a signed-in user when using GiveGigs-managed AI credentials, chooses from the allowed condition, action, and material values, and asks for a safe low-fuel return rule. It can recommend sensor radius, cruise speed, and return threshold. The returned JSON is parsed through the same BotScript schema used by local programs, so unsupported fields, invalid commands, overly long scripts, out-of-range tuning, and bad rule counts are rejected. The assistant does not run the script, and the player must explicitly apply hardware tuning.
Before a model request that uses GiveGigs-managed provider credentials, the server reserves a conservative quota and settles it for the completed request path. The interface reports an mM charge. A user-provided provider key bypasses the platform model-call charge, but secrets are never included in game state or sent to other players. GG VoidMind and the local BotScript scheduler require no model call and no mM. This separation lets the game support deterministic automation even when AI is unavailable or the player wants no model usage.
Finding, creating, and joining lobbies
Aquatic multiplayer uses public or private Local-Hosted lobbies. A player can create a room with a name, visibility, biome, maximum player count, and optional task-graph sharing. The public lobby browser lists worlds with host name, biome, and current occupancy, then offers Join when capacity allows. A private lobby uses an ID and invitation code, with an additional friends-only rule. A code alone is not permission to enter. A URL can bring a valid lobby ID into the app so the player can attempt to join through the normal authorization path.
The host’s device runs the session and must remain connected with the page open. The lobby panel refreshes state, sends periodic heartbeats, shows up to the permitted member limit, and can leave or close a room. A host can issue friend invitations through profile-related flows, subject to acceptance rules. Local-Hosted is part of the interface so players can see that the host is providing the world. Cloud-Hosted sessions are not available. Lobby discovery communicates where a world exists; membership and permission checks still decide who can enter.
World authority and shared play
A lobby includes a seed, a biome, a host identity, a shared Mermaid graph string, member records, and a world revision. The host is the owner of current world state. Guests join the host’s session and render validated snapshots rather than independently becoming the authoritative simulation. For robot multiplayer, the host runs bot schedules, resolves guest ranged and melee attack intents, then broadcasts robot positions, actions, fuel, inventories, discoveries, technology, arena enemies, and shark health/poses over the private realtime channel. The host also checkpoints selected runtime state to the revisioned world snapshot.
The world endpoint validates shared block arrays and the workshop schema before saving them. Updates increment a revision and can return a conflict if the world changed while a save was in progress; the client must load the latest snapshot and continue. The host retains responsibility for remaining online and keeping the game page open. This design reduces duplicate simulation and allows rejoining players to load a common state. The app currently documents that player movement and shared code editing still need the realtime/WebRTC delivery step, so do not assume every visible component is synchronized merely because lobby presence works.
Lobby graph sharing and invitations
The task-map sharing checkbox is off by default. When enabled, the current Mermaid graph becomes visible to everyone who joins the lobby. The interface says local files and folders are never sent through this graph-sharing control. A graph may still reveal task names, organization details, deadlines, or other text a player wrote into labels, so review it before making it visible. A private lobby remains invite-only even if an organization forum post announces its challenge. Public announcements are links, not grants of membership.
Private access requires the friends-only invitation path in addition to the room identifier and invite code. The creator can close a room and revoke the active hosted session by closing it. A member can leave without closing another player’s room. Public room membership is constrained by the maximum player count. The lobby should be treated as a collaborative place with an explicit host and membership boundary, not a public file share. Avoid placing credentials, private personal data, or confidential client material in a graph or challenge post.
Challenge Mode formats and scoring context
The host can start a one-hour Challenge Mode round. Three formats appear in the lobby: Best HTML Website, AI-assisted unsolved mathematics, and HTML Animated Movie. A crew can cooperate as one group, split into two teams, or compete individually. In team formats, the server fixes assignments for the round. New members may join the lobby world, but they need a new round to receive competitive assignment. The clock begins when the host starts the round; the panel displays time remaining or overtime and shows the recorded submission time.
Website and movie formats accept a public HTTPS URL, and the server checks that the deployment returns a live HTML page before it is showcased. A valid response check does not judge visual quality, accessibility, ownership, or the full correctness of the project. The math format asks for the problem, proposal, reasoning, and evidence; the form warns that an AI-assisted result is only a candidate until independently verified as a proof. Challenges can remain in the lobby or be linked from an eligible organization forum announcement. The public leaderboard and showcase provide a separate view of recorded entries.
Project sets, conversation lakes, and rivers
Aquatic’s planning workspace organizes conversations as lakes connected into a project set or river network. A project set has a name, a primary folder label, optional project-folder labels, a list of conversation lakes, and an active lake identifier. Each lake records a title, the original prompt, a Mermaid graph, its creation time, and an optional parent lake from which it branched. A new project set begins with a Welcome lake and a starter reef. Each set keeps up to five recent lakes; the browser keeps up to ten sets.
A generated diagram can fill an empty active lake or create a new lake derived from the current one. Selecting a lake restores its prompt and graph to the planning interface. “New conversation lake” makes a blank branch; drone evacuation also creates a new lake while preserving the route back to the prior one. The concept helps separate related planning work without losing the previous conversation. Lake records are local browser data by default. A project-folder label can connect a set to GiveGigs SuperHero context, but the game does not thereby transmit the linked local files.
GiveGigs SuperHero project context
Aquatic can receive an active project context from the GiveGigs SuperHero desktop workspace. The context contains a stable project identifier, display name, primary folder label, and a bounded list of project-folder labels. The page listens for storage updates and merges that context into a project set marked with a SuperHero suffix. This lets a user keep planning lakes associated with the desktop project they are working on. The integration shares project metadata labels, not file contents or arbitrary filesystem access through the Aquatic page.
The wider SuperHero workspace supports local projects and code editing, while Aquatic supplies a visual planning and play surface. A graph can help describe project tasks, and an agent swarm can return notes. That does not mean the game’s worker has read the local project or changed its files. Each connected tool must have its own permission and user action. The project context is validated for string types, identifier formats, folder counts, and length limits before being used. If the desktop app is absent, the user can still create ordinary local project sets.
Goal Studio and three-point budget
The SuperHero goal studio lets a player name a goal and enter minimum, average, and maximum budget values in USD. The form requires the order minimum ≤ average ≤ maximum. Values are converted to integer cents and capped by the cloud-save schema. The app’s planning target is to finish using no more than half of the average budget, reserving the last half as a safety margin. A saved goal is assigned a stable identifier; changing the average budget starts a new goal ledger because reservations from the previous goal remain recorded.
The studio compares 27 scenarios: three budgets (minimum, average, maximum), three speed levels, and three precision levels. Speed and precision each range from one to three. Speed affects the number of concurrently running workers when a goal budget is active. Precision changes the instruction for worker notes and their completion-token ceiling. A scenario matrix is a planning comparison, not a guarantee that a task can be completed within its budget. Provider costs can vary, and conservative reservations enforce the account’s configured ceiling before the next model request.
Mermaider Solo, Companion, browsing, and masking
Mermaider offers two diagram workflows. Solo Mode asks the website to build the final diagram. Companion Mode produces an intermediary handoff map and a prompt that a user can copy to another AI chat for the final diagram. The input accepts a request, requirements, or conversation with a maximum of 200,000 characters. A browsing option can crawl up to five relevant public pages per supplied URL; results show read, partial, skipped, or unavailable states. A numeric-masking option can conceal raw numeric literals for math or logic workflows, allowing values to be supplied later.
The generated Mermaid source remains editable. The UI displays the selected model, response time, tokens, quota use, source-browsing results, repair attempts, and any error. The player can copy the graph and the execution/final-diagram prompt. A malformed graph can be submitted to a repair endpoint with the renderer error and current source. The repair service is instructed to preserve meaning, dependencies, decisions, and checks while returning valid Mermaid. It is a convenience, not a guarantee that a generated plan is complete or truthful. Users should review the map and source references before relying on it.
Agent swarm levels and worker limits
The Aquatic Agents swarm runs one bounded worker for each graph node, up to 24 nodes in one run. It supports GG Nano (minimal), GG Micro (low), GG Light (medium), GG Mids (high), GG Heavy (high), and GG Dankest (maximum effort); the UI also offers GG VoidMind, a deterministic no-model checklist builder. A worker receives the original task context (up to 8,000 characters in the execution route), its assigned node, dependency notes, and a precision instruction. Dependency notes are capped so they do not grow without bound. Worker outputs are concise draft notes limited before display.
Without a durable goal budget, up to three ready nodes can run concurrently. With a goal budget, concurrency is the selected goal speed from one to three. A worker starts only after its dependencies complete. If a dependency fails or becomes blocked, downstream tasks are marked blocked rather than receiving a false success. The interface streams per-agent status, work notes, errors, total token use, reserved mM, budget remaining, and percentage progress. The worker does not edit files, browse on its own, or perform external actions. Large graphs should be split into smaller missions if they exceed the 24-step limit.
Swarm dependencies, failure, and verification
The execution route parses the same restricted flowchart shape needed by the viewer. Each graph node has an identifier, label, and a list of predecessor dependencies. The server rejects a graph with no nodes, unsupported syntax, more than 24 steps, or a dependency cycle. It computes ready tasks from nodes with no unfinished prerequisites. Workers run only after dependencies complete; if a predecessor fails or is blocked, its dependents become blocked with a prerequisite message. The stream includes initial states and later updates for working, complete, failed, and blocked tasks.
A completed worker means that a bounded response arrived. It does not mean the note has been executed, independently verified, or accepted by the user. A failed provider call can stop a goal-budgeted run and block remaining tasks when the allowance guard prevents further calls. The UI reports the cause and keeps the last confirmed budget remainder where possible. Users should inspect failure statuses, adjust the task graph, and retry only after understanding the issue. Final project acceptance, external deployment, and file changes remain the user’s responsibility.
Budget reservations and model-call accounting
An active goal’s average budget is treated as the cost ceiling for planning, but the user-facing target reserves half for completion. The execution endpoint receives the reserved portion as an integer cent budget, converts it to microMoney for quota checks, and checks account ownership for a durable goal ledger. Each managed-provider worker call must reserve its conservative estimated cost before it starts. Reservations accumulate across runs against the goal; the UI displays what has been reserved and how much remains. If the next worker cannot be covered, the run stops before making that call and marks pending work blocked.
AI usage is separate from the in-game agent coin and human gem ledger. GG VoidMind makes no provider request and no quota reservation. A user-supplied provider key does not charge GiveGigs’ platform model-call quota, while platform-managed credentials do. Provider use and platform quotas are governed by the current AI quota system, not by the goal’s visual budget matrix alone. The system uses conservative reservations; it does not claim to reconcile final provider invoices to actual usage in every case. The goal is a guardrail that helps prevent a swarm from silently continuing beyond the user’s stated allowance.
Fallback graphs and repair behavior
When a generation provider is unconfigured or unavailable, the prompt engine can create a deterministic fallback graph from the input. It extracts a short topic and produces a simple flow: parse input, extract constraints, decompose objectives, check completeness, refine missing constraints, draft the deliverable, and verify rubric gates. This keeps the planning route usable as a basic checklist without pretending a model generated it. The fallback can be generic and should be treated as a starting scaffold that needs editing.
The repair workflow responds to an actual renderer or parser error. A repair request includes the source graph and error text, with bounds on graph and context size. The repair instruction asks for a connected start, declared work, explicit decision outcomes, preserved dependencies, and terminal checks. It disallows advanced Mermaid features so the output stays inside the app’s supported subset. A successful repair only means the renderer accepts the syntax; it does not establish that the work plan is sensible, that every task exists, or that cited claims are supported.
Valley Mermaid and Giggles
Valley Mermaid is the animated guide associated with Aquatic’s task reef. Her portrait can speak through a syllable-timed compositor that combines mouth shapes, expression, and idle blinks. The 3D face uses a canvas texture, and a floating speech bubble is visible while she is underwater. When the scene is above water, she rides in the drone’s clear aqua pod; the retrieval net participates in evacuation. The implementation plan emphasizes bounded visual updates, respect for reduced-motion preferences in the compositor, and a static portrait fallback.
The drone character Giggles carries the pod and provides the sky-pilot/evacuation silhouette. These characters are narrative guides for navigating tasks and the world. Their presence does not make a generated statement an authoritative source or an external action confirmation. If Valley presents task guidance or a response from an AI tool, it should be read as interface assistance and reviewed against the graph and actual results. The character animation and voice use the application’s media pipeline; they are separate from BotScript’s deterministic command interpreter.
Accessibility and input modes
The main canvas has a descriptive accessible name and keyboard focus. On-screen movement buttons expose labels such as Move forward, Strafe left, Rise, Dive, and Crouch and use pointer capture so a held touch input ends when the pointer is released or canceled. Status announcements use live regions for health, robot reports, block notices, visitor settings, bot progress, and treasure results. Important controls have visible text labels in addition to icons; the 3D canvas has an SVG graph fallback when WebGL fails.
Keyboard, pointer, touchscreen, and detected game controllers can be used, but exact input quality depends on the device. Camera sensitivity, field of view, camera distance, graphics settings, visual density, and sound controls support adaptation. The human-fauna proposal calls for further reduced-motion controls and more accessible labeling of profession/activity data; these are not all confirmed present in the current build. Screen-reader users may find some complex 3D spatial relationships harder to perceive, so node labels, progress status, reports, and the flat SVG fallback provide text-oriented access paths.
Audio, ambient sound, and motion
Aquatic can produce a procedural ocean-hush sound. The user must press Sound on before browser audio starts; the volume slider ranges from muted to a modest maximum of 50%. Sound off disables the ambient generator. The project also contains spoken Valley output, with a portrait compositor and speech bubble coupled to speaking state. These experiences are separate: procedural ambience is not a model response, while a voice line may accompany an assistant interaction. The UI indicates the active sound state with a speaker icon and text.
Motion appears in fish schooling, swimming, bubbles, vegetation, wildlife, drone movement, couriers, node glows, camera transitions, and the animated Mermaid. Reduced motion support has been called out in the design notes for the face compositor and as an open proposal for the wider fauna simulation. Players sensitive to motion can lower visual detail, turn off ambience, change camera mode, reduce life density, or set visitors to zero where those controls are available. Check the current settings panel, because not every proposed global motion control is implemented.
What saves where
Aquatic state has several save scopes. Preferences such as biome, view, difficulty, graphics, palette, sensitivity, density, camera, avatar, audio, visitor count, and detector setting use local browser storage. The player’s placed blocks and snowballs use per-world local storage keys. Agent coins, human gems, reward keys, and treasure keys also use a world-specific local ledger. Project sets, conversation lakes, prompts, and Mermaid graphs are stored as local project networks. Goal settings are saved locally and may have a durable server-side budget reservation ledger.
A signed-in player can save and restore an account cloud backup of project sets and the goal. Restore validates the payload and asks before replacing the current device’s project sets and goal. Lobby world snapshots are host-owned and contain selected shared blocks, workshop configuration, BotScript, and robot runtime state. Lobby membership and challenge records are stored through server routes. These categories should not be conflated: clearing browser storage, restoring a cloud backup, closing a lobby, or changing the host snapshot affects different data. The UI and endpoint response should be checked before making an assumption about persistence.
Account backup format and restore checks
The Aquatic cloud backup is versioned and includes the goal, project sets, active project set identifier, and a timestamp. It is stored through the aquatic-world game-save API for the signed-in account. The client limits the set count, folder count, lake count, title length, graph length, prompt length, and identifier length. It validates goal amounts, budget order, speed, and precision before accepting a saved object. An invalid record is refused rather than partially applied.
Saving reports success or a clear error and leaves the local world available. Restoring an empty cloud save informs the user that no backup exists. Restoring a valid save asks for confirmation because it replaces project sets and goal on that device; canceling leaves local state alone. The backup is separate from the live multiplayer snapshot and does not automatically restore a public or private lobby. Goal reservations in the server ledger are tied to the account and goal ID, so changing the goal’s average creates a new budget identity while past reservations remain recorded against the prior one.
WebGL errors and recovery
The interactive world renders through WebGL and Three.js. If renderer initialization or a later render path fails, the component reports a WebGL error. Some world controls, such as evacuation, are disabled if the required renderer handle is unavailable. The surrounding task map can display an SVG fallback so the Mermaid plan remains inspectable even when 3D rendering is not working. A player may try a lower graphics preset, close competing GPU-heavy tabs, reload the page, or use a browser with current WebGL support. The game does not claim that every device can run every quality preset.
Scene construction includes canvas-based emoji and text textures, a perspective camera, orbit controls, resize handling, effects, fog, and a request-animation loop. High graphics modes create more bubbles and fauna and may use post-processing. WebGL memory and GPU limits vary by browser and device. A fallback preserves task labels and structure but does not reproduce the movement simulation, underwater fog, wildlife, or crafting interactions. If a setting does not solve the issue, the 2D Mermaid representation and textual task controls are still useful for continuing planning work.
Privacy boundaries across Aquatic features
Aquatic’s data flows differ by feature. Local game settings and collection ledgers are saved in the browser. The project lake system stores prompts and Mermaid source in local storage. A cloud backup sends the selected goal and project sets to the authenticated account save API. Multiplayer sends lobby presence and, when the host opts in, the task graph to joining participants; the host’s world endpoint stores validated shared block and workshop state. AI-assisted diagram, swarm, design, and BotScript operations send bounded user input to their server-side service according to the action and quota policy.
Do not put secrets in a task graph, public challenge, display label, script name, or shared lobby. BotScript cannot access a local filesystem or network directly. AI worker prompts are treated as untrusted task text by system instructions; they are bounded to one draft step. Local filenames and folders are not included just by enabling task-graph sharing, although a user may manually type sensitive content into the graph. A cloud backup is private account storage, not a public wiki or lobby. Review a destination’s sharing controls before sending data.
What Aquatic does not simulate
Aquatic is not unrestricted Minecraft parity, a real robotics runtime, a professional CAD package, a validated engineering calculator, a scientific marine-ecology model, a medical visualization, a field identification guide, or a cloud-hosted multiplayer service. Its BotScript is an allow-listed JSON rule set. Its world is bounded and seeded. Its animals use lightweight emoji sprites and simple movement. Its weapons and physics use game-tuning formulas. Its workshop lacks part-level assemblies and validated stress analysis. Its cloud backup covers defined planning data, not every browser or lobby state.
The product can still support exploration, practice in decomposing tasks, simulation of simple resource tradeoffs, and creative multiplayer challenges. To keep those uses clear, describe what a player can do in the current UI, provide the underlying code or docs for technical limits, and distinguish a roadmap item from a released interaction. A screenshot or a generated draft is a view of one moment, not proof that a feature works in every mode. Documentation should favor observable outcomes and avoid promoting game estimates as real-world advice.
Feature inventory: a practical checklist
A current Aquatic session can involve the following feature groups: World: five biomes, land and underwater play, a camera-following 3D scene, a Mermaid task reef, seeded decoration, water and fog effects, bubbles, underwater and land fauna, human visitors, and a pilotable drone. Input and display: keyboard, mouse, touch, controller detection, first- and third-person cameras, zoom, reset, avatar inspection, quality presets, palette, field of view, clarity, sensitivity, life density, audio, and local settings. Gameplay: Creative/Peaceful/Survival/Hardcore, hearts and respawn, shark danger, biome snowballs, harvesting, treasure scanning, gem effects, and up to 300 player blocks.
Planning and AI: Mermaid graph generation, Solo and Companion mode, optional public URL browsing, optional number masking, graph editing, syntax repair, deterministic fallback, task-worker swarm, seven worker levels including VoidMind, per-node status, notes, and optional goal budgets. Invention and automation: six shapes, four materials, three device categories, four power choices, measured previews, AI co-design, copyable briefs, four bot packs, BotScript JSON, thirteen actions, six conditions, presets, sensors, speed, fuel, reserves, refueler, shields, relays, five control links, runtime reports, sector discovery, construction, terraforming, and upgrades. Collaboration: local-hosted public/private rooms, invitations, optional graph sharing, host-owned snapshots, and one-hour challenges. This inventory is a map for readers; feature state and limits remain as described in the detailed sections.
Common troubleshooting steps
If movement does not work, click or focus the game canvas and confirm the correct mode: water, land, or drone. Try the on-screen touch controls or confirm that the controller is connected. If the camera feels uncomfortable, lower sensitivity or field of view and adjust follow distance. If rendering is slow, reduce graphics quality and marine-life density. If sound is silent, press Sound on and check the browser’s audio permission. If a graph does not render, review the supported Mermaid syntax and use the repair action. If a bot remains idle, check whether robots are running, a valid program is loaded, the bot has fuel, the rule conditions match, and the bot has the required supply or equipment.
If crafting is disabled, compare the displayed costs with the available materials and gather more resources. If a visitor is not visible, check the visitor slider, biome, and visual density. If snowballs are unavailable, walk close to a snowflake in Arctic. If treasure is not found, make sure the detector is scanning and inspect the seabed. If cloud restore fails, check sign-in and the backup version. If a lobby disconnects, the local host may have closed the page or lost connectivity; rejoin through the lobby’s authorized flow. These steps explain likely feature state, not every possible browser or network failure.
Expanded glossary
Agent coin: a game-only reward associated with worker data deliveries. Agent data courier: a visual character carrying a task result toward a recipient or repository. Aquatic Agents swarm: bounded task workers associated with Mermaid graph nodes. Block snapshot: host-owned validated record of shared placed blocks. Bot pack: one of four loadouts holding devices, materials, fuel, and network settings. BotScript: versioned JSON rules interpreted by a fixed local scheduler. Challenge Mode: one-hour lobby competition or collaboration round. Companion Mode: produce a Mermaid handoff map for another AI. GG VoidMind: deterministic checklist and bot option with no model call. Human gem: game-only modifier currency.
Lake: a saved prompt and graph conversation within a project set. Local host: player device that owns and maintains a multiplayer world session. Mermaider: workflow for converting a task into a supported Mermaid diagram. microMoney (mM): GiveGigs model-call quota unit. Node: one task in a graph. Project set: local grouping of project folder labels and up to five recent lakes. Revisioned snapshot: server-validated saved state for a lobby world. Solo Mode: create and explore a final diagram on the page. Task reef: the 3D visualization of the Mermaid graph. VoidMind: deterministic no-model worker. These terms describe product behavior, not general standards unless explicitly identified as such.
Keeping this reference accurate
Aquatic changes quickly, so this wiki article should be maintained against the shipped interface and source documentation. When a control is renamed, update the control section and index. When a BotScript condition, action, or schema changes, update both this article and the machine-readable BotScript guide. When a state-save rule changes, describe its scope and owner. When a planned feature ships, replace its proposal label with a precise description of the implemented behavior; when it is removed, remove the claim instead of leaving a stale promise.
An exhaustive description can still be incomplete. The game has many numerical balancing constants and visual implementation details that can change without representing a new user-facing feature. Document stable player-visible mechanics and important bounds, cite the relevant project guide, and avoid presenting internal values as a permanent product guarantee. If a claim is unclear, inspect the current app and source before editing. Preserve uncertainty by writing “the current build” or “the project proposal” where appropriate. Readers can suggest revisions through the Wiki’s normal contribution and revision-history flow.
Walkthrough: a first dive
Start on /aquatic/ and allow the game canvas to finish loading. Focus the canvas, then test forward movement and looking before entering a harder mode. Select Peaceful if you want to learn the terrain without shark attacks. Try first-person and third-person to see which is easier to navigate, and adjust look sensitivity if small pointer movements rotate too quickly. Check whether a controller is connected if you intend to use one; the status badge reports it.
Switch among the five biomes and observe how shoreline decoration and visitor professions change. In water mode, explore the reef and graph nodes; switch to land mode to walk the island and causeways. Set visitors to zero, then increase them to see how the roles change. Open Customize your dive to lower graphics quality or life density if the scene is slow. Press Sound on only if you want ambient audio. These steps change local preferences and presentation; they do not edit the Mermaid graph or spend an AI quota.
Walkthrough: build and undo
Enable Build blocks and select one of grass, stone, wood, glass, or coral. Move to a permitted patch of land or seabed and click once to place a block. Confirm the counter increments and the selected material remains active. Place a short path or marker, then right-click a block to remove it or press Undo block to reverse the latest placement. On touch, use the visible undo control. The game caps this player-built list at 300 and stores it per world in local browser state for ordinary single-player use.
If the player intends to build with a crafted material, use the workbench’s “Use as build block” control and confirm the toolbar selection updates. Keep in mind that a crafted alloy currently maps to an existing block type because the palette has no alloy block. In a multiplayer lobby, the host owns shared blocks and saves them through the revisioned world endpoint. A guest’s local view is not the final authority over shared durable state. Turn Build blocks off before returning to movement if stray clicks are adding blocks.
Walkthrough: gather and craft
A useful workshop session starts by checking the inventory row: wood, stone, coral, compressed air, electricity, and natural gas. Walk within reach of a visible resource to collect it; the UI can display a notice, and the resource will return after a cooldown. Select a category, a shape, material, and power source. Observe how the dimensioned preview and measured properties change before crafting. Compare the displayed recipe against available inventory; powered weapons add a utility cost, and alloy uses both stone and coral.
Press Forge & equip after the required supplies are present. The button reports whether the design was crafted, and a successful craft equips it for supported player interactions. A tool can change harvest yield and a weapon can affect combat behavior. To transfer a device to a bot, choose one whose corresponding bot slot is empty. Keep the workbench’s game-estimate warning in mind. The preview is useful for understanding the game formula and choosing a build; it does not certify a real object, and an AI rationale is not an engineering review.
Walkthrough: search for treasure
Toggle the metal detector to show that scanning is active, then look around the seabed for pirate-flag markers and shells. Move close enough to investigate a shell cache. A find updates the notice and human-gem balance; no-find messages are also possible. Treasure is keyed to the local world ledger, so opening the same cache does not pay it out repeatedly. The detector can remain selected in local preferences, but collected rewards are stored separately under the current world.
Open Gem effects to inspect each balance and modifier. Keep these game gems separate from GiveGigs mM. A task-delivery reward can add another coin and gem change later, but the treasure interaction is its own route. If a cache does not appear, the current world may have a different seeded layout, the scan may be off, or that cache may already have been opened. The activity uses simplified visual clues and random-looking gem tiers; it does not identify real buried objects.
Walkthrough: collect Arctic snowballs
Select Glacial Arctic from the biome menu. Find a visible snowflake and walk close to it; the snowball counter should increase. The toolbar will expose Throw snowball when the Arctic biome is active. Press G or the button to use one. The projectile splashes and disappears at open water. The counter decreases and the local per-world collection is updated. The interaction is intentionally separate from workshop materials and robot power supplies.
If the player changes to a different biome, the Arctic-only controls are hidden. Returning to Arctic restores the same world’s local snowball count if browser storage is available. The amount is finite until another pickup is collected. The game does not turn snowballs into blocks, weapons, or utility charges. This small loop is an example of a biome-specific activity that changes the world interaction without changing task planning or shared AI settings.
Walkthrough: compare human and AI design
Build or load a workshop concept and note its name, shape, material, dimensions, power, measured properties, and inventory. Copy AI design brief to place the current values into the clipboard; this uses no GiveGigs model call. A player can paste it into an assistant of their choice, inspect the result, and manually change the design fields. The brief asks about load, buoyancy, corrosion, ergonomics, failure modes, repairability, and safety while explicitly avoiding certification claims.
AI co-design follows a different route. It sends the structured design to the signed-in GiveGigs server endpoint, validates the response against the supported enum and numeric ranges, displays a rationale and possible failure modes, and shows the mM charge and token use. The server applies quotas for managed provider credentials. A successful response revises the editable blueprint but does not craft it or equip it until the player presses Forge & equip. A failed request leaves the existing blueprint unchanged. Review every adjustment before using it in-game.
Walkthrough: configure and start a bot
Select a starter in the BotScript studio, inspect its name and ordered rules, then examine its bot pack. Check the bot’s selected tool, weapon, material device, carried materials, fuel type, reserve capacity, current fuel, communication mode, signal shield, relay, and refueler. Adjust sensor radius, cruise speed, and return-to-base threshold to fit the mission. Add a fuel-low return rule before ordinary rules so it is visible and easy to review, even though the runtime gives it emergency priority.
Start with one active bot and watch its action label and field reports. If it has no fuel, no relevant sensor observation, an unmet material cost, or a blocked signal, it may not perform the intended task. Stop or pause the bot before changing its program, then review and redeploy. An AI draft arrives paused by design. Runtime state can be saved by the lobby host, but restored scripts remain paused until a person reviews and starts them.
Walkthrough: plan a bot supply route
Before deploying several bots, define what each one must accomplish and what supplies each action consumes. A harvester needs an appropriate tool and room in its inventory. A builder needs the material named in its build rule. A weapon action needs an eligible target and can require a weapon or utility. Upgrades need deposited materials. A returning bot needs sufficient fuel for the route, and a network-controlled bot needs a functioning link outside jammer zones. Give each of the four packs a distinct role if simultaneous work is useful.
Tune cruise speed conservatively, set the sensor range to cover the route, and raise return-at if the bot must travel farther back to base. Install a reserve or refueler when the material cost fits the plan. Use a relay mast to extend range or a signal shield to harden a vulnerable link. Do not assume that four copies can all draw from one shared inventory; the panel reports each pack’s carried materials. Observe one run, record where it ran short, and adjust only the relevant setting before deploying again.
Walkthrough: understand bot combat
Enable Play bots to activate the battle arena, then configure a bot with an appropriate weapon and an enemy-nearby rule. Projectile, hitscan, melee, and self-destruct are separate rule actions. Because the rule list uses first-match behavior, a bot will normally choose the first matching enemy rule rather than fire every listed attack at once. The emergency fuel-low return rule remains a special override. Terrain blocks can obstruct attacks or provide cover. Self-destruct has a blast and a rebuild delay, so it removes the bot from action temporarily.
Player attacks are separate. F follows the aim line for ranged fire, E makes a quick strike, and V charges a heavy swing while held and releases it on key-up. A charge shorter than 0.16 seconds cancels. Player health and respawn depend on difficulty; an arena task can be tested in Peaceful or Creative only insofar as those modes have no shark attacks, but bot battle behavior is still a separate mode. Combat is optional and the simulation is not a model of real weapon safety or wildlife response.
Walkthrough: create a Solo Mermaid map
Choose Solo Mode and describe the desired outcome, constraints, relevant facts, and what a finished result should look like. The input supports long contexts up to 200,000 characters. Decide whether the server should browse supplied public URLs and whether number masking is useful for a quantitative exercise. Submit the task and wait for the generated map. Inspect its nodes and labels, and check the browsing result statuses if URLs were included. A reported “read” result is useful context but does not replace opening and evaluating the source.
Review the output source as well as its 3D rendering. Copy the graph or execution prompt if needed, edit any unclear step, and use the repair action if the supported renderer rejects the syntax. A generated diagram can be incomplete or wrong, so verify dependencies, decision branches, terminal checks, and requirements yourself. Once accepted, save the prompt and graph to the active project lake; this creates a traceable planning record without implying that any graph task has been executed.
Walkthrough: use Companion Mode
Companion Mode generates an intermediary map and a handoff prompt for an external AI conversation. It is deliberately labeled “Handoff map only.” The website does not generate the final diagram in this mode. Copy the handoff prompt into the other chat, where a separate model can create the final Mermaid source. Preserve the original task context and ask the other model to return only the supported flowchart syntax if you want to explore it in the in-world 3D viewer.
The two steps have different outputs and budgets. The website’s map is planning context; the external model’s response is a separate artifact that may not follow the parser’s limited grammar. Inspect both the generated prompt and the final result. If the outside response includes unsupported declarations or line styles, use the local editor and repair route to bring it into the accepted subset. Companion Mode can be useful when the user wants to continue in a preferred assistant, but it does not give that assistant access to the Aquatic game, local files, or lobby state.
Walkthrough: browse public source URLs
The optional Browse the URLs control accepts supplied public URL references, including bare domains. The crawler follows up to five relevant public pages per URL and shows whether each was read, partially read, skipped, or unavailable. The generation result includes page titles and URLs for pages that were read and notes for limitations. This makes provenance more visible than a silent search, but it does not certify that the chosen page is authoritative, current, or relevant.
Before using the output, open the source itself, confirm its date and publisher, and compare its claims with the task requirements. A partial read or unavailable status means the system did not fully retrieve that page. Private URLs and login-gated documents are not guaranteed accessible. Do not paste an access token or secret URL. Browsing is an opt-in context aid for diagram generation and is not automatically repeated by each swarm worker. Workers receive the bounded task and dependency notes; they are instructed not to claim research they did not perform.
Walkthrough: mask numbers in a task map
The number-masking control is intended for math or logic exercises where raw values should be supplied during execution. Enable it before generation if revealing a literal would spoil the challenge. The system neutralizes selected numeric content in the generated map while keeping the task structure. This feature is a prompt and diagram aid; it should not be treated as cryptographic redaction. A value can remain in the original task context, URL source, or a different part of the conversation.
Before sharing a masked graph, inspect the prompt, notes, title, and full lake record for other copies of the number. If a person wants to conceal confidential business information, use a proper data-handling method and avoid entering it in the first place. The option does not strip every identifier or every data type. It is most useful for designing a staged exercise in which the map contains the procedure but a human later provides the measurements or puzzle values.
Walkthrough: run and inspect a task swarm
After creating a graph, select a worker reasoning level and run the swarm. The interface reports each graph node as pending, working, complete, failed, or blocked. Watch which nodes begin together and which wait for prerequisites. Open Worker note for each returned draft and inspect its assumptions and validation step. If a source or code change is claimed, check that the worker was actually given a tool capable of performing it; ordinary Aquatic swarm workers only return text.
The display tracks completed workers, progress percentage, tokens, reserved mM, and budget remaining where available. At most 24 graph steps are accepted. Up to three ready workers run at a time without a durable goal cap; an active goal selects concurrency from its speed setting. Dependency cycles and unsupported syntax are rejected before workers start. Failed prerequisites block successors. Use the status log to revise or split the graph, not to infer that a missing result succeeded.
Walkthrough: set a budgeted goal
Open Goal Studio and name an outcome that can be broken into Mermaid steps. Enter minimum, average, and maximum USD budgets in ascending order. Choose speed and precision, then compare the 27 scenario combinations in the data-center matrix. A selected budget scenario is not a promise of cost or completion time: it is a planning configuration for bounded AI use. The studio targets no more than half of the average budget, leaving a reserve for finishing work.
When a goal is first saved, it receives a goal ID for its server-side reservation ledger. Changing the average starts a new budget identity; the old reservation remains attached to the old goal. Sign in to apply durable account budgeting. The endpoint checks account ownership, the exact locked budget, and remaining reserved quota before starting each managed-provider worker. If the remaining amount cannot safely cover another call, the swarm stops and marks pending tasks blocked. GG VoidMind avoids provider calls entirely.
Walkthrough: organize project lakes
Create or select a project set and give it a concise name and a primary folder label if useful. Add a conversation lake when a distinct planning topic begins. Each lake keeps its prompt and Mermaid graph; selecting a river pill loads that lake’s text back into the task interface. A map generated from an empty welcome lake can populate it. Later tasks can create a new lake linked to its parent, preserving the sequence of work. The current browser stores at most ten project sets and the last five lakes in each set.
Keep projects with different audiences or confidentiality boundaries in separate sets. A folder label is metadata; it does not grant Aquatic file access. A conversation title should identify its work clearly without including private credentials. Export or copy important graph text if you need an independent record. The app’s cloud backup can store the goal and local project networks for the signed-in account; multiplayer world state is managed separately by the lobby host.
Walkthrough: save and restore a cloud backup
Sign in and press Save account cloud backup to send the current project sets and goal to the account save endpoint. The UI reports that the backup is saved while leaving the local world available. If no network or account is available, it shows an error and local data remains in place. Cloud storage is for the validated Aquatic planning payload, not every browser preference, game reward, or live lobby member.
On another signed-in device, use Restore cloud backup. The app checks the version and bounds for project count, lake count, folders, strings, graph size, prompt size, and budget values. If no backup exists, it says so. If one is valid, the confirmation identifies the number of project sets and warns that restoring replaces the local project sets and goal. Cancel if you do not want that replacement. This operation does not restore a multiplayer lobby or change the live host snapshot.
Walkthrough: host a public lobby
Open the lobby controls, enter a room name, choose Public visibility, select a biome, and set the maximum player count. Leave task-graph sharing off unless every participant should see the graph. Create the room and keep the Aquatic page open on the host device. The public browser can then display the room name, host, biome, and occupancy to other players, who can join while the room has space. The host can watch membership and close the world from the active lobby panel.
Remember that Public refers to discoverability, not to transferring host authority. The host remains responsible for the local session and current world. A public event announcement does not make private room controls disappear, and an active lobby still applies its membership and capacity checks. If the host closes the page or disconnects, the local world can become unavailable. Save appropriate world state before ending a session and explain this hosting requirement to collaborators.
Walkthrough: join a private lobby
For a private room, obtain the lobby identifier and invitation code through the host’s authorized friend invitation. Enter both in the private join section and submit. The app checks the user’s friendship/acceptance status as well as the code. A copied URL or code is not a permission grant. If the user is not eligible, ask the host to use the proper profile invitation workflow rather than trying to bypass the check.
Once admitted, the panel identifies the room as PRIVATE · Local-Hosted and shows its biome and people count. The host’s page must remain open. To leave, select Leave; this does not close another person’s lobby. The host can choose Close world to stop the room. A private room’s forum announcement, if one exists, should not contain its invite code. Do not share private invitation details in a public post.
Walkthrough: share a task graph in a lobby
Review the task graph as if every joining member could read it. Remove internal notes, secrets, and personal data that should not be shared. Then, when creating the lobby, turn on Share this task map with lobby members. The interface states that local files and folders are never sent by this option. The graph itself can include whatever the author wrote into its labels, so the user is responsible for reviewing the content. Turning sharing off preserves the default private-to-host graph state.
The shared graph is a planning aid. It does not enable simultaneous code editing and it does not upload the host’s folder tree. If a community challenge needs an organization forum announcement, the eligible host can select an organization for which they have the required membership and permissions. Public and private lobby destinations are described differently in the announcement so a private post does not imply public access.
Walkthrough: run a Challenge Mode round
The host opens an active lobby and selects one of the three challenge formats. Choose a crew arrangement: everyone cooperates, team versus team, or everyone for themselves. Starting the round creates a one-hour deadline. In team formats, assignments are fixed at that point; players who join later can explore the lobby but are not assigned to compete until a new round is started. Participants can check their assignment and the countdown in the active panel.
A website or movie submission requires a public HTTPS URL; the server checks for a live HTML response. A math entry asks for a statement, reasoning, and evidence. AI-assisted mathematical work is explicitly a candidate until independently verified. The public showcase displays recorded submissions and timing. If the host links the event in an organization forum, membership and forum authorization still apply. A deadline indicator is a timer; it does not judge quality or prove that a submission is original.
Walkthrough: rejoin and review saved bots
When a player reopens a lobby invitation, the game fetches its latest host-owned world snapshot. A snapshot includes revision, biome, shared blocks, workshop configuration, and selected robot runtime information. Rejoining restores supported position, action, fuel, inventory, discovery, and technology values. Check the revision and any conflict notice if a save races with another update. The host remains authoritative.
After loading, BotScript remains paused. Open the bot studio, review its ordered rules and pack configuration, inspect fuel and signal state, then deliberately restart automation. This prevents a stale script from continuing without a human noticing the restored state. If no runtime snapshot is present, configuration may still exist while live position or action resets. A persistence boundary is feature-specific, so review the current panel rather than assuming every animation, graph selection, treasure cache, or temporary interaction was restored.
Walkthrough: prepare a comfortable session
Choose a quality preset that your device can sustain. Potato and Low reduce scene work; Cinematic adds effects and more ambient entities. Lower life density and visitor count to reduce visual motion and scene clutter. Use the palette and camera settings that make the graph and terrain legible. First-person can help orient movement; third-person can make the avatar’s position easier to see. Adjust field of view and follow distance in small steps. Disable ambient audio if desired; the browser will not start it until Sound on is pressed.
Use the labeled touch controls if keys or a controller are difficult. Focus the game surface, and use the accessible button labels rather than relying only on emoji. Read the spoken guidance and selected-node panel for task context. If 3D rendering fails, use the Mermaid SVG fallback for graph inspection. The app offers several accessibility supports, but the broader reduced-motion and screen-reader proposals are not complete. The best accessible setup may differ by browser and assistive technology.
Walkthrough: explain a bot strategy to a teammate
A useful shared strategy description names the goal, observations, action order, materials, fuel plan, communication method, and expected recovery behavior. For example: return at low fuel, defend if an enemy is nearby, collect nearby supplies, explore unknown space within a stated radius, and report after each leg. Then explain why each rule appears in that order. A teammate can inspect the visual rules and compare them with the JSON source before deployment.
Keep the explanation aligned with what the worker can actually observe. health.low refers to a supported game observation; it does not give the script general medical or structural insight. unknown.nearby is a game-world observation, not a web search. A build rule cannot place a material the bot does not carry. If a rule is unreachable because an earlier always rule matches first, move it above that general rule. Explain when an action can consume fuel, material, power, or a bot rebuild delay.
Walkthrough: diagnose a graph that will not load
Check that the first non-empty line begins with a supported flowchart direction. Use identifiers starting with a letter and put one node declaration or one edge on each line. Keep labels inside the supported brackets or braces. Use simple arrows and optional edge labels. The viewer ignores lines beginning with %%; it rejects advanced Mermaid declarations outside its subset. If the 3D renderer presents a parser error, read the exact line or syntax hint before asking for a repair.
The execution route also rejects graphs with more than 24 task steps or dependency loops. Ensure each dependency has a declared or inferable node, and ensure the graph has a starting node. A visually readable graph can still contain a cycle. Repair produces syntactically acceptable source, not a validated project plan. After successful rendering, click nodes to inspect the full label and confirm that every edge points in the intended direction.
Walkthrough: diagnose an idle or stranded bot
First confirm the bot war party is deployed and robots are running. Check the visible status and current action. If the program has no rule that matches the current observation, the bot may have no useful next action. If an always rule appears too early, it can prevent later ordinary rules from being chosen. A fuel-low return rule has special priority, but the bot still needs enough movement capacity to return. Inspect its current fuel and capacity, selected fuel type, return threshold, reserve, and whether a refueler is nearby.
If it is stranded, add the needed fuel or use another bot’s refueler if the configuration permits. A damaged or self-destructing bot may be in its rebuild delay. A remote or satellite link may be jammed; check for a signal shield, relay, and jammer zone. A builder may lack the named block material; a weapon may have no eligible target; an upgrade may be short of supplies. Field reports can reveal discoveries and failures. Change one cause at a time and observe the result.
Walkthrough: handle a lobby save conflict
The host-only world endpoint compares the submitted revision against the current lobby record before writing. If another host update already advanced it, the save can return a conflict with the latest blocks, workshop state, and revision. Do not blindly resubmit an old snapshot; load the returned current state, review changes, and apply the intended edit against that revision. The endpoint validates the entire workshop configuration and block schema before updating. Invalid counts or designs are rejected.
A guest should not attempt to save host-owned world data. Check whether the session still identifies the user as host and whether the lobby remains OPEN. If the host closed the room, rejoin or create a new world under normal authorization. The revision counter identifies shared-world updates, not every client-side preference or local loot change. Saving a local preference cannot resolve a server-side conflict.
Walkthrough: review an AI-produced result
For each AI-assisted route, ask what the model received, what it returned, and which checks the app actually ran. A Mermaid generator creates a map; a repair model corrects syntax; a swarm worker drafts a note; workshop co-design revises a bounded game design; BotScript drafting proposes validated JSON. In each case, schema or syntax validation can confirm a structure, but not whether the underlying claim is true or the project outcome is complete. Read source links and evidence yourself.
Treat completion as a response status, then define a human acceptance test. For a bot script, inspect actions, material costs, and fuel before starting. For a workbench design, review constraints and do not infer certification. For math, obtain an independent proof. For a website, inspect the actual deployment. AI-managed costs are reserved and settled according to the quota system; GG VoidMind avoids model use. This review-first pattern is part of safe play.
Feature status and version sensitivity
Some controls are stable enough to document as player actions, while internal balancing values may change. Biome names, high-level tool options, BotScript schema limits, lobby behavior, and save ownership are current implementation facts. Enemy speed, damage formula constants, graphics counts, resource positions, and model effort guidance can be retuned. The visual roster is also tied to emoji assets and current rendering caps. Do not turn these implementation details into a promise that all future builds behave identically.
When a version change affects a player decision, update the exact subsection and source links. Record whether a described feature is implemented, partial, or proposed. The human-fauna proposal already distinguishes its implemented slice from open work. Keep such labels visible. A detailed wiki becomes more useful when readers can tell how to verify a statement and how recently it was checked.
Keep game rewards and platform quota separate
Aquatic contains several quantities that look like balances but have different purposes. Wood, stone, coral, air, electricity, and gas are crafting or bot supplies. Bot fuel and reserve capacity are simulation state. Agent coins, human gems, and loot bags are local game rewards. microMoney is a GiveGigs quota unit for eligible AI model calls. The goal studio also uses USD budgets, with server-side reservations translated into mM. None of these is interchangeable. A gem does not pay an AI quota; an mM reservation does not purchase a game item; a workshop utility charge is not an account balance.
The UI labels these quantities in their local panels. Review the nearby explanation if a number seems ambiguous. In particular, the gem-effects panel says its balances are game-only, and the swarm usage panel labels reserved mM separately. Keep these distinctions in task descriptions, challenge rules, and support guidance so that players do not mistake an animation reward for real money or a model-call estimate for a fixed purchase price.
Aquatic blocks and the separate world JSON editor
GiveGigs also contains a generic block-world schema with a world name, version, and blocks for grass, stone, wood, water, lava, gem, spawn, and goal. Its validator limits worlds to 4,000 blocks in a 65 × 25 × 65 coordinate space and allows only one spawn. Template helpers can create an island, parkour challenge, or empty world. This is a separate editor utility and is not the in-scene Aquatic building toolbar. The Aquatic toolbar instead supports up to 300 placed blocks selected from grass, stone, wood, glass, and coral.
The two lists overlap but differ in materials, placement workflow, storage, coordinates, and purpose. The generic JSON template’s goal block is not automatically a Mermaid task goal, and a generic gem block is not the human-gem loot ledger. When documenting GiveGigs games broadly, name the particular surface being described so a reader does not assume that an editor feature is available inside the Aquatic dive.
Walkthrough: compare biome roles and scenery
Use the biome selector and leave the camera in a consistent view while comparing Taiga, Beach, Arctic, Caldera, and Glade. The decoration pool changes, as do the visitor titles and land fauna. Count and life density affect how many ambient sprites are visible. A missing animal at a lower quality setting does not necessarily mean its biome roster is absent; the current visual cap may limit the number of entries drawn. The visitor slider also controls count independently, from zero through ten.
If documenting a particular seed, record the biome and display settings along with the screenshot. Note whether an emoji denotes a visitor profession, decoration, marine-life role, or land fauna. Avoid concluding that a missing sprite represents an ecological absence or that a displayed activity is simulated as a full agent behavior. The game uses small pools and lightweight animation for performance and readability.
Walkthrough: navigate and inspect graph nodes
Use the Mermaid map’s drag and zoom controls to see crowded areas. Zoom in to read labels and zoom out to understand the whole graph. Reset camera restores the initial composition. Inspect avatar centers the player. Clicking a node opens an overlay with its stable graph identifier and full label; close the panel to return to unobstructed play. Selected nodes may also trigger a Valley guide message. The overlay preserves the relationship between a task’s textual label and its position in the reef.
The graph is rebuilt from source text, so changes to node identifiers can affect graph relationships and worker matching. Keep IDs concise and stable while changing labels if progress needs to remain associated with the same task. The 3D scene can make dependencies easier to explore, but the order and semantics still come from the arrows and labels in the Mermaid source. A visual proximity between two nodes is not a dependency unless the graph contains an edge.
Closing perspective
Aquatic’s central loop is: plan a task, represent it as a graph, inspect and improve the plan, explore a world that makes the graph visible, gather or craft what a game action needs, and optionally delegate bounded work to a deterministic or quota-metered worker. The player can then review results, share a map with a local-hosted team when appropriate, and save selected state through the relevant local, account, or lobby mechanism. Each transition has a control and a boundary.
The game’s breadth comes from these connected systems rather than from any one feature acting alone. The wiki should help players trace those relationships and understand their limits. Read the earlier sections for detailed catalogs and the walkthroughs for concrete sequences. Use the app for the live feature set, the project documents for implementation detail, and the revision history for updates to this page.
Take this topic further
Turn “GiveGigs Aquatic” into a learning path
The Learning Studio will use this page’s overview and key ideas to shape a guided lesson, practice questions, and a small project around what you want to understand.
Related GiveGigs pages and features
Explore connected GiveGigs pages and tools for context and next steps.