Core: an experimental new way to write videogames

Naming, branding, and discoverability

• Multiple commenters note confusion with the existing “RPG Maker” brand and with a commercial platform also called “Core/Core Games.”
• Suggestions: avoid “RPG Maker” capitalization, phrase it as “an RPG maker,” and/or add a unique modifier to “Core” to improve searchability and reduce trademark risk.
• Some argue the author is legally fine unless trademark owners complain; others emphasize marketing clarity and avoiding future legal headaches.

Clojure, FP, and technical trade-offs

• Debate over whether a functional, immutable, JVM-based language is a good fit for games:
  • Critics cite GC pauses, performance concerns, and the rarity of FP in real-time games.
  • Supporters argue persistent data structures avoid full copies, help manage complexity, and that many genres don’t need AAA-level performance.
• Discussion of Clojure’s atoms, transactions, and Datomic-like history as a way to model game state and potentially enable time travel / replay-friendly workflows.
• Some see the Clojure/FP stack as intellectually appealing but risky for hiring, long-term support, or multi-platform/console goals.

Comparison with existing engines and tools

• Thread branches into experiences with Unity, Godot, Bevy, Pygame, libGDX, LÖVE, Raylib, cocos, Stride, etc.
• Unity: praised for 3D, tooling, performance, and console support; criticized for fragmentation, tech-debt, and ecosystem issues.
• Godot: some find its node/scene/signal model and GDScript elegant and productive; others consider signals spaghetti-prone and GDScript underpowered for large projects.
• Bevy/ECS: seen as powerful but demanding high discipline; easy to end up with many decoupled systems that are hard to reason about.

Simplicity vs. complexity in game development

• The project’s tagline about “making game dev simple” is challenged; many argue engaging games are inherently complex even if underlying models are “simple.”
• Several note the common trap of building engines instead of games; this project is cited as another example of a sophisticated engine with “no game.”

Project quality, documentation, and status

• Interest is high despite minimal documentation; several complain the README is jargon-heavy and doesn’t clearly explain why or how to use it.
• One commenter rewrites the description in plainer language; others request concrete examples and a real game to validate the approach.
• The author later characterizes the project as overengineered, under-specified, and more of a fun Clojure experiment than a successful engine, while others still see value in the exploration.