Introducing Luna: My Rust-based NNUE Chess Engine

[chrisw]

Not a SF net then?

All nets are basically SF with parameters changed, because training takes so long, new engines are unlikely to have been selecting net architectures and testing them out, there being too many parameters to change and too much time need to get a result. My guess is that new engines basically randomly stab at a particular architecture and take it from there.
What you need to look for to separate one net from another is net size, L1, threat inputs or not, structure of head, use of second net, nps, training binpacks. Even so similar nets, similar sizes, similar threat input or lack of, similar binpack source, will produce nets of similar Elo. Elo strength is quite a stubborn thing to move.

[Modern Times]

Not a SF net then?

He did say:

I have trained the network personally using a custom pipeline written in Python.

[Spunc595]

You both hit on a very good point. To clarify, the NNUE architecture for Luna Chess Engine (LCE) follows the standard NNUE approach, and the network was trained using Python scripts on curated datasets.

As a solo developer, creating a completely unique network architecture from scratch and testing it would require an immense amount of time and computing power that I simply don't have. Instead, I focused my efforts on writing the entire search, evaluation integration, and engine structure from scratch in Rust, and training the network to fit LCE's style.

It’s a compact and efficient network, and I'm really looking forward to seeing how it performs once the filename issue is fixed!

[chrisw]

You both hit on a very good point. To clarify, the NNUE architecture for Luna Chess Engine (LCE) follows the standard NNUE approach, and the network was trained using Python scripts on curated datasets.

As a solo developer, creating a completely unique network architecture from scratch and testing it would require an immense amount of time and computing power that I simply don't have. Instead, I focused my efforts on writing the entire search, evaluation integration, and engine structure from scratch in Rust, and training the network to fit LCE's style.

It’s a compact and efficient network, and I'm really looking forward to seeing how it performs once the filename issue is fixed!

If Graham suspects it is an AI generated engine will he actually test it? It’s a question he needs to answer because we’re about to get flooded with “self written new engines”.

[Spunc595]

You both hit on a very good point. To clarify, the NNUE architecture for Luna Chess Engine (LCE) follows the standard NNUE approach, and the network was trained using Python scripts on curated datasets.

As a solo developer, creating a completely unique network architecture from scratch and testing it would require an immense amount of time and computing power that I simply don't have. Instead, I focused my efforts on writing the entire search, evaluation integration, and engine structure from scratch in Rust, and training the network to fit LCE's style.

It’s a compact and efficient network, and I'm really looking forward to seeing how it performs once the filename issue is fixed!

If Graham suspects it is an AI generated engine will he actually test it? It’s a question he needs to answer because we’re about to get flooded with “self written new engines”.

I completely understand the concern, and it's a very fair point in today's landscape. To be completely transparent, if you check my GitHub, you will only see a snapshot from several months ago and the recent release. That’s because I do all my development locally on my machine and I usually push major stable milestones rather than daily micro-commits.

I know a repository with few commits can look suspicious nowadays, but the code is fully open-source under GPLv3. Anyone familiar with Rust can look at the codebase—the structure of the search, the UCI loop, and even the recent filename mismatch bug we just discussed here—and see it's an independent, hand-written project.

I'm more than happy to answer any technical questions about LCE's architecture, search algorithms, or how the NNUE inference is handled. I'm just a hobbyist developer eager to learn and share my work, and I'd be honored if Graham or anyone else wants to give LCE a spin.

[Graham Banks]

You both hit on a very good point. To clarify, the NNUE architecture for Luna Chess Engine (LCE) follows the standard NNUE approach, and the network was trained using Python scripts on curated datasets.

As a solo developer, creating a completely unique network architecture from scratch and testing it would require an immense amount of time and computing power that I simply don't have. Instead, I focused my efforts on writing the entire search, evaluation integration, and engine structure from scratch in Rust, and training the network to fit LCE's style.

It’s a compact and efficient network, and I'm really looking forward to seeing how it performs once the filename issue is fixed!

If Graham suspects it is an AI generated engine will he actually test it? It’s a question he needs to answer because we’re about to get flooded with “self written new engines”.

That would be a group decision of course, but it's certainly a good question.

[chrisw]

You both hit on a very good point. To clarify, the NNUE architecture for Luna Chess Engine (LCE) follows the standard NNUE approach, and the network was trained using Python scripts on curated datasets.

As a solo developer, creating a completely unique network architecture from scratch and testing it would require an immense amount of time and computing power that I simply don't have. Instead, I focused my efforts on writing the entire search, evaluation integration, and engine structure from scratch in Rust, and training the network to fit LCE's style.

It’s a compact and efficient network, and I'm really looking forward to seeing how it performs once the filename issue is fixed!

If Graham suspects it is an AI generated engine will he actually test it? It’s a question he needs to answer because we’re about to get flooded with “self written new engines”.

That would be a group decision of course, but it's certainly a good question.

And here's the answer:

================================================================================
LUNA CHESS ENGINE - SOURCE AUTHORSHIP ANALYSIS
Was this engine written by a human, or generated by AI?
================================================================================

Repository : github.com/spunc595/luna-chess-engine
Author : [redacted] (Spunc595) <[redacted]>
Language : Rust (100%)
Analyzed : 2026-07-09
Method : Full source read (11 files, ~2,500 LoC) + git history +
toolchain build + UCI runtime smoke test

--------------------------------------------------------------------------------
VERDICT
--------------------------------------------------------------------------------

AI-GENERATED - essentially certain.

The source text was produced by an AI assistant (Google Gemini, per
un-scrubbed citation markers) and uploaded with little or no review. The
work was DIRECTED by a chess-literate human who understands engine design
-- every algorithm chosen is correct and standard -- but the code was not
hand-written and was not meaningfully proofread before publishing.

Confidence: VERY HIGH (multiple independent, mutually corroborating proofs).

Full report at: https://whittingtonchess.com/luna-analysis/

[chrisw]

Text report:

================================================================================
LUNA CHESS ENGINE - SOURCE AUTHORSHIP ANALYSIS
Was this engine written by a human, or generated by AI?
================================================================================

Repository : github.com/spunc595/luna-chess-engine
Author : [redacted] (Spunc595) <[redacted]>
Language : Rust (100%)
Analyzed : 2026-07-09
Method : Full source read (11 files, ~2,500 LoC) + git history +
toolchain build + UCI runtime smoke test

--------------------------------------------------------------------------------
VERDICT
--------------------------------------------------------------------------------

AI-GENERATED - essentially certain.

The source text was produced by an AI assistant (Google Gemini, per
un-scrubbed citation markers) and uploaded with little or no review. The
work was DIRECTED by a chess-literate human who understands engine design
-- every algorithm chosen is correct and standard -- but the code was not
hand-written and was not meaningfully proofread before publishing.

Confidence: VERY HIGH (multiple independent, mutually corroborating proofs).


--------------------------------------------------------------------------------
EVIDENCE SUMMARY
--------------------------------------------------------------------------------

# SIGNAL WHAT IT PROVES WEIGHT
-- ------------------------------- ---------------------------------- --------
1 147 leftover "[cite: N]" Text pasted verbatim from a SMOKING
markers in code comments Gemini response, uncleaned GUN
2 All commits are GitHub-web No local development; files STRONG
"Add files via upload" authored elsewhere & uploaded
3 Orphaned duplicate uci.rs Files generated in isolation and STRONG
(not even compiled) never integrated
4 Four conflicting version Assembled from separate AI STRONG
numbers across the repo generations, never reconciled
5 "HalfKA" label on a network Fashionable buzzword attached to STRONG
that is not HalfKA code that doesn't implement it
6 Duplicated PST + Zobrist code Copy-paste from separate prompts MEDIUM
7 Tutorial-grade comment on Characteristic AI narration MEDIUM
every trivial line style
8 Italian identifiers + Generation/translation layer, SUPPORT
fluent English comments not a single human hand
9 Leftover Italian "todo" Assistant's paste-instructions SUPPORT
notes in cargo.toml left in verbatim


--------------------------------------------------------------------------------
EVIDENCE 1 - THE SMOKING GUN: LEFTOVER AI CITATION MARKERS
--------------------------------------------------------------------------------

The source contains 147 stray "[cite: N]" tags appended to code comments.
These are an artifact of Google Gemini's grounded output. No human types
"[cite: 10]" at the end of a Rust comment -- this is copy-paste residue.
Each file carries its OWN citation number, indicating each was produced in
a separate AI turn.

Example (src/search.rs):
/// Periodically checks (every 2048 nodes) if time has run out.[cite: 10]

FILE COUNT CITATION #
------------------- ------- ------------
src/tt.rs 35 [cite: 6]
src/search.rs 32 [cite: 10]
src/zobrist.rs 27 [cite: 12]
src/nnue.rs 26 [cite: 5]
src/evaluation.rs 17 [cite: 4]
src/uci.rs 10 [cite: 5]
------------------- -------
TOTAL 147

Note: src/book.rs has ZERO markers and a different comment voice (emoji,
terser style) -- likely a different session or lightly hand-edited.


--------------------------------------------------------------------------------
EVIDENCE 2 - GIT HISTORY: NO DEVELOPMENT, ONLY UPLOADS
--------------------------------------------------------------------------------

All 30 commits were made through the GitHub web UI. There is not a single
local "git commit" from real coding -- no incremental building, no bug-fix
commits, no branches.

COMMIT MESSAGE PATTERN COUNT MEANING
-------------------------------- ------- ------------------------------------
"Add files via upload" 4 Bulk paste of generated files
"Delete X.rs" ~15 Wholesale file replacement
"Create/Update README.md" ~7 Web-UI text edits
"Update main.rs" 1 Single web-UI edit
-------------------------------- -------
All authored by: Spunc595 <[redacted]>


--------------------------------------------------------------------------------
EVIDENCE 3 & 4 - INCOHERENCE: ORPHAN FILE + VERSION CHAOS
--------------------------------------------------------------------------------

src/uci.rs is a COMPLETE second UCI implementation that is never used.
main.rs implements the UCI loop inline and never declares "mod uci;", so
uci.rs is excluded from compilation entirely. The two disagree on nearly
every parameter:

PARAMETER main.rs (LIVE) uci.rs (DEAD/ORPHAN)
------------------ ----------------------- ----------------------------
Engine name Luna_Hybrid_7.2 Luna 0.6 NNUE HalfKA
Author string [redacted] [redacted]
Default hash 256 MB 64 MB
Time management time / 25 time / 30
Default depth 12 64
Search model synchronous threaded (Arc<Mutex>)

Four different version numbers coexist with no single source of truth:

LOCATION VERSION STRING
------------------ ---------------------------
README.md v1.0.0
src/main.rs 7.2 ("Luna_Hybrid_7.2")
src/uci.rs 0.6 ("Luna 0.6 ...")
cargo.toml 0.6.0


--------------------------------------------------------------------------------
EVIDENCE 5 & 6 - FABRICATED LABEL + DUPLICATION
--------------------------------------------------------------------------------

* "HalfKA" claim (uci.rs) vs reality (nnue.rs):
Advertised : NNUE HalfKA (king-relative, ~45,000 features)
Actual : Plain 768-input net (12 pieces x 64 squares), no
king buckets. The label is fabricated.

* Duplicated code that a human would have shared:
DUPLICATED ITEM COPY A COPY B
---------------------- --------------------- ----------------------
Piece-Square Tables evaluation.rs movegen.rs (verbatim)
Zobrist hash routine board.rs::get_hash zobrist.rs::hash_board


--------------------------------------------------------------------------------
BUILD RESULT
--------------------------------------------------------------------------------

Toolchain : rustc 1.97.0 (x86_64-pc-windows-msvc)
Command : cargo build --release
Result : SUCCESS - 0 errors, 8 warnings, 19.75s
Binary : target/release/luna.exe (257,024 bytes)

The 8 compiler warnings independently confirm the dead-code findings:

# WARNING LOCATION CONFIRMS
-- ------------------------------------------ ----------------- -----------
1 method hash_board never used zobrist.rs:62 Dup Zobrist
2 methods clear / new_search never used tt.rs:53,63 Dead TT
"aging"
3 methods conta_pezzi / genera_mosse unused board.rs:284,537 Dead code
4 field pst_val never read board.rs:211 Dead field
5 variant Bound::None never constructed tt.rs:6 Dead code
6 fn OpeningBook::new never used book.rs:15 Dead code
7 value assigned to val never read evaluation.rs:108 Sloppiness
8 variable beta need not be mutable search.rs:156 Sloppiness

KEY CONSEQUENCE: tt.rs::new_search() (which bumps the generation counter
for entry AGING) is never called by the live binary. Therefore the
"Transposition Table with aging support" advertised in the README is
effectively DEAD -- the generation stays at 1 forever and no aging occurs.


--------------------------------------------------------------------------------
RUNTIME TEST (does it actually work?)
--------------------------------------------------------------------------------

Input : uci / isready / position startpos / go movetime 1000 / quit

METRIC RESULT
---------------------- --------------------------------------------
UCI handshake OK (readyok returned)
Search depth reached 9 plies in ~1 second
Node rate ~2.5 million nodes/sec
Best move b1c3 (Nc3) - legal, sensible
PV legality All principal-variation lines legal
Verdict FUNCTIONAL - it plays real chess

Startup banner (note the mixed Italian/English, another authorship tell):
"NNUE: Attiva e carica!"
"Luna Engine v7.2 - Istruita Ready"


--------------------------------------------------------------------------------
BOTTOM LINE
--------------------------------------------------------------------------------

Human-conceived and human-curated; AI-authored source. A competent,
chess-literate operator prompted an AI (Gemini) to produce a standard
bitboard + NNUE engine, then uploaded the output largely as-is. The
algorithms are correct and the binary compiles cleanly and plays legal
chess -- but the un-scrubbed citation tags, four conflicting version
numbers, an entire orphaned source file, a dead advertised feature, and a
fabricated architecture label make clear the code was neither hand-written
nor carefully reviewed by a human.

================================================================================
Report generated 2026-07-09 by automated source analysis.
================================================================================

[Spunc595]

Hi everyone,
​I’ve read the analysis, and I want to genuinely thank the author for such a detailed look into the code. The verdict is accurate, and I want to be 100% transparent with the community about how this happened.
​Luna is my personal passion project. I designed the architecture and directed the logic based on my understanding of chess engines. However, because Rust is a completely new language to me, I used an AI assistant (Gemini) as a co-pilot to help me implement my ideas and syntax.
​The major mess you see in the repository—the "smoking guns"—actually happened right before release. Since I wanted to share the project internationally, I asked the AI to clean up my files, refactor some structures, and translate all my comments into fluent English.
​Because I was managing everything quickly and enthusiastically directly through the GitHub web UI, I ended up blindly copy-pasting the AI's "cleaned" outputs. That final translation/cleanup phase is exactly where the [cite] markers came from, as well as the conflicting version numbers and the orphaned uci.rs file (which was a refactored version generated by the AI that I uploaded but never properly hooked up in main.rs). The incorrect "HalfKA" label was also a boilerplate placeholder introduced during those AI refactoring sessions that I failed to catch.
​I am a hobbyist developer, and this has been a massive, embarrassing lesson in repository hygiene and the risks of unchecked copy-pasting. But I’m glad the report confirms that the core logic is functional and plays real chess, because that is the engine I intended to build.
​Tomorrow morning I am heading out for a 3-day camping trip with my son to completely unplug. Family comes first, so I will be away from my computer and offline until next week.
​As soon as I get back on Monday, I will completely clean up the house: I'll wipe the repository, remove the dead code, fix the compiler warnings, and make sure the codebase reflects the actual, clean state of the engine without AI-generated debris.
​Thanks to the community for keeping me honest, and have a great weekend!
​Best regards,
Daniele

[Gabor Szots]

Exactly, thanks Sylwy for clearing that up!

Luna Chess Engine (LCE) is a completely independent, modern project built from scratch in Rust with a custom NNUE evaluation. There is no connection with the older engine by Thomas Mergener. Thanks everyone for the support!

The Luna on our lists is also a chess engine so I can see no difference in their names barring that the initials are uppercase.