Hy

[alessandroquirino-lab]

Hi! I found Blocks Beyond The Stars and the project really caught my attention — a voxel space game built like this is exactly the kind of thing I'm into.

I use Claude Opus 5 and fable 5 and Gpt 5.6 I work in Unity and C# (VR mods and small games), and I also use Python with FastAPI, so the AI backend looks interesting to me too.

I'm away from my PC for a few days so I can't try the game yet, but I wanted to say I'd like to help. Is there something small I could pick and work from my iPhone with claude or chatgpt?

[marceld23]

Hi Alessandro, welcome — and thanks for reaching out! 👋

Great timing, there's actually stuff you can do entirely from your phone with Claude/ChatGPT, no PC or Unity needed:

Option 1: Server-side localization cleanup (#427) — right up your alley since you know C#. The game must be fully bilingual (DE/EN), but ~182 player-facing server messages are still hardcoded English literals. The fix is mechanical: move them behind Localize(session.Locale, key) and add the keys to data/locales/en.json / de.json. It's spread over the GameServer/*.cs files, so you can pick a single file (e.g. GameServerSpeeders.cs, 16 strings) as a first small PR — no need to do all of it at once. CI runs on every PR, so it acts as your test runner. There's also a tiny warm-up task in the same issue (S19): two silent content fallbacks that should log a warning instead — that one's maybe an hour of work.

Option 2: Add a new language (#99) — if your native language is something other than English or German, this would be a fantastic contribution. All game text lives in plain JSON files (data/locales/), so it's pure translation work, perfect for a phone + AI workflow with you as the native-speaker quality check. I'd handle the in-game verification on my end.

A few practical notes:

• Please have a quick look at CONTRIBUTING.md — there's also a CLA check on your first PR.
• Standard flow: fork → branch → PR. GitHub's web editor (or github.dev) works fine for this from a browser.

And once you're back at your PC: the playtest issues (#86–#94) and the UX/graphics feedback issues (#276–#278) would love a fresh pair of eyes — especially with your Unity background, #278 (URP/graphics advice) could be really valuable.

Looking forward to whatever you pick! 🚀

Best, Marcel

[marceld23]

Quick follow-up — I just opened a batch of new contributor issues, and two of them might fit your phone-only situation even better:

• 🔍 Bug hunt: pick a subsystem and audit it (static code analysis, no build needed) #568 Bug hunt — pick a subsystem and audit it by reading code. Explicitly static and read-only: no build, no Unity install needed. With your C# background plus Claude/GPT as reading tools, this could be a great match. Just claim a subsystem in a comment there so we don't overlap.
• ⚖️ Balance review: items, recipes & ore economy — pure JSON, no C# needed #575 Balance review — all gameplay content is plain JSON under data/ (items, recipes, ore economy). Pure analysis/spreadsheet work; a findings comment is already a full contribution.

And for when you're back at your PC: #573 (SRP-Batcher shader compatibility) is exactly the kind of Unity/URP expertise you mentioned.

No pressure to do all of it — pick whatever sounds fun. 🙂

Best, Marcel

[alessandroquirino-lab]

Hi Marcel, thanks for the detailed reply! 🙏

I'd like to go for #99 — adding Italian. I'm a native speaker, so I can do the quality check you mentioned.

Before starting, I had a look at the code, and I think a third language needs a bit more than the JSON files. The server-side locale handling looks binary rather than list-based:

• GameServerNpcGreeting.NormalizeLocale maps anything that isn't "de" to "en"
• GameServer.cs:2145 — bool de = NormalizeLocale(join.Locale) == "de"
• GameServerObserver.cs:53 — private static bool De(PlayerSession session)
• GameLocale is an enum with English/German only

So if I just add data/locales/it.json, my guess is the UI would be Italian but all server-authored text (NPC greetings, system messages) would silently fall back to English. I haven't been able to run it yet, so I might be wrong.

How would you prefer to handle it? Either (a) I do the JSON translation now and the C# side is dealt with separately, or (b) the locale plumbing gets generalised first.

Either way I'd start small — the block.* group (290 of the 2182 keys) as a first PR, rather than promising all of it at once.

[marceld23]

Wow — that's a spot-on analysis for someone reading code on a phone. 👏 You're right on all counts, and it's actually one step more binary than you guessed: the client hardcodes Settings.Language == "de" ? German : English too (AppShell.cs:415), and the locale tables are keyed by the GameLocale enum — so an it.json wouldn't even get loaded without touching C#. Our content tests also enforce key-completeness for EN/DE, so they'd need a "partial locale falls back to English" rule for a new language (the fallback mechanism itself already exists).

So here's how I'd split it — basically your (a) and (b) in parallel:

• You: start with the JSON translation, and your block.* (290 keys) first-PR plan is exactly right. Please keep any {0}-style placeholders intact and keep the key order matching en.json so diffs stay reviewable. Incremental PRs per key group are perfect.
• Me: I'll handle the plumbing — extend GameLocale, generalize NormalizeLocale, adjust the completeness tests for partial locales, and add the third entry to the language picker (that part needs Unity anyway, which you don't have right now).

One expectation to set: server-authored messages (NPC lines, system messages) will stay English for Italian players until #427 (S20) lands, since those ~182 strings aren't behind locale keys yet — your analysis and that issue are two sides of the same coin. The plan is to flip Italian on in the language picker once the core UI + block/item groups are covered, and let the rest fall back to English until translated.

Go ahead and start with block.* whenever you like — looking forward to the first PR! 🇮🇹

Best, Marcel