Battlelog - Building scalable web sites with tight game integration

79,723 views

Published on

Presentation by Johan Mjönes & Joakim Bodin at Stockholm GTUG meeting at DICE

0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
79,723
On SlideShare
0
From Embeds
0
Number of Embeds
72,662
Actions
Shares
0
Downloads
71
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide
  • “Battlefield has existed for many years now, next year will be the 10 year anniversary of the series. Battlelog was our vision for becoming the center of the Battlefield community from BF3 and going forward. We wanted it to become the natural hangout for all the people playing Battlefield games. Especially for our PC playing audience, were we thought we could integrate launching the game and finding servers into Battlelog.”
  • “We set up a list of features that Battlelog should include.”Friend-centric: All features should be integrated with your friends listCommunication: Always available com center UI. With friends status, such as Online/Playing/Away/Offline, 1-1 chat and group party chat system w/ optional VoIPStats: Deep and easily over viewed track record of your accomplishment and easy ways to compare yourself with your friends. This would also include a history of latest battles and a way to study them in detail.Keep up with your friends: A feed of unlock progress, played battles, new friends, popular game servers and interesting forum posts.PC Menu: Easily launch the PC game, include your friends in a Co-Op match or start a Multiplayer Squad.News / Forums: Keep up with what DICE are doing and discuss hot topics with other member of the community.All together, you would have a lot of ways to view and interact with how you and your friends play battlefield.
  • “Battlefield has built a big community over the the years and BF3 was set to make it even bigger. We wanted to build a social network for this community and if successful would need support to a large amount of users.”“Our calculations put this community at several hundred thousands users accessing our site during peak hours. Very few web sites are built to be able to support these kinds of user numbers from day 1. This would be a massive undertaking in deploying hardware and scaling our software features.”Infographic credit:http://connect.icrossing.co.uk/global-facebook-statistics_6499
  • Battlelog is not an island unto itself, so it would need to work well with EA’s account system (Nucleus) and the game backend system (Blaze).Battlelog uses Nucleus to display all your Battlelog soldiers, regardless if they’re connected to Xbox Live, PlayStation Network or Origin. We also use it to know which games and items that the player has bought or gotten through pre-order incentives for each platform.Battlelog uses Blaze to provide it with large amounts of stats information about your progress in the game, as well as detailed history of each round you’ve played. Blaze is also used by the web backend, for other functions, such as keeping track of game servers, reserve server slots and track your place in a game server queue.Blaze has an event system that enables the game servers to quickly push things to Battlelog. These events often end up as real-time information on the web frontend. For example, a Blaze event about new battle reports can be used for both pushing a real-time notification to the user and to intelligently invalidate our backend caches. This way, the player always knows when there is new information and we can make sure to always show them their latest accomplishments.”
  • Communication with Nuclues is accomplished using a thin REST client, connecting Nuclues’ account and entitlement systems with the Web Backend. The web backend then transforms these accounts and entitlements into soldiers and licenses, which are then displayed on Battlelog.
  • Battlelog uses Blaze to provide it with large amounts of stats information about your progress in the game, as well as detailed history of each round you’ve played. Blaze is also used by the web backend, for other functions, such as keeping track of game servers, reserve server slots and track your place in a game server queue.Blaze has an event system that enables the game servers to quickly push things to Battlelog. These events often end up as real-time information on the web frontend. For example, a Blaze event about new battle reports can be used for both pushing a real-time notification to the user and to intelligently invalidate our backend caches. This way, the player always knows when there is new information and we can make sure to always show them their latest accomplishments.”
  • “From the players perspective, joining a PC game server on Battlelog is as easy as loading the server browser and clicking Join.  Of course, there is a lot of things that happen in the background when that Join button is clicked. First we make sure to reserve a slot on the game server, then we construct a command line that will instruct the game client what to do, and lastly we use our own web plug-in to run our game executable with that command line.”“As Battlelog needs to provide the same player interaction as the console game client, like showing if the game is running, it’s current progress, be able to communicate error messages and close it down. For that we need a two-way message system between the game client and the web browser.”
  • Lets look at the components that make this possible.Game UIJSPluginPipeGame ClientTo make this work, we use a simple named pipe. When the browser plugin is running it has a named pipe endpoint set up and during launch the game client connects to this endpoint. After that, we can use a simple text protocol to send things such loading progress or error messages from the game to Battlelog. Of course. Battlelog can also us this pipe send commands to the game. Such as closing it down or make it switch between different game servers.”
  • “BF3 is a data driven game, our pipeline picks up after the game pipeline. Weapons, images, localization, unlocks are all from the game. This allows us to pick up patch/DLC additions/changes quickly”
  • Battlelog - Building scalable web sites with tight game integration

    1. 1. //Building scalable web sites with tight game integrationJohan Mjönes & Joakim Bodin
    2. 2. What is battlelog? › Battlefield 10 year anniversary soon › Battlelog becoming the community hangout › Integrate game launching for PC players
    3. 3. Features › Friend-centric › Easy communication › Current stats and history › Activity log › PC Menu › News / Forums
    4. 4. ESN PLANET
    5. 5. ESN PLANET OVERVIEW
    6. 6. Languages › Developing Battlelog means developing in Python, Java, C++ › The Battlelog Web is written primarily using Python › Plugin, game components in C++ › Python allows for rapid web development (e.g. remote access console)
    7. 7. Partitioning Horizontal (sharding) Vertical Battlelog Battlelog 1-7 7-14 ... User Lab Feature ... ... User DBs Different processes (slices and shards)
    8. 8. Persistence & Index › MySQL › No joins › Used as indexed KVS › Apache Solr › Full text search for forums › Other uses in the future › Fast!
    9. 9. Server to client push › Uses ESN Beaconpush › Allows delivery of messages from web server to client browser. › Uses long polling or websockets (or flash) › AV / anti-malware software + push = › Blocks all websockets › Injects Javascript into the DOM › Etc...
    10. 10. Caching with Memcached › Great framework support › Service methods cached via annotations › Invalidation using method signature instead of key › Allows populating cache directly after modification › Dog pile prevention
    11. 11. EA Services › Nucleus › Users › No user info in Battlelog DB! Success! › Personas › Soldiers › Entitlements › Licenses › Blaze › Game Servers reports to Blaze › Events to Battlelog › Game Server information › Asynchronous responses (e.g. matchmaking) › REST › Stats
    12. 12. Nucleus Details Web Nucleus HTTP Soldiers Web Backend Accounts Licenses Entitlements
    13. 13. Game ServersBlaze Details Blaze › Uses Web Access Layer (WAL) DB Blaze › WAL client generated from TDF › TDF is a API definition language › Blaze events (XML over HTTP) Events WAL Thrift Web Frontend Web Backend AJAX Real-time Events Web Browser
    14. 14. Friends › Started out normalized › Unmanagable amount of rows › Ended up as one blob per user › Packed user ids › A lot easier to cache properly
    15. 15. Server Browser › Custom search server (Java) › Custom query language, minimal message overhead › Fast update, fast search
    16. 16. Joining a game
    17. 17. Joining a game: plugin details Web Browser Pipe Game Client Plugin Game UI JS
    18. 18. Battle Reports › Game report from Blaze (HTTP XML event) › Parse and divide per player › One report per player via internal message queue › Look for unlocks, rankups, medals, awards etc › Add to feed, send real time updates › Invalidate player stats caches › Compile Battlereport (& pre-cache it) › Send notification to involved (logged in) users
    19. 19. Background › Load tested using Locust › Open Source (MIT License) › https://github.com/cgbystrom/locust › Built by ESN (& others) › Battlelog tested with 2.7 million PSU with 36 million players › That’s 40,000 requests per second › The tests was successful
    20. 20. Pre-pass › Planet dev bar › Timing › Queries › No point in load testing if there are apparent issues with a single user
    21. 21. Realistic load testing › Some testing tools simply hammer certain URLs › Locust allows for realistic usage scenarios › Many players go away for 20 minutes while playing, receiving notifications › Updated tests using actual usage data from alpha trial / open beta › Coordinated testing › Same user spans › Overpopulate tables to simulate fragmented MySQL indices
    22. 22. What did we find? › Bugs › Bottlenecks › Never assume where your bottlenecks are › Test to find out › Network related › Saturated network, not CPU › Keep the traffic within the rack! › Software related › Best practices be damned, cheat if neccessary › Lazy loading data in controllers › Client side rendering › Surface + History API + JSON =
    23. 23. Being a part of the pipeline › Data driven games › Battlelog has its own pipeline › Written in Python › Imports data from the game pipeline › Weapons, vehicles, levels, dog tags, etc › Assets include images, text, data › Resolving unlocks and dependencies › Generates python structs and javascript structs › Generates many helper maps. Some might only be used once. › DLC friendly! › Result of many iterations
    24. 24. User Interface › Separate UI from consoles / in game menu › Having the same wouldn’t make sense, different UX › Adapt to different devices › Web features › Easily accessible, e.g. Sharing › Extendability with browser extensions, user styles etc › Access on any platform (play on console, have Battlelog on iPad) › Easy to iterate over UI changes
    25. 25. Battlelog will evolve › Agile: Easy to update › Big things: › DLC › Public APIs › Other things we can’t talk about › Small things › Improvements based on community feedback
    26. 26. Johan Mjönes The Battlelog team is hiring! @nollbit http://dice.se/hiring.aspJoakim Bodin jobs@dice.se @jbripley Technical Director Development Director Backend Frontend

    ×