CODENAME YOINKS, A BROWSER-BASED

MMORPG

James DeSelms, Brandon Lee, and David Sullivan

California State University Monterey Bay

CST-499: Computer Science Capstone

Dr. Eric Tao

November 16, 2021

 2

Executive Summary

Massively multiplayer online role-playing games have a certain amount of accessibility

issues. An Increased complexity as the genre has continued to advance has the unfortunate side

effect of pushing out less technologically skilled players. Similarly, new players may become

intimidated before even beginning the game. Furthermore, a tight-knit community has resulted in

some tribal knowledge not being fully explained in all cases, especially with regards to etiquette

and lingo. The MMORPG codenamed Yoinks seeks to trim away some of the fat provided in the

games produced by large corporations, while simultaneously making it accessible through an

internet browser, hypothetically vastly increasing the available audience.

 3

Table of Contents

Part

I Introduction and Feasibility…….…….…………………………………...4

Introduction………………………………………………………………..4

Feasibility Discussion……………………………………………………..5

Environmental Scan and Justification……………………………..5

Future Support…………………………………………………….6

Legal and Ethical Considerations…………………………………6

II Design Requirements……..…….…….…………………………………...7

Platform….………………………………………………………………..7

Major Functions…………………………………………………………...8

Usability Test Plan………………………………………………………...9

Usability Testing/Evaluation……………………………………………..10

III Final Discussion And Reflection….…….…….…….……………….…..12

Timeline/Budget…………………………………………………….……12

Final Implementation…………………………………………………….13

Discussion………………………………………………………………..14
 4

Part I

Introduction

With the rapid evolution of technology, it is undeniable that some people are left on the

wayside, unable to engage with certain activities in the same way. While the progression of

technology has resulted in video games becoming an increasingly versatile medium for

developers, there are certain consequences that may go unnoticed on first glance. The most

popular video games of some twenty-odd years ago were more or less plug and play experiences,

with little to no changes available after purchase. Similarly, the number of concurrent players

was often limited to the number of people who could fit in one room, or occasionally over a

computer network (which may not have been much better at the time). More recently, however, it

has become possible to update games with new content after release, and an entire genre has

been created focussed on high numbers of simultaneous players, the MMORPG (Massively

Multiplayer Online Role-Playing Game).

In recent years, the increasing system requirement for the genre has resulted in a certain

number of people being pushed out of the MMORPG community. Tight-knit communities came

about as the result of the collaborative nature of the genre, which may result in new players

feeling as though the genre is difficult to get into. A higher base learning curve may also present

some difficulties. Overall, MMORPGs can be fairly inaccessible for some groups of people, and

those affected this way are the main group the project is targeting. Codename Yoinks would

present two solutions to the main problems faced by the MMORPG genre. First, the game

increases accessibility on a technological level by making it available through a web browser.

 5

Players are no longer required to install a client, choose a server to play on, or anything else

required by a more traditional MMORPG. By reducing the number of bloat and excess in the

game, players unfamiliar with certain conventions can enjoy the game just as much as more

experienced players.

Feasibility Discussion

Environmental Scan and Justification

There are around three main classes of competitors to the project. First, with perhaps the

most polish and budget, there are the modern MMORPGs. This includes Runescape, which was

formerly playable in a browser, but no longer. Codename Yoinks distinguishes itself from these

by increasing accessibility both in terms of content and delivery. While the core MMORPG

community may generally prefer other, more established games, the nature of the genre would

make it difficult to pull these groups away from their chosen game anyways. On the other end of

the spectrum, highly accessible games in other genres are also competitors to the project, with

mobile games perhaps being the largest among these. Similar to the previous group of

competitors, however, those who are more interested in mobile games rather than Codename

Yoinks were unlikely to play the game anyways. For these previous two groups, it seems clear

that while the project may serve a small niche in comparison to some other games, it has

relatively few competitors for the attention of those within that niche. Because of this, large

companies are unlikely to develop similar products, which puts the burden of competition mainly

on new, unbudgeted, independent developers, who make up the third and perhaps most relevant

group of competitors.
 6

Newgrounds (https://www.newgrounds.com/) has some number of games advertised as

MMORPGs, but not all of them are playable in a browser due to the Adobe Flash end of life

(“Adobe Flash Player”, n.d.). Furthermore, games on Newgrounds will often cater to the

Newgrounds community rather than a wider audience, thus limiting the potential audience of any

competing products. Elyssia (https://elyssia.myztregaming.net/) is an RPG playable in a browser,

but this is fairly distinct from Codename Yoinks due to its text-based gameplay. Mirage Online

(https://mirageonlineclassic.com/) is perhaps the largest competitor to Codename Yoinks.

However, the project distinguishes itself from Mirage Online with its artstyle, which is perhaps a

more significant change than it might seem initially. In any case, if there is only one main

competitor to a given game, it seems likely that there is room for both games to coexist. This is

due to both the large number of people who play video games, and the fact that people can play

more than one game, even if they share many similar features. As such, Codename Yoinks is not

likely to be dead upon arrival, although support will be necessary if the game is to continue to

succeed.

Future Support

Continued technological support, such as debugging and keeping ahead of feature

deprecation will be necessary for long-term success with Codename Yoinks. A game with too

many bugs or similar problems will fail quickly when alternatives are available. New features

will help keep people interested in the game. Which features are able to be added will depend on

what is complete at the end of the current development period, but new player classes, maps, and

increased supported player count are all potential future additions. A solid base for later
 7

additions will be necessary for this to be successful of course, but this is simply good practice

regardless of which additions are planned.

Legal and Ethical Considerations

Most legal and ethical concerns have already been mitigated. Assets have been licensed

appropriately, and the project should not be at risk of any international scandals as part of its

release. With no monetization planned until after the current development period ends, there is

still time for due consideration to be made to the monetization strategy, but the exploitative

monetization strategies technically available are unlikely to be used for a variety of reasons

including personal preferences and difficulty in actually executing the monetization strategies in

an exploitative manner. The risks of gaming addiction are similarly not relevant during the

current development period, since most of the issues largely only appear once a product achieves

a certain amount of success. The number of people addicted to unpopular games is fairly small.
 8

Part II

Design Requirements

Platform

From a consumer perspective, the platform is the web. However, this is rather imprecise,

as it does not describe much about the nature of the project from any other perspective. The

game uses a number of different technologies to deliver the simplicity of what the final recipient

views, including Phaser (https://phaser.io/) for the engine, Socket.io (https://socket.io/) for

communication between each client and the central server, and Amazon Web Services (AWS) for

the server itself. Each of these were chosen deliberately due to their popularity. While there may

be alternatives, and perhaps even superior options for this use case, the seemingly more popular

options were chosen in order to facilitate quick development time of a new kind of project for

team members.

Major Functions

The two major, uncompromisable functions are player on player interaction and

exploration. The Massively Major aspect of the MMORPG requires some number of players to

simultaneously access the game, and so player interaction is a must, even if it is at a very basic

level. Similarly, the RPG part requires a certain amount of role-playing elements, and allowing

for the exploration of some game world is perhaps the minimum satisfying requirement. It would

be difficult to claim that a character exploring a defined world does not allow for some amount
 9

of role-playing. Both of these functions together certainly constitute an MMORPG, and perhaps

even an enjoyable one, although certainly a simple one.

Figure 1

Spawn Area for Players

There are non-necessary functions that would be major elements of the final product.

This includes Non-Playable Characters (NPCs), areas to explore beyond the major overworld,

and combat (either between players or players and NPCs). However, the timeframe for the

project may not allow for these, or other similar features to be completely fleshed out.

Table 1

Potential Future Additions

Feature Development Time Required (post-testing

stage)

Non-Playable Characters 1-2 Weeks

Magic/Melee/Ranged Combat 2 Weeks

Special Class Abilities 1 Week

Dungeons 1 Week
 10

Usability Test Plan

The project test will be small scale initially, with people the development team is already

familiar with being the first testers. While a full-scale release may benefit from a wider-scale

testing solution with strangers being a major part of the test group, this testing pattern provides

benefits that are more helpful at this stage. For example, certain small issues, such as account

problems, can be fixed while the testers are using the game, reducing downtime. Until a certain

amount of testing has been completed, testing groups should stay small and be easy to

communicate with. The main evaluation method is a checklist of four separate tasks. A live

conversation will allow the development team to understand what exactly is going wrong for any

member of the focus group, which should help any urgent issues to be fixed in the future. An exit

survey was considered, but this did not present many benefits with the way the testing was

conducted. A live conversation during the focus group’s time with the project allowed for a more

personal way to share information and experiences with the project.

Usability Testing/Evaluation

The testing process went smoothly. A phone call, proximity, and the use of a voice over

internet protocol application allowed each of the three members of the focus group to provide

detailed live feedback about their experience. Two members of the focus group were also able to

show what they were experiencing live on screen, with the final member providing a recording.

This allowed for immediate feedback on the problems and irritations experienced by the focus

group. Notes were taken during the testing process, in order to allow the development team to

investigate what the most common issues were, what is fixable within the given timeframe, and

if there are any parts of the project design that must be reworked. Two testers were able to
 11

complete each task in the checklist entirely. The third tester was unable to do so, but this was due

to some browser settings that the project cannot work around in this case. As such, the

development team is generally comfortable with the major parts of the project. Some of the

feedback from the testers will of course be taken into account, but these are minor tweaks rather

than major changes.

 12

Part III

Final Discussion And Reflection

Timeline/Budget

Most milestones were met by the end of the development period. However, the

development team decided to reevaluate the necessity of certain milestones related to player

interaction for two main reasons. First, in a commercial setting, if the development team was

attempting to market the game to publishers, other features would be a first priority. For

example, the server-side processing cannot be neglected, since it is a core marketing point.

Features like chat and combat are expected for an MMORPG, but not strictly necessary under

certain designs. This leads into the second reason for the reevaluation. Removing things like

in-game chat can result in a more accessible experience for new players, as they now are able to

engage with fellow players on their own terms, whether that be through external channels (e.g.,

Discord or local friend groups) or simply through the game itself. League of Legends, a popular

online game, recently removed the ability to chat with enemy teams for a testing period in order

to see how it might affect players and if it could be done permanently in order to decrease

toxicity (“Disabling /All Chat”, n.d.). For a similar reason and to increase accessibility, features

directly related to player interaction were deprioritized in order to allow players themselves to

decide how that might look, and more development time was spent polishing other aspects of the

game, such as hitboxes, visuals, and connection latency.

 13

Original assets were not created for the project. While this is slightly disappointing for

some members of the development team, it was always an optional milestone, and there would

not have been time to create enough assets to reach the visual fidelity shown in the final product.

All other milestones were met however, and roughly according to the initial schedule. The

maximum delay for individual milestones was generally only one day, often caused by time

differences or misevaluated requirements. This was counterbalanced by some milestones being

met faster than initially planned, sometimes by multiple days. Overall, a more detailed schedule

would have been necessary in order to reasonably meet a schedule in a stricter fashion.

Preexisting art assets were acquired and used for the game. However, the team member

who acquired them intends to continue using them past the development of this project, so the

budget was not harmed by this. A larger number of AWS dynamo hours were used than initially

expected, putting the development team technically above budget if no planned budget is

considered equivalent to zero dollars. While the development team does not consider the project

over-budget, a second look suggests that a more detailed investigation into the budget during the

planning period would have been warranted.

Final Implementation

The final implementation of the project is fairly simple from the perspective of the user.

After logging in, the users can create a custom character and use that character to explore the

map. The side of the project that the user does not see, however, is significantly more complex.

The game uses Phaser to implement game functions. Phaser uses a preload and create function to

prepare content before the game begins. This is where things like the music and art are prepared

before the player begins play. The main content is driven by an update loop. A function is called
 14

each frame to progress the game state. Within this loop is where the keyboard state and client

identifying information is passed to the server. This information is used to decide the game state

for all connected players, and the appropriate information is streamed back to the connected

players. This ensures that there are no discrepancies between one player’s game state and

another’s.

A fairly minimal amount of information is stored about each player. Their created

characters (including the class and name) are stored in order to allow them to access it at a later

date after logging out. OAuth2 is used for login information and functionality, but players can

not be identified from any information the development team has access to. In the future, if

player interaction such as chat or friend groups are implemented, more information may be

necessary in order to prevent abuse, but this will have to be decided once the design of those

features has been discussed further.

Discussion

While development generally went smoothly, there were a few difficulties. For example,

the aforementioned reevaluation of the necessity of chat, among other features, required a

restructuring of certain other elements of the project. The removal of chat specifically required

the webpage used to play the game to be redesigned, since the original design included an area

for the chat box that would have been visually disharmonious with the rest of the site if there

were nothing in it. While the final rollout to users went smoothly, there were a few occasions

where a weekly push to the hosting service would take a longer amount of time than would be

tolerated by expectant customers. There was only one occasion where a change broke the

environment, and this was fixed within a day. Overall both development and design went
 15

smoothly, with minimal interruptions. Any further development after the release of the project

should be done carefully with contingency plans ready for any major issues. All goals that were

not deliberately reconsidered were met. The final product is easily recognizable as an

implementation of the original plan.

Table 2

Summary of Met Goals

Original Goals Status

Create an interactive world to be accessed Met in completion.

through a browser.

Create a chat service for players to Not met, necessity was reevaluated.

communicate.

Allow for more complex in-game player Met to the intended and necessary degree.

interaction. Further development is possible.

Allow for server-side processing of data, Met in completion.

resulting in a less vulnerable architecture

while simultaneously requiring less

calculations client-side.

Create original assets (optional). Not met (pre-existing assets were better suited

for the project).

 16

The project would not have been possible without the team’s ability to work together, and

the development would likely have been made more difficult if any non-trivial changes were

made to the team. More team members could have made it difficult to effectively

compartmentalize and assign work, and overlapping tasks could have been difficult to work on in

a project of this nature. Less team members would have resulted in a workload too high for the

remaining team members to reliably complete to the same degree. Different team members

would have resulted in different skill sets that may not have been as well-suited to the assigned

tasks. The end result is a product that each team member believes is a well-executed

implementation of the original design with a potential future as a commercial product.

 17

References

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

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

Disabling /All Chat. (n.d.). Riot Games.

https://www.leagueoflegends.com/en-us/news/game-updates/disabling-all-chat/
 18

Appendix A

All testers should be able to complete the following tasks without major hardship:

1. Initial game load and login process (with AuthO).

2. Custom character creation process, including naming, class choice, etc.

3. World exploration, potentially including viewing other players.

4. Complete the login process a second time to allow them to play the same character.
 19

Appendix B

While each team member filled in where necessary, team roles were assigned in the

following way:

James DeSelms - Frontend Engineer and Testing Lead

Brandon Lee - Backend Engineer

David Sullivan - Backend Engineer and Resource Acquisition

In general, the assigned team roles defined responsibilities unless changes were

absolutely necessary.