YOINKS, A BROWSER-BASED MMORPG

James DeSelms, Brandon Lee, and David Sullivan

Department of Computer Science, California State University Monterey Bay

CST-499: Computer Science Capstone

October 25, 2021

 2

Executive Summary

The MMORPG (Massively Multiplayer Online Role-Playing Game) genre can be very

difficult to get into. Not only may there be some amount of difficulty present in learning how to

begin playing the game, as multiple systems interconnect to make this possible, but the game

itself may rely on information taken for granted, making it difficult for newcomers to the genre

or those unfamiliar with certain technologies. Yoinks attempts to solve these problems by

providing those interested in the genre an easily accessible game, with the access point being a

simple internet browser and the fat of more complex systems trimmed back. The final product

should result in a game both enjoyable and accessible, making it possible for more people to

become familiar with and enjoy the genre.

 3

Table of Contents

Executive Summary……...………………………………………………………………..2

Part

I Background and Approach………………………………………………..4

Introduction/Background………………………………………….4

Project name and description……………………………...4

Problem and/or issue in technology……………………….4

Solution to the problem and/or issue in technology.…..….4

Evidence that the proposed project is needed……………..5

Project Goals and Objectives……………………………….….….6

Environmental Scan/Literature Review…………………………...7

Stakeholders and Community……………………………………..8

Approach/Methodology…………………………………………...9

II Ethical and Legal Considerations……………………………….…….…11

Ethical Considerations…………………………………………...11

Legal Considerations…………………………………………….12

III Project Scope…………………………………………………………….14

Project Scope…………………………………………………….14

Final Deliverables………………………………………………..16

Usability Testing…………………………………………………17

Team Members…………………………………………………...18

References………………………………………………………………………………..20

Appendix A………………………………………………………………………………21
 4

Part I

Introduction/Background

Project name and description

Yoinks is an independently developed MMORPG that runs in a browser. Powered by

cutting edge technology and a passion for games, the game should fill a gap in the video game

industry left by larger companies like Sega or Blizzard. Those looking for a game of the genre

and those looking for a game on the platform should both be interested in the project. While the

project is primarily to complete an assigned task, it is also important to make this kind of game

accessible.

Problem and/or issue in technology

Certain game genres have been made increasingly more difficult to get into as technology

has progressed. As game designers created increasingly advanced games, those who did not keep

up with the games would be forced to deal with more complex controls, mechanics, and ideas in

the new ones. The already complex genre of the MMORPG did not escape from this. With

discussion of launchers, clients, and servers, newcomers to the genre may feel pushed out.

Solution to the problem and/or issue in technology

The all-in-one solution presented by Yoinks makes the MMORPG genre significantly

more accessible. Rather than forcing people to dig through forums, guides, and tutorials to play a
 5

game, Yoinks provides a single URL. By stripping down the excess forced by other platforms,

Yoinks can reach a larger number of people. At the same time, keeping the concepts from

popular iterations of the genre keeps people interested.

Evidence that the proposed project is needed

The MMORPG genre is no longer as popular as it once was. The list of popular

multiplayer games from the last few years has a notable lack of MMOs. In an admittedly not

all-encompassing list from Gamesradar, there is one game that is used in conjunction with the

term “MMO”, and it is used in the context of “not-quite-an-MMO” (Horti & Arguello, 2021).

Games like Among Us and Fortnite are currently at the forefront of the public consciousness, in

the same way that World of Warcraft, Ultima Online, and Runescape used to be. This could be

attributed to any number of reasons of course, but imagine the process for somebody not familiar

with the MMORPGs to play one. First, they would have to choose a game to play. Next, they

have to download the client. This is not the entire game of course, the client connects to a server.

They may then begin to look into different servers to join, but they will come across a problem.

When different servers are described, there are some terms they might not know. What does it

mean when a server advertises no PvP? No n00bs? Does it matter? The newcomer now has to

familiarize themselves with an argot dating back to the 70s mixing different languages, numbers

and letters, and multiple generations of people. After visiting Google, UrbanDictionary, and

multiple internet forums, the newcomer chooses a server, but shortly after joining they get

ganked, having barely touched the controls. The gradual complexity creep of the genre has

resulted in an ecosystem that can be very unforgiving to newcomers.

 6

Project Goals and Objectives

Goals Objectives

Create an interactive world to be accessed ● Create a frontend to visually represent

through a browser. such a world.

● Create scripts for certain events, such

as movement, damage, or item

collection.

● Test with multiple common internet

browsers.

Create a chat service for players to ● Implement design for the chat service

communicate. functionality.

● Create and implement a visual design

for chatbox.

● Integrate new socket events for chat

with previous socket events.

Allow for more complex in-game player ● Ensure that player hitboxes are not

interaction. noticeably disjointed from their visual

position.

● Add new collision events for players.

● Balance Player vs. Player combat,

 7

including due consideration of how

enabling PvP may change PvE (player

vs. environment).

● Test for potential exploits, especially

ones that could result in a positive

feedback loop of negative experiences.

Allow for server-side processing of data, ● Create a backend to handle user data

resulting in a less vulnerable architecture and data processing.

while simultaneously requiring less ● Create an API to allow data to be

calculations client-side. passed back and forth between the

frontend and backend.

Create original assets (optional). ● Create art for the game, potentially

including player characters, items,

and/or promotional material.

● Create original music, potentially with

multiple tracks for different areas.

● Debug any potential issues that arise.

Environmental Scan/Literature Review

There are a few notable games that are similar to Yoinks in certain ways. RuneScape is an

MMORPG that could previously be played in a browser, but no longer (“Browser Support”,

n.d.). The 2013 drop of Chromium support for the Netscape Plug-in API (“Saying Goodbye”,
 8

2013) caused this. Similarly, Webkinz Classic is a multiplayer online game that, while not an

RPG, could previously be accessed through a browser. However, it now requires a client

(“Update on Flash”, n.d.). Of course, there are many MMORPGs that began by requiring a

desktop application, but these miss what makes Yoinks fundamentally different.

The most likely places to find similar projects would be hubs for independent browser

games. Newgrounds (https://www.newgrounds.com/) is potentially the most likely, but the reach

of any individual game is going to be more limited due to the enormous amount of competition

from other content on Newgrounds itself. Newgrounds content can be tagged, making the games

easily searchable for any potential competitors or predecessors to Yoinks. MMORPG.com also

has a list of MMORPGs to be played in a browser, but this does not mean that there is no room

for Yoinks in the market (https://www.mmorpg.com/games-list/show/browser). The Adobe Flash

end of life (“Adobe Flash Player”, n.d.) has all but eliminated any possibility of projects using

Adobe Flash filling the same niche as Yoinks. Ruffle is a work-in-progress emulator for the

Adobe Flash Player (“Ruffle”, n.d.), but this raises the level of complexity to an unreasonable

degree for any competitor to Yoinks.

Stakeholders and Community

A large portion of interested people will be gamers interested in the genre, as well as any

gamers particularly interested in browser games. For these stakeholders, Yoinks simply seeks to

provide an enjoyable experience. However, given the problem of accessibility Yoinks is seeking

to help assuage, the main stakeholders Yoinks is catering to are those who feel pushed out of the

MMORPG community. To these stakeholders, Yoinks offers an accessible and enjoyable

experience. With careful consideration given to gameplay features and overall game design,
 9

Yoinks can deliver on its promise of an enjoyable experience. As for accessibility, Yoinks

increases the number of people who can utilize it due to the platform. Most, if not all, modern

computers have some kind of internet browser installed. Even smartphones, small enough to fit

in a pocket, can browse through the internet. Provided testing is carried out across multiple

browsers, the number of devices that can access Yoinks from the beginning is high. By removing

some of the complexities associated with other MMORPGs while retaining key aspects, Yoinks

remains accessible to those not familiar with the genre.

Stakeholders have relatively little to lose, considering. Of course, some amount of

personal information may be at risk, such as an email address used to create an account or any

personal information shared in a chat, but this is to be expected. Many concerns can be

mitigated, if not eliminated outright, however. By not retaining user-entered information for any

period longer than is strictly necessary and informing the user base of the decision to do so,

stakeholders are given reason to believe that their information is not at risk. The risk on the part

of the stakeholders cannot be dropped to zero, since an outright demonstration of removal of user

data would require betraying user trust, but it can be reduced to a very small amount.

Approach/Methodology

The project will use a combination of multiple top-of-the-line web technologies in

conjunction with each other to deliver the final product. Socket.io and Phaser.io make up the

backbone of the project in addition to JavaScript. With pre-made artistic assets easy to find, these

will be used for the majority of development, since it is fairly easy to switch to original assets if

time allows. The team is weighing the benefits of the structure provided with Angular.js in

comparison with the freedom provided by shedding a specific framework and focussing efforts
 10

elsewhere. The project will use a microservice architecture, with a split front and back end, and it

will be deployed using Amazon Web Services.

Team members have already started work, with multiple small-scale prototypes of several

features having been completed. Rapid Application Development is a fitting methodology for the

project, although the team has also taken some concepts from Agile. Due to the iterative nature

of Rapid Application Development, frequent testing with focus groups is an option, but it is not a

requirement. With some proof of concepts having already been completed, a short integration

period should result in a working prototype to be demonstrated to focus groups.

However, with certain decisions not yet made (in particular whether to use Angular),

there is still some amount of preparative work to be done. A lack of team experience with

Angular may also result in a short delay in development as team members gain familiarity with

the framework. With the large amount of work to be done to create any game, Yoinks is a

daunting project to complete. However, team members foresaw the potential difficulties, and

have been working small-scale for several months now. While the aforementioned problems

certainly still exist, many other similar problems have previously been dealt with, and no longer

present any difficulties. As such, development is proceeding roughly as planned with minimal

hiccups.
 11

Part 2

Ethical and Legal Considerations

Ethical Considerations

While the ethical concerns presented by Yoinks are not major, they do need to be

considered. The main concerns are the same as those faced by other video game developers,

especially those who develop MMORPGs. In particular, the concerns of enabling addiction and

use of potentially exploitative monetization strategies. There are some potential secondary

concerns about the content of the game, some may consider certain types of content (such as

gore) to be too objectionable to put in any game. However, Yoinks is unlikely to be any cause for

concerns of this nature, regardless of whether those concerns are valid in other contexts. As such,

these can safely be ignored. The main concerns therefore, are related to the aforementioned

addiction and exploitation.

There are groups of people more vulnerable to both internet/gaming addiction and the use

of certain types of monetization strategies. Youths are perhaps the most likely to be at risk if

microtransactions are a part of a monetization model, and subscription-based services can be

easy to continue paying for without knowing regardless of age or other defining characteristics.

Similarly, the risk of addiction is not tied to a particular group of people defined by anything

besides their propensity to fall victim to addiction. As such, the best solution for these concerns

is to deal with the problem at its root rather than attempt to adjust for a particular group.
 12

Positive feedback loops encouraging more playtime encourage addiction, or at the very

least do nothing to discourage it. If increased playtime results in being rewarded for further

increases, or large-scale playtime from the player population would result in patches being

applied to allow for it to continue, the risk of addiction is increased to a high degree. Developers

in general must be careful not to exploit the nature of the game in this manner, and thus their

players. Careful playtesting and market research can help ensure that the game systems do not

perpetuate these concerns. As for the concerns on monetization, since Yoinks is only a school

project at this stage, a monetization strategy does not have to be decided on at this stage. If

Yoinks moves forwards to a commercial release this will be more of a concern, but it is not a

concern for the capstone project itself.

Legal Considerations

There are two main legal considerations for Yoinks. Use of preexisting assets could result

in some legal concerns, regardless of whether Yoinks is monetized or not. It may also present

some legal concerns to make the project available in certain regions, although those concerns

would likely only be localized to those regions. While it is unlikely that these concerns will come

to fruition, it does no harm to consider how these might be dealt with and what the consequences

of the relevant laws might be. Given the wide nature of the law however, any look into potential

concerns is likely to be partially incomplete.

One of the goals for the project is to use original assets. However, time constraints may

make this difficult or impossible. However, the development team has already secured some

preexisting assets along with the rights to use them, making the concern over misuse of

preexisting assets significantly less of a danger. If necessary, there are marketplaces for assets
 13

that can be used in the event that original assets are unachievable. Unless the team deliberately

takes risks with use of preexisting assets, the chance of legal issues affecting the project can be

reduced to zero. The United States also has some fair use laws that are fairly ambiguous in their

interpretation, but some people may consider non-monetized use of preexisting assets for a

school capstone project to fall within the borders of fair use. As such, regardless of which assets

are used, these potential legal concerns are fairly minimal, and the potential consequences of

disregarding these concerns would be unlikely to come to pass.

The second main legal concern has to do with different countries’ practices and laws on

video games. If Yoinks was to take a monetization model using loot boxes (similar to a lottery

mechanic for in-game rewards), for example, Belgium has certain laws that may make this

difficult (“Gaming loot boxes”). However, since the development team is based in the United

States and China, the laws of those countries are of immediate and primary concern. The United

States does not have any prominent laws that would prevent Yoinks from moving forward.

However, there are some potential concerns presented by Chinese laws. In particular, China’s

State Administration of Press and Publication (SAPP) has certain regulations (“China to

Introduce”). However, since Yoinks is to be a browser game released with hypothetical global

access, these regulations are unlikely to apply to Yoinks. In any case, since Yoinks is

fundamentally a school project, and not a commercial release, these concerns should not apply.

As such, the development of Yoinks should be able to continue as planned with no changes for

different regions of the world being necessary.

 14

Part 3

Project Scope

Project Scope

This project roughly follows a Waterfall template. While this does present some potential

difficulties in the event of urgent changes becoming necessary with only a limited amount of

time left available, the nature of the project makes it difficult to not complete development in

distinct and separate stages.

Week 1 ● Establish minimum viable product

requirements.

● Develop basic game systems required

for further development (e.g.,

movement system, collision, etc.).

● Develop maps for the game.

Week 2 ● Further develop frontend website

(styling, orientation, etc.)

● Further development on the

environment after internal review for

any undesirable effects such as too

many dead ends or not enough space.

 15

Week 3 ● Integrate multiplayer in frontend with

Socket.io connections, chat updates,

and a visual representation of other

players.

● Integrate multiplayer in backend with

player on player events, and player

information passthrough.

Week 4 ● Integrate front and backend, using the

internal REST API to handle events

rather than frontend processes.

Week 5 ● Begin focus group testing.

● Final artistic changes if possible (map

and player sprites can be swapped

very quickly).

Week 6 ● Make necessary changes after focus

group feedback.

● Final internal debugging stage.

There is currently no planned budget for the project, since any external services used

have free tiers that should be enough for the project. Similarly, the necessary resources are fairly

minimal, with hosting and the like being provided by external services. A certain amount of art

may be used in the event that original art cannot be created, but this has already been acquired. In

general each week corresponds to one milestone, and each week solves some dependency, which
 16

is why a Waterfall-like approach was chosen. The largest risk the project faces is feature creep.

Attempting to add too many features could result in none of them being complete. The

aforementioned original art is perhaps the best example of this, since it is both a desirable but

ultimately unnecessary feature and particularly time consuming. Each member of the team is

interested in making an enjoyable video game, and so there will need to be a significant amount

of discipline required to temper expectations.

Final Deliverables

While the exact final product is subject to change depending on time constraints and the

number of extra features that are able to be added, there is a certain baseline expectation that

should be met. The end product should include a functional game, along with an accompanying

barebones website to contain it. Other than these requirements, there are no other deliverables.

There is no client to seek approval from, although it may be worth considering the focus group’s

feedback as something close to this. That is, if the focus group is extremely dissatisfied with

what has been created by the time they are consulted, some heavy reworks should be considered.

The game in particular is difficult to establish final deliverables for beyond the minimum

viable product. The minimum requirements for the game include a world for players to explore,

even a simple one and the ability for multiple players to exist and interact with each other in this

world. Some amount of role-playing elements should be included as well, as the name of the

genre would suggest, but this could be limited to what is made available by player interactions as

a design choice. The nature of the project makes a minimum viable product still rather

technically difficult, so expectations should be kept to a minimum, especially in order to avoid

feature creep from increasingly heightened expectations.

 17

Along with the area containing the game, the project website should have some amount

of information on the game as an introduction for those unfamiliar with the project. While the

style of the website has yet to be decided, its construction should be significantly less complex

than the game itself. A high amount of styling could result in a more immersive experience, but

it is ultimately unnecessary. At the same time, no styling could result in an unpleasant

experience, especially for the focus group testing the project. A delicate middleground is the

current plan, stylized enough to allow for the content to be presented in a way that allows the

intent to shine through, but without sacrificing other aspects of the project.

Usability Testing

A video game that is unplayable for one reason or another seems to have failed in its

purpose to a certain extent. As such, rigorous tests for usability are necessary. While the project

is going to be continuously tested internally as development progresses, it may be difficult to

spot problems with an objective eye. As such, the focus group will be extremely useful to test

exactly how usable the project is.

It may seem intuitive to simply request the members of the focus group to play the game

as they normally would, this leaves some potential scenarios untested. While it is rather

undesirable, there is a non-negligible amount of players in larger games who attempt to do things

out of the ordinary. Whether they are attempting to ruin other players’ fun (sometimes referred to

as BM or BMing, from Bad Manners), attempting to exploit potential bugs in the system, or any

amount of unforseen behavior, players do not always play the game as it was perhaps intended.

This is perhaps the most important thing to test beyond the tests necessary to eliminate game

breaking bugs, since an unpleasant community can kill a game just as surely as anything else. By
 18

selecting a random, but small, number of people within the focus group and specifically

requesting that they attempt things out of the ordinary, some amount of these concerns can be

dealt with.

Feedback from the focus group can be collected via a survey. While the exact content of

the survey cannot be established until more of the project is completed, there are a few questions

that can be expected. For example, asking whether there were any issues with the game that

resulted in a more negative experience, whether the experience overall was enjoyable, and what

the best part of the experience was. Since the focus group is largely made up of acquaintances of

the development team, personal interviews are also a possible option for collecting feedback on

usability, although this could result in overlapping data.

Team Members

The team is made up of James DeSelms, David Sullivan, and Brandon Lee. Each member

of the team is prepared to help the others if it becomes necessary, but there are clearly defined

basic roles for each team member. James will be responsible for the majority of the frontend,

while David takes responsibility for much of the backend. They will be working together on the

game system design. Brandon Lee will be assisting in the backend and the gateways necessary

for the frontend and backend to connect. If at any point a member of the team requires additional

assistance, the other members of the team are qualified to provide this assistance, but these are

the basic paths each team member expects to be working in for the majority of the project.
 19

References:

Adobe Flash Player EOL General Information Page. (n.d.). Adobe.

https://www.adobe.com/products/flashplayer/end-of-life.html

Browser Support. (n.d.). RuneScape. https://www.runescape.com/browser-support

China to Introduce New Game Approval Process This Month. (2019). Variety.

https://variety.com/2019/gaming/news/china-game-approvals-1203194653/

Gaming loot boxes: What happened when Belgium banned them? (2019). BBC.

https://www.bbc.com/news/newsbeat-49674333

Horti, S. & Arguello D. (2021). The 30 best online games to play right now with your friends (or

foes). Gamesradar. https://www.gamesradar.com/best-online-games/3/

Ruffle. (n.d.). https://github.com/ruffle-rs/ruffle

Saying Goodbye to Our Old Friend NPAPI. (2013). Chromium Blog.

https://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html

Update on Flash End-of-Life. (n.d.). Webkinz Newz.

https://webkinznewz.ganzworld.com/announcements/update-on-flash-end-of-life/
 20

Appendix A

Link to Temporary Usability Test Survey

https://forms.gle/YrDUT3in9vEPtKYA8