Making of

Aeon of Strife

Aeon of Strife is the result of a study project focused around innovation. For 20 weeks I was challenged in research, design & development in order to create a truely innovating product within any area of my choice. I chose an area out of one of my expertises: Competitive eSports.

For potential business proposals about Aeon Of Strife, I recommend reading through the Executive Summary first.

THE PRODUCT

The product that I have created over the past 20 weeks is presented in the shape of a website. This website is accessed on AeonOfStrife.FlorisSchippers.nl and serves as a community platform for every competitive eSporter out there. Currently I am focusing on the eSport of my choice: Dota 2, but this platform has the capability to expand to any mainstream form of competitive gaming.

Players can register and login on my platform using en email address and password combination. Once logged in, they can edit their profile with a custom nickname and profile picture. Also they can supply the platform with their current MMR (Match Making Rating) in Dota and a captain preference, both of which are used within the platform later on.

In turn players can choose to create or join teams and participate in tournaments or leagues. Teams can be created on the player's profile page or can be joined on the specific team's page using the preset secret code. Players can join tournaments by just clicking the 'Join Tournament' button on each tournament's page.

THE INNOVATION

The true innovation of my product lies within the tournament section of the platform. At the moment, I am hosting 5v5 randomized tournaments, this means that players only register themselves and not an entire team. If players choose to participate in a tournament, the platform will revise all players' skill ratings, which is the most important attribute in creating fair and balanced teams. As mentioned above, Dota uses MMR as the main skillrating, which spans a range of 0 - 10,000 MMR.

Using this data in mind, I have written a matchmaking algorithm that allocates 5 players to each team (the standard Dota format), keeping in mind the current average skillrating of each team. The algorithm is intelligent in a sense that it attempts to allocate high-skill players to teams with a lower average skillrating and vice versa. This will result in a distribution of players over a number of teams, depending on the initial amount of participating players. The calculated average skill rating of these teams does not differ much at all, resulting in fair and balanced teams.

In the example above you can see that there are 18 randomly generated filler players that vary in 'skillRating' from 880 to 9994 (0 - 10,000 MMR). Keeping in mind this extreme gap in skillrating, the matchmaking algorithm has found a way to create 4 teams with a skillrating discrepancy of merely 90 points. It is worth mentioning that this discrepancy is less than 0.1% of the initial skillrating spread.

Previously in similar tournaments hosted by gaming communities, teams were either completely randomized or hand picked by a handful of players like we used to do in primary school's gym class. Both methods resulted in unfair and unbalanced teams where a clear winner could be appointed before the tournament would even commence. This resulted in general annoyance, bad spirits and less tournament registrations for following events. Resulting in a non-self-sustaining environment which eventually dies out over time.

THE DEVELOPMENT

Before I started the development of Aeon of Strife, I determined the main functionalities of the platform into user stories. Out of the must-have and most should-have user stories I created a (ever changing) planning, which served as a tool for me critically to check my progress on a day-to-day basis.

Every day I could see which task was the most important goal for that day and how much time I had to finish that task. This way of working gave me the opportunity to divide the development process into 3 sprints; Sprint 1 - Basics, Sprint 2 - Teams and Sprint 3 - Tournaments. After each sprint, I rounded up all loose ends and created a new release, deployed onto AeonOfStrife.FlorisSchippers.nl.

THE FRONT-END

Since I would like to personally keep exploring the possibilities of the React Framework, I decided to build Aeon Of Strife using React. React offers me efficient browsing, controlled routing and most importantly it is all Javascript. This means that the entire platform is loaded on page-visit, merely switching components in the view during browsing.

During development I was searching for ways to present large amounts of information in an intuitive manner. After some research, danez' & mzabriskie's React-Tabs module came to my attention. React-Tabs is a clear and intuitive way of presenting a multitude of separated pieces of information to the user. Furthermore, React-Tabs is very well documented and easy to put to use. I was able to display all tournament information to the user in a intuitive and structured manner using a few (nested) tabs.

To implement dynamic tournament brackets onto my platform, I discovered a different module named React-Tournament-Bracket by moodysalem. This module renders a dynamic bracket using svg (Scalable Vector Graphics) imagery using a single object input. Do not underestimate this input object however, this single object must contain all information to draw the entire bracket. I had to do a lot of research on how this object was structured before I could attempt generating one using algorithms I specifically wrote for this component. One of these algorithms generates an entire bracket object based on teams of players as input, the other algorithm goes through the entire object to update scores that happen during the course of the tournament.

THE BACK-END

Since I am only using Javascript to power the front-end of this platform, I was looking for ways to use Javascript for the back-end as well. I worked with Google's Firebase before, but I was looking for something new. Firebase has been expanded with Cloud Firestore, a "flexible, scalable NoSQL cloud database to store and sync data for client- and server-side development". It uses a structure that bears similarities to a classic database where 'collections' are similar to tables, 'documents' are similar to table rows and 'fields' are similar to the columns of the table holding the values, where interestingly not every document needs to have the same fields.

Cloud Firestore is powered by a database tool where all the data can be monitored live. This means that you can see your data updating in real time whenever you push any changes to it. This gives the developer a clear image on the amount of requests that is done to the database and how the data is manipulated.

THE INTERNATIONAL TECH COMMUNITY

To contribute to the international tech community, I have decided to openly publish my matchmaking algorithm with instructions as a gist on my Github page. To get an idea of the algorithm, you can see the code contents of the gist below.

As mentioned before, Aeon Of Strife uses 2 community-made modules; danez' & mzabriskie's React-Tabs and moodysalem's React-Tournament-Bracket. The first of these 2 is documented very well and was easy to implement, but the second one was a different story. In order to use those components I had to do a lot of research about the data object that the components were expecting. I decided to contact the creator of the module after I found his Reddit username, who gave me a push in the right direction by teaching me how to dissect his demo page.

I ended up writing another 2 algorithms in order to correctly use the React-Tournament-Brackets; a bracket generator and a score crawler. Both of these algorithms are openly published as gists on my Github page.

THE COST ANALYSIS

In order to run the platform I am using a Apache stack on a Ubuntu web server, hosted by TransIp. I am using TransIp's cheapest package which costs €10.- per month. This VPS (Virtual Private Server) allows me to run multiple websites with moderate traffic, of which all possible revenue can be used to cover the web server's expenses.

The database is facilitated using Google's Cloud Firestore. Firestore is a service with a free entry package that allows up to 50,000 document reads, 20,000 document writes and 20,000 document deletes per day.

The cost for both of these services can be tackled using a combination between ad revenue and potential Patreon support. Clicks on ads generate €0.052 which are clicked by around 0.84% of users. In order to generate €10.-, I would need 193 clicks, which by calculation require a total of 2298 monthly users. This traffic seems out-of-reach to me at this point in time, so additional income will be necessary. Patreon support could potentially cover all expenses. In return for becoming a Patreon, I can offer various monthly reward. For example ways to stand out in the community Discord (custom emoji, vanity roles, etc.). Various Patreon roles could be created, varying in ranks from €1.- to €10.- of monthly contributes. This way only 10 Patreons are necessary to completely cover all expenses.

Furthermore I would need to expand my cost analysis model if I were to reward players with prizes for winning tournaments and leagues. If I were to offer such prizes, I would need to create traction with larger organisation which could act like sponsors for these prizes. These prizes would not require to be cash prizes, but could also exist of various services. For example a month of premium membership on a Dota analysing platform like Dotabuff. In return for these prizes, I could integrate Dotabuff's services into my platform, generating publicity and possibly more income for them.

Visit Aeon of Strife at AeonOfStrife.FlorisSchippers.nl