Core: an experimental new way to write videogames
An experimental Clojure-based game engine called “Core” is prompting debate over both its technical approach and its branding. Commenters question the practicality of building games on a functional, immutable-data model atop the JVM—citing garbage collection pauses, talent pool issues, and performance trade-offs—while others see benefits in clearer state management, REPL-driven development, and unconventional architectures. The project also draws criticism for sparse documentation, name confusion with existing tools like RPG Maker and other “Core” platforms, and for feeling more like an overengineered hobby engine than a ready vehicle for shipping games.
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.