ESAPI (stands for eSports API, pronounced e-sap-ee) consisted of two main components/products. The Web Front End was designed for the normal user/gamer, and then there was the API that would be used by game developers directly in order to add eSports functionality to their games.
My project was selected as a project to be shown at ExpoTees which is an initiative ran by Teesside Univeristy, showcasing Final Year Student work. You can view the 2014 Brochure, or just the section I had in this image:
Front End
The Front End was designed to be as simple and straight forward as possible for users, so they could get to where you they wanted to be with the fewest clicks possible. The home page has a “drill down” navigation approach into various supported platforms such as PC, PlayStation, and Xbox. There was also flexibility to add new platforms going forward. From the various platform pages, you could then select a game and in turn, drill down into that section to see the various ladders/tournaments.
Example of “drill down” navigation, going from Home -> PC -> Starcraft -> Ladder
Another benefit of this approach was that, each area could be designed differently to suit that platform’s specific style. In particular, the background image could promote a product or game (allowing for ads). The game pages were also claimable by the official developer, which meant they could be then promote aspects of their game or provide in game offers, expansion packs, or even advertise the next sequel to a game.
Example of a custom background override advertising a Roccat Mouse
Live Games
One of the more unique features for the platform was to allow developers to have a “live game” view of a particular game in session. This was designed due to the popularity of live streaming platforms like Twitch, and comparative gamers wanting to follow popular matches on the go, with possibly limited bandwidth where watching a live stream would not be suitable.
Once a developer adds their game or claims an existing one, they can then create as many live game views they wish. They are allowed to create custom HTML and then insert binding parameters which will be sent by themselves to the API. An unlimited amount of variables can be created giving as much flexibility as required. In fact, you could re-render the game in the browser!
There’s a few things on the image example above, that would need data pushed from the game:
- Income/Supply (Minerals, Gas, Supply+Limit)
- Players
- Build Order
- Chat Stream
Profiles
Another important feature was the ability to create a profile. So some services existed already but I felt that it was important to design my own that allowed for more specific things like describing PC specs, which teams/clans a player is part of as well as a Facebook like “wall” that shows off results from matches as well as allowing status updates.
Profiles also played a part of the user access levels which were “Player”, “Developer” and “Administrator”. A “Developer” would get access to features which allowed them to add and manage games which an “Administrator” would need to approve initially.
You could also have favorites attached to your profile to easily access content you wanted.
