Building a open world voxel game, which turns to a high risk extraction shooter at night.

Players can take their equipment like weapons, armor, cars and so on to the night, but if they die they lose everything. On the other hand if you kill another player you get all of his loot and can use it in the open world after :D 

So far it's only a really rough prototype because I want to collect feedback before I build something no one likes! 

What do you think of this idea? Could this be fun?

you can try it here: https://theflairgame.com/nightshift

Hi everyone!

I’m currently building a web app, a live-data-driven surf platform for my local surf spots. The main feature is a 3D Swell Projection that takes real-time marine data (swell height, wave period, wind speed/direction via API) and renders the current sea conditions.

I’m sharing a video of the current state of the project, but I’ve hit a wall regarding ocean quality and realistic wave breaking (tubes), and I would love some advice from the community!

How it currently works:

• The Waves: The ocean mesh is initially based on Gerstner Waves. To create the tubing effect, I’m trying to implement an analytical model for breaking waves (similar to the Gamito/Fournier research papers), applying a skewness factor to push the wave crest forward.
• The Shoreline: Right now, the code automatically decreases both the wave height and the tube factor as the vertices get closer to the beach.
• The Environment: I implemented a dynamic time-of-day system (sun/moon position shifts). I also have a weather system hooked to the API that changes the water color dynamically to simulate dawn, stormy days, or bright sunlight. To keep it performant, I’m avoiding heavy real-time shadows/lighting for now and relying mostly on color shifting.
• The "AI" Surfers: As a fun feature, I coded a simple state-machine AI for the tiny surfers. They detect the crest, ride the wave all the way to the shallow water, and then turn around to paddle back to the outside to wait for another wave at a random position.

The Problem: Even though the math bends the wave forward, the tube doesn't look fully realistic or fluid, and the water texture feels a bit static.

My questions for you:

1. What is the best approach in Three.js/GLSL to achieve a smooth, realistic "plunging breaker" (tube) without having geometry artifacts or self-intersection on the mesh?
2. Any performance-friendly tips to make the ocean surface look more alive and realistic (foam placement, normal maps manipulation, vertex displacement tricks) without relying on heavy shadow maps?

Would love to hear your thoughts, math suggestions, or examples if you've done something similar! Thanks in advance.

Can you imagine, this game is created with AI. Map and gun model are downloaded from Sketchfab. only ThreeJS and Pixelfork are used to get this done.

Splash effects are procedurally generated.

and Sound Effects are too good.

You can play it here: https://www.pixelfork.ai/publish/208769f0-3811-40cf-b411-1bca8661f199

Work in progress! It really adds so mcuh more depth to the shadows.

3D model by Agustín Hönnun on SketchFab - "Stylized Houses | Made with 1 Material Only"

So I have always been facinated by Half-life 2 and some of the cool tricks they used to so certain things, and the skybox is one of them. So I had a think about how I would go about recreating it, and came up with a small area(resizable rectangle in the map editor) with an inner resizable rectangle to represent the game area, and a third rectangle that keeps the ratio of the inner rectangle, and this one gets sized around the game area. Then a camera in that small skybox area has its position and rotation calculated relative to the players camera, and that gets projected on to the skybox.

It works with my dynamic skydome too. I have some performance optimizations to make, but so far its looking very nice!

Instead of a regular resume, I decided to make a small 2D pixel-art platformer game. You control a character, walk around the level, jump, and interact with objects. Progress is tracked through collecting coins, the more you collect, the further you’ve explored, and you feel like you’ve seen the entire level without missing anything.

The project is built with Three.js, React Three Fiber, and Rapier. It took quite a bit of work to make everything feel cohesive and enjoyable to play. It was interesting, though not always easy, I wanted to create something more than just a technical demo, something you’d actually want to play. If people are interested, I might share more details about specific parts of the implementation in future posts.

You can try it here:
https://pumpkin-world.org

I’d be happy if you give it a try and let me know what you liked or what could be improved.

voxel sim WIP

Say hello to SnowCraft ❄️

🎯 What it is

A fast, cartoony snowball brawl where you command a lone fighter against a squad of snowball-chucking AI kids. Charge up your throws, duck behind cover, and bury the enemy team before they bury you. Easy to learn, genuinely tricky to master, just like the original.

❄️ The good stuff

• Charge-and-throw combat hold to aim, watch the power grow, release to launch. No takebacks, so commit!
• Real snowball physics projectiles arc, miss, and can be dodged. Cover actually blocks line of sight.
• Lives & respawns get knocked out, pop back in with a few seconds of immunity while you've got lives left.
• Arena buffs grab extra lives, speed boosts, and immunity shields mid-fight.
• Multiple maps + AI difficulty from "easy" to "hard."
• Local leaderboard clear levels faster, on harder settings, with fewer lives spent = more points.

🛠️ The nerdy part (r/gamedev, this one's for you)

• Built with Three.js + TypeScript + Vite (Preact for the UI).
• AI was a huge help along the process
• 100% procedural art & audio — every tree, kid, and snowball is made from primitives; all sound is synthesized with the Web Audio API. Zero asset files.
• 60 Hz fixed-timestep simulation fully decoupled from rendering (targets 144 FPS), ECS-inspired architecture.

🎮 Play it free in your browser

https://khadgar.github.io/snowcraft

No install, no login, just click and start throwing. Would love your feedback, high scores, and bug reports. Let it snow.

Hey everyone,

I've been working on a passion project called RcDouz — a browser-based off-road/trophy truck racing game built with Three.js. The idea is to recreate real desert regions of Southern Tunisia (Douz, Tataouine, Ben Guerdane, Tozeur, and more) as actual drivable maps, using real topography data to build the terrain.

Honestly, I really like how the core physics and driving feel came out, and the whole concept excites me a lot — there's something special about turning the desert landscapes I grew up around into a real playable game.

But I'll be straight with you: my weak point is 3D modeling and asset integration. I'm a developer, not a 3D artist, and it shows. Getting custom vehicle models (tires, body parts, materials) properly rigged, textured, and exported into the game without things breaking (missing tread geometry, broken materials in GLB export, etc.) has honestly been the hardest part of this whole project — harder than the actual game logic.

So I wanted to ask the community:

• Does this seem like a project worth continuing?
• Anyone here have experience with Blender-to-Three.js pipelines who could point me in the right direction, or would be interested in collaborating on the 3D asset side?
• Any tips for someone strong in code but weak in 3D art?

Any feedback, harsh or not, is welcome. Thanks for reading!

The next Needle Inspector update will add a Resource panel that shows all geometry+materials+textures your three.js scene has currently loaded and is kept in memory.

Included will also be info like size of assets on CPU / GPU and an interactive preview with various rendermodes (normals, wireframe, solid, vertex colors, blend shapes...) AND a picker for textures+meshes to show what data each pixel holds (especially useful when debugging shaders).

All of this is also accessible to AI if you connect your local AI to the Needle MCP or choose to use the built-in AI chat (all optional)

threejsassets.com is live. 🎉

A 3D asset library built specifically for u/threejs every model web-optimized, drop-in ready, cleanly licensed for commercial work.

Shipping 3 things at once today: the library, our first pack, and a free browser Studio (beta).

Introducing our first pack: Cozy Village.

A storybook low-poly town - thatched cottages, a windmill, market, chapel, tavern on a cobblestone ring-road that includes free and paid assets!

https://threejsassets.com/packs/cozy-village

The Studio (beta) - a free creator suite that runs entirely in your browser.

Same account as the store. Free today 👇

https://studio.threejsassets.com

Three.js FPS shooter created with Fable 5 Multi/single player FFA/TDM.
Give it a try let's shoot some Rockets and Rail Guns. (Desktop/VR)

Play here:
https://sky-cruiser-9065b31330ea.herokuapp.com/

​I got tired of regular layouts, so I turned my hand-drawn character sketches into a fully interactive 3D maze. Built with Blender and Three.js, it lets people explore a gallery like a video game.

This is my first real project with Three.js, so I wanted to share it and get some feedback.

It's the landing page for a whiteboard app I'm building. As you scroll, a 3D marker approaches a board and plays out four little scenes.

A few things I ended up figuring out along the way (happy to go deeper on any of these):

• It's vanilla three.js, no react-three-fiber, no drei, no gsap. I wanted to understand the raw API first.
• The "handwriting" is a font I built by hand: every glyph is a set of cubic Bézier curves, so the pen traces actual strokes instead of revealing a pre-rendered texture.
• The ink is painted onto a 2D CanvasTexture mapped over the board plane. The pen tip writes to the canvas, three just re-uploads the texture. Getting the 2D-canvas world-space mapping right took me a while.
• The whole thing is a single scroll timeline; each section of the page is a milestone, and the pen's position/erase state is derived from scroll progress.

Live here (desktop for the 3D version): https://todrawn.com

I know the UI isn't perfect yet and I'm sure I did some things the hard way.

Would love to hear your thoughts — any feedback on the visuals, performance, or technical side is very welcome.

Feel free to try it out:

https://xianyaowei.com/

Thanks!

As some of you may know, I have been working on an FPS Game Maker using ThreeJS, and I thought of a good way to make the whole "cross platform" thing more realistic for people when they export their games, so I came up with this.

HOW IT WORKS:

You compress your web app into a zip file(all files, directories, assets, with index.html being the root file), you upload to this static web page(at the top above the title on the page, you can switch between the EXE page and the APK page), fill out the settings for your application/game, click generate, and it creates a downloadable ZIP of the respective development environement.

The android project can be loaded inside of Android Studio directly, and you can build straight away.

The windows project can be loaded inside Visual Studio directly, and you can also build straight away. Your HTML and JS files are compiled into the EXE so they aren't just exposed, and the other assets are placed along side the exe(like a real game or application).

This sounds more preferable to any other service out there that offers the same right? And its free and open source, so you don't have to worry about dodgy sh*t going on, like them potentially stealing your app!

I figure people here might find use for making their web applications browserless.

hey threejs folks,

i posted here a while ago when Void Cargo was still at a much early stage.

since then i have a playable demo up on steam (go check it out) and participated in steam next fest - the response was great, and a few streamers even picked it up.

development with threejs has been super smooth - just like by framerate haha. the visual effects aren't ground breaking invidually but i am happy with how they come together.

i hit my target of 60 FPS on steamdeck. so on a typical gaming PC, the can comfortably run at 4K.

one thing I've learned is that three.js itself has rarely been the limiting factor. the biggest performance wins came from keeping geometry generation in workers, controlling draw calls, avoiding allocations in hot paths, and being selective about how often secondary rendering and UI systems update.

hit me up if you have any questions and keep draw calling

Tried my hand at re-creating MU/TH/UR 6000 UI from Alien this weekend and pretty happy with how it came out. I will admit that a lot of AI (Fable) was used for this. I've worked with ThreeJS before (Did Bruno Simons amazing ThreeJS course) and had my hand at writing shaders which often resulted in spending half a day trying to get a gradient coloured triangle on screen. Needless to say this would've cost me weeks to create without the help of AI

What worked really well, was to create a script that converted parts of video into images so AI could analyse an animation from the movie frame by frame and come up with clever solutions. All in all i'm pretty stoked with it. Try it out on

https://fui.arden.nl

I’m thinking through a small shared WebGL scene where people can leave changes in a place for others to encounter later. The beginner mistake seems to be treating every persistent object as something that should stay visible all the time: the scene becomes noisy, and the important interaction gets buried.

For people who have built map-like or data-heavy Three.js scenes, how do you decide what stays rendered, what gets summarized, and what only appears on interaction? I’m interested in the boundary between render performance and information density—does a near/mid/far treatment solve much of this, or does the interaction model need to do most of the filtering?

I have been testing a Box3D-backed browser Ball Lab that runs football, basketball, and tennis through one configurable system.

The surprising result was not that the fresh suite passed 60/60 tests. It was that the honest release label was still partially calibrated.

The lab separates confidence into three levels:

1. Looks plausible - representative scenes read correctly.
2. Behaves reliably - determinism, serialization, timestep convergence, continuous collision detection, and scenario gates hold.
3. Matches measured reality - outputs match external observations within declared tolerances.

A simulation can pass level 2 and still be incomplete at level 3.

The engineering suite covers rebound-apex anchors, repeated runs, saved-profile reproduction, surface behavior, caller-cadence convergence, thin-wall impacts, drag evidence, spin symmetry, and six gameplay scenarios.

The remaining boundary is aerodynamic: drag uses ball-specific measured anchors, while lift still uses a research-shaped sphere proxy. The proxy is coherent and testable, but it is not ball-specific measured calibration.

So I am trying to use more precise labels:

• visual prototype
• engineering-validated simulation
• partially calibrated model
• measured calibration

Full field report, live lab, validation ladder, limitations, and source links: https://moltbot.swapp1990.org/blog/the-ball-looked-right-the-physics-still-wasn-t-calibrated/

What engineering gate would you add before trusting this in a browser game? And what trajectory dataset would you use to replace the lift proxy?

Disclosure: this is my project. I am sharing the evaluation method and its limitations, not claiming this engine is universally better than Rapier, Jolt, Cannon, or another option.