Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Catan world and Churchill

4,994 views

Published on

Slides from Massively Fun's talk at the August JavaScript Game Development meetup in Seattle. In it we discuss our new title, Catan World, as well as our new HTML5 MMO game engine, Churchill.

Published in: Technology, Design
  • Be the first to comment

Catan world and Churchill

  1. 1. Catan WorldGrant GoodaleDean HudsonMason Browne August 23, 2012 #gamedevjs
  2. 2. A year ago:
  3. 3. += ??
  4. 4. January 15: Go!Port server-side engine to JavaScriptRedesign client-side engine for canvas, mobileDesign & build for scalability (up and down)
  5. 5. 7 months later:
  6. 6. Catan World!
  7. 7. Catan World
  8. 8. Catan World
  9. 9. Catan++Single massive game worldreal time play - no turns!Exploration, global trade, technology, and more
  10. 10. Catan WorldHardware-accelerated canvas rendering on desktopand mobileRealtime, cross-platform playInifinitely large world without sharding
  11. 11. Churchill A proper game engineA full-stack JavaScript game engineDual-pipeline client rendering (DOM and canvas)MMO server functionality with code parity betweenclient and server
  12. 12. Churchill A proper game engine~ 186 classes~ 7412 lines of CoffeeScriptCompiles to ~10849 lines of JS, split out by targetplatform
  13. 13. Churchill Engine
  14. 14. Front-End Architecture Ignore the Single Responsibility Principle At Your Peril
  15. 15. Game EntitiesManage positionManage velocityManage collision / point intersectionRespond to update() calls
  16. 16. Rendering Primitives Implement draw specifics Separate draw calls for different renderers (visitor pattern) Delegated to by GameEntity for calls that require per pixel information (image hit detection, etc.)
  17. 17. Entity ManagerKeep track of entities in the gameInterface for adding, deleting, and retrieving entitiesProvides component interfaceDispatches update calls and normalized events
  18. 18. Multiple RenderersPluggable renderers, adhering to a common interfaceAllows canvas/DOM specific caching, double buffering,etc.Builds render queueMakes draw calls to rects
  19. 19. Core LoopWrap it all togetherDispatch queued server/UI eventsMake update callsBuild render queueCall renderer.render()
  20. 20. Embracing ConstraintsUsing all canvas rendering in Catan World
  21. 21. Why?Excessive DOM manipulation is slow and prone toperformance/memory issuesMore consistent support for mobile wrappersBecause we can.
  22. 22. But... The DOM does A LOT of work
  23. 23. Infinite Scrolling Computationally expensive-nearly every pixel is dirty so we have fewer tricks to save drawImage calls Necessitates double buffering Relative positioning is hard
  24. 24. Building UI/UX in canvas Needed to implement our own click detection, windows, buttons, dragging handlers, etc. Use a JSON (esque) layout format to specify positioning
  25. 25. Building UI/UX in canvas
  26. 26. DOM events !=Churchill events Need to normalize DOM events UI/UX events coming in on a single DOM element (the canvas) Touch and mouse normalized into pointer events Canvas relative positioning
  27. 27. Hit Detection See above Infer z-ordering Dispatch events to game entities based on x, y containment Bubbling behavior needs to be handled explicitly (brew your own!)
  28. 28. Hit Detection
  29. 29. ChurchillServices
  30. 30. Sage Advice”Establish & Embrace Constraints” - @kevmoo (or something to that effect)
  31. 31. On Node, Not Of NodeChurchill clients and services are pure.Your JS engine is your runtime (V8, Nitro,SpiderMonkey)Node and browsers are platforms (runtime + features)All code should run in all supported runtimes
  32. 32. Be Modular!Factor out platform-specific feature functionality intomodules: File I/O, Network I/O, DB accessSupporting a given platform just means having thesupporting feature modules
  33. 33. Use Channels!Discrete message & event channelsAbstraction lends itself well to composition andchainingIn turn makes transport-agnostic message passingeasySupport for TCP socket, in-memory (direct dispatch),and socket.io (WebSocket, XHR, etc) transport
  34. 34. Emergent Properties!Can run multiple, independent services in the sameruntimeMakes service composition a sane design decision No I/O overhead incurred for in-memory (direct dispatch) between services in the same runtime Scale!
  35. 35. Other Neat Stuff Message routing amongst cluster peers Leader election amongst cluster peers Locality-based message dispatching
  36. 36. DevelopingWith Churchill
  37. 37. CaveatsWe’re an OS X shopWe like UNIX-y things: emacs, bash, sed/awkWe’re highly opinionated and not very nice
  38. 38. Node!Development is node-centric engine is a set of npm modules express app for serving games in devCake (make-alike) tasks for mobile client builds, tests
  39. 39. We Need You! Help us test before launch! http://catanworld.goko.com
  40. 40. We Need You! Come help us build the next generation of connected games iwanttowork@massivelyfun.com http://massivelyfun.com/jobs/

×