I Built a Country Higher or Lower Game with JavaScript and Country Data
I recently built a small browser game called Country Higher or Lower. The idea is simple: the game shows two countries, one population is visible, and the player has to guess whether the other country has a higher or lower population.
This project is based on a similar idea to my Pokémon Higher or Lower game, but it feels different in practice. Pokémon stats are fun if you know Pokémon, but countries are much more general. Almost everyone understands the concept immediately. You see two countries, compare them, and make a guess.
That is why I think this version works well as a small browser game. It is clean, fast to play, and easy to understand. The player does not need to read a long explanation before starting. The game can be played directly in the browser, and it also works on mobile.
You can play the game here: Country Higher or Lower Game
The source code is available here: Country Higher or Lower on GitHub
The basic idea
The game shows two countries. One country has its population shown, while the other country has its population hidden. The player chooses higher or lower. If the answer is correct, the score increases and the game continues. If the answer is wrong, the round ends and the player can restart.
That is the whole game loop, but the data makes it interesting. Country population is not always easy to guess. Some countries are very large on a map but have relatively small populations. Other countries are geographically smaller but have far more people living there.
That makes the game more interesting than just recognizing flags or country names. It becomes a small guessing game about geography, population, and how misleading country size can be.
Using REST Countries for the data
For the country data, I used REST Countries. REST Countries describes itself as a RESTful API for getting information about countries. The official website lists v3.1 as the current version, with v4 currently in preview. It also says the API covers more than 250 countries and is open source and free to use.
For my game, I only needed a small part of that data. The important values were the country name, the population, and the country code. The country name is shown to the player, the population is used for the comparison, and the country code becomes useful later for displaying the flag.
I did not want the game to call the API every time someone plays a round. That would be unnecessary for this kind of project. Country population data does not need to be fetched again and again during gameplay.
Instead, I wrote a JSON builder. The builder fetches the country data once, extracts the useful values, and creates a local JSON file. The actual game then reads from that local JSON file.
This keeps the game simple and fast. It also works well for a static GitHub Pages project because the game does not depend on live API requests while someone is playing.
Why I did not use live API calls during gameplay
Using an API live can be useful when the data changes constantly or when the user needs the newest possible result. But this game does not need that. For a small higher-or-lower game, it is enough to prepare the country dataset once and use it locally.
This is similar to what I did with my Pokémon Higher or Lower project. At first, using live API requests feels like the most direct solution. But once the project becomes a game, repeated requests can become unnecessary.
A local JSON file is a cleaner solution here. The game loads the prepared data, picks countries from it, and compares their populations. The API is still useful, but it is used as a data source during the build process instead of being called during every game session.
The flag problem I did not expect
One problem I did not expect was how annoying country flags can be in a browser project. At first, I wanted to use flag emojis. That felt like the smartest and most efficient solution. I would not have to download images, store image files, or load a separate flag service. I could simply display a flag as text.
But then I tested it and noticed a problem. Flag emojis are not displayed reliably on Windows. On many Windows systems, country flag emojis do not appear as actual flags. Instead, they appear as two regional indicator letters. So instead of seeing a German flag, French flag, or Japanese flag, the user may only see something like DE, FR, or JP.
This happens because emoji rendering depends heavily on the operating system and the browser. On Windows, the Segoe UI Emoji font does not include country flag emoji support. A web developer writeup by Nolan Lawson explains that Microsoft’s emoji font does not have country flags on Windows 10 or Windows 11, so Chrome on Windows can show country codes instead of actual flag images. A Stack Overflow discussion about flag emojis also points out that Windows users often need a separate font, image replacement, or another workaround if proper flag display is important.
That was a problem for this project. For a normal text article, maybe this would not matter much. For a country guessing game, it matters a lot. If some users see flags and other users only see two-letter codes, the game feels inconsistent.
This is one of those problems that only appears once you actually build something. I thought emojis would be a clean solution, but the real browser and operating system behavior made them unreliable. So I decided not to use emoji flags in the game.
Why I used FlagCDN instead
After dropping the emoji idea, I needed another way to display country flags. One option would have been to download and store flag images directly in the project. But that did not feel like the best solution. It would make the project larger, and it would also raise the question of where the images come from and whether they are okay to use.
The better solution was to use FlagCDN. FlagCDN describes itself as a free flag API and CDN service. Its website says it includes all 254 country flags and provides them in formats such as PNG, WebP, SVG, and JPEG.
This worked very well with the structure I already had. My JSON file already contained country codes from the REST Countries data. FlagCDN uses country-code-based URLs. That means the game can take the country code and generate the correct flag image URL.
This made the final solution much cleaner. REST Countries gives me the country data I need for the game. FlagCDN gives me reliable flag images. The country code connects both systems.
I later realized that REST Countries also has flag-related fields. But that was not the original path I took. My first plan was to use emoji flags. When that did not work reliably on Windows, I looked for a solution that could use the country codes I already had in my JSON file. That is how I ended up using FlagCDN.
Why this solution felt clean
The part I like about this project is that the final structure is simple. The game does not store hundreds of flag images. It does not depend on flag emojis working correctly across every operating system. It also does not send unnecessary API requests while the user is playing.
The JSON builder prepares the data. The game reads the local JSON file. The country code is used to load the correct flag image. The player only sees the clean result: two countries, two flags, one simple choice.
That is the kind of solution I like in small web projects. It is not overengineered, but it solves the real problem.
What I learned from this project
The biggest lesson from this project was that the data source is only part of the work. Getting country data was not the hardest part. The more interesting problem was turning that data into a game that works reliably in the browser.
The flag issue is a good example. At first, emojis looked like the easiest solution. But once I tested them across systems, they were not reliable enough. Using FlagCDN with country codes ended up being a much better solution.
I also learned again that local JSON files are very useful for small static projects. You can still use an API during development, but the final game does not always need to call the API live. Sometimes the better structure is to fetch the data once, clean it, and let the game use a prepared dataset.
This project is simple, but it connects several useful web development ideas. It uses API data, a JSON builder, local data loading, generated image URLs, JavaScript game logic, and static hosting. None of these things are huge on their own, but together they create a complete little browser game.
Related projects
This game is connected to a few of my other projects and articles. If you want to try the earlier version of this idea, you can play my Pokémon Higher or Lower game here: Play Pokémon Higher or Lower
I also wrote a longer article about using APIs and local JSON files in browser games: How to Use APIs in a Web Game with JSON Optimization
You can find more of my projects here: View my projects
Conclusion
Country Higher or Lower started as another version of my Pokémon Higher or Lower idea, but it became its own useful project. Countries are more general than Pokémon stats, so the game is easier for more people to understand. The topic is simple, but the implementation still led to interesting technical problems.
The most surprising problem was the flag display. I expected emojis to be an easy solution, but they were not reliable enough on Windows. Using FlagCDN with country codes turned out to be cleaner and more dependable.
For me, this is exactly why small projects are useful. You start with a simple idea, but while building it, you run into real problems that teach you something. In this case, I learned more about APIs, JSON files, country codes, flag images, emoji rendering, and browser differences.
That is what makes these projects worth building. They are not only small games. They are also a way to learn how the web actually behaves.
Sources and credits
Country data is based on REST Countries: REST Countries
Flag images are loaded through FlagCDN: FlagCDN
For more background on the flag emoji issue on Windows and in browsers, these explanations were useful: The struggle of using native emoji on the web and Flag Emojis not rendering
This project is created for educational and entertainment purposes. It is not affiliated with REST Countries or FlagCDN.
No comments:
Post a Comment