My son (9 yrs old) used plain JavaScript to make a game, and wants your feedback

Original Article ↗ Hacker News Discussion ↗

A 9‑year‑old’s browser-based RPG that mixes monster battles with mental arithmetic has drawn wide praise for its charm, animations and surprisingly solid JavaScript and CSS. Commenters offer concrete suggestions—clearer indicators for “charged” attacks, better color contrast and typography, in-page input instead of browser alerts, tighter hit/HP timing, sound, and difficulty tuning—while noting how impressive it is that the game fully ships and runs on plain web tech. The thread also becomes a case study in how kids can now learn to code with parental mentoring plus AI tools, raising questions about authorship, pedagogy, and the future role of large language models in teaching.

Overall reception

  • Very positive reaction; many found the game charming, surprisingly polished for a 9‑year‑old, and genuinely fun.
  • Several adults said it triggered nostalgia for early web/Flash, QBasic, HyperCard, and BBS/MECC‑style games.
  • Multiple parents plan to show it to their own kids; some kids reportedly enjoyed it and were inspired.

Game design & UX feedback

  • Biggest recurring issue: the “charge” mechanic is unclear.
    • Players can’t tell when attacks are charged, what charges them, or how much charge each move costs.
    • Suggestions: greyed‑out or dimmed buttons, charge bars/counters, distinct colors, “CHARGED” labels, or a shared charge meter near HP.
  • Many want HP and damage feedback improved:
    • HP changes before the hit animation; people prefer syncing HP drop with the visual hit and animating the health bar.
    • Some want clearer hit/miss feedback, damage numbers (“hitsplats”), and less confusing simultaneous win/lose states.
  • UI/visual suggestions:
    • Change blue/black text on red to higher‑contrast colors (often white on dark).
    • Center the layout, improve readability on large screens and mobile.
    • Replace alert()/prompt() with in‑page UI for questions and answers.
    • Provide a way to exit battles or return to main menu.

Math mechanics & difficulty

  • The math‑based attacks were widely praised as a clever edu‑game twist.
  • Some want:
    • Time pressure (timers increasing damage or driving enemy attacks).
    • Difficulty levels and question tuning (no trivial “0 + n”, more nuanced “hardness”).
    • Configurable question sets for other subjects.
  • Several note that with consistently correct answers, fights can feel long and inevitable.

Bugs and exploits

  • Known quirks: spamming attack buttons rapidly charges moves; cancelling prompts (e.g., Escape) can still increment charge; turn order isn’t enforced, leading to confusing overlapping attacks and end screens.
  • JS‑disabled environments make the game appear non‑functional; adding a fallback/error message was suggested.

Code quality & technical discussion

  • Many are impressed by readable, reasonably structured vanilla JS/HTML/CSS for a first project.
  • Suggestions:
    • Use "use strict", clearer naming conventions, avoid dead code, and consider structuring data in objects/maps.
    • Move away from inline onclick handlers; consider event listeners and less global state.
    • Improve deployment/archiving via GitHub and continue using version control.

Use of AI in learning

  • The learning process (using an LLM as an interactive tutor, then implementing solutions) is seen as a compelling pattern:
    • Child asks for explanations, restates understanding, and has the model correct misunderstandings.
    • This is framed as “learning with AI,” not just copy‑pasting.
  • Some recommend other tools (e.g., Claude, p5.js, game engines), but many agree simple web tech is a great starting point.

Parenting, pedagogy, and kids & screens

  • Several discuss pathways from Scratch‑style blocks to text‑based programming and share their own kids’ learning stacks.
  • A recurring theme: distinction between “consumption” (games, social media) and “creation” (coding, art, music), with more leniency for the latter.
  • Some worry about too much tech exposure; others argue that steering kids toward creative, skill‑building uses is beneficial.

Skepticism, marketing, and authenticity

  • A few are skeptical that a 9‑year‑old could produce this without heavy adult involvement, citing best practices and blog prose.
  • The parent clarifies:
    • Both parents are programmers; they acted as “senior dev” mentors.
    • The child did the coding and art, while adults guided architecture, tooling, and writing structure.
  • Some question promoting a child’s project across multiple platforms and adding a blog/newsletter; others see it as teaching real‑world “build–share–iterate.”

Accessibility & broader reflections

  • One commenter tested with a screen reader and found the game surprisingly accessible thanks to native HTML controls, while suggesting ARIA and text feedback improvements.
  • There’s broader reflection on how LLMs, better tooling, and ubiquitous computers let today’s kids reach much further than previous generations, while also changing how programming is learned.