Javascript in Battlefield 4

We take a closer look at the Battledash, the ingame version of Battlelog and how Javascript has it's place inside a modern game. We also look at the tools used during day to day developement.

Transcript

1. Javascript in Battlefield 4 HÅKAN ROSENHORN
2. TODAYS TALK → ESN, WHAT WE DO → BF4 & THE BATTLEDASH → WORK ON A DAILY BASIS → Q & A
4. https://www.youtube.com/watch?v=zB3LFY1sp8Q
5. Introducing the Battledash
7. CHALLENGES → No JIT → Memory constraints (memory budget) → Busy CPU → Respect first party restrictions → Similar to mobile dev → But, good graphics cards
8. ARCHITECTURE OVERVIEW → Running in WebKit → Faster turnaround times → Easier to hire web devs → React → Evaluated different frameworks → JS bridge to C++
9. REACT USAGE IN THE DASH
10. REACT OVERVIEW → Very efficient DOM manipulation → Virtual DOM → Minimizes changes needed to be sent to browser → Reduced layout trashing / reflows → There is no template language (WTF?) → Structures everything as components → Talks a lot about 60 FPS on non-JIT devices → Easy to optimize
11. COMPONENTS → Examples are → Menu, Soldier, Footer → State comes from parent called props → All have a render method
12. RENDERING COMPONENTS → Content becomes available asynchronously → Rendered in multiple passes → Only areas affected are updated
13. RENDERING COMPONENTS → user: Not resolved → dogtags: Not resolved → myStats: Not resolved → user: RESOLVED → dogtags: Not resolved → myStats: RESOLVED
14. INTERFACING WITH THE GAME → Native object injected by Frostbite game engine → Allows for event listening → Dash opened / closed → New multiplayer round started → Job complete (video, audio etc) → Provides async API → Play video → Fetch stats → Join game
15. LOCALIZATION → Available in multiple languages → One JS bundle per language → Great support in Webpack → Translated when compiled/packaged → Reduces size → Less overhead → Dynamic translations → Increases bundle size
16. WORK ON A DAILY BASIS
17. DEVELOPMENT → Built with React → Node js during development → Chrome dev tools → Webpack for packing and bundling → Grunt for tasks → Development done using fixtures → Ensure each developer uses same data → Easy on-boarding and easy test running
18. TESTING & CI → TeamCity runs all tests on each commit → Developer is notified if build fails → Style checks → JSHint for JavaScript best practices → JSCS for code style (no debate, tool decides) → Unit tests → Tests small contained behaviour of functions → Can also test rendered React components → Runs headless inside PhantomJs with jsdom → End-to-end tests → Test user behavior from a high level perspective → Navigate between tabs and checks for broken images and console errors → Runs in real desktop Chrome browser
19. EXAMPLE UNIT TEST var RankName = React.createClass({ render: function () { var rankContent = this.translateRank(this.props.rank); return ( <span className="rank"> {rankContent} </span> ); } }); it("should output correct name given recruit data", function () { var RankName = require("../../src/components/RankName"); var node = ReactTestUtils.renderIntoDocument(RankName({rank: 0})); var entry = ReactMount.getNode(node._rootNodeID); expect(entry.className).toBe('rank'); expect(entry.nodeName).toBe('SPAN'); expect(entry.innerHTML).toBe("RECRUIT"); });
20. EXAMPLE E2E TEST it("should be able to navigate to settings menu and entering it", function (done) { var down = SPECIAL_KEYS["Down arrow"]; var right = SPECIAL_KEYS["Right arrow"]; browser .get(common.getPage("/")) .sleep(1000) .keys([down]) .keys([right]) .url() .then(function (result) { expect(result).toContain("settings"); done(); }) .catch(function (err) { expect(err).toBe(null); done(); }); });
21. PERFORMANCE TESTING → TeamCity also runs automated performance tests → Two examples → Switch between tabs as fast as possible → Scroll in lists as fast as possible → Stores result for each build → See what build that caused a performance degradation → Possible to see trend over time → Manual tests to trigger performance issues with WebKit inside game
22. PERFORMANCE TESTING
23. REMOTE DEBUGGING → Weinre Video :)
24. UPDATING / PATCHING → Update content on a daily basis → Feature flags → Switch features on and off → Rollout → Test a new build on a subset of user base → Target an entire platform → Send debug builds to certain people
25. Questions? HÅKAN ROSENHORN