I'm not a programmer. My kids asked me for a game "with our rules", and I didn't know how to make one. So I asked an AI to help me.
One of the first games was a small platformer with my daughter as the hero. Today there are more than 70 free games on the site, in four languages, and the whole family tests them. This is what I learned along the way, for anyone else who is "not technical" and wants to try.
The stack is boring on purpose
- WordPress on managed hosting, because I needed something I could not break easily.
- Each game is one self-contained page: HTML, CSS and plain JavaScript, no framework, no build step. The AI writes it, I test it on a phone, we fix it, repeat.
- The Code Snippets plugin for everything custom on the server side: a small admin panel, our own cookie-free visit counter, a daily report.
- Polylang for Portuguese (Portugal and Brazil), English and Spanish.
- An Android app that is just the website wrapped as a Trusted Web Activity.
No React, no game engine. When you can't read code well, fewer moving parts means fewer things you can't debug.
What AI was great at
- Turning house rules into code. "In our family, Sueca is played like this" is a perfectly good spec.
- Boring but important stuff: saving progress, fullscreen on mobile, translations, accessibility labels.
- Explaining things. I now understand caching, service workers and why my own stats were wrong, because I kept asking "why?" until it made sense.
What was hard
- Card game opponents. Making a computer partner bid Bridge in a way that feels human took many rounds. The trick that worked: add a teacher. In our Bridge there is an owl called Mox who explains why each bid makes sense, so when the bot does something odd, at least it tells you its reasoning.
- Rules have dialects. Every family plays Sueca or Truco a little differently, so each game needs clear rules on screen and sensible defaults.
- Listening to feedback. A developer community told me my pages were cached for 31 days. They were. My host's gateway was overriding my headers, so the fix was a service worker that revalidates pages on every visit. The same people asked for a timer in Spider Solitaire, which was already there but too hidden.
- Measuring honestly. One day my counter said 55 visits and 1 game opened. The bug was mine: I only counted a game as "opened" when it went fullscreen. Now it counts the first tap.
What I'd tell other parents
- Start with one small game your kid actually wants. Their excitement is the best project manager.
- Test on the real device they use. Most of my bugs only appeared on a phone.
- Say out loud that AI helped. Nobody minded, and people were curious about the process.
- Ask the AI to explain, not just to fix. That is how you stop being stuck.
Try it
Everything is free, with no download and no sign-up. A good place to start is the Bridge game with the owl teacher, or the full list of games.
I'd love feedback from people who actually know what they're doing: what would you change in this setup?
Top comments (7)
I’d keep the first tap that starts a game as the
game_openedevent and record fullscreen entry separately. A useful regression case is a game that starts without entering fullscreen, then enters fullscreen later: assert one open and one fullscreen event. That keeps the count tied to gameplay instead of a browser-specific display path.Thanks Dave, that's exactly the fix I ended up making. The first tap or key press inside a game now counts as "game opened", and entering fullscreen no longer does. Before the change, 55 visits showed up as 1 game opened, because most phones never went fullscreen. Logging fullscreen as its own event is a good idea, and your test case (start without fullscreen, go fullscreen later, expect one open and one fullscreen) goes on my checklist.
That addresses the measurement gap: on a phone, players can start the game without entering fullscreen. I’d keep
game_openedon the first input and count fullscreen separately. One test I’d add is a touch/key path that fires both handlers but still records only one open.Good point on the double-fire case. On some phones a single tap can trigger both the touch handler and a synthetic click, so it could count two opens. I'll add that to my test list: tap once, check that exactly one game_opened is recorded. Thanks for taking the time to think this through.
That test should catch it. I’d also assert the event payload stays identical after the synthetic click, so the duplicate path can’t quietly alter the first event.
Good point. The failure modes are what separate a toy from a tool.
Agreed. Most of what I learned came from things breaking: a counter that counted the wrong thing, a cache that kept serving old pages for a month. Writing those down taught me more than any feature list.