First off – really cool to see someone your age building a game engine and sharing it open‑source. That takes guts, and the fact that you're already thinking about rendering, physics, and AI at 16 is impressive. Keep that energy — just a few practical notes that might help you avoid common pitfalls and make the project stronger in the long run.
-
C++ & hybrid architecture – You mentioned you don't know C++. For a serious game engine, the performance‑critical parts (rendering, physics, asset streaming) almost always need native code. Python alone makes it hard to get low‑level control over memory, threading, and hardware. A pragmatic next step would be to gradually move core systems to C++ extensions (via pybind11 or similar) while keeping high‑level logic in Python. That hybrid model is what lets mature engines stay both fast and scriptable.
-
Editor / runtime separation – Early architectural decisions matter a lot. A clean separation between editor mode and runtime mode (scene view vs. game view) helps avoid massive refactors down the road. If you're sticking with Python for now, consider using Dear ImGui's Python bindings to build a lightweight editor — it gives you immediate‑mode UI without locking you into a heavy framework. Defining a clear distinction between scene representation (editing) and game execution (play mode) early will save you from reworking your render pipeline later.
-
Physics – I cloned your repository and noticed the physics accuracy is fairly low, and some basic query APIs (like sphere‑casts or overlap tests) are missing. Integrating a mature physics engine like PhysX or Bullet would be a solid move. Both are battle‑tested, well‑documented, and widely used. Since you're working with AI‑assisted coding, these engines have huge training corpora — your AI tools can handle the binding layer without much trouble.
-
License & personal info – GPLv3 plus a separate "commercial license" offering is unusual for an individual without a legal entity. It also tends to discourage contributors who prefer simpler, permissive terms (e.g., MIT). On the privacy side, you've publicly listed your full name, school, photo, WeChat, and even mentioned your mother taking away your computer. As a minor, that's a serious safety risk. I'd strongly suggest switching to a permissive license (MIT / Apache 2.0) and removing all personally identifiable information — just keep a GitHub handle and a generic project email.
Again, respect for putting yourself out there. Open source is a great way to learn and grow. With a few architectural tweaks and a bit more focus on sustainability, this project could become a solid learning reference for others. Stay safe and keep building.
First off – really cool to see someone your age building a game engine and sharing it open‑source. That takes guts, and the fact that you're already thinking about rendering, physics, and AI at 16 is impressive. Keep that energy — just a few practical notes that might help you avoid common pitfalls and make the project stronger in the long run.
C++ & hybrid architecture – You mentioned you don't know C++. For a serious game engine, the performance‑critical parts (rendering, physics, asset streaming) almost always need native code. Python alone makes it hard to get low‑level control over memory, threading, and hardware. A pragmatic next step would be to gradually move core systems to C++ extensions (via pybind11 or similar) while keeping high‑level logic in Python. That hybrid model is what lets mature engines stay both fast and scriptable.
Editor / runtime separation – Early architectural decisions matter a lot. A clean separation between editor mode and runtime mode (scene view vs. game view) helps avoid massive refactors down the road. If you're sticking with Python for now, consider using Dear ImGui's Python bindings to build a lightweight editor — it gives you immediate‑mode UI without locking you into a heavy framework. Defining a clear distinction between scene representation (editing) and game execution (play mode) early will save you from reworking your render pipeline later.
Physics – I cloned your repository and noticed the physics accuracy is fairly low, and some basic query APIs (like sphere‑casts or overlap tests) are missing. Integrating a mature physics engine like PhysX or Bullet would be a solid move. Both are battle‑tested, well‑documented, and widely used. Since you're working with AI‑assisted coding, these engines have huge training corpora — your AI tools can handle the binding layer without much trouble.
License & personal info – GPLv3 plus a separate "commercial license" offering is unusual for an individual without a legal entity. It also tends to discourage contributors who prefer simpler, permissive terms (e.g., MIT). On the privacy side, you've publicly listed your full name, school, photo, WeChat, and even mentioned your mother taking away your computer. As a minor, that's a serious safety risk. I'd strongly suggest switching to a permissive license (MIT / Apache 2.0) and removing all personally identifiable information — just keep a GitHub handle and a generic project email.
Again, respect for putting yourself out there. Open source is a great way to learn and grow. With a few architectural tweaks and a bit more focus on sustainability, this project could become a solid learning reference for others. Stay safe and keep building.