SUSHI TREASURE VIDEO GAME

Author: Ericka Koyama

California State University, Monterey Bay

CST 499 Online: Computer Science Capstone

Faculty Advisor: Dr. Eric Tao

Fall B 2021
 2

EXECUTIVE SUMMARY
Sushi Treasure Video Game
By
Ericka Koyama
California State University Monterey Bay, 2021

The purpose of the project is to fulfill the project requirements for the CST 499 Computer

Science Capstone course, by producing a cooperative video game, called Sushi Treasure. The

game is built with modern web technologies, such as HTML, CSS, and JavaScript. In addition to

being on the Internet, the game is played in real-time, using Socket.io, a well-known WebSocket

library. Using Socket.io, players are able to join a game with their friends, using one-time room

codes. The project is deployed on the Internet through Heroku, a cloud-based services platform.

The population affected by the project is potentially quite wide and diverse, to include

virtually any person with a computer and reliable internet. There is a focus group of 4 people

who have tested the finished project and given feedback on it. This group is in the age range of

25 to 35, and is a mix of genders and comfort level with technology. In the current landscape of

video games, there are many highly competitive ones, and only a relatively smaller number of

cooperative ones. Ultimately, one of the primary goals of the project is to create an enjoyable

game experience where players are encouraged to cooperate with each other and as such, the

game contributes to existing cooperative game options.

 3

TABLE OF CONTENTS

PART I 5
Introduction 5
Feasibility Discussion 6
PART II 9
Platform 9
Major Function 9
Usability Test Plan 11
Usability Testing/Evaluation 11
PART III 13
Timeline/Budget 13
Final Implementation 13
Discussion 15
REFERENCES 18
APPENDIX A. Usability Feedback Survey 19
APPENDIX B. Major Server Classes 22
APPENDIX C. Major Client Classes 24
 4

LIST OF FIGURES

Figure 1. Diagram of use of Socket.io rooms for game sessions 10

Figure 2. Enemy states 11
Figure 3. Game state diagrams 14
Figure 4. ReactJS Web Application Diagram 15
 5

PART I

Introduction

The project is an Internet browser-based video game called Sushi Treasure. There is no

official client in this project; however, a focus group of 4 participants have given feedback via

survey after playing the game. The intended user base is virtually any individual with a reliable

Internet connection and keyboard-controlled computer. The players of the game are the primary

benefactors of the project. The issue Sushi Treasure sets out to solve is that the abundance of

popular competitive video games misses out on the opportunity to engage players by rewarding

cooperative vs. competitive behaviors. The impacts of more cooperative games could potentially

be felt in a wide range of social settings; therefore, it is of importance to both create and foster

opportunities for players to engage this way.

Sushi Treasure aims to serve as one of those opportunities. The mechanics are simple.

Players collect as much treasure in a level before a time limit expires. In addition to the time

challenge, there is an artificially-intelligent enemy, later referred to here as just ‘enemy’. The

enemy occasionally chases characters that are within a certain range of the enemy. Once the

enemy touches a player, the player becomes immobile, and will remain in that state, until another

player touches them, which will make the player mobile again. Players are able to overcome the

enemy collectively by helping each other. Through the use of in-game gestures, players can

signal to each other that they need help. This mechanic of players signaling to each other has

been designed to challenge players by making them scan the board for players who need help,

while still trying to collect treasure chests. If the enemy is chasing a player, the enemy will

retreat, once the player is close enough to another uncaptured player.

 6

The end users of the product are the players of Sushi Treasure. A focus group of 4

participants have provided feedback on the product. Participants are in the age range of

approximately 25-35, although the game is appropriate for a wider audience. Players of Sushi

Treasure are expected to benefit from playing the game because it is fun, challenging, and

provides motivation for cooperative gameplay. The game is designed to be charming. If a group

of people were to play the game for the purposes of team-building, the potential benefit could be

increased team performance, due to the social benefits of playing games together. As with other

cooperative games, the aim is for players to have fun, while still realizing the benefits of

cooperative gameplay.

The project is needed because it contributes to the existing options available for

cooperative gameplay online. The project is unique in the sense that it requires players actively

watching each other’s characters for visual cues. Many of the existing options for cooperative

gameplay are on consoles or platforms, and require purchase and/or download of additional

hardware or software. As an Internet browser-based game, Sushi Treasure is easy to play and

share with others.

Feasibility Discussion

There can be little doubt that today’s most popular online video games are highly

competitive. After all, the entire multibillion dollar industry of esports has grown out of

competitive gaming. Fans and players alike are thrilled by the top competitors in popular games,

such as Fortnite, League of Legends, and Counter Strike. In some cases, playing competitive

games has also come at a cost, specifically through non-productive trash-talking between

players. Trash-talk, or insultatory speech, can be seen in online games between friends, and can

even be an expected form of communication in some cases, as Lenhart (2015) suggests. This
 7

type of interaction can also happen between strangers, in an unwelcome and hostile fashion. This

aggressive behavior is unproductive and unbecoming from a social perspective.

There are also many popular games aimed at increasing collaboration, such as

Overcooked, Keep Talking and Nobody Explodes, and Moving Out. These types of games rarely

have an individual achievement aspect, and instead, rely on players moving in sync and

cooperatively. Cooperative games are often played in professional settings for team building

activities, since optimizing cooperative behavior is often preferred in business settings. In a

particular experiment, results suggested that playing video games had a 20% gain in team

performance over traditional team-building activities. (Keith et al. 2018) One proposed reason

why playing the games were successful in the experiment, was because they were fun and safe

environments, in which a team could fail and still feel positive and motivated to succeed in the

near future. (Keith et al. 2018)

With regards to ethical and legal considerations, the primary ethical concern is related to

usability, and legal concern would be related to copyright. For usability, it is important that users

be able to see the critical game pieces clearly. For example, any text displayed in the game must

have the proper contrast against the background colors. In addition, text used in the game is

minimal, and therefore, more friendly to players who may not be very familiar with the English

language. For copyright, the primary concern is that all libraries and tools used allow personal

project use and any visual game assets used have an appropriate license. The game is built using

popular open source libraries such as Socket.io, Phaser.js, Express, Node.js, etc. Most, if not all

of these softwares are provided with an MIT license, which is one of the most permissive open

source licenses possible. Game assets have been created specifically for the game, so there is no

need to attribute or purchase game assets.

 8

Looking beyond capstone submission, many changes could be pursued to improve the

gameplay and also help the project become profitable. A few improvements that could be

considered would be, adding end-of-round badges, adding additional levels, and allowing more

customization of characters. End-of-round badges would improve the gameplay since it would

motivate players to excel in certain metrics, such as ‘most saves in a single game’, or ‘least

enemy captures’. Additional level maps would make the game more challenging and interesting,

since players would have to navigate different types of terrain with new obstacles. Allowing for

customization of character skins would make the game more fun, entertaining, and also allow an

opportunity for monetization. The game could also be improved by modifying the graphics to fit

on multiple screen sizes, such as mobile or tablet. In keeping with ethical practices, anything sold

in the game should be cosmetic only and would not affect the player's ability to win the game.

Ultimately, the project as-is is suitable for long-term use, provided the game resources continue

to be hosted on a server. The project could also be made public on GitHub, thereby allowing

others to learn from the code by example and even deploy it themselves.
 9

PART II

Platform

The game will be developed using HTML, CSS, and JavaScript. Specifically, the game

will be built using PhaserJS, which is a popular JavaScript framework for building HTML

games. PhaserJS was chosen for its popularity and community support. Socket.io was chosen to

provide real time game play. Socket.io is the de facto standard in Internet projects requiring web

sockets technology. ReactJS was chosen for the client application UI. ReactJS was chosen for its

popularity and community support. In order to make the game widely available, the project was

deployed with Heroku, a cloud-based services platform. Heroku was chosen for its ability to

easily deploy projects with an application resource management dashboard.

Major Function

As Figure 1 shows, players should be able to join or create a game with other players,

using room ids. Player movements will be controlled by each client representing a particular

player, and those movements will be sent to the server, and on to other clients, in order to render

what other players are doing on each client screen. Players should be able to gesture to each

other, using an ‘okay’ or ‘distress’ gesture. If another uncaptured player touches a captured

player, the captured player should become free again. The enemy character should be controlled

centrally by a server, with updates being broadcast to each client in a room.

 10

Figure 1. Diagram of use of Socket.io rooms for game sessions

If a player is caught by the enemy, they should not be able to move. As Figure 2 shows,

if the enemy is chasing a player, and the player is joined by another player, the enemy should

retreat. The enemy should not even initially target a player if they are close to another player.

Treasure chests should be present and distributed around the game map. If a player passes over

an uncollected chest, the chest should become collected, displaying the sushi that was collected.

Once a round is over, a screen should appear that summarizes the gameplay data, and offers the

option of playing another round. All text in the game and website should appear with high

contrast to the background, in order to be clearly readable. The game should be made widely

available through being deployed and available at a URL on the Internet.

 11

Figure 2. Enemy states

Usability Test Plan

Usability testing was done with a focus group of 4 participants. The age range of

participants was approximately 25 to 35, with a variety of genders represented. The level of

comfort with technology ranges from beginner to expert in the group. Participants were asked to

play the game for a period of time, and afterwards, were asked to complete a short online survey

for feedback on their playing experience. A Google Form was used to collect feedback (See

Appendix A), due to the popularity of Google Forms, and the ease with which the form can be

built and submission data collected. The survey comprises a range of questions to gather

information about the participant's experience playing the game, and contains a mix of linear

scale (1 to 5) and short answer questions. Survey questions are about topics such as how easy or

difficult the game controls or rules were to understand, if the gameplay was enjoyable, etc.

Usability Testing/Evaluation

The focus group of 4 participants were tested in different sessions, due to scheduling

challenges. Michael and Jon were each tested individually, while Sarah and Kelsey were tested

together. Ahead of the meeting time, participants were given a link to the game and survey (See
 12

Appendix A), and given instructions to play the game and complete the survey afterwards. Video

chat was used to communicate with the participants in each session. For individuals who were

tested by themselves, they played the game alone for a period of time, and then the student

developer played the game in the multiplayer mode with them, in order to demo the multiplayer

aspect of the game. Participants gave verbal feedback during the video chat as well as feedback

via the Google Forms survey.

 13

PART III

Timeline/Budget

Project milestones were met and even exceeded during implementation. This includes

changes from early testing feedback, as well as unplanned changes, aimed at enhancing the game

and ensuring a stable product was produced. For example, a piece of early feedback was that

players were not sure what had triggered the game over state. This piece of feedback was acted

on by spending nearly one week enhancing the game over screen with additional details, to

explain more about why the game had ended. The final project cost in terms of hours was over

initial estimations. This was most likely due to the fact that project development started ahead of

the actual course start date.

Final Implementation

Sushi Treasure’s architecture is separated into server and client functionality. The server

receives events from clients and broadcasts the events to other connected clients through a

Socket.io connection. The server architecture is primarily made of two classes, GameServer

and ServerEnemy. The GameServer class is responsible for managing game states and

handling socket communication between clients. The ServerEnemy class is responsible for the

enemy movement and state logic. The client side of the application is a ReactJS single-page web

application, which uses the Socket.io client library for server communication, and PhaserJS for

the game engine.

Players are able to create and join a game through the use of a Socket.io feature called

‘rooms’, which gives the ability to broadcast and receive events to or from a subset of sockets.

The server controls the game state through a Map data structure, which is keyed by room id, with
 14

values representing each game’s state. In the application UI, users will choose between creating

and joining a game. If they join a game, a room id will be asked for, and if they create a game, a

room id will be assigned to them.

The enemy behavior is implemented by the ServerEnemy class. The class is externally

controlled by the GameServer class. As Figure 3 shows, a server global gameStates object

maintains state for all concurrent games by their room id, with each game state having its own

server side game loop, which serves to update the enemy state while the game is running. With

each iteration of the server game loop, the update method is called for the Enemy class, which

allows the enemy to continue carrying out actions, whether it is scanning for players to chase,

chasing a player, or retreating. Once a player is caught, the player object is yielded to the

GameServer class by calling the getCapturedPlayer method on the ServerEnemy

class (See Appendix B).

Figure 3. Game state diagrams

The client side of the application contains the ReactJS app and PhaserJS logic. ReactJS is

used to render the UI surrounding the PhaserJS game. It is used for the homepage, and all forms

and buttons. As shown in Figure 4, the ReactJS application uses a series of wrapping contexts to

provide global application data, such as the current page, and game user information, as well as a
 15

series of page components to render the different app pages. The gameplay code is built on top of

PhaserJS. There is a global Phaser.Game instance, as well as a series of classes that extend

the Phaser.Scene class, which serve as the different view components of the game, and two

additional classes that manage player and enemy sprites. The Player and Enemy classes serve

to control the player and enemy characters. For each of these classes, much of the animation

logic is contained in the update method, which calls specific animations to play based on each

character’s state. Except for the current local player, these classes serve as a reflection of updates

from the server, such as enemy movement updates and other player updates (See Appendix C).

Figure 4. ReactJS Web Application Diagram

Discussion

There were many challenges and accomplishments encountered while developing the

project. Towards the middle and end of the project, a few changes were made, but all changes
 16

were broadly within the project timeline, especially because the end of the timeline allowed for

refinements specifically. All proposed objectives were achieved during development. The

process of deploying the project to users went smoothly with Heroku. The most significant

challenge was the enemy's movement logic. All player movements were generated from player

actions; however, the enemy, being server-controlled, needed to have logic written for all

behaviors. About midway through the project, it was determined that the enemy’s movement

logic was overly complicated, due to having to track around an island in the center of the map. In

an effort to not exceed timeline scope, the island was taken out of the map, and replaced with

beaches in the four corners of the map. This greatly simplified the enemy movement to be more

maintainable and achievable within the project timeline.

As a solo project, it was critical to get a basic prototype working quickly. Since the

student developer had no prior experience with Socket.io or game development, it was important

to be able to get a sense of what areas were going to be more complex than others. Even though

it was daunting initially to work alone, time was ultimately saved by not having to coordinate

with a group. A large portion of time was spent researching issues in community online forums.

Even though all major project objectives were met during development, there is still much room

for improvement and expansion in Sushi Treasure.

Looking ahead for the project, there are many areas to improve in the game. Some

feedback suggestions received from play test participants were allowing customization of

characters, adding additional levels, and making gameplay more dynamic through the addition of

power-up objects. With regards to customization, it would be possible to allow players to choose

the colors for their cat, as well as any future accessories that may be added. Adding additional

level maps would make the game more fun. Since rounds are quite short, it could be a good way
 17

to retain player attention, by providing a feeling of progression in the game. For power-up ideas,

collecting certain chests could give players temporary speed boosts, or grant them invincibility.

This type of mechanic would be desirable particularly if there were more levels with increasingly

challenging obstacles. Indeed, there are many directions Sushi Treasure could go in the future.

The student developer is looking forward to sharing the game with a wider audience and

receiving more feedback.

 18

REFERENCES

Keith, M. J., & Anderson, G., & Gaskin, J., & Dean, D. L. (2018). Team Video Gaming for Team

Building: Effects on Team Performance. AIS Transactions on Human-Computer

Interaction. Retrieved from https://www.researchgate.net

Lenhart, A. (2015, August 6). Chapter 3: Video Games Are Key Elements in Friendships for

Many Boys. Pew Research Center. Retrieved from

https://www.pewresearch.org/internet/2015/08/06/chapter-3-video-games-are-key-elemen

ts-in-friendships-for-many-boys/
 19

APPENDIX A

Usability Feedback Survey

The following survey is available at https://forms.gle/G7kzn4x4hKi1iLNy7

20
21
 22

APPENDIX B

Major Server Classes

23
 24

APPENDIX C

Major Client Classes

25
26