Gen AI tools for Half Life

GEN AI TOOLS FOR HALF-LIFE

I’m starting a side project that I want to share with the Visual Space community: a Gen AI-assisted campaign editor for classic mod-friendly games, starting with Half-Life.

The first goal is intentionally narrow: use AI to help design, generate, inspect, iterate on, and eventually package new Half-Life campaign maps. Longer term, I want this to grow into an open source repo with multiple “bridges” for different games and engines: Half-Life / GoldSrc first, then potentially other mod-friendly games where level source formats, scripting, entities, and asset conventions can be represented in a way that AI tools can safely work with.

This is also a practical experiment for Visual Space itself. I want to understand what VS needs in order to become a serious place for indie online project development: not just posting updates, but planning, building, reviewing, versioning, testing, and collaborating around actual game projects.

WHY HALF-LIFE?

Half-Life is a good first target because it has a strong modding culture, a readable level format, a clear entity system, and a workflow that is old but understandable:

.map / .jmf source

-> compile tools

-> .bsp playable map

-> test in Half-Life

It is also a useful constraint. The engine is limited compared to modern engines, but that is exactly what makes it interesting. If a tool can help produce believable spaces inside GoldSrc, with readable geometry, lighting, gameplay scripting, and entity logic, then the same ideas can later be adapted to richer engines.

I’m not trying to remake Half-Life or replace hand-authored level design. The goal is to build tools that help with the boring, repetitive, structural parts of campaign creation while still keeping the designer in control.

WHAT I HAVE TRIED SO FAR

The first experiments were very rough.

I set up Half-Life, J.A.C.K., and the compile tools inside Windows running through Parallels on a Mac M1. The basic loop works:

Generate or edit a .map

-> open it in J.A.C.K.

-> save as .jmf

-> compile to .bsp

-> run it in Half-Life

-> playtest

-> patch

-> repeat

The first maps were simple:

- a test room

- a locked door and button

- a lab area

- a reactor / smelter concept

- an experimental Xen-contaminated industrial reactor room

The early output was not good visually. It was too rectangular, too repetitive, and too obviously generated. It looked like random industrial blocks in a box, not a believable Half-Life environment. That was useful because it exposed the real problem: generating valid .map files is only one part of the job. The harder part is generating credible level design.

A good map needs composition, readable routes, believable architecture, lighting hierarchy, landmarks, affordances, gameplay pacing, and environmental storytelling. AI can generate brushwork, but it still needs design rules.

THE DIRECTION

The current direction is to build a deterministic map-generation layer.

Right now the experimental workflow uses small Node.js scripts that generate GoldSrc .map files. These scripts are not a Half-Life standard; they are just a practical bridge:

custom generator script

-> GoldSrc .map

-> J.A.C.K.

-> compile tools

-> playable .bsp

The next step is to turn this into a proper open source toolkit:

goldsrc-map-tools/

geometry helpers

entity helpers

texture rules

validation checks

map templates

compile helpers

Codex prompts/workflows

VS integration notes

The tool should understand things like:

- rooms

- corridors

- doors

- catwalks

- stairs

- ramps

- triggers

- lights

- pickups

- enemy placement

- scripted messages

- map transitions

- compile errors

- invalid brush geometry

- texture conventions

Eventually I want it to support higher-level prompts such as:

Create a Xen-contaminated reactor chamber with a broken catwalk path, a lower hazard pit, two combat arenas, one locked control room, and a changelevel exit.

But the output should not be treated as final art. It should become a strong starting point that can be opened, inspected, edited, and improved in J.A.C.K. or another editor.

VISUAL SPACE AS THE PROJECT HOME

I want to host the project development inside Visual Space.

The interesting part is not only publishing screenshots. VS can become the workspace around the project:

- Feed for development logs, experiments, failures, and releases.

- Chat for discussion, testing notes, and community ideas.

- Whiteboard for level flow, encounter sketches, and spatial planning.

- Storyboard tools for campaign beats, chapter pacing, scripted scenes, and visual references.

- Files for design docs, generated maps, references, and release packages.

- Git integration for source history, branches, reviews, and open source collaboration.

- Codex integration for generating map source, debugging compile logs, writing tools, and iterating on design.

The ideal loop looks like this:

Sketch idea in VS whiteboard

-> turn it into a level/storyboard plan

-> generate a first .map

-> open in J.A.C.K.

-> compile and playtest

-> paste logs/screenshots back into VS

-> Codex patches the generator

-> Git tracks the changes

-> community reviews the result

That is the experiment I care about most: can Visual Space become a place where an indie project is not just talked about, but actually built?

OPEN SOURCE PLAN

The project will be open source.

The first repo will likely focus on Half-Life / GoldSrc:

- deterministic .map generation

- reusable geometry primitives

- validation helpers

- entity templates

- campaign planning docs

- example maps

- compile/debug workflows

- prompts and agent instructions

Later, the repo can grow into multiple bridges:

bridges/

goldsrc/

quake/

source/

godot/

unreal/

other-mod-friendly-games/

Each bridge would define how AI tools talk to that game’s formats and workflows. Some games may support map generation. Others may support quest scripting, entity placement, dialogue drafts, asset manifests, or test plans.

The important idea is that every bridge should be practical. Not “AI makes a whole game,” but “AI helps with a real part of the production pipeline.”

WHAT I’M LEARNING

The biggest lesson so far is that valid output is not the same as good output.

A generated map can compile and still be boring. It can contain lights, enemies, and weapons and still feel fake. It can have a reactor, catwalks, and a hazard pit and still not read as a place.

So the next phase is less about raw generation and more about design intelligence:

- stronger references

- better layout grammar

- more believable scale

- texture discipline

- landmark composition

- verticality

- path readability

- encounter pacing

- playtest feedback loops

The AI should not just emit geometry. It should help reason about why a space works.

THE FIRST CAMPAIGN GOAL

The first playable goal is a small Half-Life campaign slice:

1. an intro/service area

2. an industrial reactor or smelter facility

3. Xen contamination breaking into the facility

4. a locked control-room objective

5. a hazardous lower pit

6. a vertical catwalk combat space

7. a transition into the next map

If this works, the project can grow into a full campaign toolkit.

CLOSING

This is early, messy, and experimental, but I think it is worth sharing now.

The dream is to create an open source Gen AI-assisted editor workflow for classic and mod-friendly games, starting with Half-Life, hosted and developed in Visual Space. Not a magic button that replaces level designers, but a set of tools that helps us move faster from idea to playable prototype.

I’ll keep posting progress, screenshots, failures, compile logs, generated maps, and design notes here. If this works, Visual Space can become both the place where the project is built and one of the tools that makes building it possible.