CartographerAPI [CAPI]: Halo API Extension for UGC

----- Overview -----

The Cartographer API, or CAPI for short, is a map analytics extension of the Halo API. It provides the ability to grab game data based on Maps, Gametypes, and Forgers rather than just Players and Games like the standard Halo API. This means that people will be able to see every custom game ever played on a map, be able to see how often their map is being played, generate statistics on their maps, and so much more.

----- Summary of the Tech/Process -----

Because CAPI is an API this means that it can be tapped into just like the Halo API and custom web apps, mobile apps, and more can be created based on the data that CAPI provides. It does this by storing every single custom game ever played and then running those custom games through an analytics system that takes note of answers to questions like what map was this game played on? Sounds like a lot of information right? Well it is. Storing every custom game and the analysis for maps will take a huge amount of storage and the entire system will need to have a ton of processing power to pull this off. And this would normally be a huge development effort.

Enter Amazon Web Services (AWS)… AWS provides an infinitely scalable platform that will allow CAPI to grow to whatever it needs to grow to. Using the latest tech like AWS Lambda and API Gateway means that CAPI is backed by enterprise level tech and hardware to ensure it meets the expected demands of the Halo Community. There are more specific details on what tech is being used on the Bitbucket readme.

CAPI is an open source project. This means that not only does CAPI exist for the improvement of the Halo Community, but it also exists for the teaching of an enterprise level API that is easy to manage thanks to the beauty of AWS. And that means that any member of the Halo Community that has the know how can participate in the development of CAPI. All of my development for CAPI will be live streamed for the world to watch how the system grows and learn from its explorations through LiveCoding.tv. And those that have even a bit of development experience can learn, ask questions, and help build CAPI to be the best that it can be.

In addition CAPI is looking to also hold some key software engineering principles to speed up development. A serverless architecture will be used to remove the overhead of most of the systems work. No managing servers, deploying servers, or dealing with databases crashing. Nanoservices is how things will be segmented. Thanks to AWS Lambda we are able to keep our business logic in small compartmentalized portions without ridiculous overhead to deployment of new features. Also following things like the SOLID principles, pub/sub systems, and things like automation will speed up the development of features. And thanks to AWS we will have a lot of features covered for us like logging, monitoring, and scaling. All in all this means that it will be wonderfully simple to add new features to CAPI within a matter of hours or a few days. This will allow developers to focus on what matters. Below is a current model of the architecture that is in place right now. Anything in red lettering has not been implemented yet and this is far from complete as the system is just going to keep growing from here.

<<< CAPI Architecture >>>

As custom games are added to the cache, they are run through the CAPI system in order to get stored into materialized views. Basically questions like “What games have been played on my map” are anticipated and then pre-calculated and stored in a materialized view. This means that no runtime calculations are done on data. No querying or anything. Instead endpoints will just retrieve data stored in these views… which is blazing fast thanks to DynamoDB and the magic of NoSQL. As more questions need to be answered, we create new materialized views and add new endpoints.

As time goes on the goal will be to have Halo developers be able to help define the contracts for these questions based on what their apps need. Eventually we will be incorporating Swagger/RAML/API Blueprint to provide documentation and using a system like that developers an define the kind of endpoints they are looking for and create a Feature Request to have those implemented. API Keys will be provided as well to developers to ensure that only those that need access to the data get it. Eventually CAPI will evolve into more than just a place for materialized views and allow users to claim maps, group maps, request heatmap generation, create teams, etc. So that will come in the future as well.

CAPI is being developed in Java, one of the three currently supported languages for AWS Lambda. I prefer the strongly typed language over Node and Python. As mentioned I will be live streaming the development of CAPI for anybody who is interested in following along. You can watch as I trip over my own feet and make mistakes as I also try to explain the ridiculous ideas in my head. This is also a good opportunity for the Software community to watch the usage of AWS’s serverless architecture model. Which has been a great experience so far and I hope more people give it a shot.

----- When will it be available -----

I’m currently just previewing CAPI to draw up some discussion on it. My current projection will probably be within the next month. I’ve got the core of the system working that can essentially store every custom game available and keep the system up to date. At this point it is stress testing, catching edge cases, building the discovery system, and building out every materialized view we could possibly want. So expect it to come soon. :wink:

----- Links -----

CAPI Bitbucket Repository - https://bitbucket.org/GodlyPerfection/cartographer-api

Join the development of CAPI or see how it works under the hood.

LiveCoding.tv Stream - https://www.livecoding.tv/godlyperfection/

My LiveCoding.tv stream where you can watch me code CAPI. This means you can ask questions, stay up to date on the roadmap, and more.

----- Further Discussion -----

Do you have any ideas on what CAPI could do? Use this thread as an idea generation space. Help design a tool that will bring the level design community that much further.

This looks like an impressive project. The analytics that will be possible could be invaluable to the right person.

Do you have any indication of the cost required (particularly the storage requirements), over 1 (2, 3?) millions matches? I have a feeling it’s going to run over any of the free-tier plans pretty quickly.

> 2753093343646559;2:
> This looks like an impressive project. The analytics that will be possible could be invaluable to the right person.
>
> Do you have any indication of the cost required (particularly the storage requirements), over 1 (2, 3?) millions matches? I have a feeling it’s going to run over any of the free-tier plans pretty quickly.

Yes it will definitely be over the free tier. DynamoDB costs are for every GB after the first 25. I’ve just done some rudimentary estimations at this point. Now that the core of the system is in place I can get more accurate estimates. The entire system that is in place now grabs every custom game for a single gamertag and also refreshes the cache every hour for any player that we haven’t updated in the past 24 hours so it handles all new games that come in. Those intervals will probably change. The only major part of the core system is the discovery system that will recursively find new players based on the players in each of those custom games and also the system that caches events. Once those are in place it is all materialized views from there which will be a very small fraction of the data based on what each view needs.

In the next week or two I’ll have better estimations on what the costs will look like including the processing portions that include Lambda Executions, API calls, SNS publishing, SQS requests, throughput provisioning, and data transfer out… and whatever else I might be missing off the top of my head. I’ll also probably write a system to project costs going forward as well as systems that can essentially work within a monthly budget and essentially just be put on pause when the monthly budget is reached.

But yes, costs are always on my mind. For your answer 3 million matches roughly ends up being 42 GB… but that is just consider the raw custom game details. I’m also caching the Player/Game match list summary details… which are arguably smaller… and also the events. Current estimations are a bit rough as players can play the same custom game and games can have 1-16 players. Also if the budget looks gross I can also stick to the purpose of CAPI and just cache relevant games which are played on user generated maps rather than the dev maps. So that will cut a HUGE chunk out of the storage requirements as well.

The “business” needs are flexible and adjustable so we’ll see where it goes and adjust accordingly.