CSUMB: The Fantasy MMORPG

Project by Cian McDermott

California State University Monterey Bay

CST 499: Directed Group Capstone

Faculty Advisors: Eric Tao, Brian Robertson

October 17, 2017

 McDermott 1

Executive Summary:

Over the course of this project, I created a functioning environment for an online game,

capable of hosting several different users at once. However, the game itself is not the most

important part of the capstone project; instead, it is meant to help demonstrate the use of and test

for a specific feature among many. A fatigue system, meant to lessen the amount of experience

points a player receives based on time, is hardly new to MMORPGs. Many have incorporated

this kind of system in the past, and several stopped implementing it, either because some players

managed to find a way around it, or because its introduction was met with disapproval by their

audience. This feature, implemented in the project to encourage users to play yet discourage

them from spending too much time in the game, are the main focus of the project.

The reason that I am working on this project, and developing a way to discourage daily

overuse of online games, is related to players turning into MMORPG addicts. Some people end

up spending most of their time awake playing online games, ignoring education, careers, and

even their social lives. In order to prevent individuals from wasting their lives in virtual worlds,

many different methods, including the fatigue system, were created. While they may have helped

curb the problem, they were not completely effective on the entire community, and did not solve

the problem.

In the present day, there are dozens of MMORPG titles with plenty of community

members, with the most popular ones consisting of several million subscribers. While that is the

case, the amount of people actually suffering from addiction are a minority in comparison. Even

if that is the case, there have been stories about people whose lives were taken over by online

games, and there is awareness about this issue. Although the percentage affected by this project
 McDermott 2

depends almost completely on interest in the project itself, I believe that this project is worth the

effort if even a few are positively affected by its results.

After weeks of writing and editing code, configuring game objects, and testing the

software, I believe I can demonstrate a new method of curbing addiction and preventing players

from becoming too addicted to online games as a means of entertainment. A lot of this, however,

depends on the attention this project gets after the courses end; considering the short time in the

course, the final product is relatively scarce in terms of features compared to popular online

games, so the game itself gaining enough popularity during class duration is very unlikely.

However, if the project gains awareness afterwards, then other developers concerned with the

issue may use this project as an example in order to create similar methods.
 McDermott 3

Table of Contents

Part I
Introduction and Discussion 4

Project Name and Description

4

Problem / Issue with Technology and Proposed Solution 4

Project Goals and Objectives 6

Community and Stakeholders 6

Evidence the Project is Needed

7

Feasibility Discussion 8

Part II

Design Requirements 10

Functional Decomposition of Project 10

Selection of Design Criterion 11

Final Deliverables 12

Approach / Methodology 13

Legal Considerations 13

Ethical Considerations
14

Part III

Timeline / Budget 15

Usability Testing / Evaluation

16

Final Implementation 18

Conclusion 22

References 25
McDermott 4
 McDermott 5

Part I

Introduction and Discussion

Project Name and Description

For my Capstone project, I am proposing to spend the term working on designing a

small-scale online RPG. My project, given the tentative title CSUMB: The Fantasy MMORPG,

is a game that will allow players to interact with one another within the online environment,

managed via Cloud applications utilized by the game. Since the initial creation of MMO

(massively multiplayer online) games, several titles have emerged in the present day, each

appealing to players with a variety of genres and settings. Similarly, many indie developers

have managed to create successful video game titles, despite having less funding and developers

than mainstream AAA titles, but very few have the capabilities for players to interact with

others online. Over the course of completing my Capstone, I plan on learning the process for

designing an online RPG, demonstrate my ability to program features commonly present in these

games, and to create something that appeals to a variety of users, despite being relatively small in

scale.

Problem / Issue with Technology and Proposed Solution

When it comes to issues related to MMORPGs, the one that most commonly comes to

mind is addiction; for various reasons, people end up spending most of their lives in these games

and end up giving up their careers, education, and social lives simply to spend more time in the

virtual world. The easiest solution to this, in addition to keeping the product from being too

boring, would be to find ways to encourage players to not spend entire days logged in.
 McDermott 6

From a gameplay perspective, a good majority of the motivation to continue playing

these games revolves around experience points, in-game currency, and item drops. I could limit

these by making it so experience gain does not come from defeating enemies, but solely from

completing quests. In addition, I thought of making it so each player can only go to the area

where they can gather items and defeat enemies for quest completion a limited number of times

per day, and to prevent them from monotonously farm for those two things for hours on end

(which is common in these types of games), there should be a fatigue system, where the rate

enemies drop items decreases the longer the players are logged in, to the point where they no

longer drop them until the player logs in the next day. I kept these solutions, in addition to others

I came up with, in mind during design of the game.

While video game addiction may be signs of underlying problems within the individuals,

online games without methods to curb individual play time to reasonable amounts do nothing to

help. According to data gathered on a website regarding tech-related addictions, 41% [in a

sample] of online gamers acknowledge they use games as an escape. In the same sample, 7%

were viewed as dependent. These gamers possessed several behavioral attributes that are

related to more well established forms of addiction, and those who thought they played

excessively appeared to have withdrawal symptoms and relapse (Conrad). Similar data found

that online role-playing games, especially MMORPGs, had users more likely to exhibit addiction

than any other platform (Conrad).

MMORPGs have been around since the earliest installments around the 1990s. Since

game development was relatively low-tech compared to today, they did not need teams

composed of many programmers and developers to create those online games as they do today.
 McDermott 7

However, among them there is one title that can be considered today to be an indie MMORPG:

Runescape. Originally created by three brothers (Andrew, Paul, and Ian Gower), Runescape was

designed by these three after a few years of programming and designing, they managed to release

Runescape in 2001 using elements from their previous attempt at an MMO, DeviousMUD (De

Groodt, 13-14). To this day, Runescape is still running, and it has advanced both in size and

quality since its initial release a little over 15 years ago.

Project Goals and Objectives

The ultimate goal of this Capstone project is to create a functioning game where many

users are capable of interacting and playing together in the same environment. Most of the

features that will be present in my product will be vital for testing my main feature: a means for

convincing players to spend more reasonable amounts of time on online games. The other

features, while not directly related to that, will make the game easier for the users playing and

testing my project.

Although the main focus for this project is a single feature, the proper testing for it is

dependent on various others. Assuming I use a method that lowers experience over time, I would

still need to implement methods of players gaining experience, and before that I would need to

create an environment for the players to explore, as well as a means for them to enter the game

itself. In order to properly demonstrate the focus for this project, I need to create a proper

environment for it to be tested. As such, the creation of my online game, at least to the barest

minimum, is just as important.

Successfully implementing each of these features, running perfectly fine without any

explicit errors, are each important objectives for my goal in this project. Concerning the order in
 McDermott 8

which each are created, I have a rough idea about the priority for the features, based on what I

believe which ones are dependent on others.

Community and Stakeholders

There is a massive community surrounding MMORPGs, where each title potentially has

millions of users subscribed and logging in regularly. For reference, World of Warcraft,

considered to be the most successful and popular MMORPG to exist, had a total of roughly 12

million subscribers worldwide in 2010, and although the numbers have dropped significantly

since, it still managed to stay above 5 million total players in 2015 (Statista).

In comparison to the long-running World of Warcraft, a newer MMORPG released

roughly one and a half years ago, Black Desert Online, managed to reach 3.4 million players

total in Europe and North America as of March 2017 (Censeo91). Even if these numbers are

significantly less than the former title, these numbers alone say just how large the online gaming

community is today. However, these numbers also represent these titles overall quality and

appeal to their players; an online game made and maintained by large teams, constantly updating

and upgrading their product, would naturally have higher numbers than an independent project

worked on by a much smaller team.

With these comparisons, I do not believe that there is much for this community to either

gain nor lose because of my project. On the chance that my project does become well-known in

this community, I might have reason to expand it into a larger, more open-world game, or other

companies may use some ideas I implement to create their own online games. If it does not,

however, that just means it was one of several other games that ended up shutting down due to a

lack of interest.
 McDermott 9

Evidence the Project is Needed

If it is meant to curb MMORPG addiction, in addition to discouraging players from

spending too much time online, I believe it is better that the solution take the form of a game. As

explained earlier, those suffering from this addiction experienced withdrawals and relapses, the

same as any other addiction. If that is the case for the individuals, they should find a suitable

substitute as a means of coping, similar to how those trying to overcome cigarette addiction tend

to switch to e-cigarettes, vaporizers or vapes, and other nicotine products that lack the other

substances found in cigarettes. Substituting a game they are addicted to with another may not be

100% successful, but making it so they get gradually less exposure to the source is a practical

and common solution to overcoming addiction.

Feasibility Discussion

As mentioned previously, one MMORPG that can definitely be described as indie

would be be the game Runescape. As such, my literature review mainly involved research into

the games beginnings and development into what it has become today.

The History of Runescape by Gunter De Groodt, my main source of information about

the game, explains how its developers made Runescape using a lot of the ideas they made for

their original game, a 2D Multi-User Dungeon game, and consistently began adding additional

features over the years. The game was officially released in 2001, and lacked its Grand Exchange

(an online market that let players make in-game trades without having to be face-to-face) until

2007 (De Groodt, 16). In addition, while Runescape was initially free-to-play, that was when the

game was not very popular and the creators did not expect it to become popular enough that they

would need to pay for maintenance of its servers; early in the year following its release, the
 McDermott 10

developers added additional content for purchase as a means of covering the costs for

maintenance of the game overall (De Groodt, 16). This game has existed for a decade and a half,

and while my project also involves adding various features over time, those ones are more

integral to basic functions in the game, and I am doing this over the course of a few weeks, as

opposed to the several years Runescape has.

Initially, Runescape came up with a fatigue system that limited player actions, albeit for

reasons unrelated to curbing the amount of time individuals spend in-game. The fatigue system

used in the game was meant to counteract the high amount of bots, A.I.-controlled player

characters meant to repetitively gather experience and items without the requiring the actual

player to do anything (De Groodt, 202). How it worked was that, as your character performed

actions, they would gain fatigue, which would lower the amount of experience and resources

they gained from said action; in order to recover, they had to rest in beds in-game, something the

creators believed bots were incapable of doing (De Groodt, 202).

This feature, however, made playing the game tedious for the actual players, as they

would have to travel to and from different areas in order to lower fatigue they gained over time.

To make matters worse, the developers solution to this made it easier for bots to get around

what the fatigue system was preventing them from accomplishing (De Groodt, 203). For these

reasons, very few reacted positively to the fatigue system, and it was eventually removed and

replaced for something else entirely in 2004 (De Groodt, 203). While the fatigue system I am

working on is not meant to combat bots, the ideas used in Runescapes fatigue system can be

used to help in the design of my own. In a way, the problems with internet addiction and bots can

be related, particularly when it comes to repetitive actions in-game for long periods of time.
 McDermott 11

The ideas introduced in Runescapes fatigue system can be used to make something that

would work in this game as well. Earlier, I mentioned several possible ideas to program ways to

discourage playing for several hours, such as lowering item drop rates each hour and limiting

experience point gain to quests. If the players have to report completed quests in town, then they

would be moving between the two areas constantly in order to gain experience points. To have

this work with my fatigue system, as well as adding a bit of realism to the game, I could make it

so the players also gain fatigue upon returning to town, and making it impossible to go to the

field once the player maxes out their fatigue for the day. If the player is incapable of gaining

more experience or collecting items, it almost completely discourages them from continuing to

play the game, which I believe will serve the purpose of this system.

Part II

Design Requirements

Functional Decomposition of Project

While my capstone project revolves around the creation of an interactive online game, the

main purpose is to properly demonstrate a fatigue system, which is supposed to act as a

deterrent for players to play this game for hours on end. To properly demonstrate this design,

several elements common in online games are necessary; from the most basic, we would need an

environment to explore and avatars for the players, records of their play time, and means for

them to gain experience, which ended up being enemies, the items they drop, and quests where

players turn in those items.

As they play the game for extended periods of time, players would gain fatigue for

every consecutive hour. In previous games where this system was present, fatigue would affect
 McDermott 12

the base percentage of experience they would gain from certain tasks, but certain flaws and their

solutions would render them pointless. Instead, I am making it so players only gain experience

from completing quests, and fatigue only affects the enemies item drop rates, which are

necessary to complete the quests in the first place. Since fatigue gain is gradual, and in order for

the players to properly test the system, I also plan on making it so that, when a player returns to

the in-game town from the field, they will also gain fatigue for when they return to the field.

Say that the highest possible value for fatigue is eight. If so, then each time an event

occurs to trigger an increase in fatigue by one, either by playing for an hour or returning to town,

all item drop rates of enemies will decrease by 12.5% of their base value, as shown below.

Hours in-game and/or trips back to town Item drop rate (from their base value)

0 100%

1 87.5%

2 75%

3 62.5%

4 50%

5 37.5%

6 25%

7 12.5%

8 0%
 McDermott 13

Selection of Design Criterion

The performance of this project depends on whether the users computers are capable of

running the game. However, it also depends on whether or not the Cloud application I chose to

implement with the game are capable of supporting the multiple clients, as well as keep all of

them in sync with each other without significant delay between the Cloud and each client.

After spending several weeks working on my project, I found that several scripts ran at

least 200 to 300 lines of code. While this may not seem like much, I am in need of several scripts

working for different objects within the game. So far, I have written scripts regarding player

controls, user interface, connecting to the games server, and several other functions running less

than 200 lines.

Thanks to the availability of free game assets when creating a game with Unity, the costs

for creating the project have been close to none. When in need of specific assets for the purposes

of my project, I chose ones that were as cheap as possible, which let me spend as little as

possible on the project.

Final Deliverables

Once the capstone is complete, the final version of the game will be presented as the

main deliverable. All of the environments, assets, and code written in order to create a complete,

working game would be considered the final version. Given my initial timeline and the amount

of time I have to work on this project, I most likely will not be able to implement other elements

more common in MMORPGs, such as separate character classes, a party system, friends lists,

and other small yet important features. However, despite this deficiency of common elements,
 McDermott 14

the idea for my final product is an online game that is still entertaining for its players, and

manages to exhibit many core elements of gameplay.

In order to give users and testers access to the build of the game I have created so far, I

have created a standard website that contains a link to the current build of my game. Originally, I

had planned on posting builds directly on the website, but the file size limit for free users on

Weebly.com made things slightly more difficult. Instead, I posted a link to my account on a

file-sharing site that gave me significantly higher, in addition to basic game controls and an

e-mail address to send any reports or feedback on the game.

Over the course of the user testing, I will most likely have gathered a good number of bug

reports via e-mails I receive from players. If necessary, I will include these e-mails as part of my

projects deliverables (with the senders information edited out, of course). These reports would

serve as proof not only that I had communicated with the users testing my product, but that errors

were found in my code, and they had been fixed once I was aware of them.

Approach / Methodology

As mentioned earlier, I will conduct user testing by releasing current builds of the game

to the public. It is common practice for game developers to release an open beta in order for

them to receive proper feedback from developers and become aware of any bugs overlooked. As

such, they will be able to access game builds from my website, play the game first-hand, and

send any feedback or reports to my given e-mail address.

Before releasing a beta version of the game, I had done some preliminary testing myself.

What the testing consisted of was basic player controls, animations, and making sure the players

interface functioned correctly. In addition, I made sure it was possible for multiple users to
 McDermott 15

connect by running multiple instances of the game on my computer. The reason I had done this

much by myself, rather than have users test immediately, was both to make sure the players

could control properly and know what to test for, and I was waiting until I had implemented

internet connectivity as a feature. My reasoning for this was I wanted to get the more obvious

bugs out of the way, so that users could test for any that were not as apparent when I tested by

myself.

When it comes to the feedback I receive from playtesters, I plan on following my initial

schedule as I correct the errors I become aware of. So far, I have been able to correct any errors I

noticed by the end of the milestone week. However, depending on the type of feedback I receive,

certain features may have to be delayed or pushed back to another week.

Legal Considerations

As far as game assets are concerned, the Unity store offers downloads for both free and

paid-for assets that I could implement into my project. Therefore, I do not believe there would be

any copyright issues involved in regards to assets in the game. So far, the assets I downloaded

for the game all came with a copyright disclaimer, but I am slightly concerned if there would be

copyrights concerning how I have written my code.. To my knowledge, however, copyright is

not an issue unless I am actually making a profit from this project. If I plan on using what I

created in the capstone as the basis for something I would want to earn a profit from, it would be

after the completion of the capstone, and I would perform the related research and apply changes

according to what I discover.

 McDermott 16

Ethical Considerations

The Massively Multiplayer in MMORPG implies there is a significantly large number

of players within the game. Despite calling my project an MMORPG, the amount of players

within the game (testers included) are predicted to be much smaller in scale compared to others.

Whether or not the size of the games player base ends up being big or small, almost all ethical

concerns relating to my project has to do with what kind of community emerges within.

The first part of my proposal discussed the game Runescape in a few sections. To use this

as an example of my ethical concerns, it was announced in June that they would be holding an

event for the LGBT community. However, in response a large number of players announced they

would be rioting in-game as part of an Anti-Pride protest. I do not imagine the community in the

game growing nearly as large in the span of time for my capstone, but these thoughts should still

be put into consideration.

Considering the nature of my project is an online game, I cannot imagine the capstone

itself negatively impacting anyone. I imagine any harm that occurs would be a result of

interaction between players within the game, but that is as far as I can imagine there being any

impact. If underprivileged groups would be affected any other way, it would have to be related to

the games hardware requirements. Although I do not plan for it to be a game that requires a

high-performance computer, if theirs have low performance, the game may run poorly or they

will not be able to run it at all.

When a beta version of the game is released, a lot of testing within the environment is

dependent on those playing the game. However, from my understanding of the definition, what

the testing involves does not constitute Human Subject Research. The purpose of releasing a test
 McDermott 17

build of the game is not to study the interaction of players, but for the users to test how the

environment reacts to their actions.

Any ethical issues I may have regarding my capstone do not relate to the project itself,

but how those using it interact with others or whatever else they do within the environment. If

any unethical behavior does occur within the games environment, the most common action

performed by administrators is to suspend their accounts as a warning, or to ban the offenders. If

this issue comes up when I create an open beta, I would do the same in order to mitigate any

ethical problems regarding the project.

Part III

Timeline / Budget

In the beginning, I ended up meeting the various milestones and had them working

without almost any problems by the end of the week, or just shortly after. Near the end of this

courses final weeks, however, we had users testing our projects, which revealed several bugs

and issues present that I was previously unaware of. Due to this, my last weeks milestone was

put aside in favor of fixing these more prolific errors. The last milestone, a character editor, was

not really vital for the project overall, but I thought it would be more helpful considering

multiple users may become confused based on having several identical models on screen. Even

when project development for the course is close to over, I will spend a little more time trying to

fix the few remaining lasting bugs.

Considering the types of assets available for free thanks to the Unity editor, before the

project began I did not expect to spend much money over the projects development. I actually

did not think I would spend any at all, but there were two instances in development where I felt
 McDermott 18

certain assets were needed for the project. Even then, the total amount of costs was a mere seven

dollars; even considering the amount of assets I was able to use for free, this amount is

negligible.

Usability Testing / Evaluation

What the usability testing involved in my project amounted to was relatively simple;

since my project was a game, the best way for users to test for the final product would be by

playing it. Using the website I made to host information and the latest build of the game, I

essentially held a small open beta, where I asked acquaintances familiar with playing online

games to test the build I had prepared. In addition, since the project is an online game where

multiple people could play at once, I had logged in alongside them for testing, in order to see if

any problems arose related to having more than one client on the server at a time.

When both I and the playtesters had logged into the game, I had them explore the

environment: first, the town area, and then the field where they would fight enemies. The tests

performed while in town were basic; the first involved being able to control the player avatar and

having the camera focused on the right avatar. Afterwards, I noted details such as how the

movement of other players was perceived from my client. The movement of other players was

not as smooth as my movement, and the difference appeared to be the same regardless of testers.

Due to this, I believe it was not a matter of lagging due to network connection, but how often the

script I was using kept track of other clients. Having more than one player on the same server

also resulted in extra avatars being instanced, which is an issue that was fixed after user testing

was completed.
 McDermott 19

After observing scene transition and how movement of other players was presented in my

client, we moved on to other tasks I was having issues with. In the field, I observed details

regarding players status, enemies, and items. When players took damage, they noted that the

display for their hit points did not change, but there were signs in-game that they took damage.

In addition, one player had taken enough damage for their character to faint, but only the

appropriate animation played, without a window popping up to give them the option to logout or

return to town. Parts of this error have been fixed by now, but there is still some work being done

relating to the animation and disabling movement while fainted.

While observing the actions of other players within the field, I noticed them performing

attacks when there were no enemies nearby, their avatars being blown back from hitting

enemies I did not see, and one player even told me that there were enemies right next to me that I

did not see. All of these factors informed me of one issue that could only be revealed from this

testing period: enemies appearing on my client and theirs were in different positions. Luckily,

this was fixable by applying certain scripts to the enemies that I did not think were necessary

before these tests.

On a related note, since enemies would not be seen by different clients, that means that

the items dropped would not either. The reason for this would be similar to the issue with

enemies, but there is another problem with items that was related to character instancing. The

script that allows enemies to drop items is written so that, when the enemy object is destroyed,

there is a chance for one or two items to be created upon enemy destruction. However, when my

network connection had been cut briefly and I logged back in, I was informed by a tester that,

upon exiting the game, several enemy objects were destroyed and they drop a lot of items as a
 McDermott 20

result. I found out later that, because code is written so the scene is reloaded upon a player

leaving the server, the enemies destroyed upon the scene reloading dropped items after I had left.

This issue, in addition to others, ended up being fixed after I had edited out certain parts of the

script I was using.

As described earlier, all the testers really needed in order to evaluate the project was a

copy of the current build and a stable internet connection, in order to access the game alongside

others. In order to get feedback from one person at a time, I messaged them to ask them to test

the product, and played on the server with them one at a time. While they played, I asked them

how different parts of the game looked on their end compared to mine, if they ran into any

issues, or if any features were behaving differently than they expected. There were no formal

surveys or other documents involved; if I needed any information regarding their experience, I

would ask them in person or review the logs from Skype chat for the information I required.

Final Implementation

The project has an associated website as a means of hosting the latest build of the game,

in addition to giving visitors basic information regarding controls, features, and other details of

the game. One of the pages contains an encrypted link and password to download the latest build

from a file hosting site I have an account on, and instructions regarding placement of a database

file used to store player account information.

Once the games files are unzipped and the user clicks on the exe file, they will be taken

to a login screen after setting the clients window size and graphics resolution. On this login

screen, the user is given two choices: creating an account, which will add rows to the database

tables assuming that the entered username has not already been taken, or signing in, which will
 McDermott 21

log the user in only after confirming that the inputted username and password matches those in

one of the rows in the associated table. Almost all online games use a database located on a game

server to store this information, as it makes it more difficult for players to illegally alter their

characters information or the data of other players. For the sake of convenience and simplicity

in project testing, this project uses the local database file mentioned above instead. Note that the

reason you are instructed to move the database file to the correct folder is because, for now,

attempting to login or create account without it in the correct location creates another database

file, with a similar name but lacking any tables accessed in the games scripts.

Once the user has successfully logged in, the game accesses a Cloud server used by

multiple clients at once. If the user is the first to log in, they are assigned as the master client,

which is responsible for running game logic that the server is not capable of; so long as the

master client exists, the server is still running, and if the master client logs out, one of the

remaining clients, if any are logged in, are assigned the role instead. This does not relate to

gameplay or any features players would otherwise find in the game, but it is necessary in order

for the project to act like an online RPG, making it possible for multiple players to exist in the

game at once and interact with each other.

The game has a user interface consisting of several elements; the more basic ones include

a bar displaying the players hit points, a chat window which still need work, and a button which

opens a dropdown menu. This dropdown menu consists of three buttons, two of which retrieve

information from a database table upon being clicked; the first is for the players inventory,

while the second displays the characters status, including maximum hit points, experience
 McDermott 22

gained, and a fatigue percentage. The last option in the menu, which logs the character out of the

game, records the players location before closing the client.

Considering the short length of the course, I decided to limit the in-game areas to a

simple town and field. When the user logs in, they will enter the town, and can interact with

NPCs that give them brief information regarding some of the features present in the game. The

towns layout was modeled after a part of the CSUMB campus, and, while being relatively

empty compared to its overall size, is part of my idea on how to convince players to limit their

daily playtime. In addition to the NPCs present in the area, the town also contains a quest board,

containing a list of tasks that the players complete in order to gain experience points, and a

means of traveling to the field area.

The field, in contrast to the town, is significantly larger, consists mainly of trees and

grass, and is where all of the enemies encounterable in the game appear. When a player enters

this area, it will be completely lacking in enemies. However, the associated script in this area are

written so that more enemies will appear as time goes on. Each of the three types of enemies has

an associated number of allowed instances at once, a location for them to instance, and a

cooldown period between each individual instance. This is designed to prevent any problems

involving too many objects appearing in the area, in addition to limiting the actions of players

who plan on mindlessly defeating any enemies they come across to accomplish tasks.

In most games in the same genre, combat with enemies involves trading blows until one

of the two or more combatants has their hit points reduced to zero. For the sake of time, combat

was simplified; upon instancing, an enemy object will continue moving in a random, linear path

until it detects that a player is close. Once it finds a player in range, its path will change, and it
 McDermott 23

will pursue the nearest player and collide with them. When a player object and an enemy object

collide with each other, one of two things will happen, depending on the players actions. If the

player is attacking while colliding with the enemy, the enemy is destroyed, and there is a chance

it will drop one or two items necessary for completing the quests in town. However, if the player

does not attack during a collision, then they take one point of damage and are sent backwards.

The entire point of the project is to find a way to discourage players from staying on

online games for prolonged periods of time. The game was designed in order to test the fatigue

system I came up with, to see if this does have an impact. Earlier in this report, I discussed how

this system lowers the item drop rates of enemies the player defeats, but I did not go into

complete detail on how players gain fatigue. For starters, the first in-game event that raises

player fatigue is the player spending an hour logged in, since time spent in-game is one of the

things this system is trying to reduce. Second, to make players act sparingly in terms of

movement between areas, and to simulate returning home from a hard days work, the fatigue

counter increases whenever a player returns to the town area from the field. Since the only way

to gain experience points is to obtain a required amount of specific items found by defeating

enemies in the field, and then turning them in at the quest board in town, players have to make

their decisions more wisely if they want to make progress. The final factor involves the players

hit points reaching zero and the player fainting; whenever the player faints, their fatigue counter

increases regardless of whether they decide to log out for the day or return to town. This way,

they cannot cheat the system by closing the program or logging out, then logging back in to

prevent gaining fatigue.

 McDermott 24

Over the course of this project, I had used several assets available on the Unity store. This

not only included 3D models, but animations, network connection capabilities, and even code I

either used as-is or edited to make it more suitable for what I had in mind for the game. While

scripts for most tasks, such as controlling the player and camera, connecting to the games

network, and scene managers were borrowed and edited, there was also plenty of code I wrote by

hand. For example, before I began adding online features to the projects build, I had written the

code enter the game from the login screen based on how I designed the interface, and the scripts

attached to enemies, which decide the random direction they move in and if they drop items on

defeat, were written by referencing the Random library and looking up associated functions in

Unity.

In the past eight weeks the game was in development, I came across several errors which

caused me to postpone work or push certain milestones back for a bit until they were solved. One

of the earliest issues I could remember involved writing working code for the players camera;

while attempting to make the camera move around the player or zoom in and out with the

mouses scroll wheel, the result ended up making the camera not focus on the player avatar. This

part of an early milestone ended up being pushed back until module six, where a similar camera

issue ended up being fixed by using an example game as a reference. This same solution also

helped me solve another issue with the players user interface, where the players displayed hit

points did not update when receiving damage from an enemy.

This project came with many issues I had trouble resolving until I did some more

research on the specific feature I was making or looked into other Unity users that ran into

similar problems. In addition, testing the scripts by running the project myself was sometimes
 McDermott 25

difficult, especially when the error in the code caused the game to crash when it happened. These

incidents were double-edged swords; on one hand, they made it much more obvious what the

problem in the code was. However, this meant I had force quit the editor, start it up again, work

on the part of the code that needs editing, and try the exact situation again, hoping that it does not

cause the editor to crash again. While the time this process takes might not seem much more than

usual, it often made me more stressed than I would be encountering regular errors, which would

affect my willingness to continue my work on the project for the day.

Conclusion

In order to try and alleviate any issues related to peoples dependence on online games, I

attempted to design a game with a mechanic that discourages players from continuing to play for

hours on end. Since other online games tried implementing similar mechanics by targeting

experience points players gain, I tried something a little different, by making it so the more time

players spend in-game, the less likely they gain items needed to gain experience in the first place.

With this in mind, I built an entire game environment in order to properly test this mechanic for

practical use.

The MMORPG community is made up of millions of users, and part of this community

consists of people whose entire lives are practically dependent on these games. I want to try and

curb the problem using another game, since it would be a similar enough substitute for those

exhibiting signs of addiction and over-dependence. When comparing my capstone idea to

existing projects, both the main example for an independently-developed MMORPG and fatigue

system was the game Runescape, which had humble beginnings in the early 2000s to a popular

game in the present day.

 McDermott 26

While I do not believe the games requirements are close to those of current-age,

high-quality games, some may not have access to this project due to possessing computers with

inferior hardware. Despite this, after trying to run the game on an older computer of mine with

the lowest possible settings, I noticed a significant amount of lag, even before I logged into the

games online network. There is very little need for ethical and legal concern, as this game was

made using assets available for free and those I had paid to use. In addition, any other concern is

mainly around communities that may arise within the game, assuming it ever becomes popular

enough.

During my two years in CSUMBs online computer science course, there rarely were

times where a courses final project was done individually. Considering that I undertook one of

the most important projects of the course by myself, I feel as if I have accomplished a lot in

comparison. However, I also feel that, if I had worked in a group on this project, there would

have been less issues than the ones I encountered, and having at least one more person working

on the project as much as I could have greatly improved project quality, making many features

better and reducing the frequency I had to push back project objectives and features.

As far as the projects future is concerned, by itself I hope that the ideas I have brought

forth with the games design may be used by game developers with concern for those with online

gaming addiction. However, if I want to take this project and improve upon it after graduation, it

may take a completely different form than what I have worked on. The fatigue system and a lot

of the scripts I have written will surely be used, but this is assuming that I decide in the future

that a career in game design is something I am willing to pursue. Otherwise, I would be happy so

long as the ideas I implemented and introduced are used in future titles.
McDermott 27
 McDermott 28

References

Censeo91 (username) (March 2017). Black Desert Online Has 3.4 Million Players in NA and EU
Servers. Retrieved from
http://2p.com/47509136_1/Black-Desert-First-Year-EU-vs-NA-Statistic-Differences-by-c
enseo91.htm
Conrad, B. Gaming Addiction Statistics - Facts, Articles, & Research - TechAddiction.
Retrieved from http://www.techaddiction.ca/gaming-addiction-statistics.html
Conrad, B. Video Game Addiction Statistics - Facts, Percentages, & Numbers -
TechAddiction. Retrieved from
http://www.techaddiction.ca/video_game_addiction_statistics.html
De Groodt, G. (2016). The History of Runescape. Retrieved from
http://rshistory.com/downloads/TheHistoryOfRuneScape.pdf
Statista. WoW subscribers/player numbers. Retrieved from
https://www.statista.com/statistics/276601/number-of-world-of-warcraft-subscribers-by-q
uarter/