Open-source project
chrxh/alien avatar
chrxh/alien

ALIEN (chrxh/alien): a CUDA particle simulator for artificial life experiments

ALIEN is a CUDA-powered artificial life simulation program.

5,588 stars193 forksC++BSD-3-Clause

At a glance

What is it?
ALIEN is a CUDA-based artificial life environment where particle networks act as digital organisms with sensors, muscles and neural controllers. It runs on NVIDIA GPUs through CUDA and is also available for AMD GPUs.
Who is it for?
Adopt ALIEN if you have a supported NVIDIA or AMD GPU and want a real-time particle sandbox for evolution experiments or generative work. Skip it if you need CPU-only execution or a stable interface you can build a long-lived pipeline on top of.
Can I use it commercially?
Yes. BSD-3-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 2 days ago.
What is it written in?
Mainly C++, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on November 13, 2026, and from our analysis. They are not legal advice.

From daily snapshots

Star history

  • chrxh/alien5,588 ★ · +67
Star history
Repository2026-09-232026-11-13
chrxh/alien5.5k5.6k

67 Stars in the last 51 days, measured from the daily GitHub snapshot. Compare with other projects

Editorial analysis

What ALIEN simulates, and who the simulator is actually for

ALIEN stands for Artificial Life Environment. The README describes it as an artificial life simulation tool built on a specialized 2D particle engine in CUDA, aimed at soft bodies and fluids. Each simulated body is a network of particles. Those particles can be upgraded with higher-level functions, from pure information processing to physical equipment such as sensors, muscles, weapons and constructors. Neural networks orchestrate how those functions execute. Bodies behave as agents in a shared environment, and their blueprints can be stored in genomes and passed to offspring.

The README offers four answers to the question of what this is for. The first is curiosity: once self-replicating machines exist and mutations are enabled, the simulation runs on its own. The second is that it is fun, closer to a game with a fast physics engine than to a research instrument. The third is academic: studying how complexity or life-like structure arises from simple components, how ecosystems reach new equilibria after environmental change, and what conditions permit open-ended evolution. The README also names generative art as a use case, on the grounds that evolution is a creative force producing new forms.

That range matters when you decide whether to adopt it. ALIEN is not a library you call from a script. It is an interactive environment with editing tools: a genome editor with live preview for designing creatures, freehand and geometric drawing tools, inspection windows for every object, creature and genome, and mass operations. The intended workflow is hands-on, with the mouse, on a running simulation.

How the CUDA particle engine and genome system fit together

The architecture combines a CUDA physics engine with rendering that uses CUDA-Vulkan interoperability. The physics and graphics engine handles particles for soft and rigid body mechanics, fluids, adhesion, fracture and damage. The artificial life layer sits on top: multi-cellular organisms are particle networks, a genetic system constructs offspring cell by cell, and neural networks drive the higher-level functions attached to cells. Rendering and post-processing happen via Vulkan with CUDA-Vulkan interoperability, and the README also lists hardware ray tracing.

The Dockerfile notes that the Base component links ImGui for settings serialization, which comes with the GLFW backend of the GUI. That is a useful detail for anyone reading the build: even the headless console build, which never opens a window, may still need libGL and the X11 libraries to resolve at load time, which is why the image installs them.

According to the README, the simulation code is written entirely in CUDA and optimized for large-scale real-time simulations with millions of particles. Simulation parameters can also vary across the world through layers and radiation sources, which the README says create diverse habitats.

Installing ALIEN on Windows, Linux and a rented cloud GPU

The README gives three routes. On Windows, a nightly build is available for both NVIDIA and AMD GPUs, or you can build from sources.

For building from sources, the repository carries CMakeLists.txt, CMakePresets.json, a vcpkg.json manifest and a build-windows-ninja.bat helper, so the intended toolchain is CMake plus vcpkg.

For a rented cloud GPU, the repository ships a Dockerfile for the headless console build, alien-cli. It is meant for instances such as vast.ai. The binary is not compiled inside the image. A GitHub Actions workflow, .github/workflows/docker-nightly-deploy.yml, builds it natively on the CI runner and stages it next to resources/ in docker/payload, which is also the build context:

bash
docker build -f Dockerfile -t <user>/alien:nightly docker/payload

The Dockerfile comments explain two constraints that matter before you rent anything. The base image defaults to vastai/base-image:cuda-13.0.3-auto, and the CUDA version has to match the toolkit the binary was built with, because the CUDA runtime is linked dynamically. A build made with CUDA 13.0 needs libcudart.so.13. CUDA 13.0 in turn requires an NVIDIA driver of 580 or newer, which the comments describe as a filter criterion when renting an instance. The image also installs libgl1, libglu1-mesa and the X11 client libraries so the shared libraries resolve at load time, even though alien-cli never opens a window. The Dockerfile notes that vast.ai starts Jupyter with --preferred-dir /workspace but the base image does not carry that directory, which makes the server abort during initialization; the comment says this is unrelated to ALIEN.

Hardware requirements that rule people out before they start

The platform table is the most consequential part of the README. On Windows, both NVIDIA GPUs (CUDA) and AMD GPUs (HIP or SCALE) are supported through the nightly build or by building from sources.

The README says the engine runs entirely on the graphics card, so a CPU-only machine is not a target.

The second constraint is less obvious. The physics engine is built for real-time interaction with millions of particles, and the README frames the whole experience around watching evolution unfold and manipulating it with the mouse. That means the resource profile is a GPU with enough memory and compute to hold the particle count you want, plus a display for the interactive builds. The headless cli build exists precisely because the interactive path needs a window, and the Dockerfile says it is meant for rented GPU instances such as vast.ai.

Documentation is the real adoption cost, not the build

The README lists built-in documentation with tutorials and a complete reference, opened with F1, and links a getting-started chapter under resources/docs.

For automation, the README describes a built-in MCP server that lets an AI agent build worlds, design genomes, run experiments and read statistics.

The version history compounds this. The three most recent releases listed are v4.12.3 from 2024-12-29, described as a simulation parameter window revision; v4.11.0 from 2024-11-23, described as new autosave functions and a responsiveness update; and v4.10.2 from 2024-08-17, described as improved sensors for evolution simulations. Those titles tell you where effort went, and the v4.12 title in particular suggests the parameter interface is still being reworked. Until you have checked RELEASE-NOTES.md in the repository, treat saved simulations as artifacts of the release that produced them until you verify otherwise.

The README also describes a built-in simulation browser: browsing and downloading need no account, while uploading simulations and genomes requires one, and uploads can be kept private or shared with the community.

ALIEN against Lenia and other continuous artificial life systems

The closest comparison is not another particle engine but the family of continuous cellular automata that dominate recent artificial life work. Lenia simulates life-like patterns as continuous fields on a grid, with a small set of parameters and no explicit bodies: what you see are self-organizing structures that emerge from local update rules. It runs on CPUs and GPUs, and its state is a grid of numbers.

ALIEN takes the opposite approach. Bodies are explicit particle networks with a graph structure. Connections between particles carry meaning, cells can be equipped with sensors, muscles, weapons and constructors, and neural networks decide when those functions fire. Genomes store blueprints and construct offspring cell by cell. Where Lenia asks what patterns arise from a rule, ALIEN asks what happens when agents with sensors and actuators compete in a physical environment. The cost of that richness is everything the previous section described: a GPU requirement, a heavier build, and documentation that lives inside the application. Lenia's parameters are a short list you can write down; ALIEN's are a spatially varying set you edit in a window.

If your question is about emergent structure from minimal rules, a grid-based system will get you to an answer with far less setup. If your question involves morphology, sensing, and bodies that can be damaged and rebuilt, the particle-network model is the reason to pick ALIEN. The README itself frames the goal as understanding the conditions for pre-biotic evolution and the growing complexity of biological systems, which is a question about agents in an environment rather than about fields.

Licence, maintenance and what upgrading costs you

ALIEN is released under BSD-3-Clause. That is a permissive licence: it allows use, modification and redistribution, including in closed products, provided the copyright notice and licence text are retained and you do not use the project's name to endorse derived work. It does not impose a copyleft obligation on your own code. The one thing to check before publishing is the external/ directory, which is a submodule in the repository layout; third-party dependencies pulled in there may carry their own licences. That is a fact to verify in the repository, not a legal conclusion.

On maintenance, the last push to the develop branch was on 2026-10-31, and the repository is not archived. The Docker image is built by a nightly CI workflow, so the release cadence at the top of the tree is high even though the tagged releases listed are from 2024. The practical upgrade cost is therefore not about abandonment. It is about churn: if you build from source or pull the nightly, you are tracking a moving develop branch, and the repository's RELEASE-NOTES.md is the place to check what changed between versions. Pinning to a tagged release such as v4.12.3 is the conservative option, but check whether the nightly features you want are present in it.

Editorial conclusion

Adopt ALIEN if you have a supported NVIDIA or AMD GPU and want a real-time particle sandbox for evolution experiments or generative work. Skip it if you need CPU-only execution or a stable interface you can build a long-lived pipeline on top of. Before committing, check the platform table and the getting-started chapter in resources/docs to confirm your GPU and operating system are covered.

Frequently asked questions

What hardware does ALIEN need to run?

The README says the engine runs entirely on the graphics card and supports NVIDIA GPUs through CUDA and AMD GPUs through HIP or SCALE. For rented cloud GPUs, the repository's Dockerfile packages the headless alien-cli build.

How do I install ALIEN on Windows?

The README's platform table lists a nightly build for Windows on both NVIDIA and AMD GPUs; you can also build from sources with the repository's CMake and vcpkg files.

Can I run ALIEN on a rented cloud GPU?

Yes, through the headless alien-cli build in the repository's Dockerfile, which the comments describe as meant for instances such as vast.ai. The binary is not compiled in the image; a CI workflow builds it and stages it in docker/payload, which is the build context. The CUDA runtime is linked dynamically, so the image's CUDA version must match the toolkit the binary was built with.

Where is the ALIEN documentation?

The README lists built-in documentation with tutorials and a complete reference, opened with F1 inside the program, and links a getting-started chapter at resources/docs/getting-started.md.

What licence is ALIEN released under?

BSD-3-Clause, according to the repository.

Official sources

  1. chrxh/alien on GitHub
  2. License: BSD-3-Clause
  3. Project website
  4. README
  5. Releases
Community

Where developers are discussing it

Posts on Hacker News, dev.to and Lobsters that link to this repository, found by our scan of those communities. 1 in the last 30 days; newest first.

Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/chrxh-alien.svg)](https://hysenlabs.com/projects/chrxh-alien)

Star history chart for your README

markdown
[![Star history](https://hysenlabs.com/chart/chrxh-alien.svg)](https://hysenlabs.com/projects/chrxh-alien)

Was this useful?