I Turned My Old Pokémon Generator Into a Higher or Lower Game
I recently made a small Pokémon Higher or Lower game, and the idea for it actually came from something I built a long time ago.
A few days ago I realized that I can embed my GitHub projects directly into my Blogger site. That made me go back and look through some of my older projects, and one of them was my random Pokémon generator.
That project is already a few years old, maybe two or three years, but it still works. It was also a good base to build something new on top of, because it already had the basic idea: pick a Pokémon, get data from the PokéAPI, and show it on the page.
I wanted to make something simple and fun. Not a big project, not a full game with lots of systems, just something small that I could finish quickly and embed on the blog.
The idea that came to mind was a classic Higher or Lower game. It fits really well with Pokémon because every Pokémon has stats, so you can compare them in a way that feels simple but still interesting.
So I built a small game where you get two Pokémon and you have to guess which one has the higher total stats. After each round you get a new comparison and try to keep your score going.
How the game works
The game is built around one simple question: which Pokémon has the higher total base stats?
Each Pokémon has different stats, like HP, attack, defense, special attack, special defense, and speed. For the game, those values are added together into one total number. That makes it easy to compare two Pokémon without making the rules too complicated.
The player sees two Pokémon, chooses the one they think has the higher total, and then the game checks the answer. If the guess is correct, the score goes up and the next round starts.
That is a simple loop, but it works because Pokémon are already familiar. Even if you do not know the exact stats, you probably have some feeling for which Pokémon might be stronger.
How it connects to the old generator
The original random Pokémon generator was much simpler. It picked a random Pokémon, fetched the data, and displayed the name and sprite.
For the Higher or Lower game, I reused that basic idea, but added game logic around it. Instead of only showing one random Pokémon, the game needs two Pokémon at the same time. It also needs to compare their total stats, track the score, and decide if the player guessed correctly.
So the project went from this:
random Pokémon → show name and image
to this:
two random Pokémon → compare stats → player guesses → update score
That small change makes the project feel much more like a game, even though the code is still beginner-friendly.
Why I used Pokémon data
Pokémon data works really well for beginner web projects because it is visual and structured. You get names, sprites, types, stats, and other information from the API.
The PokéAPI is also public and easy to experiment with. You can request data for a Pokémon and get a JSON response back. That makes it a good API for learning how browser projects can use external data: PokéAPI documentation.
For this game, the most useful part was the stats data. The API gives each Pokémon multiple stat values, and those values can be added together into one total score for the comparison.
The first version used live API requests
The whole project was actually very quick. I think the first version took me around two hours or something like that. It was not about building something complex. It was more about getting back into web development and using something I already had.
At first, the game requested Pokémon data live while the player was using it. That worked, but it was not the best long-term solution.
Every round needed new Pokémon data. That means more fetch requests, more waiting, and more dependence on the API being available. For a small project, that is not a disaster, but it made me think about how the project should work if more people used it.
The JavaScript Fetch API is the browser feature that makes this kind of request possible. MDN has a good explanation of how fetch works here: MDN: Fetch API.
Why I changed the data approach later
After building the first version, I realized that I did not really need to request the same Pokémon data over and over again while people were playing.
Pokémon base stats do not change every second. The game does not need live data for each round. So I changed the project to use a local JSON file instead.
That made the game faster and reduced unnecessary API requests. The browser can load the prepared data directly, and the game can choose random Pokémon from that local file.
I wrote a separate post about that part because it became the most interesting technical lesson from the project: How I used JSON to improve my Pokémon API game.
What I liked about this project
What I liked about this is that it connects directly to my old Pokémon generator. Instead of starting from zero, I could reuse the idea and turn it into something more interactive.
It also reminded me that small projects are useful. Not every project has to become a huge app. Sometimes a small idea is enough to practice JavaScript, work with APIs, and finish something playable.
For me, this was mainly about getting back into building things. I had an old project, I saw a way to expand it, and I turned it into a simple browser game.
Play the game
You can play the Pokémon Higher or Lower game here:
If you are interested in the original generator, you can check it out here:
I also wrote a separate post about the Pokémon generator itself and how it works:
Source code
The source code for both projects is available on GitHub:
Final thoughts
This project was not about making something huge. It was about taking an old idea and turning it into something more game-like.
The random Pokémon generator taught me how to fetch and display API data. The Higher or Lower game added comparison logic, scoring, and better data handling.
That is why I like projects like this. They are small, but each one teaches something new.
No comments:
Post a Comment