Case Study - Online Game

Hello students, welcome to Kwickprep. You play games in your browser, but have you ever planned one? What happens behind the screen when you click play? Today we will study a simple online game, from the idea to the database, using the steps of a web project.

Here is our case. A school wants a word guessing game in the browser, to help students practise spellings. Players first register and log in with a username and password. The computer picks a secret word, and the player guesses it letter by letter. Only a wrong guess uses a try, and six tries are allowed. Every score is saved, and a leaderboard shows the top ten players, where a leaderboard is a ranked list of scores.

Next, we list the requirements. A functional requirement is something the game must do, and the first is that players can register and log in. The second is that a player can play a round and get a score. The third is that the game shows a leaderboard of top scores. A non-functional requirement says how well it works, so the game must run smoothly on phones. And passwords must be stored hashed, which means scrambled so that nobody can read them.

Now we choose the technology. The front end uses HTML for structure, CSS for style, and JavaScript to react to key presses. The back end, written in PHP or Python, checks logins and saves scores safely on the server. MySQL is the database, and it stores players and scores in tables. Finally, the game is hosted on a web server, so anyone can open it with a link.

Let us trace one round as a flowchart. The player clicks Play. The server picks a secret word, and hides it from the browser. The player guesses one letter. The game asks, is the whole word now complete? If yes, the player wins and the score is saved. If no, the game asks, are any tries left? If yes, the game repeats until the tries end. If no tries are left, the player loses and the word is shown. Finally, the leaderboard appears.

Now the database design. The Players table stores one row for each player. Player ID is an integer and the primary key, which means it is unique for every row. Username is text up to twenty characters, and no two players can share it. Pass hash stores the scrambled password, never the real one. Joined on stores the date when the player signed up.

The Scores table stores one row for every game played. Score ID is the primary key of this table. Player ID is a foreign key, which means it links each score to a row in the Players table. Points holds the score, from zero to sixty. A win earns ten points for each unused try. Played at stores the date and time of the game.

Pause and predict. A win earns ten points for each unused try. Riya completes the word with two tries still left. What score is saved? Two unused tries give twenty points. And if she used all six tries without finishing, she loses, so zero points are saved.

The leaderboard comes from one SQL query. It joins the Players and Scores tables, matching rows where the player ID is the same. Group by username collects all games of one player, and max of points picks that player's best score. Order by, descending, puts the highest score first. Limit ten keeps only the top ten rows.

An online game must be safe and fair. Always hash passwords, so a stolen database does not reveal them. Keep the secret word on the server, because anything sent to the browser can be seen by a clever player. Calculate and check scores on the server, since a player can change values inside the browser. And filter usernames, so the leaderboard stays clean for school students.

Before launch, we test with planned test cases. In a normal win, correct letters should finish the word and save the score. After six wrong guesses, the game should end and show the word. A wrong password should show a clear error, and never log the player in. Guessing the same letter again should not waste a try.

A good case study ends with future improvements. We could add levels, with easy, medium and hard words. We could add word lists in Hindi and other Indian languages. A daily challenge could give everyone the same word each day. And a gentle screen time limit could remind students to take a break.

Let us revise this case study. We began with the problem and listed functional and non-functional requirements. The game uses HTML, CSS and JavaScript in front, a server back end, and a MySQL database. A flowchart showed the logic of one round. The Players and Scores tables are linked through player ID. And the secret word and scores are kept and checked on the server.