Learning JavaScript With freeCodeCamp: What the RPG Project Teaches You

patrick mbithi — Thu, 04 Jun 2026 16:49:45 +0000

tags: javascript, beginners, webdev, freecodecamp

I've tried to "learn JavaScript" more times than I want to admit. Courses, YouTube videos, the usual. I'd get through loops and think I understood them, then open a blank file and have nothing to show for it.

freeCodeCamp's RPG project is different. Not because it's fun (it is), but because it forces you to actually use the concepts instead of just nodding at them.

What you're building

It's a browser-based RPG. You fight monsters -- a slime, a fanged beast, a dragon -- collect gold, buy weapons, manage health. The whole thing lives in index.html with a JavaScript file doing the heavy lifting. No frameworks. No libraries. Just you and the DOM.

Here's what that looks like when it clicks:

const locations = [
  { name: "town square", "button text": ["Go to store", "Go to cave", "Fight dragon"] },
  { name: "store", "button text": ["Buy 10 health (10 gold)", "Buy weapon (30 gold)", "Go to town square"] },
  // ...
];

That array of objects is the entire game state engine. When you first write it out, it looks like a lot of typing. Then you realize: every button, every screen transition, every monster is just pulling from this one structure. That's when data structures stop being an abstract concept.

The thing nobody tells you about arrays of objects

I spent probably 45 minutes confused about why locations[3].name worked but location.name didn't. Obvious in hindsight. At the time it felt like the floor had dropped out.

What actually made it click was the update function -- one function that takes a location object and rewires the whole UI:

function update(location) {
  monsterStats.style.display = "none";
  button1.innerText = location["button text"][0];
  button2.innerText = location["button text"][1];
  button3.innerText = location["button text"][2];
  button1.onclick = location["button functions"][0];
  button2.onclick = location["button functions"][1];
  button3.onclick = location["button functions"][2];
  text.innerText = location.text;
}

Every time the player clicks something, you're not writing new HTML. You're just swapping the data the function reads. That pattern -- separate your data from your rendering -- is something I now see everywhere.

Where it gets genuinely tricky

The combat system. You need to track player health, monster health, the current weapon, and whether the monster is still alive. And you need to update the DOM after every single action without losing track of any of it.

I got it wrong twice before I understood why global variables exist in small programs like this. Not because they're good practice forever -- they're not -- but because the alternative (passing state through every function) gets complicated fast. This project teaches you why people care about state management. Not as a concept. As a problem you personally ran into.

The Easter egg that teaches you something real

There's a secret number guessing minigame hidden in the RPG. The randomness that powers it uses the same Math.floor(Math.random() * X) pattern as the combat system. The first time I noticed I'd written the same two lines in three different places, I understood what "don't repeat yourself" actually means as a constraint, not just advice.

What I'd tell someone starting this project

Don't read ahead. Seriously. The temptation is to look at the full solution when you get stuck on the buyWeapon function or the monster health math. That's the exact moment where fighting through it pays off. Google the specific thing you don't understand. That's different from looking at the answer.

Also, the dragon fight is hard by design. You're probably not missing something. It's just hard.

I'm still early in my JavaScript journey, but this project changed how I think about learning to code. Writing something that runs -- that has a win condition, a lose condition, and a secret cheat code -- is worth more than any number of practice exercises where you guess what the output will be.

If you're somewhere in the middle of the freeCodeCamp JavaScript curriculum and this project is next: you're going to be fine. It's longer than it looks. It's also better than it looks.