open_spiel VS Bullet

Deep mind actually has a repository where they applied this algorithm for incomplete-knowledge games. You could use it for reference: https://github.com/deepmind/open_spiel/tree/master/open_spiel/python/algorithms

+1. You can also find an implementation of Clobber and AlphaZero (and many other basic RL algorithms) in OpenSpiel: https://github.com/deepmind/open_spiel

You can find a lot of code online if you look, and many of these applied to Poker. There's a general implementation of both in Python and C++ in OpenSpiel, with some examples applied to small poker games. It's nice code to learn from because the algorithms operate over generic game descriptions, so there aren't game-specific design choices mixed up with the implementation of the algorithms, and you can create your own poker game and just run them on it.

And many other additions and improvements. See all the details here: https://github.com/deepmind/open_spiel/releases/tag/v1.3

I would checkout the openspiel package. It's main focus is RL in games (multi-agent environments). You'll find RL examples there and games that are small enough to solve without deep RL. There's also a wide range of environments from fully cooperative to adversarial zero-sum.

Hi, you can check out OpenSpiel: https://github.com/deepmind/open_spiel/

as for algorithms , openspiel repository has few implementations some of these are not related to imperfect information games , and others are not for multiagent environment and others are tabular algorithms .

This includes single-agent Gymnasium wrappers for DM Control, DM Lab, Behavior Suite, Arcade Learning Environment, OpenAI Gym V21 & V26. Multi-agent PettingZoo wrappers support DM Control Soccer, OpenSpiel and Melting Pot. For more information, read the release notes here:

I've had some success using Action Masking - you can refer to here https://github.com/deepmind/open_spiel/blob/120420a74a69354d64c10b51cd129d4587f9f325/open_spiel/python/algorithms/dqn.py but for DQN you need to mask out q values for invalid actions (as well as masking them during prediction). In my case I'm able to place my mask in the observation so can fetch it quite easily during prediction but if that's not possible you could query it from the environment and store it in the replay buffer (like they do in the link I shared)

Take a look at this simple implementation: https://github.com/deepmind/open_spiel/blob/master/open_spiel/algorithms/minimax.cc

For typical game physics engines... not that much. Math libraries like Eigen or Blaze use lots of template metaprogramming techniques under the hood that can help when you're doing large batched matrix multiplications (since it can remove temporary allocations at compile-time and can also fuse operations efficiently, as well as applying various SIMD optimizations), but it doesn't really help when you need lots of small operations (with mat3 / mat4 / vec3 / quat / etc.). Typical game physics engines tend to use iterative algorithms for their solvers (Gauss-Seidel, PBD, etc...) instead of batched "matrix"-oriented ones, so you'll get less benefits out of Eigen / Blaze compared to what you typically see in deep learning / scientific computing workloads.

The codebases I've seen in many game physics engines seem to all roll their own math libraries for these stuff, or even just use SIMD (SSE / AVX) intrinsics directly. Examples: PhysX (https://github.com/NVIDIA-Omniverse/PhysX), Box2D (https://github.com/erincatto/box2d), Bullet (https://github.com/bulletphysics/bullet3)...

I suspect most C++ physics libraries like Box2D (https://github.com/erincatto/box2d) or Bullet3 (https://github.com/bulletphysics/bullet3) could really benefit a lot from SIMD.

No, they replaced Bullet with Jolt. That is considerably more than "some adjustment", regardless of what you think of the result.

Vulkan graphics via Intel GVK, and physics via Bullet

The first two have a bunch of great examples, and I’m tying them together by refactoring some of the THREE examples to fit the ECS paradigm defined in AFrame. then upping the ante by adding physics using AMMO, which is more challenging since it’s only a partial implementation of Bullet, and already poorly documented (yet popular) physics engine.

Plus, SM uses a system called bullet physics, I imagine this would be rather complex to rework into a modern engine such as Unreal or Unity (after all, the majority of performance issues come from the physics engine rather than the graphics engine)

The physics in HDT-SMP are actually being calculated outside of Skyrim's engine with Bullet, an open-source physics engine. So this isn't some limitation of Skyrim's engine.