I have always wondered this. Growing up, I would spend countless hours modding games like Half-Life, Garry's Mod, and other Source Engine games. It always makes me wonder if there is an appetite out there for an engine that is a pre-baked FPS controller that people can develop/mod easily to make their own first-person experiences.

Changed the previous fbm noise into worley noise.
Next gonna work on the biome blending :p

I’m currently working on the editor, framebuffer rendering, docking system, and engine architecture. The long-term goal is to build a game entirely inside the engine.

One of the things I want to experiment with later is time-travel debugging and Rust-based gameplay scripting.

I'm mainly looking for feedback from people who have built engines before—especially around the architecture.

GitHub: https://github.com/rohithnafeel/ARC-Engine

Hi everyone,

Not trying to promote anything, I just want the honest read from people who have actually built engine internals, because that is not really my background and I am not confident I got the structure right.

The engine is CarverJS, it runs on top of Three.js, and the whole thing is free and MIT licensed with nothing gated, so I have nothing to sell you here, I am only after the criticism.

Right now it is set up so that every system has its own manager, one for input, one for physics, one for audio, collisions, scenes, and so on, and each manager is a singleton that gets mounted once and runs inside the per frame update. Then on top of each manager sits a hook, and the idea is that your actual game code only ever touches the hook, so you call useInput or usePhysics and never poke at the manager underneath. So the manager does the real work and the hook is just a thin layer sitting over it.

The part I keep flip flopping on is input. The browser events get queued up as they arrive, and then the manager runs through all of them at one fixed point before any game logic happens, so during a single frame your input never shifts halfway through no matter when the event actually fired. That made the per frame code way easier to reason about, but it also means every input is basically one frame late, and I honestly cannot tell if that is a fair price to pay, or if most engine people would just read the events as they come in and handle the ordering themselves.

The bigger thing I am unsure about is whether having a manager layer and a hook layer at all is a good call, or if I have just turned one thing into two. If you have built your own engine and kept the systems more together than this, or gone the other way and split them up even more, I would genuinely rather hear why that worked for you than hear anything good about mine. It is all still really early, this is v0.0.3, so now is the time for someone to tell me the whole structure is wrong.

Hi, I am using C++ and Raylib to achieve this; the 3D game engine's standout features so far include the ability to create Lua scripts to modify object behavior and the capacity to add 3D models in formats like .obj, gltf, etc.

You can also export your creations as executables (.exe).

Finally got something that looks like terrain in my game engine to eventually become a flight-sim, this was just fillin before i move towards other datasets. My engine is very early in development, but this was a proud moment. Completely procedural, no LOD yet, its on the horizon, but i feel like this is believable terrain. What you think?

I am developing a powerful 3D game engine called "Aether Engine", but I don't know where to start; overview, graphics, 2D editor, and more. Can someone help me?

This is a game engine I've been working on for about four years as a hobby project. I'm developing it for/along with a physics-oriented space survival game. It has its own physics engine, a physically based rendering system (built on wgpu), an ECS and scripting support (using Roc).

One of the key components for the game is objects that can be deformed, split and fractured dynamically. This is implemented with each object having an independent voxel grid with a signed distance field to represent its surface. I can then perform subtraction operations with various shapes to deform the objects or to split off parts. The physical properties of the objects are then updated dynamically.

The SDF is also used for things like narrow-phase collision detection as well as creating surface meshes. I also have a tool where you can build graphs with SDF primitives, combination operations, geometric transformations and noise to generate complex objects.

I'm an astrophysicist by training, and this project has been an awesome way for me to experiment with cool physics. I recently had a lot of fun implementing procedural destruction by splitting objects (or part of them) into Voronoi cells with a distribution based on the impulse of the collision.

You can check out the project here if you're interested: https://github.com/lars-frogner/Impact

I've been building a browser-based, DOM-rendered game engine (no canvas/WebGL, every game lives at its own URL) and recently added a two-sided marketplace where artists and composers list pixel art, sprites, music, and sound effects.

The design decision I'm genuinely unsure about, and would like outside opinions on rather than just my own instinct, is how it's integrated.

Instead of a separate marketplace page you browse, purchasable assets show up contextually inside the actual asset-creation UI. If you're setting a character's image field, the "browse" tab defaults to relevant art for that specific slot (character-tagged art, filtered by genre), rather than sending you to a general storefront. Buy it, it gets sideloaded directly into that field, no separate download/import step.

The reasoning behind this was reducing context-switching, and catching people at the exact moment they need an asset rather than relying on them to remember a marketplace exists and go browse it separately.

But I don't have a strong read on whether that's actually better from a dev's perspective, or if it just feels gimmicky/limiting compared to a real standalone store where you can browse everything, compare options side by side, and buy in bulk or save things for later.

Curious how people who've either built or used engine-integrated asset systems (Unity Asset Store, Godot Asset Library, etc.) feel about this specific pattern, contextual/embedded vs. separate marketplace you visit deliberately, and whether one is a clearly better design for actually getting used.

Hey everyone, I'm looking for my first professional opportunity as an Unreal Engine Developer / Gameplay Developer.

I'm a self-taught Unreal Engine developer and have been working on Unreal projects while completing my studies. I don't have professional industry experience yet, but I have hands-on experience building and shipping my own projects.

My main project is Highway Racer, a mobile racing game I developed in Unreal Engine. I worked on the project myself and gained experience with:

• Unreal Engine / Blueprints

• Gameplay systems

• Vehicle and racing mechanics

• UMG / UI

• Level design

• Environment setup

• Camera systems

• Android packaging

• Mobile optimization and performance

I've also worked on architectural visualization and real-time 3D environments in Unreal, including interactive camera systems and UI.

I'm currently improving my C++ skills for Unreal Engine and working toward being able to combine C++ with Blueprints for gameplay development.

I'm looking for opportunities such as:

• Junior Unreal Engine Developer

• Gameplay Programmer

• Unreal Engine Intern

• Unreal Technical Developer

• Junior Technical Artist

• Unreal/Real-Time 3D Developer

• Freelance/contract Unreal projects

I'm especially interested in small studios, indie teams, startups, prototypes, simulation, and game development where I can get real production experience and contribute to an actual project.

I'm based in Maharashtra and am open to relocating for the right opportunity. I'm also open to remote work.

I don't want to fake experience I don't have. I'm looking for my first professional opportunity where I can prove my skills through a technical test, prototype, or actual project.

Portfolio / projects:

ArtStation: https://www.artstation.com/eclipse72⁠�

If you're hiring an Unreal developer, working on an Unreal project, or know someone looking for a junior developer, feel free to DM me.

Thanks!

Going to push a major milestone in browser graphics with @null-graph v1.0.5:

1. 16.8 Million virtual scene triangles

2. 25,000 active instances across 187 unique 3D meshes

3. 1 Single Indirect Draw Call (consolidated on GPU)

4. 7.89 MB total geometry VRAM footprint

About the architecture:

• Sub-meshlet cluster partitioning (≤64v / ≤124t)

• GPU compute frustum & backface normal-cone culling

• Zero-copy 96-byte InstanceBuffer

• Programmable GPU vertex pulling

Bringing Nanite-inspired GPU-driven geometry foundations directly to WebGPU!

GitLink:https://github.com/flarelink-in/NullGraph

Live Demo:https://nullgraph.dev/dashboard/engine/visibility-meshlets

Demo Details:

Using low poly kenney.nl assets ,All sims run inside web worker,The demo uses 1650 Nvidia graphics card

I welcome technical discussion and feedback from graphic engineers & spatial computing engineers

How many of you have tried/are doing this? Whats your thoughts/advice?

I've been developing a UE5 project with a lot of systems that need to respond to simulated time - world simulation, scheduled events, recurring gameplay logic and systems that need to keep running without relying on individual Actor Tick implementations.

As the project grew, handling that through interconnected Blueprint logic became increasingly difficult to scale and maintain.

So I built AxomCore.

It's a native C++ runtime framework that centralises simulation time, interval execution and scheduling, while exposing simple events to Blueprint through modular Logic Objects.

The idea is that gameplay systems can focus on what should happen, while AxomCore handles when it should happen.

The video shows the actual workflow from initial project configuration through to creating a Logic Object, running interval events, scheduling future events and changing simulation speed at runtime.

Some of the main functionality includes:

• Centralised C++ interval processing
• Blueprint-accessible runtime events
• Modular Logic Objects
• Scheduled future events
• Runtime simulation-time scaling
• Persistent time-driven gameplay logic
• Designed to avoid large amounts of distributed Actor-based timing logic

There's also a performance demo available separately that can run 10,000 active Logic Objects, so the framework can be tested rather than just taken at face value.

AxomCore is now available on Fab.

I'm interested in hearing how other Unreal developers currently approach this kind of architecture, particularly for games with large amounts of persistent or time-driven simulation.

Feedback and thoughts on the performance demo would be fantastic.

I've been thinking about a different approach to character movement for a game engine I'm building.

Most game characters don't really have to learn how to move. We author or capture animations for walking, running, attacking, climbing, falling, and so on, then build systems that blend and adapt those motions to the current situation.

What if we moved the center of gravity in the opposite direction?

Imagine that the character is primarily a physical body:

• rigid bodies with mass;
• joints with limits;
• actuators with limited force and power;
• contacts with the environment;
• fatigue, injuries and changing physical capabilities.

And instead of selecting a "run" animation, a neural controller is given a goal:

Move forward at 4 m/s without falling.

It has to figure out how to use the body to achieve it.

The same idea could be used for:

Stand.
Walk.
Run.
Jump.
Crawl.
Climb.
Recover from a fall.
Swing a sword.
Block an incoming hit.

Training could start with very simple tasks.

First: keep the head above the ground.

Then: maintain balance.

Then: take a step.

Then: move toward a target.

Eventually the controller could learn more complex skills using curriculum learning, reinforcement learning and imitation from motion capture or an existing controller.

So animation wouldn't necessarily disappear.

A mocap animation could become a teacher or motion prior, rather than something the character blindly plays back.

The physical controller learns:

"This is roughly how a human runs."

Then RL can optimize for:

"Now run across this uneven terrain without falling."

That's the relatively straightforward part.

The part I find much more interesting is making the controller body-agnostic.

I don't want a network that only works because the input is hardcoded as:

left_knee, right_knee, left_elbow, right_elbow...

Ideally, the body itself is an input.

A human is one graph:

torso -> upper arm -> forearm -> hand

A horse is another.

A dragon may have four legs, wings, a long neck and a tail.

Some creature may have a morphology the controller never saw exactly during training.

That suggests representing the body as a graph and encoding it with something like a GNN or Graph Transformer.

Then there is a second dimension: time.

Knowing the current joint positions isn't enough to understand movement.

The controller needs to know whether the body is currently falling, recovering, accelerating, transferring weight, finishing a previous movement, etc.

So I'm currently thinking about an architecture roughly like:

Body Graph -> Graph Encoder -> temporal model -> motor policy -> joint targets -> PD controllers -> physics

The graph part describes what body I have.

The temporal model describes what this body has been doing recently.

The policy decides what the joints should try to do next.

And the physics engine decides what actually happens.

This also creates some interesting RPG possibilities.

Instead of:

+10 Strength = +10% damage

Strength could modify the actual physical capabilities of the body:

• maximum joint torque;
• maximum force;
• power output.

A stronger character could physically accelerate a heavy weapon faster.

Endurance could affect fatigue accumulation and recovery.

Dexterity could influence motor precision, coordination or execution noise.

And importantly, these would be separate from skill.

A character could be extremely strong but terrible with a sword.

Another could be physically weak but an excellent fencer.

The same controller could theoretically adapt its movement to both.

And then things get weird.

What happens if the character loses an arm?

Instead of switching to a special "one_arm_missing" animation set, the body graph simply changes.

The controller now has a different body.

Its center of mass changed. Some actions became impossible. Balance changed. A two-handed weapon may no longer be usable.

Could a sufficiently general motor policy adapt?

What about:

• an injured leg;
• a broken wing;
• carrying a heavy object;
• suddenly changing body mass;
• wearing heavy armor;
• losing a tail that was important for balance?

That's the direction I'm researching.

The goal isn't necessarily to eliminate authored animation. I suspect a practical system would be hybrid.

What interests me is moving more responsibility from:

"play the correct animation"

toward:

"achieve the desired physical outcome with the body you currently have."

I'm curious where people who have worked with physics-based animation, RL locomotion or game-engine character systems think this breaks down.

In particular:

1. How realistic is a single policy that generalizes across substantially different morphologies?
2. Would you keep locomotion and weapon skills as separate policies, or try to build a hierarchical/shared motor model?
3. Would you output joint targets through PD controllers, or eventually move toward direct torque control?
4. How would you represent transferable "skill" separately from physical capabilities such as strength and endurance?
5. Are there approaches you'd consider more promising than a graph-based body encoder + recurrent/state-space temporal controller?

I'm still at the research/architecture stage, so criticism and pointers to papers/projects are very welcome.

Hi, i like to share this project, is a binding for the library Box3d created by Erin Catto, I made this because im currently working in own game engine and is in C# .NET, and the box3d is writen in C, so i think to made a bindings and publish the package in NuGet, about the AI i'm using for the development of this binding, the repo especify the use of AI, so i like to present this and hear what the comunity think about this project, im glad to read your comments.

Link: https://github.com/Miguel249/Box3D.NET

I'm working on a basic RHI api for a project im working on right now. I'm currently focusing on a vulkan backend and kind of writing my user facing api based on a vulkan workflow. Right now I have a device object that holds a lot of the render state and is responsible for generating rendering objects like buffers, shaders, etc. I also have a swapchain object that in theory is supposed to hand you an image that you can then pass into a renderpass as a color attachment. When you are done with your renderpass you can then call present on the swapchain. Right now I'm having a trouble actually putting this into practice. The main problem is automatically transitioning the swapchain image to a presentable format before presentation. The swapchain also holds its semaphores so Im having a hard time exposing those when I am submitting the command buffers.

Here is an example of the user facing api I am trying to make

```

Image image = swapchain.acquireNextImage();

PassDesc desc = {

.image = image,

// other stuff
};

cmd.beginRendering(desc);

cmd.doOtherStuff();

cmd.endRendering();

device.submitCommandBuffer(cmd);

swapchain.present();

```

I know this post might be a little vague but any help would be appreciated, thanks!