{"id":25865,"date":"2023-09-15T18:06:07","date_gmt":"2023-09-15T16:06:07","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=25865"},"modified":"2023-09-15T18:06:12","modified_gmt":"2023-09-15T16:06:12","slug":"guess-what-we-built-a-web-game-with-firebase","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2023\/09\/15\/guess-what-we-built-a-web-game-with-firebase\/","title":{"rendered":"Guess What? We Built a Web Game with Firebase"},"content":{"rendered":"\n

What is more or less?<\/h2>\n\n\n\n

“More or Less”<\/a> is a guessing game where you guess which item has a higher value for a specific attribute. For example, in the “Commit Clash: Which GitHub repo has more commits?” mode, you see one GitHub repository’s commit count and another repository. You have to decide if the repository has more or less commits. If you guess correctly, you see the next pair. If you’re wrong, you lose. Players who score high earn trophies. If they guess every pair correctly, they win a special trophy.<\/p>\n\n\n\n

Different Game Types<\/h3>\n\n\n\n

Players can challenge themselves with modes like determining which country is bigger, <\/a>who might have more money<\/a>, or which website gets more visits<\/a>. Plus, there are even more modes <\/a>to explore and enjoy.<\/p>\n\n\n\n

\n
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n\n
\n
\"\"<\/a><\/figure>\n<\/div>\n<\/div>\n\n\n\n

Player Profile<\/h3>\n\n\n\n

Players have a profile where they can view their high scores per game and various statistics, such as total playtime, overall high score, trophies earned, and average score.<\/p>\n\n\n\n

\n
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n\n
\n
\"\"<\/a><\/figure>\n<\/div>\n<\/div>\n\n\n\n

What did we did this semester?<\/h2>\n\n\n\n

Initial Setup<\/h3>\n\n\n\n

At the beginning of this semester “More or Less”<\/a> was using a Jamstack approach<\/strong> with React<\/a> and a static JSON backend. This is cost-effective<\/strong> and easy to develop<\/strong>. High scores were stored in the browser so there was no need for server-side profiles. We kept our game data in file-based databases on a static server and managed this data on our own.<\/p>\n\n\n\n

This semester, we updated our game to allow user-created content and server-side profiles adding a dynamic backend part to our application.<\/p>\n\n\n\n

Features added this semester<\/h3>\n\n\n\n

User-Created Game Modes<\/strong><\/h4>\n\n\n\n

The main update was letting users create their own game modes. This introduced user-generated content to the platform. Users can now design new modes to share with everyone, or create personalized modes just for their friends or themselves.<\/p>\n\n\n\n

\n
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n\n
\n
\"\"<\/a><\/figure>\n<\/div>\n<\/div>\n\n\n\n
\n
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n\n
\n
\"\"<\/a><\/figure>\n<\/div>\n<\/div>\n\n\n\n

Account Authentication<\/strong><\/h4>\n\n\n\n

Now, users can sign in using oAuth or email and password, instead of the old local storage method. This allows game modes to be shared with the community and highscore saved in your account instead of your browser storage. We also introduced email verification and password reset features.<\/p>\n\n\n\n

\n
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n\n
\n
\"\"<\/a><\/figure>\n<\/div>\n<\/div>\n\n\n\n

Profile Updates<\/strong><\/h4>\n\n\n\n

With the move to server-side profiles, we updated the profile design to allow users to share their highscores and added more account settings options. Now, users can include social links and have the ability to change their email, modify their password, and delete their account if necessary.<\/p>\n\n\n\n

\n
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n\n
\n
\"\"<\/a><\/figure>\n<\/div>\n<\/div>\n\n\n\n
\n
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n\n
\n
\"\"<\/a><\/figure>\n<\/div>\n<\/div>\n\n\n\n

Software is not an end in itself<\/h2>\n\n\n\n

By looking back at what projects we did the last semesters we found out that most of them couldn\u2019t make it to the market<\/strong>. <\/p>\n\n\n\n

We discovered that it\u2019s mostly because they were not really designed to be for the market. Trying out new things like a new technique or a jump into a new design pattern was a lot of fun, and a great learning experience, but the primary goal of a software \u201cSolving a functional problem\u201d was never really successful. <\/p>\n\n\n\n

In this semester we wanted to change that and focused on building an app which really covers the user’s needs. We started by focusing on the functional requirements<\/strong> instead of the technical ones. <\/p>\n\n\n\n

Task-Oriented Design<\/h2>\n\n\n\n

To achieve this goal we started to define which user groups we have and what task they would like to achieve. Tasks are actions or goals these users want to do or reach in your app. Based on this definition we build our whole API and logic around these tasks. <\/p>\n\n\n\n

User Groups<\/strong><\/h3>\n\n\n\n

Players are users who only want to play the game modes.
Contributors are users who want to create game modes.<\/p>\n\n\n\n

Player Tasks<\/strong><\/h3>\n\n\n\n