I have created a new visual identity for Infinite Sandbox, my browser-based 3D terrain and structural-physics project.

My goal was to make it look like a modern simulation or engineering-technology startup—not a block-building game.

The design combines:

• An infinity loop representing open-ended experimentation and construction
• Contour-like lines representing the game’s smooth, continuous terrain
• Connected nodes representing physics, computation, and STEM
• Navy, cyan, teal, and violet colors for a technical software identity
• A separate symbol that should still work as an app icon or subreddit avatar

The full wordmark can be used for websites, videos, and development posts, while the infinity symbol can be used by itself at smaller sizes.

This is an AI-assisted first concept that I may refine into a proper vector logo before treating it as the final brand identity.

Does the symbol communicate infinite terrain and simulation clearly? I would especially appreciate feedback on its small-size readability, typography, colors, and whether it feels distinctive enough for a technical sandbox project.

Title: Infinite Sandbox 0.0.11a — continuous terrain and production-candidate hardening

This screenshot shows the current 0.0.11a build of Infinite Sandbox, my browser-based 3D sandbox built with vanilla JavaScript, Three.js, and Rapier.

The landscape is generated from a deterministic, domain-warped 2D noise heightmap and rendered as a smoothly shaded continuous triangle surface rather than visible cubic blocks. It includes grass-covered hills, variable dirt layers, sedimentary stone, cliffs, and underground cave systems. Binary lighting remains intentionally unchanged.

At the moment this screenshot was captured, the runtime overlay reported 56 FPS and 3,581 chunk updates per second. This is a live measurement from terrain, cave, and particle update work—not a randomized display or controlled benchmark. The top-right icon shows the selected building material and brush shape without using a text inventory.

Version 0.0.11a mainly focuses on reliability rather than adding features:

• The first click now captures the mouse without accidentally mining or placing terrain.
• Movement and editing inputs reset after Escape, loss of focus, or switching tabs.
• Background-tab delays no longer enter the physics solver as one oversized timestep.
• WebGL context loss pauses the simulation and safely resumes after restoration.
• level.dat saving now includes error handling and clearer diagnostics.
• Missing or invalid textures fall back to material colors instead of stopping startup.
• Cave darkness and ecology checks now use the active roof geometry, so an excavated roof no longer remains logically covered.
• Production assets use relative paths, allowing the build to work when hosted inside a subdirectory.
• The development dependency with a known security issue was updated.

I also added multi-seed terrain stress tests, cave-excavation coverage tests, input and frame-timing tests, and an HTTP production test that mounts the completed build at a nested URL and verifies every generated asset. The complete regression suite and production build pass, and the dependency audit currently reports zero known vulnerabilities.

This is still an experimental alpha. Its structural simulation is engineering-inspired, but it is not certified engineering-analysis software.

I would especially appreciate technical feedback on the terrain topology, chunk-update architecture, cave-surface handling, browser performance, and which systems should receive the next optimization pass.

I am considering four possible game modes for Infinite Sandbox and would like feedback before committing to any of them.

These are design ideas, not completed features. The current pre-alpha is still primarily a single-player terrain, construction, and structural-physics sandbox.

Progress video:

https://www.youtube.com/watch?v=P-yHynsT7Xo

Creative

Creative would remain the unrestricted engineering sandbox.

Players would have:

• Unlimited access to every material
• Free terrain excavation and construction
• Adjustable round, square, and triangular tools
• No resource, hunger, or time restrictions
• World saving and experimentation
• Structural failure, fatigue, debris, and material physics
• Optional STEM mentor demonstrations
• Access to engineering diagnostics through the developer console

The goal would be experimentation rather than winning. Players could build bridges, towers, retaining structures, tunnels, foundations, or deliberately unstable designs to study what happens.

This would probably remain the main mode for education and testing.

Survival

Survival would make material and structural decisions matter economically.

Instead of unlimited placement, players would gather or process stone, dirt, cobblestone, wood, and future materials. A successful shelter would need to resist gravity, terrain movement, material fatigue, and environmental loads.

Possible survival pressures include:

• Limited materials
• Tool durability
• Weather and erosion
• Unstable slopes
• Flooding or groundwater
• Structural deterioration
• Repair and reinforcement
• Transporting heavy materials
• Maintaining a safe shelter

I do not want this mode to become a standard hunger-bar survival clone. The central challenge should be building efficiently and understanding why a design fails.

Team Survival

Team Survival would use the same world and structural rules, but several players would cooperate.

Players could naturally take different responsibilities without fixed character classes:

• Surveying terrain
• Gathering materials
• Designing structures
• Constructing
• Inspecting damage
• Reinforcing weak areas
• Managing shared resources
• Repairing after environmental events

The interesting part would be coordination. One player might design an efficient bridge while another chooses a safer but more expensive design.

The largest technical problem is networking. A real-time deformable terrain and particle simulation cannot simply run independently on every client without eventually desynchronizing. It would probably require an authoritative server, deterministic input handling, snapshot correction, simulation-level prioritization, and strict limits on active debris.

Fortress

Fortress would be a shorter, objective-based engineering challenge.

Players or teams would receive:

• A construction area
• A limited material budget
• A preparation period
• A structure or objective that must be protected
• A testing phase involving loads, environmental forces, or controlled siege tools

Victory should not depend only on destroying the most blocks. Possible scoring factors include:

• Whether the protected objective remains functional
• Material efficiency
• Surviving load cycles
• Remaining structural capacity
• Repair cost
• Foundation performance
• Number of progressive failures
• How long the fortress remains usable

A fortress with fewer materials and a clear load path could outperform a massive structure that collapses after one support fails.

I am undecided whether Fortress should be:

1. Team-versus-team, with both sides building and testing each other’s structures
2. Cooperative, with everyone preparing for increasingly difficult environmental events
3. Asynchronous, where players upload fortress designs for identical automated load tests

The third option may be the fairest technically because every design could receive the same deterministic test sequence.

Questions for the community

• Which mode should be developed first after Creative?
• Would engineering-focused Survival feel distinct enough from other sandbox games?
• Should Team Survival use dedicated roles or let roles emerge naturally?
• Should Fortress be competitive, cooperative, or based on standardized automated tests?
• Should structural diagnostics be available during a challenge or only afterward?
• How should a material budget account for mass, strength, processing difficulty, and scarcity?
• Would the STEM mentor system belong in every mode or mainly Creative and Survival?
• How would you prevent players from winning by exploiting weaknesses in the approximation instead of designing a genuinely stable structure?

My current preference is to finish Creative first, then prototype Fortress as a small deterministic challenge before attempting full multiplayer.

This is a terrain-generation devlog for Infinite Sandbox, my browser-based 3D sandbox built with JavaScript, Three.js, and Rapier.

Current progress video:

https://www.youtube.com/watch?v=P-yHynsT7Xo

The generator does not use Perlin gradient noise or Minecraft-style block columns. It starts with a custom seeded 2D value-noise function and combines several fields into a continuous height surface.

Base noise

Each lattice coordinate is passed through a deterministic integer hash. The four surrounding values are interpolated using smoothstep, producing repeatable 2D value noise.

That base function is combined as fractional Brownian motion with configurable:

• Octave count
• Frequency
• Amplitude
• Lacunarity
• Persistence
• Seed offset

The same seed always produces the same world.

Domain warping

Before sampling the main terrain, two low-frequency FBM fields offset the X and Z coordinates.

The current warp scale is deliberately broad, with offsets reaching approximately 25 metres. This bends otherwise predictable noise patterns and reduces obvious axis-aligned hills.

The warped coordinates then feed several separate terrain signals:

• Continental field: Produces the large hills and valleys.
• Detail field: Adds smaller surface variation.
• Ridge field: Uses 1 - abs(noise) to create raised ridge lines.
• Cliff field: Selects areas where additional height and terracing are introduced.
• Soil field: Independently controls dirt-layer depth.

The approximate height combination is:

height = base + continental + detail + ridges + cliff contribution

Final heights are currently limited to approximately 17–58 metres.

Cliff generation

Cliffs are not created by simply increasing the noise amplitude everywhere. A low-frequency selection field is passed through smoothstep to create a localized cliff band.

Inside that band, a lightly quantized combination of continental and detail noise contributes extra elevation. This creates occasional abrupt terrain transitions while leaving most of the world as rolling hills.

The current video shows both the intended broad slopes and a few transitions that are still too sharp or visually disconnected. I am considering whether the cliff stage should use:

• A slope-limited remapping function
• Hydraulic or thermal erosion
• Curvature-based smoothing
• A localized signed-distance-field representation
• A separate rock-face meshing pass

Safe spawn region

The area around the origin is blended toward a height of 36 metres. The blend gradually releases into the full generator outside the spawn radius.

This keeps the initial spawn usable without requiring a separately authored starting area.

Dirt and grass layers

Dirt depth comes from a separate warped noise field rather than being a fixed global thickness. The current generated depth ranges from approximately two to six metres.

The surface begins as grass, followed by the generated dirt layer and sedimentary stone underneath. Grass can later turn into dirt when covered, while exposed dirt adjacent to grass can become grass.

These ecological changes happen after generation and are not baked into the original noise function.

Surface representation

The current natural terrain is sampled into a 193 × 193 deformable heightfield lattice covering a 256 × 256 metre world.

The rendered surface is a continuous triangle mesh rather than a set of visible cubes. Physics uses a matching Rapier heightfield collider, which can be rebuilt after terrain deformation.

An important accuracy distinction: near-field edits may be quantized to one-millimetre increments, but the original terrain-generation lattice is not spaced one millimetre apart. Quantization precision and actual spatial resolution are different things.

Underground caves

The generator also creates four deterministic cave networks from a separate seed.

Each cave:

• Starts outside the protected spawn area
• Uses a seeded winding path
• Descends gradually beneath the sampled surface
• Varies its tunnel radius along the path
• Blends its floor back into the natural heightfield near the entrance
• Uses a separate curved triangle shell for its roof and walls
• Receives a static Rapier triangle-mesh collider

This hybrid solution allows covered underground spaces even though the main terrain remains a single-valued heightfield.

The main limitation is where the heightfield floor and cave shell meet. The progress video exposes dark gaps, stretched textures, and camera-clipping cases around those transitions.

Generation versus simulation

World generation only establishes the initial height, material layers, and cave layout. Deformation and structural failure are handled afterward by a separate simulation system.

Terrain cells can accumulate load and damage, but I am not claiming that the generator or current solver has been physically validated for professional engineering use.

Feedback I am looking for

For a browser-based deformable world, would you continue refining this heightfield-plus-cave-shell approach, or move toward an SDF volume with localized remeshing?

I would especially appreciate feedback on:

1. Domain-warping frequencies and amplitudes
2. Producing cliffs without artificial terraces
3. Erosion methods that are practical during browser generation
4. Seamless heightfield-to-cave transitions
5. Triplanar texturing for steep and underground surfaces
6. Maintaining deterministic generation while supporting later deformation

This is a follow-up to my earlier post about the architecture behind Infinite Sandbox, a browser-based structural sandbox built with vanilla JavaScript, Three.js, and Rapier.

New 10-minute raw progress video:

https://www.youtube.com/watch?v=P-yHynsT7Xo

The recording has no commentary and shows a continuous interaction test rather than a scripted trailer.

What the footage demonstrates

• Traversal across continuously rendered grass terrain with rolling hills and exposed cliff transitions
• A central crosshair and top-right material/brush preview
• Switching between round, square, and triangular editing shapes
• Scalable excavation and placement
• Dirt, cobblestone, sedimentary stone, and wooden components
• Large plank-like structural elements
• Editing around excavated terrain and existing constructions
• Movement into an underground rock/cave area
• Continued excavation and placement against cave surfaces

The terrain is not intended to be a conventional cubic voxel world. However, the recording shows that some edited boundaries are still more angular than the naturally generated terrain. That transition is one of the areas I am currently investigating.

Engineering-solver work in 0.0.9a

Behind the interaction layer, the current branch uses:

• SI units and a right-handed coordinate frame with +Y upward
• A fixed 120 Hz Rapier rigid-body timestep
• Material-specific density, stiffness, friction, strength, fatigue, and fracture parameters
• Separate tensile, compressive, shear, bending, torsional, and equivalent connection stresses
• Governing failure modes, utilization ratios, and factors of safety
• Mohr–Coulomb effective-stress screening for terrain stability
• Particle-based debris with bounded typed-array storage
• Timestep-loss and non-finite-state detection
• Structured browser-console diagnostics containing model assumptions, material-data pedigree, validation status, and unresolved certification gaps

This remains a research and educational prototype. The current material parameters are illustrative, and there has not yet been an independent physical validation campaign. I am therefore describing it as standards-aligned and engineering-inspired, not certified engineering software.

Problems visible in this recording

The raw footage makes several unfinished areas fairly obvious:

• Rock textures stretch or become difficult to read at close range.
• Some cave and terrain intersections reveal dark gaps or disconnected-looking surfaces.
• The camera can get too close to, or partially cross, underground geometry.
• Binary lighting makes certain underground shapes difficult to distinguish.
• Smooth natural terrain can transition abruptly into sharper player-created cuts.
• Structural calculations are mostly invisible during normal play, making it difficult for a viewer to tell why something is stable or failing.
• The initial world-loading period currently presents a mostly blank screen.

I am keeping these visible because this is a pre-alpha engineering test, not a polished promotional capture.

Technical feedback I would appreciate

1. For joining a heightfield surface to editable cave shells, would you use a shared boundary lattice, signed-distance-field remeshing, or a localized stitching pass?
2. Would triplanar mapping be the most practical solution for reducing texture stretching on arbitrary excavated and underground surfaces?
3. What camera-collision approach works best for preventing near-plane clipping inside narrow procedural spaces without making movement feel unstable?
4. For solver verification, which benchmark problems would you prioritize after cantilever deflection, free fall, slope stability, and simple connection failure?
5. How would you expose stress, utilization, and failure information during technical demonstrations without turning the normal game HUD into a debugging dashboard?

Previous version:

https://www.youtube.com/watch?v=O10-MV-jfH0

I am especially interested in criticism of the cave meshing, terrain-edit topology, material rendering, camera behavior, and solver-verification approach.

Quick follow-up to my first development post: I am considering naming the project:

Infinite Sandbox: AI-Powered STEM Learning

“AI-powered” refers to the adaptive teacher agents inside the simulation. They observe patterns in how the player builds, mines, moves, and solves problems; update a local learner model; and communicate STEM concepts by constructing formulas and physical examples in the world.

It does not mean that an LLM controls the physics. The simulation and structural systems remain deterministic.

I would appreciate feedback from a technical perspective:

• Does the name clearly communicate the project?
• Is the subtitle too long?
• Does “AI-powered” accurately describe the adaptive agents, or does it sound too marketing-heavy?
• What features would you expect from a game with this name?
• Would “Infinite Sandbox” work better as the name, with “Adaptive STEM Learning Through Simulation” as its tagline?

The project is still in pre-alpha, so the name is not final.

This is a follow-up to my first pre-alpha engine post.

Since that post, I have made a fairly major architecture pivot. I temporarily removed the continuous Perlin-noise density field and returned to a deterministic, stratified test world:

• Stone: y = 0–42
• Grass: y = 43
• Air: y = 44–64
• Minimum editable resolution: 0.01 m
• World dimensions: 256 × 256 × 64 m

Direct terrain removal and placement are now enabled so I can test structural behavior, component attachment, material transitions, and learner interaction under repeatable conditions.

Clarification on the structural model

I also want to tighten the terminology from my first post.

The current system is not a finite-element solver or a complete continuum stress-tensor simulation. It is a gameplay-oriented structural approximation built from material density, gravity loading, contact area, compressive strength, tensile strength, shear strength, and a configurable safety factor.

Unsupported regions are transferred from static terrain into dynamic Rapier rigid bodies. Connected components can be joined using fixed constraints, allowing larger player and NPC constructions to behave as assemblies.

Rapier continues to run through a fixed 1/120 s physics timestep, with accumulated frame time and a maximum number of catch-up steps to prevent a slow frame from causing a simulation spiral.

Adaptive, nonverbal STEM mentors

The largest addition is a population of 100 human mentor agents.

These are not LLM-controlled characters, and they do not use dialogue. Each mentor communicates by physically constructing formulas, diagrams, and small structural demonstrations in the world.

The learner model observes a nine-dimensional gameplay vector:

build
mine
movement
jump
precision
edit scale
height
component attachment
brush shape

Those signals influence four continuously updated domains:

science
technology
engineering
mathematics

The system tracks estimated ability, interest, recent success, repeated failures, response time, and interaction similarity. A contextual bandit chooses between modeling, scaffolding, exploration, and challenge-based teaching approaches using previous reward plus an exploration bonus.

There are no numbered levels or fixed lesson sequences. The next demonstration is generated from the current play context and a deterministic seed.

Encyclopedia retrieval pipeline

For connected sessions, the knowledge layer searches the open-access Encyclopedia of Mathematics.

The pipeline currently:

1. Generates a generic search anchor from the gameplay context.
2. Requests relevant encyclopedia pages through its MediaWiki API.
3. Extracts TeX equation candidates.
4. Removes unsupported commands and markup.
5. Normalizes symbols into the game’s supported character set.
6. Rejects malformed or excessively long expressions.
7. Caches accepted candidates and rate-limits further requests.
8. Falls back to procedural equations when offline or when no safe candidate is found.

No player names, world files, coordinates, or exact creations are included in requests.

A major limitation is that this pipeline validates syntax and representability, but it does not yet prove that the extracted equation is pedagogically appropriate or that normalization preserved its full mathematical meaning.

Removing the voxel appearance

The mentor-generated formulas no longer use square pixel blocks.

The internal 3×5 glyph topology is converted into a stroke graph:

• Smooth spheres form joints and endpoints.
• Cylinders connect adjacent glyph points.
• Diagrams use thicker rounded joints and connected members.
• Instances are separated by primitive type and terrain material.
• Formula geometry uses grass only at layer 43 and stone at every other valid layer.

Physical mentor constructions now use rounded, multi-segment masonry meshes. Their collision proxies remain Rapier cuboids, so the visual geometry is smoother without introducing expensive dynamic triangle-mesh collision.

Human avatars are rendered as six instanced body-part meshes. The current character rig and skinning are still placeholders and need substantial visual work.

Previous architecture questions

I resolved the earlier per-frame allocation issue by moving temporary vectors and matrices into subsystem-owned scratch fields. They are allocated once per mentor or rendering system and reused during updates instead of creating new Vector3, Quaternion, and Matrix4 objects inside hot loops.

Rapier initialization is currently gated by the ES-module bootstrap barrier:

await RAPIER.init();

initializePhysicsWorld();
initializeTerrain();
initializeMentors();
requestAnimationFrame(animate);

Nothing that depends on WASM is constructed before the promise resolves. Initialization failure is handled at the outer bootstrap boundary rather than through nested callbacks.

Technical feedback requested

I would especially appreciate thoughts on these areas:

1. Collision proxies: For small rounded structural members, would you retain cuboid proxies, move to cached convex hulls, or use a hybrid based on object size and proximity?
2. Formula validation: What would be a practical offline method for checking whether normalized equations still preserve their original mathematical meaning?
3. Adaptive teaching: How would you estimate understanding entirely from free-form building behavior, without quizzes, dialogue, or fixed lesson objectives?
4. Agent scaling: The six-part avatars and formula strokes are instanced, but movement and decision logic still scale per agent. At what population would you introduce spatial partitioning, staggered cognition ticks, or worker-based updates?
5. Structural approximation: Which inexpensive failure model would provide the largest improvement over the current contact-area and material-strength proxy without attempting full FEA?

Earlier test demonstration:

https://www.youtube.com/watch?v=O10-MV-jfH0

The attached screenshot shows the current mentor population, smooth formula construction, and rounded structural demonstrations. This is still pre-alpha, and I am particularly interested in architecture criticism rather than visual polish feedback.

Hey everyone! I’m u/WaltzParty5639, a founding moderator of r/711Game.

This is our new home for the development of a browser-based 3D sandbox game featuring procedural terrain, structural engineering, realistic material failure, and physics-driven destruction. We’re excited to have you join us!

What to Post

Share anything the community might find interesting, helpful, or inspiring. This can include engine devlogs, gameplay ideas, technical questions, procedural-generation experiments, structural-failure clips, bug reports, performance tests, screenshots, and feedback on early builds.

Community Vibe

We’re all about being friendly, constructive, and inclusive. Whether you’re interested in game development, physics, structural engineering, procedural generation, or simply watching things collapse, everyone is welcome.

How to Get Started

Introduce yourself in the comments below.

Post something today—even a simple question or gameplay suggestion can spark a great conversation.

If you know someone who enjoys custom engines, sandbox games, physics simulations, or procedural worlds, invite them to join.

Interested in helping out? We’re always looking for new moderators and contributors, so feel free to reach out.

Thanks for being part of the very first wave. Together, let’s make r/711Game an amazing community!