MAJOR PROJECT PROPOSAL relating to IT networking security

GamePad SOCIAL NETWORK FOR GAMERS

Feb 7, 2018

TS A00000000 COMP 8045 & 8046 Major Project 1 & 2 (18 credits)

Table of Contents 1 Student Background.................................................................................................................................................................. 4

1.1 Education......................................................................................................................................................................... 4 1.2 Work Experience............................................................................................................................................................... 4

2 Project Description.................................................................................................................................................................... 5 3 Problem Statement and Background......................................................................................................................................... 6 4 Complexity................................................................................................................................................................................ 7 5 Scope and Depth....................................................................................................................................................................... 8

5.1 Requirements................................................................................................................................................................... 9 6 Test Plan.................................................................................................................................................................................... 9 7 Methodology........................................................................................................................................................................... 10

7.1 Tools and Technologies................................................................................................................................................... 11 8 System/Software Architecture Diagram.................................................................................................................................... 13 9 Innovation............................................................................................................................................................................... 20

9.1 Technological Innovation................................................................................................................................................. 20 10 Technical Challenges.............................................................................................................................................................. 21 11 Development Schedule and Milestones................................................................................................................................. 21

11.1 Phase 1: Library Tracking............................................................................................................................................... 24 11.2 Phase 2: Central Database Population........................................................................................................................... 25 11.3 Phase 3: Deployment.................................................................................................................................................... 25 11.4 Phase 4: Data Importing................................................................................................................................................ 26 11.5 Phase 5: Dashboard...................................................................................................................................................... 27 11.6 Phase 6: Other User View.............................................................................................................................................. 28 11.7 Phase 7: User Messaging............................................................................................................................................... 29 11.8 Phase 8: Library Comparing.......................................................................................................................................... 30 11.9 Phase 9: Extended User Profle...................................................................................................................................... 31 11.10 Phase 10: Advanced Stats Tracking.............................................................................................................................. 32 11.11 Phase 11: Parties and Events....................................................................................................................................... 32

12 Deliverables.......................................................................................................................................................................... 33 12.1 Source Code................................................................................................................................................................. 33 12.2 Running Applications.................................................................................................................................................... 33 12.3 Designs and Wireframes............................................................................................................................................... 33 12.4 API Documentation....................................................................................................................................................... 34 12.5 Project Report............................................................................................................................................................... 34

13 Conclusion and Expertise Development................................................................................................................................. 34 13.1 Project Future............................................................................................................................................................... 34

14 Appendix: Detailed Schedule Breakdown.............................................................................................................................. 36

2

15 Change Log............................................................................................................................................................................ 38 15.1 2nd Revisions (February 7, 2018).................................................................................................................................... 38 15.2 1st Revisions (January 3, 2018)....................................................................................................................................... 38

3

1 Student Background I am a student of the Bachelor of Technology in Computer Systems program at BCIT. I also have 2 years of professional experience creating web and mobile applications, as well as the servers that connect those applications to the Internet. Since early 2016, I have specialized in JavaScript development on both the client and server side. This project will use this experience to keep things going smoothly, while also taking advantage of several more modern techniques, frameworks, and programming languages.

In addition to professional experience and education, I began learning to program as a hobby in 2010 and learned to develop games in 2012. In my free time, I like to play video games and board games, play guitar, listen to music, watch movies, play hockey and golf, read, woodwork, snowboard, and ride my snowmobile and dirt bike at my family’s cabin near Princeton. My attachment to the games industry and this project come from being an avid gamer since I was a toddler and played old Star Wars games on my dad’s computer in the 90’s. This long-term involvement in the gaming community helps give me the insight to deliver what gamers want with this project.

1.1 Education After graduating from high school in 2013, I immediately transitioned to being a full time student at BCIT enrolled in the Computer Information Technology diploma program. I fnished this 2 year diploma in December of 2015, after a 1 semester delay caused by taking part in the co-operative education program. In Fall of 2016, I returned to BCIT as a part time student to take the Bachelor’s of Technology in Computer Systems program, with a specialization of Wireless and Mobile Applications Development.

At the end of the Fall 2017 semester, I will have fnished all the courses required to complete the Bachelor’s program, with the exception of this project practicum. Once I have obtained my Bachelor’s of Technology degree, I will not be continuing into a Master’s program; however, I will likely return to school sometime in the future for single courses or certifcates.

1.2 Work Experience After the Winter 2014 semester, I started my co-operative education program with a 2-term co-op at the BC Liquor Distribution Branch (BCLDB) head ofce as an IT Security Analyst. During my time at the BCLDB, my primary responsibility was to manage user access to all company IT systems. This included the head ofce workstations, corporate email, manager laptops at the stores, wholesale customer accounts, and more. Other responsibilities included writing scripts in PowerShell to perform batch operations on groups of users, usually based on a spreadsheet sent from HR; monitoring the credit card PIN pads in all the stores across the province; and keeping up to date with current security threats, vulnerabilities, and exploits, and proposing necessary updates and changes to company systems to avoid these issues. This program lasted until the end of 2014.

4

I did not work for the Winter 2015 semester, but got hired by the company that my group worked with for the Computer Projects Practicum 2 course, Assembly Co. Originally, I was just hired for a summer position to continue work on the project, but they kept me on part time during the Fall 2015 semester, and that turned into a position that lasted over 2 years, until August 2017. During my time at this company, I worked on several mobile apps for both iOS and Android, numerous websites, and a couple web servers. The most notable project was a cross-platform mobile application for iOS and Android that was created using the Ionic framework, which allows for writing an app with web technologies that builds to both iOS and Android (and Windows 10 phones, if desired). This project also included working on the server that the app connected to. Other notable projects included 2 native iOS apps, written in Swift; a native Android app, written in Java; and a couple websites, written in PHP.

In August 2017, the company announced they were closing the development department. After that announcement, I decided to double down on my courses to get all the classes fnished by the end of 2017. Right now, the only work I am doing is a single freelance web development project.

2 Project Description GamePad is a social networking platform targeted at gamers. It aims to do for gamers what Goodreads did for readers, or what IMDB did for movie enthusiasts. Users will be able to interact with other gamers in multiple ways, including messages, comments, posts, and sharing. They will also be able to search for and host public or private events for a specifc game, allowing a way for gamers that don’t have a lot of friends to play online with to connect with the community.

GamePad will contain a central database of thousands of games and information about each game. Many game tracking sites require users to manually enter game titles and consoles, but having a central database will make it easier for gamers to connect, ensuring that no issues arise around 2 people writing the name of a game slightly diferent, or other such issues that come with not having a central catalog.

For the purposes of this project, GamePad is a native mobile application for Android. After the end of the project term, if the app is successful, I will be looking into adding an iOS app and/or a web app; however, I chose to stick with 1 platform for the project practicum so that I could focus more on adding depth and complexity before the end of the 2-year limit. After studying the usage habits of users of other social network platforms, such as Facebook, I have determined that mobile is the most important platform, so I am focusing on that frst (Protalinski, 2016). The reason I have chosen Android over iOS is simply that I am an Android user, and so are most of my friends. Additionally, though, my studies at BCIT were focused on Android development, making it the platform I have specialized in.

5

3 Problem Statement and Background One of the nice things about this project is that I am part of my target niche. This gives me something that I have never had when working on a large project before, a direct connection between the developer(s) and the type of person that would use the app. To sum it up, my primary target niche is people who like seeing stats about their gaming collections and comparing them with their friends and/or the community, as well as people that just have too many games and want a central place to fnd them all. Having too many games to track may seem ridiculous, but by being a subscriber to both Xbox Live Gold and PlayStation Plus, I am currently receiving 10 free games a month from their respective Games with Gold and Instant Games Collection services; additionally, Humble Bundle ofers regular bundles of games that usually average less than $1 per game.

When I frst came up with the project idea, all I wanted was a simple application that can track a user’s games library, including what platform they own it on, whether or not they have beaten it, how many hours they have played, and more. At the time, I was doing this exact type of tracking, but just using an Excel spreadsheet.

In 2014, I created a simple proof of concept by creating a small desktop application using Java in my free time. The application just presented a full screen table that basically looked like a spreadsheet, but then added some basic advantages, such as easy sorting and fltering, better performance, easy adding, deleting, and editing of games, and the ability to generate basic graphs of some stats from your games collection. An example graph would be a simple pie graph showing how many games you have beat, how many you are working on, and how many you haven’t even started.

I have been using this desktop application ever since and it does everything it was intended to. I have over 900 games in the library and it tracks them all perfectly and never has performance issues; however, after using it for 3 years, I’m starting to see room for growth. For starters, I fnd myself wanting access to it from my phone, which is currently impossible. I also wanted my data in the cloud, which I am doing now by placing the save fle in my Dropbox.

As I looked around at specialized websites that allow users to track information, such as achievements or time played, I started to realize the niche was bigger than I had anticipated. HowLongToBeat, a website that lets users record how long it took them to beat a game, has a “New in the Last 48 Hours” section on their site, and it stated that users added 3000 new completed games and 270 new users signed up in the last 48 hours on November 7, 2017. These numbers made me see that, while a very small percentage of gamers are interested in this type of service, gaming is such a huge mainstream culture that this small percentage is still a large number of people.

So I started looking into other things that I wanted in an online gaming service, stretching far beyond the original spreadsheet replacement. As a gamer of many platforms, one of the most common issues I have is comparing games with a friend and being unable to see my entire collection. For example, I can compare trophies with my friend on the PlayStation 4, I see the games I play on PS4 next to the ones he plays and we can compare progress. As I’m scrolling down the list, I come across Borderlands 2. According to the PS4, he has 35% of the trophies and I have never played. The issue here, is that I have 85%, but of the achievements on the PC.

6

Looking at this issue, I decided that the problem expanded beyond seeing your own games all in one place, but also seeing everybody else’s games all in one place. I took a look at the frst-party online systems—Xbox Live, PlayStation Plus, and Steam —and decided they ofered most of what I wanted, but just were restricted to their respective consoles. So I started designing an online platform that would take all the functionality from these services and ofer it in a platform agnostic manner.

Soon, I started looking in to how I could expand the social features. As an active Reddit user and gamer, I started seeing more and more posts like “Does anybody want to play some Nex Machina on the PS4?” This seemed like the perfect opportunity to expand the range of my niche to include people that don’t have a lot of real life friends to play games with. Before long, I had refned my target niche and iterated on my idea enough times that I came up with something I felt would not only satisfy everything I wanted from this type of gaming platform, but also be useful for a fairly large audience online.

4 Complexity Social networks are obviously very complex services. If it succeeds, it becomes a performance nightmare that needs to scale to handle large numbers of active users at any given moment. If it fails, it still had to be designed and developed with a complex network of relationships between users, games, consoles, messages, posts, comments, and more. Every active user brings a large amount of data with them. Data in social networks isn’t generally deleted, I can still go back and view posts I made on Facebook 8 years ago. Imagine the kind of data an active user foods Facebook’s databases with over 8 years.

While a social network’s features are complex enough, I want to draw special attention to the messaging feature. Managing games, libraries, friends, comments, and other social features is a major database and API design challenge, but messaging is a completely diferent type of challenge. This will be the part of the app that requires a real-time connection between the client and the server. Messaging can’t wait for the user to open the app and press refresh, it needs to send and receive messages on its own. This is a type of system that I have worked close to, but not something I have ever done myself.

In addition to the complexity of the data structure, this app will involve 3 separate code bases that need to interact with each other, 1 Kotlin project for the Android app, 1 Go project for the RESTful API that connects the server to the app, and another Go project for importing data from 3 rd party services. Handling 3 projects is complex on its own, and to add to that, I have no experience with either of these languages. This is intentional to force me to learn new languages that can be helpful for me in my career. I am confdent that learning these languages will not be enough of an issue to impair my progress on getting the project complete properly. Learning new technologies and languages is part of being a programmer, especially in the web and mobile application development realm, and it is something that I would not be wise to shy away from.

Regular deployment will be another form of complexity in this project. As a developer, I have a few years of experience developing projects for both server and client side; however, deploying these projects into a production environment has not generally been my responsibility. Even if the code is stable, deploying a server that is suitable for production is not an easy task, especially when it comes time to update that server. I need to ensure that I take the actions required to keep my server as reliable as possible so that my test users have an enjoyable experience. I will also need to perform recovery actions, such as making regular backups of the database.

A fnal major form of complexity is populating the games database. I have stated that GamePad will have a centralized library of thousands of games for users to choose from. Obviously, I will not be populating this database 1 game at a time by myself.

7

The Internet Games Database (IGDB) API will be assisting me in this issue, but it is still a complex problem to solve. I have some experience with this kind of API crawling in the past, and it can be complicated trying to fnd a way to scrape data from the API without exceeding request limits. The easiest solution would be to just write a script that hits the IGDB API every night to get all their games and save them in my database, but that would almost guaranteed get me blocked by a DDoS protection at IGDB, and would lead to lots of redundant requests. Trying to fgure out a suitable way to scrape the IGDB API will be harder than it sounds.

5 Scope and Depth There are several ways that this project could get out of hand for the project practicum. For one, this project is being limited to a native Android app. For the purposes of this practicum, at least, I will not be doing an iOS app, a website, a Windows app, an OS X app, a Linux app, or a Windows Phone app.

The functionality that will exist in the app will be limited to that which is described in the “Development Schedule and Milestones” section. Any features that come up that aren’t described in this section will be omitted. As an exception, if a feature is discovered during development that is considered necessary it may be included, but currently documented features of the same development time must be removed. The scope cannot aford to grow.

The scope will also be limited in which device versions will be supported. The oldest Android version supported will be Lollipop (5.0). As of February 5, targeting this version makes my app compatible with 82.3% of all Android devices currently active (Tim, 2018). Since GamePad isn’t expected to go live any time soon, that number will only increase between now and then. Adding compatibility with anything older than Android 5.0 is out of scope for this project.

Finally, the scope will be limited in 3 rd party services that are supported. A major feature of this app is that users can import their libraries from the services they play games on; unfortunately, several of these services, including Xbox Live and PlayStation Network don’t provide any way to publicly access a user’s list of games. Getting the data required is still possible —I know this because I know a few sites that manage to do it—however, I have researched potential ways these services are doing this and have not been able to fnd anything. I will be looking into getting this solved after the practicum, but this is likely going to involve countless hours of grinding away at time-consuming solutions that may or may not work; therefore, these services are out of scope for the project practicum. Services that are currently listed to be included are Steam, Blizzard (Battle.net), and League of Legends.

8

5.1 Requirements 1. The Library section must meet the following loading times. This means the frst page of games being presented to the

user.

a) If the games have already been loaded from the server, the library should open in less than 2 seconds.

b) If the games need to be fetched from the server, the library should open in less than 5 seconds.

2. The messaging server must be able to handle 1000 messages per second.

3. Database backups must be automatically performed once an hour.

4. The server code must be active 99% of the time that server itself is. Server reliability will be the responsibility of the cloud service used.

5. All page transitions must be completed in less than 0.5 seconds. This will often mean transitioning to a loading screen briefy, but that is better than doing nothing.

6. All server endpoints involving private user data must not be accessible by other users.

7. The app and server must be able to handle users with libraries of up to 100 000 games.

6 Test Plan For this application I will need extensive automated test coverage. With a 1 man development team, I do not have multiple internal eyes on the project to catch bugs before they get deployed to the users. This means that the automated test suite is pretty much the only way to catch the bugs before they reach the users.

For this project I will have multiple types of tests. The frst type is unit tests. These tests are designed to be super quick. They test each component of the code in isolation, so they will not catch bugs that only occur when the whole program runs as a unit, but they are fast enough to run every time I commit the code. These tests won’t cover all the potential bugs, but they will allow me to have tests running constantly.

The next type of unit tests is integration tests. These tests run the application as a whole. For the server side, these tests will hit the same endpoints that the client application does and validate the responses received. On the application, these tests will actually launch the app in a test environment and go through a scripted screen fow. Unlike the unit tests, integration tests do not focus on each function in isolation, but will catch issues with the components not interacting with each other properly. The problem with integration tests is that they are really slow. They require connections to real databases and actually starting the entire application. For this reason, integration tests cannot feasibly be run every commit, or you would lose too much time while waiting for tests. Instead, I will be connecting CircleCI for continuous testing connected to my GitHub account.

9

The fnal test suite I will be including is for performance testing. These tests will only be for the server side, though. Performance tests send hundreds to thousands of requests to the server in a very small amount of time and ensure the server continues to behave as expected. As with integration tests, these tests are extremely slow to run and not suitable for running each commit. These tests will also be added to the continuous testing.

7 Methodology As I mentioned in the introduction, I am an avid gamer myself. As part of this, I have several gamer friends, both in real life and online. I plan to try and use these friends as test subjects for my application. By essentially rolling out a private alpha during the development, I can use real people to help fnd bugs that my automated tests don’t catch and suggest new features and design improvements that could make the app more useful.

In order to include real life testers frequently into the workfow, I will be using my own modifed hybrid of Agile and DevOps. This will ensure that issues are detected as soon as possible so that I fail early, rather than fail later when it’s hard to fx. Since I am the only developer working on this project, I will be omitting many of the principles of both Agile and DevOps, but I plan to extract parts of those methodologies that I can employ alone.

10

I will be running automated unit tests on my own machine every time I make a commit, but I also want other forms of automated testing that take longer to execute, such as integration tests. For these tests, I will try the free tier of CircleCI and connect that to my GitHub repository so that I can have continuous testing. CircleCI will run all my tests every time I push new code to GitHub, making sure I don’t merge any branches that don’t pass the tests.

While I will be doing continuous testing, I will not be doing continuous delivery. Releasing new versions of the app nightly or weekly is overkill with only 1 developer. A single day or even week could result in absolutely nothing to deliver. Instead, I will be taking an Agile approach to releases. I will divide my work into small sprints and then release a new working version of the product after each sprint. While not delivering on a continuous basis, this will still ensure I get software into the hands of users for testing as soon as there is something new to use.

7.1 Tools and Technologies For this project I will be creating a mobile application for Android, including a RESTful web server to provide Internet services for the app. For the client app, I will be using Android Studio. I would like to use the Ultimate version of IntelliJ IDEA, which is the IDE that Android Studio is a fork of, but IntelliJ IDEA is a bit behind on its support for Kotlin for Android.

Kotlin is a fairly new programming language created by Jetbrains, the developer of IntelliJ IDEA, which I will be developing the app in. Google announced ofcial support for Kotlin as an Android development language during Google I/O 2017, back in May of this year (Miller, 2017). It is the second ofcial language for Android development, joining Java, which has been the lone ofcial language since Android’s inception. The Kotlin support just fnally left beta in October, with the release of Android Studio 3.0 (Eason, 2017). Kotlin was designed as a wrapper over Java; it uses the same basic constructs and still runs on the Java Virtual Machine (JVM), but it provides several syntactic diferences that make it easier to read and work with. This will help me avoid bugs and speed up development, as well as allow me to work with a new language.

For the server, I will be using Google’s Go programming language. I will also be using IntelliJ IDEA as the IDE for this. Go has been around for almost 10 years now and is optimized for concurrency, which makes it ideal for server programming. Being a modern programming language, it has many of the quality of life features that you would fnd in other web server languages, such as JavaScript, Python, or Ruby; additionally, it is a compiled language, whereas the languages just mentioned are interpreted. This means it has a major performance boost over these languages, and also can make development easier because several errors are caught at compile time that would not be caught until runtime in interpreted languages.

On the server, I also have a small program that needs to run once per day to import data from the IGDB API. This is a completely separate program from the rest of the server; however, I will still be writing this program in Go. There is no requirement for this, since it isn’t tied to the rest of the server, but adding even more languages would be unnecessary.

The database that will be sharing the data for both server side programs will be an SQL database. A library will be used in the Go code that allows me to swap the database management system (DBMS) without needing changes to the code, other than a confguration fle. The database being used on production will either be MySQL or Postgres.

11

The real time communication component of the app will need to be a separate process from the rest of the web server. This process will need to communicate with the web server, but will need to act as a standalone process, on a diferent port, that is capable of pushing data to the users’ devices. Ideally, this will be written from scratch by me using the Socket.IO framework, which has a library available for Go. This framework will allow me to create a socket server that establishes a persistent connection between the server and the clients. This persistent connection allows the server to communicate to clients without needing to wait for them to initiate a request. If an issue arises with this solution, a backup plan will be to implement this connection using Firebase. Setting up and implementing Firebase is still a complex task in itself, but Google has taken care of the most complex parts for me if I go with this solution, which makes it a good safety net. Firebase also plays really well with Android, and Go.

In addition to the development, I need to design the screens before I can created them. I will be using Sketch for this. Sketch was created specifcally for designing user interfaces for websites and mobile applications. Because of this niche target, it is cheaper, easier to use, and sometimes even more powerful than Adobe Illustrator or Photoshop.

Finally, I will be using Git for my version control system, with private repositories for each project hosted on GitHub. The application will be deployed to the Google Play Store and Apple’s App Store. Likely, the Android app will be the only one being published to users for a large chunk of development. This is because the cost of putting apps on the App Store is much greater than that of the Play Store. The server will likely be hosted using a free instance on Heroku during development. When the app goes live and has real production users, this will be moved to Amazon Web Services (AWS).

12

8 System/Software Architecture Diagram

13

14

15

16

17

18

19

9 Innovation Much of the innovation for this project comes from centralizing an existing community. Pretty much everything that GamePad will be able to do can be done elsewhere; however, there is currently no central place dedicated for gamers to do all of these things. Want to fnd some new friends to play a game with? Put a post on that game’s subreddit. Want to see how your unlocked achievements compare with community averages? Sign up for TrueAchievements. Want to set up a gaming event? Create an event on Facebook. Want to see ratings for a game? Go to Metacritic. Want to compare all your achievements with a friend across all platforms? Well, you better be ready to have several browser windows open at once and start jumping back and forth.

Another way that GamePad innovates is in the delivery. Every service I mentioned above, with the exception of Reddit and Facebook, have terrible support for smartphones. Most of these gaming sites have existed since before the release of the frst iPhone and, therefore, before smartphones became mainstream. These services do not ofer mobile apps and their websites are not responsive. This is part of why I am focusing on the mobile app before the website. I feel that the best way for GamePad to establish a core audience is to try and attract the attention of those people who primarily, or exclusively, use these services from their smartphones.

This entire project idea spawned from a desire to track a large library of games and see data about each one, including being able to see a dashboard of statistics about your collection. While the project idea expanded vastly from there, this is still the core feature. There are a couple sites that ofer something similar to this already. From what I have seen, the most popular of these is Backloggery, which lets users add as many games as they want and fll out information about each one. The issue with Backloggery is that it looks like it was created 20 years ago and everything is manual. You are presented with a wall of text felds and you enter everything yourself. There is no searching for games and no way to import collections. The library feature of GamePad aims to innovate on what Backloggery has done by providing a central database of games and allowing for some basic importing of games from services like Steam.

9.1 Technological Innovation On the technology front, this project is using 2 diferent programming languages, both of which are relatively new and cutting edge. Go version 1.0 released back in March of 2012 (Gerrand, 2012), and Kotlin 1.0 just came out last year (Breslav, 2016). These are all very new considering that most of the popular programming languages of today originated in the 90s, including Java, PHP, Python, and JavaScript. These languages will help me learn several modern approaches and concepts in programming, as well as allow me to learn languages that have started to see widespread adoption already and will likely be very useful to know in the coming years.

I will also be using several modern libraries and frameworks in this project. Since Kotlin is built on the JVM, it has support for pretty much any Java library that already exists for Android, but new libraries are coming out that are optimized for Kotlin and take advantage of its modern features in a more streamlined way. Modern libraries that I will be using include RxKotlin, Koin, and more. These libraries have come out in the last couple years or less and will be completely new to me, along with Kotlin itself.

20

Another form of technological innovation is the use of modern DevOps practices, including the use of CircleCI for continuous integration. I had 1 course on DevOps recently, but it is a concept that is still pretty new to me—and to the programming world in general—and CircleCI is a platform that I have never used before.

10 Technical Challenges One of the biggest technical challenges for me on this project is going to be adding the ability for real time communication. While I have experiencing building web servers for large projects, I have never implemented a real time connection before. This connection will be needed to push messages and other notifcations to the users’ devices. This will not only occur while the app is open, but also while it’s closed, in the form of push notifcations.

Another challenge is going to be creating a database and server model that is organized well enough to handle the complex network of data that will be involved in this project. If this is not planned for from the beginning and executed well enough, maintaining the project in the later stages is going to be a nightmare. It will also mean scaling the application for larger amounts of users will become a major issue. Since I am taking an Agile approach to this project and do not have a perfect image of every feature I want the app to have right now, I cannot simply plan for the entire database right up front. This means, to circumvent this challenge, I am going to need to design the server in a way that allows for easy additions to the data model.

Finally, creating a front end application that is this large and feels silky smooth to the user will be a major challenge. One of the issues I have experienced in the past with mobile development is issues with performance, especially in applications that rely heavily on Internet requests. I will not tolerate a slow app for this project, which means I need to be smoother with my transitions and smarter about my caching, advanced loading, and delegation of asynchronous operations. I also need to design the app in a way that allows it to retain as much functionality as possible when going ofine.

11 Development Schedule and Milestones For this project, I am breaking the work up into phases. Each phase does not necessarily correspond to a release, however. In each phase, there are a few smaller components that can be delivered to the test users. Rather, each phase corresponds to a single complete feature set. These are my milestones and each one is a substantial amount of work.

Since I am using 2 programming languages that I am unfamiliar with, I will have to begin this project with an exploration component. Before I can get any meaningful work, I will have some extra time set aside to ensure I fully understand these languages. By allotting this time, I ensure that I don’t run into any major issues later in development caused by bugs that could have been avoided if I understood the languages better.

21

In most of the phases, I have included extra padding time at the end to allow for testing and unknown issues. As I have done software development professionally in the last few years, I have learned a couple things about estimates. First, programmers always tend to be optimistic about their estimates and fail to properly allow time for things like testing; second, something unexpected always happens and extends the development time. These padding blocks at the end of each phase are essential in making sure I can fnish the work I have planned.

My total estimate is 939 hours to complete this project. For this reason, I am submitting this proposal for the 18 credit version of the practicum. This means that I have 2 years to complete this project. My milestone deadlines are based on fnishing 1 month before this 2 year deadline, which would have me fnishing the project on January 31, 2020. This will give me 702 days to fnish the project, with 1 month of padding to handle any unforeseen issues.

22

Phase Estimated Time (hours) Deadline*

Learning 25 March 19, 2018

Phase 1: Library Tracking 187 August 6, 2018

Phase 2: Central Database Population 40 September 5, 2018

Phase 3: Deployment 25 September 24, 2018

Phase 4: Data Importing 132 December 31, 2018

Phase 5: Dashboard 45 February 3, 2019

Phase 6: Other User View 60 March 20, 2019

Phase 7: User Messaging 124 June 20, 2019

Phase 8: Library Comparing 50 July 28, 2019

Phase 9: Extended User Profle 66 September 15, 2019

Phase 10: Advanced Stats Tracking 70 November 7, 2019

Phase 11: Parties and Events 115 January 31, 2020

Padding Time February 28, 2020

Total 939 * Deadlines are all based on an estimated start date of March 1, 2018

23

11.1 Phase 1: Library Tracking To start the development process, I will be creating the feature that was the core behind the entire project idea, the ability to track all your games, including statistics for each. Potential statistics include hours played, percentage complete, rating, and more. This phase will include creating designs for the diferent screens required, as well as scafolding a server, database, and mobile apps for both platforms. Once the applications are set up, I can add the functionality for the designed screens.

For the purposes of this frst phase, the games in the database will be manually entered. This means the app will not be ready to go public to anybody after this phase, but there will be a fully working product that I can use and test. By creating the fow with manual data entry at the beginning, it will allow me to refne the structure of the database before I create an automated workfow for populating the database.

As part of this phase, I will also have to implement authentication and authorization so that users can log in and can have their private data hidden from other users. The authentication will be done by connecting to 3 rd party OAuth providers. This form of authentication is commonly seen in modern apps in the form of a “Login with Facebook” or similar button.

Item Estimated Time (hours)

Designs for the required screens 17

App scafolding 10

Creating static versions of the screens on the client 32

Server scafolding 30

Database design fnalization, creation, and population 13

Creating server and connecting to client 50

OAuth fow setup 15

Padding for testing and unknown issues 20

Total 187

24

11.2 Phase 2: Central Database Population Once the core functionality is in place, it will be time to write a program to automate the process of populating the database. To perform this task, I will be pulling data from the IGDB API, which allows access to over 70 000 unique games. This is a much larger collection than competing APIs, GiantBomb and thegamesdb. More importantly, however, IGDB permits commercial use, and is even okay with you building a product that directly competes with them. This means IGDB is the only service that guarantees I won’t run into legal issues at any point. As the icing on the cake, the API is even free until you go over the free usage quota, which won’t be an issue for this program.

The program in charge of importing data from IGDB needs to do so with as few requests as possible, to ensure I don’t hit the quota, but also to reduce CPU usage and bandwidth on the GamePad server. Every game in the IGDB API has a “created at” and “updated at” feld that can be fltered by. Once per night, my program will hit the IGDB API to get all games that have been added or updated since the previous night. All the data received will then be dumped into the GamePad database, so that all requests can be served directly from the server, rather than having to hit the IGDB API every request.

Once this phase is complete, the app will have everything it needs to go live to a private set of test users. Phase 1 had delivered a fully working product with a valuable feature, but was just waiting on a populated database to be ready for real users. This means that setting up and deploying a server, and submitting the apps to their respective stores as private beta versions are included as part of this phase. Part of this deployment step though will involve creating a script so that the deployment is automated for future phases.

Item Estimated Time (hours)

Learning all the features of the IGDB API 5

Create script that requests data from IGDB on a regular basis 25

Padding for testing and unknown issues 10

Total 40

11.3 Phase 3: Deployment Once a usable app has been created, it will be time to get it in the hands of some users. At this point, the app will not be very useful for the users, so it will only be going out to a small number of people I have personal connections with. Fortunately, this time lost to deployment will only need to happen once. This is time that is required to set up the server the frst time and get it ready for production. Once this has been set up properly, deploying updates to the server will be a trivial task.

Item Estimated Time (hours)

Find and launch a test server 10

Deploy the frst version of the code to the server 10

Deploy the client app to the Google Play Store 5

Total 25

25

11.4 Phase 4: Data Importing Importing games from 3rd party services is going to be where the server starts getting real complex. Importing data from the services is a simple task by itself; however, connecting it with the data already in the database is the opposite. To explain the reason for the complexity, I will use Steam as an example.

All of the games in the GamePad database will have been imported from IGDB, and will contain their unique ID. When I regularly update the database with new games, it will be easy to determine what games already exist in my database because I can check if their ID exists in my system. When I am importing data from Steam, however, the ID of each game will be diferent from Steam than they were from IGDB. For most games, this problem will be trivial, because I can just compare titles; if a game is called Move or Die on IGDB, then it will be called Move or Die on Steam. There are 2 issues with this solution, however:

1. Depending on the platform, some game titles have minor variations. For example, one platform may include a trademark symbol and the other platform doesn’t. One platform may use diferent casing, or exclude a semicolon. These variances will be small and easily detected by a human, but the program needs to be designed in advance to handle these possibilities. This issue by itself is not too bad, but is still an issue.

2. The bigger issue is the fact that game titles are not exclusive. For example, Tomb Raider released in 1996 and became a major series. In the 2000’s, however, they took a break from the series. In 2013, they released the reboot, titled Tomb Raider. These 2 games have no more in common than any 2 other games in the series, but neither of them have a subtitle or a number. Sites like Wikipedia handle this by having one page called “Tomb Raider (1996 video game)” and one page called “Tomb Raider (2013 video game).” The data coming from Steam and IGDB, however, will not be titled so nicely for me. The games I receive from these APIs will have the exact same titles as their boxes, and I will be forced to create an algorithm that can identify 2 games as being the same, while avoiding similarly-titled games. To do this, I will have to use any other information about the game that I have access to, such as release date, available platforms, review scores, etc. Writing an algorithm that can identify correctly for 1 specifc targeted title, such as Tomb Raider, will not be overly challenging. The challenge will be making a generic algorithm that can do this for titles I have never heard of or that have not released yet.

My solution for this will be to add another script, similar to the one that is accessing the IGDB API, that is responsible for looking at all the games in the other 3 rd party services and mapping their IDs to the ones in my database. This is not something I want to be doing every time a user’s games are imported; this should be done ahead of time.

26

Item Estimated Time (hours)

Designs for the required screens 6

Creating static versions of the screens on the client 16

Create script on server and connect to app 75

Add support for users to log in to the 3 rd party services and authorize import 10

Padding for testing and unknown issues 25

Total 132

11.5 Phase 5: Dashboard By this phase, the user libraries will be completed and the test users will hopefully be enjoying it. Once the library is completed, the next step is to add a dashboard section to the app. This section is where users can see high-level statistics about their library. It is great for a user to be able to see all of their games, along with stats for each one, but that still won’t be overly useful, aside from helping users track all their games. The real appeal of the library is the ability to see aggregated data about the entire library. This will include things like “average price paid per game” and “total hours played.”

Some of this data will be most useful just presented as a single number to the user, but a lot of it will be best presented in the form of a graph/chart. Generating and displaying these charts will be the hard part of this phase. I have never worked with any chart libraries on Android, but I know from my experience with them on websites that they can be a challenge. Just displaying basic charts will not be enough, either. The charts need to be styled so that they ft nicely with the rest of the app and are appealing to the user. At this point, the calculating of these statistics will just be done on the client side, since the client has access to all the data it needs.

Item Estimated Time (hours)

Designing the dashboard 10

Creating dashboard on the client 30

Padding for testing and unknown issues 5

Total 45

27

11.6 Phase 6: Other User View Once users can see all the information they need about their own library, they should be able to see the same information for their friends’ libraries. This will include browsing through other users’ games, as well as looking at their stats on their dashboard. To do this, I will frst need to implement the ability to add friends. Once users can add friends, they will be able to use their Friends screen to get to their friends’ libraries. The library for a friend will look almost identical to the library for yourself, with the exception of being able to access editing features.

The hardest part of this phase will be generating the aggregated data for other users. Last phase, I was able to generate data for the dashboard on the client side because all of the user’s games are going to be synced to their device. When looking at another user’s dashboard, however, the client shouldn’t have to request every game the user owns at once and then calculate the statistics. To solve this, the server is going to have to calculate these stats ahead of time and cache them.

Every time a user updates their library, it will start a background task on the server to update their dashboard stats. These stats will be cached in a table in the database that will be called whenever any user views the dashboard. When viewing a user’s own dashboard, though, the stats will still be calculated on the client side. The reasons for this are that it will save a small amount of the user’s data, reduce the load on the server, and allow a user to view their stats without being connected to the Internet.

Item Estimated Time (hours)

Designing the Friends screens 8

Creating static versions of the screens on the client 12

Add server features and connect to the client 30

Padding for testing and unknown issues 10

Total 60

28

11.7 Phase 7: User Messaging Adding messaging to the app will be a major task. Not only will this involve a few new screens that are hard to create on the client, but it will also include the addition of a socket server and client to establish a real-time connection between the two. I intend to do all the messaging features from scratch and host the messages on my own server, which will be a large chunk of complex work. The beneft of this work though will be a lot of saved money in the long run versus using an external service like Firebase. It also means that the messaging system will be completely controlled by me, meaning that I do not have to worry about issues with the external service, such as the service being shut down or changed.

While a staple of social platforms, this is going to be a challenge for me. I have never implemented a real time server connection before, and I have never done a messaging system, either. There are several questions that go into the execution of this type of system. How do I establish the connection? How do I archive older messages as the database of messages becomes huge? How do I ensure that messages sent really close to each other arrive in the same order that they were sent? This last question is a problem that has always plagued SMS, but Internet messaging has the technology to avoid that issue.

Item Estimated Time (hours)

Designing the required screens 9

Creating static versions of the screens on the client 20

Add server endpoints for sending and retrieving messages 25

Add a socket server and client for receiving new messages over a live connection 40

Padding for testing and unknown issues 30

Total 124

29

11.8 Phase 8: Library Comparing The next phase is fortunately relatively simple compared to the complex work before it. At this point, users are able to populate their libraries with all their games, see stats about their games, and see all the same data for their friends. This library functionality is nice, but a major feature it is still missing is the ability to directly compare with friends.

This phase adds the ability to view a friend’s library side-by-side with your own. This means users will be able to see information like “my friend has played 120 hours of Borderlands 2 and I have played 237” at a simple glance. By the end of the phase, this is where I expect to fnally have a version of the app that users will receive a large amount of beneft from using. After this phase, I will likely be considering a public launch, as opposed to the private beta I will have until this release.

Item Estimated Time (hours)

Designing the comparison screens 5

Creating static versions of the comparison screens on the client 15

Add server functionality to get data optimized for comparison and connect to client 20

Padding for testing and unknown issues 10

Total 50

30

11.9 Phase 9: Extended User Profle Now that users can compare libraries. Phase 5 dives into extending the amount of social features. Right now, the only social features included in the app are the ability to send messages and view friends’ libraries. This phase will add several enhancements to the dashboard section to make it more like a complete User Profle. This will include adding a “wall” to every profle. The wall is a concept that Facebook launched with back in 2004 (Bonnington, 2014), which allowed users to post to each other’s profles. The real innovation, though, was when they added the news feed in 2006. This is a central location, still present on Facebook today, where users can see a central feed of all the activity going on throughout their network of friends. Facebook is very general purpose and, therefore, allows users to share pretty much anything, including text, links, pictures, video, location, and mood. Since GamePad is specialized towards games, it does not need such a wide variety of options. Design decisions will be made at this point to determine if there is a way to make it easier for users to post what they want by tailoring the interface towards game-related posts. One such idea could be a version of hashtags where users can tag games from the database in their posts. Part of the wall will also include the ability to try and organize game sessions with other players. Users will be able to posts requests to play on their own wall or the walls of other users.

Other smaller features will be added to the profle, such as user avatars, information they wish to share public, and more. This will include some basic social information, such as country of residence, birthday, and real name; however, it will also include lots of information targeted specifcally for gamers, including favourite game, favourite genre, favourite console, and usernames for diferent gaming services, such as Xbox Live, PlayStation Network, Steam, uPlay, and Origin.

Item Estimated Time (hours)

Design the profle screens 8

Create static versions of the screens on the client 18

Add server support and connect to the client 30

Padding for testing and unknown issues 10

Total 66

31

11.10 Phase 10: Advanced Stats Tracking The next feature I want to implement for this project brings me back to the core feature, the library. In previous phases, I will have created a dashboard and transitioned it into a full profle. This screen, however, just has some high level statistics. This means graphs that are more complex than the existing basic graphs. For this phase, the advanced stats tracking feature will become the new Dashboard, since the old Dashboard became the User Profle last phase.

In this new Dashbord, there will be some standard graphs, but a big feature of this will be customization. I want users to be able to apply custom flters to each graph type. For example, a standard graph might be “Games Owned by Genre” or “Hours Played by Genre”; alternatively, a customized graph might be “Games Owned on PS4 or Xbox One by Genre” or “Hours Played by Genre for Games Released This Year.” These custom graphs will also require some extensive design work beforehand. This is a complex feature and, therefore, will require a complex interface. I need to try and make this interface as simple and intuitive as possible so that users can actually take advantage of the feature without just getting confused.

Item Estimated Time (hours)

Design required screens 20

Create screens on the client side 50

Total 70

11.11 Phase 11: Parties and Events The fnal feature is another social feature, and the one I think will help bring in a diverse audience. So far, the entire app has been built around the use case of tracking games and comparing them with your friends; however, there is another use case I want to tackle because I see it come up on Reddit all the time. The “Parties and Events” section of the app will target gamers that are interested in fnding other gamers online to play with.

In games like Call of Duty, when you want to play online, you simply press “Find Match” and go; however, that isn’t always the best experience. The people that join your team can be both insanely obnoxious, as well as just downright awful at the game. For this reason, it is usually preferred to join a game with friends; however, not everybody has the option of joining a game with a bunch of friends, especially not at all times. For this problem, I see posts on Reddit with titles like “Anybody want to play Battleborn on the Xbox One” or “Can somebody help me with an achievement in Borderlands: The Pre-Sequel.”

Small services have been created in the past targeted at providing a place for these gamers to help fnd people to play with. The problem with these services is that they are specifcally targeted at this use case, so most people don’t know about them and those that do usually only check the service if they actively want a group. By adding this functionality to a more general app, it can target a larger amount of users. With a feature that is completely based on fnding other users, the number of users is pretty important; otherwise, it would be like a dating site with no matches.

A big part of this feature will be the ability to subscribe to notifcations. If you particularly like a certain game, you will be able to enable notifcations on your phone like “let me know when somebody wants to play Overwatch on PC.”

32

The fnal feature is Events. This feature is for a similar demographic, but serves a diferent purpose. This is another feature that’s borrowed from other social networks, like Facebook, but will be tailored for gamers. Users will be able to create events and make them public or private; they will also be able to tie specifc games, platforms, and user counts to these events. An example event could be “Super Smash Bros. Melee with 24 people on April 29.”

12 Deliverables 12.1 Source Code The frst deliverable will be the source code for 4 separate repositories:

1. Android app

2. RESTful server

3. Scheduled program that populates the database

This code will be made available in a manner preferable to the recipients. I can provide all the source code together as a single zip archive, which can then be delivered via Google Drive or a USB drive. Alternatively, I can provide access to the private GitHub repositories that I will be using to host the source code.

12.2 Running Applications In addition to source fles, I will also have live instances of the programs that the source code compiles to. A Linux server will be online and running both the RESTful server and the database population program, both of which will be compiled executable binary fles from the Go code.

There will also be an APK fle live on the Google Play Store. This application will hopefully be available for download to anybody at this point. If not, I can grant access to the private beta.

12.3 Designs and Wireframes Throughout the development of this application, I am going to be creating several wireframes and high fdelity designs. These designs will all be in propriety formats of the Sketch application; however, they are all exportable as PNG images. The exported PNG images will all be submitted as one of the deliverables.

33

12.4 API Documentation I will be using APIDoc as a service to automatically generate documentation. This documentation will be used exclusively by me to make it easier to remember what the server supports when I am working on the client side. This will prevent me from having to look through server source code every time I am building client features. Because of this, the documentation won’t be pretty and will probably just be point form, but it will be complete documentation that will be a suitable deliverable.

12.5 Project Report As per the criteria of the project practicum, I will also be submitting the fnal report for the course.

13 Conclusion and Expertise Development This project is a large platform that utilizes several skills that are required in my line of work. Although I already have a few years of professional experience developing websites and mobile apps, I have never used Kotlin or Go. These are both languages that I will likely use in future jobs. Swift has already received widespread adoption for the development of iOS apps and Kotlin will likely not be far behind, now that it is an ofcial development language of Android. Of the 2 languages I am using, Go is the language that I am least likely to make use of in a professional environment.

Even if I never use either of these languages, there are benefts to learning new programming languages. When you focus on just a small set of programming languages, you tend to restrict your thought process and style of problem solving to things that are easy to do with the features of those languages. Learning a diverse set of languages, though, changes the way you approach problems.

In addition to new languages, I will also be learning how to solve several technical problems during this project. These problems include making a messaging system, creating a large database structure that can scale easily, developing algorithms optimized for performance, and more. The skills I will take away from this project will help me to become a better developer in the future.

13.1 Project Future I do not intend for this project practicum to be the end of development for GamePad. After this project is complete, the app should be ready to deploy to the public. Ideally, I will actually leave the private beta and do a public release during the project practicum. After I have fnished the course, I will move on to creating iOS and web applications that support all the same features as the Android app. This will allow iOS and desktop users to access the app, and also allow mobile users to use it without needing to install a native app.

34

The short term plan for GamePad going forward will be to monetize it using simple unobtrusive ads. Ads, however, ofer a very small income and that would not be sustainable for the hosting costs of a service this complex. The easy solution would be to ofer a freemium model, in which users could gain access to an extended feature set by paying a subscription fee, but that would be detrimental to the user experience. Instead, the goal of GamePad is simply to accumulate as many daily active users as possible. Once the platform has accumulated a large user base, it will then be used as a means of advertising my own games to the users. These games will be the services that bring in profts.

35

14 Appendix: Detailed Schedule Breakdown The pages below provide the detailed time estimates breakdown that I used when planning out how long the application would take. The breakdown goes much deeper than the details described in the “Schedule and Milestones” section.

36

37

15 Change Log 15.1 2nd Revisions (February 7, 2018) This revision set aimed to add more complexity to the app without going way over the time expectation. I have removed the machine learning component after last month’s feedback because it was clear my knowledge on the subject was too weak to reasonably pursue that feature. Instead, I have added a much larger and deeper set of features to the app. To achieve this feature set, though, I had to remove iOS from the project scope. I have added Android tablet support, as opposed to the phone-specifc release that I had planned before.

1. Updated “Project Description” (2) to refect the removal of iOS from the project. (Page 4)

2. Updated “Complexity” (4) to elaborate further on the new complexity added in this revision. (Pages 6–7)

3. Modify “Scope and Depth” (5) to remove iOS support, add Android tablet support, and update current Android version distribution stats. (Pages 7–8)

4. Merge “Functional Requirements” and “Non-Functional Requirements” into a single “Requirements” (5.1) section, which contains testable requirements, as per feedback. (Page 8)

5. Remove information about testing the machine learning algorithm from the “Test Plan” (6) section. (Pages 8–9)

6. Remove iOS tools from “Tools and Technologies” (7.1). (Pages 10–11)

7. Update frst 2 images in “System/Software Architecture Diagram” (8) to remove iOS and machine learning components. (Pages 12–13)

8. Modify “Technological Innovation” (9.1) to remove machine learning component and dig deeper into the modern features of Kotlin and Go that I will be using. (Pages 15–16)

9. Remove machine learning component from “Technical Challenges” (10) and add paragraph on the complexity of the performance and ofine features of the app. (Page 16)

10. Replace “Development Schedule and Milestones” (11) with a new schedule that accompanies all the major changes to the plan for the app. (Pages 16–28)

11. Remove mentions of iOS from “Deliverables” (12). (Pages 28–29)

12. Remove mentions of iOS from “Conclusion and Expertise Development” (13) and add mentions of it to the project future. (Pages 29–30)

13. Add “Appendix: Detailed Schedule Breakdown” (14). (Pages 31–32)

15.2 1st Revisions (January 3, 2018) 1. Added “Functional Requirements” (5.1) and “Non-Functional Requirements” (5.2) subsections to the “Scope and

38

Depth” (5) section. (Page 8)

2. Added “Testing the Machine Learning Algorithm ” (6.1) section to the “Test Plan” (6) section, detailing how testing will be handled diferently for the machine learning component of the system. (Pages 9–10)

3. Added a paragraph to “Tools and Technologies” (7.1) that discusses the technology used to implement the real time communication component of the application. (Page 12)

4. Added new section to “Technological Innovation” (9.1) that provides more details into how machine learning will be used to provide benefts to the users. (Page 18)

39

References Protalinski, E. (2016, April 27). Facebook passes 1.65 billion monthly active users, 54% access the service only on mobile.

Retrieved from https://venturebeat.com/2016/04/27/facebook-passes-1-65-billion-monthly-active-users-54-access-the- service-only-on-mobile/

Tim (2018, February 5). Android Distribution Updated for February 2018: Oreo Breaks 1%!. Retrieved from https://www.droid- life.com/2018/02/05/february-android-distribution/

Miller, P. (2017, May 17). Google is adding Kotlin as an ofcial programming language for Android development. Retrieved from https://www.theverge.com/2017/5/17/15654988/google-jet-brains-kotlin-programming-language-android-development- io-2017

Eason, J. (2017, October 25). Android Studio 3.0. Retrieved from https://android-developers.googleblog.com/2017/10/android- studio-30.html

Gerrand, A. (2012, March 28). Go version 1 is released. Retrieved from https://blog.golang.org/go-version-1-is-released Swift Has Reached 1.0. (2014, September 9). Retrieved from https://developer.apple.com/swift/blog/?id=14 Breslav, A. (2016, February 15). Kotlin 1.0 Released: Pragmatic Language for JVM and Android. Retrieved from

https://blog.jetbrains.com/kotlin/2016/02/kotlin-1-0-released-pragmatic-language-for-jvm-and-android/ Goode, L. (2017, March 16). Netfix is ditching fve-star ratings in favor of a thumbs-up. Retrieved from

https://www.theverge.com/2017/3/16/14952434/netfix-fve-star-ratings-going-away-thumbs-up-down Bonnington, C. (2014, February 4). Facebook's Greatest Innovations: The First Decade. Retrieved from

https://www.wired.com/2014/02/decade-facebooks-innovations/

40