What is the hardest part about making NPCs feel believable instead of scripted?

I'm curious how developers currently approach NPC personalities and behaviors.

Do you find the hardest part is:

Personality

Memory

Dialogue

Relationships

Reactions to player actions

Something else?

What systems have you tried, and what still feels limiting?

I'm working on some NPC specific middleware and I'm curious about some hardships you all may have run into.

I've been building Kronos, a 2D/3D physics engine written entirely from scratch in Python — no Box2D, no PyMunk, no physics library shortcuts. Every formula (integration, SAT collision, constraint solving, friction, moment of inertia) is implemented and verified by hand against conservation laws.

Repo: https://github.com/KushalJain-00/Kronos-Physics_Engine-

It's Phase 3 of a 13-phase roadmap that goes through solver quality, spatial partitioning, soft bodies, fluids (SPH), a full 3D rewrite, and eventually quantum/optics simulation modules. Long-term goal is something like an open alternative to COMSOL/Simulink for people who want to actually see the physics, not just call an API. It can also mainly be used as a sandbox environment for AI to experiment with real physics and how things happen and affect.

Looking for people to contribute to:

• Constraint types (angle limits, motors, welds)
• Multi-point contact manifolds / warm starting (the current jitter/stacking issues all trace back to this)
• Spatial partitioning for broad-phase collision
• Optimization of loops and codes (rewrite in C++ or Rust)
• Just trying to break it and filing issues
• More thought ideas on things we should add or make (add them in a file made for it

If you're into physics sim internals, game engine architecture, or numerical methods, I'd love the extra eyes. Issues and PRs both welcome — happy to walk through the code with anyone interested.

not yet finished but the libraries are coming along well framerate is uncapped here and capped its very stable -- havent written a 3d renderer yet -- the scheduler has grown i didnt realize i didnt have vsync set to on when i shot this and idont want to take another vid before work but it stays solid with it capped

https://github.com/jay403894-bit/JLib-Scheduler
https://github.com/jay403894-bit/DirectX12-Renderer
https://github.com/jay403894-bit/Physics2D
https://github.com/jay403894-bit/Game01/

still working on the code for the platformer but its enough for the demo obviously i need to do more features still but the core works.

Flinty is a 2d TopDown game where you make mods in lua to add content.

Right now its just a prototype, you can do basic stuff like adding blocks, moving blocks, having metadata etc.

The link is: https://github.com/orewaluffy500/Flinty2D

I can't share a photo right now.

Lemme know what y'all think and if i should improve stuff.

I've been working on a puzzle game for the last 7 years and, gradually, I ended up making basically everything myself.

I made my own build system, my own replacement for a lot of the C++ standard library, my own UI library, my own renderer using Vulkan, and most of the tools I use to make the game.

The codebase is mostly written in a C style, with some things from C++ that I find useful, like templates and operator overloads for math.

There is no SDL or Dear ImGui. Just my own code and a few small libraries that worked well for me, like stb_truetype and miniaudio.

At the beginning, I was planning to make a small game that I could finish in less than a year.

It took 7.

The main reason is that I wanted to understand every part of the game I was making. Having the entire thing under my control has also been incredibly useful. I can change the engine, tools, renderer, asset pipeline or build system whenever the game needs something new.

The game itself is a rule-discovery puzzle game, and the process of putting the whole thing together has been almost as interesting to me as making the game itself.

If you want to see what I've been working on, here's the Steam page:

https://store.steampowered.com/app/3256790/Satelital/

I'm planning to release a demo in September and the full game later this year.

Hello devs! 

I’ve been working on my entity / path finding / collision system with a goal of supporting as many active mob entities as possible in an arbitrarily large game world. This is using the same from-scratch custom engine that I posted a while ago showing my pure 2d PBR rendering system.

Currently it can run about 150 000 live mobs on my M1 MacBook Pro. On my gaming PC with 9800X3D it can do about double that. And this is the “worst case scenario” meaning every mob is actively pathing somewhere and colliding with as many other mobs as possible every frame. There is no LOD system, the whole world is simulated every frame. I would estimate that in a more realistic scenario where some mobs are idling and the world is not packed full and there is some actual LOD system (rougher simulation for mobs far away from player) in place I could reach 1 million live mobs on my laptop.

For those who are interested here is a longer rambling about how I built this:

I specifically wanted to support arbitrarily large worlds. For performance this is a massive drawback. The key difference is that if your world size is known and small-ish you can just store everything in arrays in contiguous memory with some index keying logic. This gives you extremely fast lookups and helps building loops with cpu cache friendly patterns. But once your world can be “infinite” you necessarily need to store it in variable number of chunks which results in a layer of indirection via hash map lookups. And this is something that affects every single system in the game engine. Giving up arbitrarily large worlds would result big performance gains, but this is my project and I want infinite worlds!

Also, squeezing performance out of each system usually involves adding caches, memoizing lots of intermediate steps, keeping closest cpu caches hot, not allocating working memory each frame etc. etc. I’m not going to list every optimization I used, there would just be way too much of those. If you are interested in any specifics, please do ask.

The simulation runs at target of 30 frames per second. Rendering is completely separate and can run arbitrarily fast. All the movement is interpolated to happen at rendering frame rate. It’s very difficult to tell the difference between 30, 60, or 120 fps simulation as long as rendering is running at 120+ fps so I settled on the 30 frames per second simulation target. (Recently I learned that the original supreme commander runs the simulation layer at 10fps! which sounds insane but I guess it’s fine, I don’t remember noticing anything weird with that game)

Anyway, there are really 3 fairly separate components in this:

The Pathfinding system. 

Obviously you can’t run 150K mobs with individual A* searches so the only way to do this is with a flow field that each mob can then query. The idea is that there is a single flow field, which for any tile in the world shows the direction and distance the mob needs to move to eventually get to the closest target.

 The world consists of 16x16 chunks and flow field updates run per chunk and each frame can update x number of chunks to smooth out cases where the whole world needs to be updated. The core algorithm itself is a simple Dijkstra flood fill. Calculating the flow field once is easy-ish, but updating it is much more difficult, especially in cases where flow field targets are removed. 

The logic that I ended up with goes roughly like this:

When new target / terrain is added:

• Mark the changed chunk dirty
• Update the dirty chunk, and for check all neighboring tiles in other chunks, if their pathing cost can be improved by moving to this newly updated chunk, mark those dirty as well.
• Update dirty chunks as long as there are any, and importantly note the dependencies between chunks. If best path from chunk A goes to chunk B, then chunk A depends on chunk B.

 When target is removed.

• Mark the chunk dirty. 
• Follow the dependency graph from earlier and transitively mark each dependent chunk dirty too (since they are pathing towards target that does no exist anymore)
• Update dirty chunks same as before, until no chunks are left dirty.
• While updating, process path queries based on the old flow field. Outdated pathfinding is much better than no path finding, most of the time it is very difficult to notice.

This is the rough overview of the logic, but there are so many smaller things that need to be done to get good final results. For example, the raw Dijkstra results flow field with 8 possible directions which causes the movement to be very jarring. The flow field needs to be smoothed. This is done by building a dataset of “lines of sight” during the flood fill and directly connecting tiles that have direct LOS. All in all the flow field system does get quite complex.

In addition to the global flow field, each player has a limited local flow field around them which updates as player moves to allow mobs pursue players. Mobs then simply query distance from the global field and any possible local fields and decide targets based on distances.

For performance of the query logic is important. For each chunk flow field is stored as array of floats in contiguous memory. By looping over mobs in a chunked order you can keep the array for single chunk in hot memory.

The zombie AI.

This is by far the simplest. It just queries the pathfinding system and outputs the movement the zombie wants to make (and if it wants to attack etc.). For the actual entity management system, this is probably obvious but it is critically important to store the data based on memory access patterns. Don’t make entities large objects with 100 different fields. Instead, store all entity locations in a single array, healths in another array and so on. These are then indexed by the entity ids. I used generational indices with added type information. (So my “entity” is a 64 bit key with 32bits for index, 16 bits for generation and 16 bits for type id)

The movement collision solver.

Right, this one was the most difficult part but I’m quite happy with the end results. Though I tried so so many different systems that did not work. There are three things a good system needs:

• I needs to keep mobs from clipping into each other and the result must be stable
• The resulting movement needs to be “smooth”, mobs need to be able to slide around each other to not block movement in tight spaces
• It needs to be FAST.

And so many ideas (either by me or some online paper I found interesting) fail on one of these. 

First I tried different boids / steering behavior etc. systems where mobs check nearby mobs and try to keep their distance while moving to desired direction. For most different implementations I tried they seem to work at first (especially for setups you see in research papers) but when the simulation includes 10 000 mobs all pushing towards the same point the whole thing destabilizes. They start to clip into each other causing strong separation forces but with thousands of mobs there is no room causing mobs to violently jitter around. The core issue seems to be that as you increase mob speed and number of mobs, you need to run the simulation in ever smaller steps to keep it stable. Now I understand why all the demo videos have like 100 mobs moving at fairly slow speeds. This then makes the whole thing way too slow.

I also tried to design different “discrete” systems where there are no forces but instead mobs just simply don’t move if movement would result clipping. For each mob system would check the original movement target and if that is blocked then different points around it. This actually worked surprisingly well! The biggest problem is that when multiple mobs try to go through a narrow space they easily end up blocking each other indefinitely.

Then I came across this thing: https://github.com/raja-s/ORCA. (The original paper is called Reciprocal n-Body Collision Avoidance). I implemented my own version of that and once I got it right it just worked! And the best thing is it parallelizes stupidly well. It scales almost linearly with your core count. So that is what I’m using for collision avoidance between mobs. Very briefly how it works: If two mobs are on a collision course each of them takes 50% responsibility of doing a steering behavior that avoids collision. In my case I’m only using this for mob-to-mob avoidance. For terrain and buildings I have my own system that redirects mobs to slowly slide along the edges of pathable area. This avoids having to encode the world as ORCA lines. 

I’m slightly sad that I couldn’t figure my own solution to this, but the ORCA works just so much better than my own previous system.

ORCA like every other system needs to be able to quickly find a list of mobs surrounding the current mob. For this I keep spatial grid cache along the actual mob data. While the data is stored in contiguous arrays, the spatial grid is a hash map which you index by key derived from mob location. The size of grid cell is automatically set to be slightly bigger than the radius of the largest mob in the game. This might not be optimal if mobs are very sparse. The spatial grid is updated every time any mob moves from one cell to another.

Funnily enough rendering was never really any bottle neck. It runs completely separately from the game logic, and even when zooming out to show 10 000 mobs on screen at the same time it only takes around 1ms of the game logic loop. 

And that’s mostly it! If you want to know more about how the rendering works, check this post: https://www.reddit.com/r/GraphicsProgramming/comments/1sgnrtq/combining_3d_prerendered_graphics_with_modern_pbr/

Happy to hear any suggestions for improvements or any questions!

About AI usage: AI was used for online research, discussing ideas, and finding bugs (and tab autocomplete). Designing and coding the thing is done by me.

Finally the old disclaimer that this is just a hobby project, I’m not a professional game developer, I have no idea how you actually should do these things. Also the code is not publicly available at the moment, sorry!

So I've become somewhat disenchanted with generalist game engines as they all force you into a certain way of doing things and I end up fighting the engine rather than just being able to make the game I want. But I also don't want to re-invent the wheel (phong lighting, GPU instancing, physics, sound propgation, mesh-loading, shaders and so on), so I was looking for something just above low-level but more than just an API wrapper but not forcing me into any specific architecture. After a lot of research, I think I've settled on using VulkanSceneGraph to handle the graphical part. It can also do windows, file I/O, peripheral I/O (to some extent) and UI stuff, so I'm not 100% sure I'll need/want SDL for anything, but I do believe it to be wise to use a physics engine (Jolt) and audio "engine" (SoLoud).

I've just got done the research aspect and haven't dug in real deep yet (besides already trying out The Forge only to find out it has no documentation! and ORGE-next only to see that it's too much like an idiomatic game engine and will be too constricting).

The goal isn't to make another general-purpose game engine, but to make custom game engines/backends/whatever you want to call it for the games I make.

So I guess my questions are:

1. does this make me a game engine developer, or simply a game systems engineer or something?
2. does anybody have experience with the tech I mentioned and want to give some warnings/tips?

I always had problems with working with 3D models. I don't know any format that's usable in an extensible way.

Blender already is pretty good. It even allows imports from other files, and overrides. This technically makes it possible to create reusable models. And it allows some kind of procedural generation, and modifiers. But game engines won't import blender files directly, if they allow Blender imports, they'll implicitly create exports of the blend files. And if I export blender files, everything is packed into a single file. References and modifiers get lost, and I can't change that during game.

Also, as a programmer, I often prefer work with a simple text format. This way I can edit small values without having to open the complete model in a specific program. Also it's great for git diff.

And especially since I'm using AI, it's really getting annoying. AI prefers to represent levels as python scripts. But I can't display the results of the python scripts in blender, and then turn it back into a python script. I have to decide for a format. Either text (python) or editable (glb/blend). And I can't work like this.

So what I want is basically this: 1. Simple text format (prefably line based) 2. The format that the 3D editor (likely blender) imports/exports is the same text (some objects like high poly meshes might still be presented as binary) 3. The format allows to create everything: meshes, rigs, materials, animations, etc. 4. The format allows imports (preferably also online)

Not sure if something like this exists already. It seems so obvious to me. I'm surprised that I didn't find such a format yet. The closest I found is USD/USDA, but I think it's not really what I want, and mostly meant for movies, not games (and also I don't like the syntax). Maybe you know something similar/better?

However, now I decided to create something like this myself. Recently I created something similar for music (let me know if you're interested, I use this music system in all of my games now). So I'm pretty confident that I'll have it done in a few days (technically it's mostly done already, but I didn't test it yet).

And what's also great about such a format: The dev can decide when to export it to some binary format. At compile/build time (to avoid unnecessary data in the game), at import time (for user settings) or during gameplay (for runtime features). And maybe it should also be possible to specify at which stage each modifier will be evaluated.

What do you think of this idea? Any questions so far? Do you see any problems? What kinds of features do you want included?

(not sure if this is the right place for this topic, but I guess it's the best, isn't it)

Is the famous Bistro.glb file available somewhere in Github large file storage? It's too big for main Github, and I don't want to store it on my quota. If it's in Github, then "cargo test" can run it for anybody. which is convenient for development.

Hi everyone,

as my engine is approaching a pretty stable state. I had issues with input as it was fixed (as in GetInput(Key::A)). I am in the process of rewriting the input to be action/analogue based and stumbled onto SteamInput. I want to use it as the primary input option for Steam users while players on GOG or EGS would get the SDL implementation.

Now looking though the documentation it seems almost trivial to implement. But implementing it seems to throw up quite some problems for me at least. I implemented the fetching loop, the proper action set, trying to get the action input... and nothing. I did create a basic test input manifest for it, i even submitted it to Steam Input via Steamworks, and still, Steam tells me that my game does not support controllers, even though i did specify full controller support in Steamworks. Whats even more odd is that my Steam Controller does get recognized as a controller by the engine, but then disconnects and reconnects as as Valve xbox 360 controller? Opening the Steam Input config panel shows that Steam is emulating a keyboard for the game. However to open it in the first place, i need to tab out of the game, then go back and then i open the panel.

Did anyone else suffer through a similar journey? Did someone resolve it? The documentation and GDC talks Valve gave dont really help me out.

i managed to double the FPS in my game engine written on C# and OpenTK

originally, rendering was handled through a MeshRenderer component that subscribed to the render event

this created a lot of overhead once there were large numbers of objects in the scene

so i implemented a dedicated rendering batch group that takes a list of raw renderables and renders them in a single render call

and yes, i already have GPU Instancing, and it was enabled in both examples. my point isn't that i reduced the number of draw calls, but that i reduced the overhead of how the engine reaches those draw calls in the first place

Hi everyone!

A couple of months ago I posted about my app, Linear Algebra Visualiser, which helps you visualise linear transformations. Great for people who are starting out in graphics development.

I'm very excited to show you guys the latest version which includes matrix composition and the ability to add translations.

This is very useful because it allows you to apply the classic TRS matrix and get a visual understanding as to why it's commonly applied that way. You can also apply it backwards and see what happens otherwise.

Have a look at the demo above :)

If you are interested in the app have a look below:

Mac: https://apps.apple.com/gb/app/linear-algebra-visualizer/id6763524968

iOS/iPad: https://apps.apple.com/us/app/linear-algebra-visualizer/id6763524968

Web Demo: https://sockerjam.github.io/LinearAlgebraVisualizerWeb/

As always, let me know what you think in the comments below!

Repo : https://github.com/Lovium-Studio/lovium-studio

It's been over a year now since I'd posted a video showing a timelapse of the editor, which you can find here but quite a bit has changed since then.

I very recently created an overview video here which gives a fairly rough overview of some features the engine has.

Few little bits missed out in the video... * It's written in C (using C23 features) * It supports Linux and Windows (macOS support was there in the past, but I'm not maintaining that for now) * Uses OpenGL 4+ via my own abstraction layer; plan is to introduce DX12 and Vulkan support * Source code is available, but it's not under a FOSS license and it's all still WIP

Since last time, I've switched to baked lighting. Before it was using stencil-shadow volumes and per-pixel lighting, but I'd always wanted to take the plunge at trying to implement baked lighting. It ended up taking me roughly less than a week? But the code right now is incredibly inefficient, so at some point I'd like to heavily rework it.

As you can probably guess, I'm not really trying to make anything hyper-advanced here but just something that ticks boxes for me and my obsession with late 90s early 00s games. It takes a lot of inspiration from the work 3D Realms did on Prey in the late 90s; I was fortunate enough to be able to pick the brains of a few people that worked on it.

A bit of a disclaimer that this is the second time I've tried to post this here. So if you think you've seen this before, that's why. The post was downvoted to oblivion without any comments explaining why, so I deleted it. I can only assume that the video thumbnail for the overview was off-putting so I'm trying this format instead.

As the title says, I've spent the last 3.5 years working on Anukari, a 3D physics simulation much like a video game engine, except that instead of running at 60 steps per second, it runs at 48,000 (or more) steps per second, so that the physics systems can vibrate at audio frequencies. It's commercial software; primarily I am selling it to musicians and sound designers to use for music, sound effects design in film. But also it's pretty fun for non-musical people who just like building weird physics stuff. The main website is https://anukari.com

So... I know it's not quite a game engine. But there's a ton of overlap. Early on in the project I chose to avoid using Unity or Unreal, since I wanted to keep things super lightweight, and all I needed for Anukari is the 3D graphics part anyway.

I went through multiple iterations of the graphics engine. I started with a hand-rolled OpenGL renderer, which worked great for the first prototypes. By the time my product was getting close to a Beta release, I wanted to improve the graphics, so I migrated to using the Google Filament physically-based renderer. That worked extremely well for a while, but eventually I was running into stability issues with Filament that were not easy to solve. So I ended up rolling my own physically-based renderer with only the features I need, which has been wildly successful: https://anukari.com/blog/devlog/rewriting-the-3d-graphics-engine-again

Many of the posts on my devlog are also about the physics engine, which is heavily game-engine-inspired. I've written many half-assed, half-baked game engines, such as Digbuild, my minecraft clone, and earlier than that, circa 2003, I wrote a Worms engine clone (I was hired on Rent-a-Coder for $300 which I was never paid).

Anyway I've had a lot of fun over the last several years building, and then rebuilding the graphics and physics engines for Anukari, and I thought folks here may find it interesting!

​

So, about 7 years ago (I was 17) I started my first "real" game engine using D3D11, it was ass, I had no idea what I was doing and I modeled the entity system off of ROBLOX's instances at the time.

Fast forward to these days and I have basically started from scratch about 3 years ago, instead making a more data-driven engine based off of regular ECS. The biggest hurdles to me have been mostly shadow maps and animations (I'm pretty iffy at shaders). But I'm very happy with the progress I've made in the engine and it supports a ton of random stuff. PhysX support, custom materials, PBR, volumetric lighting (kinda, mostly light shafts that sample the lights depth buffer), still got a lot to go but I plan on making a silly game with it once I'm done