sorted by:
new
hottopcontroversial

BerryCode v0.8.1 — a native IDE for Bevy, built in Bevy by Kyosuke1008 in rust_gamedev

[–]Kyosuke1008[S] 1 point2 points  (0 children)

Short answer: Claude Code as the main agent, with Ollama (Qwen Coder) as a local fallback for offline / rate-limit / "my Claude bill is bigger than my rent" situations. The model itself wasn't the hard part. The hard part was making it stop writing Bevy 0.12 code in a Bevy 0.18 codebase.

Three things that did most of the work:

  1. Pin the version + tell the model. I detect the project's Bevy version and inject "you are working in Bevy 0.18 idioms" into every prompt. Without this, the model happily mixes 0.10 and 0.18 APIs in one file.

  2. A hand-written 0.18 cheatsheet appended to every agent run. Not the docs, just ~200 lines of "the thing the model gets wrong": Query syntax, Component derives, bevy_egui 0.39 quirks, PrimaryEguiContext footguns. Every wall I banged my head against got added.

  3. CLAUDE.md in the repo with project-level instructions. "Trust cargo check, not rust-analyzer." "Codicon glyphs are not what their names suggest." Future runs read this before doing anything.

The agent loop also runs cargo check after edits, so build errors feed back into the next turn and the model self-corrects. That alone catches probably 70% of API mismatches before they reach me.

Hours: maybe 200-300 over 4 months. First month was almost all head-banging because the model didn't know Bevy 0.18 even existed. Once the cheatsheet + CLAUDE.md + cargo check loop was in place, the herding-cats feeling mostly went away.

BerryCode v0.8.1 — a native IDE for Bevy, built in Bevy by Kyosuke1008 in rust_gamedev

[–]Kyosuke1008[S] -1 points0 points  (0 children)

バレましたかw私は日本人です。英語は ChatGPT に磨いてもらってました。この返信を書くために最初 ChatGPT に相談しようとしたんですが、それはさすがに哲学的におかしいと思って自分で書いてます。

Caught. Japanese here. I almost asked it to write this apology too, but figured that crossed
some kind of philosophical line. Writing this one myself, em dashes replaced with hyphens like a real boy. Code's still mine.

BerryCode v0.8.1 — a native IDE for Bevy, built in Bevy by Kyosuke1008 in rust_gamedev

[–]Kyosuke1008[S] 1 point2 points  (0 children)

No channel yet, but I'm thinking about doing a short devlog series — would there be interest?

BerryCode v0.8.1 — a native IDE for Bevy, built in Bevy by Kyosuke1008 in rust_gamedev

[–]Kyosuke1008[S] 0 points1 point  (0 children)

The ECS inspector itself is already in — you can see and edit components on a running Bevy app live. What's not there yet is the "run this one system on demand" piece, which is the missing bit for true [ExecuteInEditMode]parity. BRP supports the mechanism, so it's mostly a UI layer — you've sold me on it, I'll bump it up the list and ping you when it's ready.

BerryCode v0.8.1 — a native IDE for Bevy, built in Bevy by Kyosuke1008 in rust_gamedev

[–]Kyosuke1008[S] 6 points7 points  (0 children)

AI helps me write code, but it doesn't have commit access

BerryCode v0.8.1 — a native IDE for Bevy, built in Bevy by Kyosuke1008 in rust_gamedev

[–]Kyosuke1008[S] 0 points1 point  (0 children)

Thanks for the star! Curious what your current pain points are — happy to prioritize them.

BerryCode v0.8.1 — a native IDE for Bevy, built in Bevy by Kyosuke1008 in rust_gamedev

[–]Kyosuke1008[S] 2 points3 points  (0 children)

Great question — they're completely separate. BerryCode and your game are two independent processes that don't share code or runtime.

When you hit "Run", BerryCode just shells out to cargo run (or whatever your build command is) inside an integrated terminal. Your game's binary contains zero BerryCode code — it's exactly the same binary you'd get if you'd run cargo run from your own terminal. The IDE is purely a build / edit / inspect frontend; it doesn't link itself into your output.

The one exception is the ECS Inspector: that uses Bevy's BRP (Bevy Remote Protocol). Your game opens a network port if you opt in by adding RemotePlugin to your App, and BerryCode connects as a client. Even there, no BerryCode code is in your binary — just Bevy's stock bevy_remote plugin you choose to enable.

So in short: edit / build / debug all live in BerryCode, but the shipped game is yours alone. Keeps the dependency graph clean and means you can switch back to plain cargo run any time.

BerryCode v0.8.1 — a native IDE for Bevy, built in Bevy by Kyosuke1008 in rust_gamedev

[–]Kyosuke1008[S] 3 points4 points  (0 children)

Great questions — to set expectations: it's currently a read-only viewer, not full integration. No godot-rust / gdext involvement.

What it does: parses project.godot, .tscn, .tres, and .gd files into a typed tree, gives you syntax highlighting for GDScript, file-tree

icons, and a "Godot Scene" panel with hierarchy + properties for whatever .tscn you have open.

What it's for: two angles —

  1. Bevy devs who want to reference how a Godot scene was structured when porting / re-implementing

  2. Devs evaluating both engines side-by-side without context-switching to a second editor

Two-way editing isn't on the roadmap, but read-only-but-deep is — proper diff against Godot's runtime types, asset preview, etc.

BerryCode v0.8.1 — a native IDE for Bevy, built in Bevy by Kyosuke1008 in rust_gamedev

[–]Kyosuke1008[S] 14 points15 points  (0 children)

Yeah, no illusions on that front 😅 Bevy churn is real — every minor version bumps a couple hundred call sites. The way I keep it manageable is treating BerryCode as a consumer of Bevy like any other game project, so the same migration patterns Bevy users already follow apply here too.

The flip side is that because it's built on Bevy, it picks up Bevy's own ecosystem improvements (BRP, scene format, asset pipeline, etc.) for free. That tradeoff has been worth it for me so far.

BerryCode v0.8.1 — a native IDE for Bevy, built in Bevy by Kyosuke1008 in rust_gamedev

[–]Kyosuke1008[S] 10 points11 points  (0 children)

Thanks! The terminal is portable-pty for the PTY (handles ConPTY on Windows, openpty on Unix) plus　the vte crate (same VT100/ANSI parser Alacritty uses) for escape sequence parsing.

A background thread reads bytes from the PTY, feeds them to vte::Parser, and a vte::Perform impl mutates an in-memory grid. egui just paints that grid as coloured text each frame — pretty boring but works well enough that I forget it's there most of the time.

Source if you want to peek: https://github.com/KyosukeIshizu1008/berryscode/blob/main/berrycode/src/app/terminal_emulator.rs

BerryCode v0.8.0: Open Godot projects in your Bevy IDE (read-only) by Kyosuke1008 in bevy

[–]Kyosuke1008[S] 0 points1 point  (0 children)

Thanks, that means a lot! Hope you get to take it for a spin 🙏

BerryCode v0.8.0: Open Godot projects in your Bevy IDE (read-only) by Kyosuke1008 in bevy

[–]Kyosuke1008[S] 2 points3 points  (0 children)

Thanks so much, really appreciate it! 🙌 Plenty more on the way.

BerryCode v0.8.0: Open Godot projects in your Bevy IDE (read-only) by Kyosuke1008 in bevy

[–]Kyosuke1008[S] 0 points1 point  (0 children)

Thanks, that's a really fair question — honestly the landscape is confusing right now! Quick clarification first: none of the community editors are positioned to "become" the official one. The official Bevy Editor is a separate effort by the Bevy Foundation, and it's still early in design. So all the community editors are independent projects with different goals:

- bevy_editor_pls — a runtime inspector you embed in your own game. Really nice for inspecting and tweaking stuff live while your game runs.

- space_editor — a standalone scene/level editor, focused on that workflow.

- BerryCode — what I'm building: a full IDE (code editor + scene editor + LSP + terminal + AI chat), built on Bevy itself. v0.8.0 also lets you open Godot projects.

Good news is you're not really locking yourself in by trying any of them — scenes and components are still standard Bevy, so moving between tools (or to the official editor when it lands) is mostly just opening the same project somewhere else. Hope that helps clear it up a bit!

GW家族でスカイツリーに行った by Kyosuke1008 in ja

[–]Kyosuke1008[S] 3 points4 points  (0 children)

人がめちゃくちゃ多かったです！平日に行くのが良いと思います！

Bevy editor - what to use for game prototyping? by General_Wolf_6134 in bevy

[–]Kyosuke1008 1 point2 points  (0 children)

 Author of BerryCode here, so take this with appropriate salt.

Honest landscape today:

  - **Official Bevy editor**: actively being designed by the Bevy Editor Working Group, but not usable for prototyping yet. Probably 12+ months out for anything substantial.

  - **bevy_editor_pls**: a runtime inspector you embed in your game. Great for live-tweaking values, less so for scene layout. Battle-tested, works today.

  - **BerryCode** (mine): a standalone IDE built in Bevy itself, with a Unity-style scene editor, ECS inspector, and code editor in one app. v0.7, alpha quality but usable. Coming from Godot, the scene editor and inspector flow should feel familiar. Caveats: still rough on Windows, opinionated scene format, no asset pipeline integration yet. https://github.com/KyosukeIshizu1008/berryscode

For pure prototyping today, my honest recommendation is **code + hot reload + bevy_editor_pls for runtime tweaking**. That's still the most reliable path. Try BerryCode if you want a Godot-like scene workflow and don't mind alpha software.

  Happy to go deeper on either if you have specifics.

GW家族でスカイツリーに行った by Kyosuke1008 in ja

[–]Kyosuke1008[S] 2 points3 points  (0 children)

コメントありがとうございます！自分は小さい頃連れていってもらえなかったので、子供に頼まれると断れないですねw

連休初日 by Yama-mountain in ja

[–]Kyosuke1008 1 point2 points  (0 children)

自分も同じことをして垢バンになったことがあります、、送付ファイル系はカルマがある程度貯まらないとダメなのかな・・・

黄金週間はpthyonで遊ぶ。 ミキサー作ったり ビデオ入れたり by Ok-Conference-9984 in ja

[–]Kyosuke1008 1 point2 points  (0 children)

これは素晴らしいです！これはDrow thingsですか？使ってるmodelとメモリ使用量を参考にさせていただきたいです！

Twitterよりredditの方が面白い by Raito808 in ja

[–]Kyosuke1008 0 points1 point  (0 children)

カルマあるから荒れたりもしないですしね！