My first game with Carimbo, my homemade engine

Project reception & context

• Many commenters find the homegrown engine + game inspiring, especially as a hobby project and something made for a child.
• Several say actually shipping a game on a custom engine is rare and impressive.

Engine vs. game: when to roll your own

• Common advice repeated: if your goal is a finished, marketable game, existing engines (Unity/Unreal/Godot, etc.) usually save huge time.
• Counterpoint: for hobbies, learning, or tightly scoped projects, writing your own engine is seen as entirely valid and often more appropriate.
• Strong disagreement with blanket “don’t write engines” advice: generic big engines can be overkill, inflexible, or inefficient for small or unusual games.
• Middle-ground view: write “just enough engine” for your specific game, avoid premature generalization.

Educational value vs productivity

• Many argue engine-building gives deep understanding of rendering, physics, asset pipelines, scripting, and architecture that you don’t get from only using big engines.
• Others stress that if your real aim is “make a game,” tooling/engine work will dominate and can derail the project.
• Consensus: it’s easier to plan and build an engine once you’ve shipped at least one game with an existing engine.

Tooling, editors, and debug workflows

• Tooling and editors are described as the true time sinks: projects, resource management, UI, undo/redo, level editing.
• Several recommend embedding minimal debug/editor features directly into the game (watches, live tweaking, simple console, graphs) instead of building a full external editor.

Technical details discussed

• Asset prefetching: loading one asset per frame into a cache, with a separate mechanism to evict unused assets.
• Collision: current game uses a crude position threshold; plans mentioned for proper physics (e.g., Box2D) or GPU-based pixel-perfect collision, with browser/WebAssembly constraints noted.
• WebGPU is mentioned as future-facing but not yet widely available; WebGL remains the common baseline.

Engines, libraries, and the “middle ground”

• Libraries like raylib, SDL, Ogre, Sokol, and fantasy-console-style frameworks are praised as a sweet spot between “raw API” and full engines.
• Several report renewed enthusiasm using such low-level libraries to build custom 2D engines or small frameworks.

Terminology and philosophy of “engines”

• Some argue “engine” is overused and mythologized; historically it just means the non-game-logic core (rendering, assets, input, entities).
• Clarification of “make a game, not an engine”: don’t over-abstract your first game into a generic, reusable product unless you explicitly want an engine.