Times Tables Animals

During the last few weeks, my 8 years old son and I “vibe coded” Times Tables Animals, a web-based game featuring cute animals, maths and volcanos.

This year, as part of his homework duties, my son had to play a game on the tablet to practice the multiplication tables. I think it is a good idea from the school part to use videogames to make learning easier - I remember having to memorize the multiplication tables myself when it was my turn, and it was quite a chore.

Unfortunately, even though my son genuinely likes maths, he is not really fond of this specific game, because he finds the characters scary or annoying. So, homework time has been a struggle throughout the year, and involved hours and hours of negotiations and parental tactics to make him finish his duties. You can imagine it.

So, after almost a year of painful negotiations over homework, I challenged him to imagine how the game could be improved. “If you don’t like the way this game is implemented, how would you do it differently?”. That’s what led us to develop Times Tables Animals.

To develop the game, we used a code editor integrated with an LLM (think of ChatGPT), to write the code. More specifically, we used Visual Studio Code with the Kilo-Code extension.

Essentially, my son and I wrote into a chat and described what we wanted to create, and the bot implemented all the code, creating files and writing code in a matter of minutes. Then, we reviewed and tested, designed new functionalities, and went back to the bot again, asking it to fix bugs and implement changes. This was repeated over a few weeks of back-and-forth, until we were satisfied that the game was good enough to be shared publicly.

I am not particularly versed in Javascript, so for this project I just let the LLM write code, and trusted it to do a good job. Vibe coding is also new to me, too; and in fact, this little experiment was a way for me to familiarize with the tools and the techniques.

We first put the Kilo in “Architect” mode. We used the chat to describe what we wanted to implement, and the LLM helped us create an implementation plan. Sometimes, the LLM would ask for clarifications, as in the screenshots below, and we would discuss and choose an option.

I felt that this was the most educative phase of the project. My son is too young to really learn programming, so there it was little point spending too much time on the details of the implementation. Instead, we sat down and planned, using the tool to learn what is possible and what is not, and “prototyped quickly”.

He’ll learn proper programming in due time. In fact, he’s already learned a lot, just by looking at the code generated by the LLM, and manually changing some details. He knows how to modify some of the text messages, the timers, and the positions of the bunnies. He knows how the code is structured in multiple files, including one for each scenario, a main, and a file for the math engine. We even have a simple testing pipeline, because we realized that new functionalities can often introduce new bugs.

Coding is important, but there is so much else to developing a game, or a software product, than writing code; and this system allowed us to focus on that, and learn about it.

In terms of coding quality, I think the LLM worked very well, for our purpose.

I am not Javascript expert, again - but the LLM delivered a working a game, with minimal work, and that is enough for what we wanted to do.

The LLM did not use any existing framework for developing Javascript games or visualization, and reimplemented everything from scratch. This is a behaviour I’ve observed with chatGPT in other occasions. It will likely be very difficult to scale this game up, if we wanted to add advanced functionalities, enhance security, or export it as an App. For the next game, we’ll look into existing frameworks for developing web games, and start from there. This approach worked well for a simple app, but it’ll not be good enough for something more advanced.

There were times when I felt that the LLM was over-engineering some parts of the code, or spending too much time to fix something trivial. While we were developing this game, we discussed many times what was worth letting the LLM bot fix automatically, and what to fix manually ourselves. If this was a real project, I would have written the code in a much simpler way - although I must concede that the quality of the code produced was quite high.

It may seem a bad idea to teach these tools to a kid, so early.

However, I think that for good or worse, this way of coding is going to be part of the world he is going to live in. It is very likely that in ten years from now, most programming will be done that way - or in other ways that we cannot even imagine right now.

The best way to deal with this is to look at these tools together with them, and help them see the advantages and disadvantages. These new tools provide amazing opportunities to the future generations, and they are only going to get better, but we need to provide a good education to our kids on how to use them.

As mentioned earlier, the next step is to look at broader frameworks for developing games. I am familiar with PyGame, but it may still be too difficult at this point. Any suggestions for frameworks or general tips are appreciated :-)