Catan world and Churchill
•Télécharger en tant que KEY, PDF•
2 j'aime•3,862 vues
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.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (9)
Similaire à Catan world and Churchill
Similaire à Catan world and Churchill (20)
Dernier
Dernier (20)
Catan world and Churchill
- 1. Catan World Grant Goodale Dean Hudson Mason Browne August 23, 2012 #gamedevjs
- 2. A year ago:
- 4. + = ??
- 5. January 15: Go! Port server-side engine to JavaScript Redesign client-side engine for canvas, mobile Design & build for scalability (up and down)
- 7. Catan World!
- 8. Catan World
- 9. Catan World
- 10. Catan++ Single massive game world real time play - no turns! Exploration, global trade, technology, and more
- 11. Catan World Hardware-accelerated canvas rendering on desktop and mobile Realtime, cross-platform play Inifinitely large world without sharding
- 12. Churchill A proper game engine A full-stack JavaScript game engine Dual-pipeline client rendering (DOM and canvas) MMO server functionality with code parity between client and server
- 13. Churchill A proper game engine ~ 186 classes ~ 7412 lines of CoffeeScript Compiles to ~10849 lines of JS, split out by target platform
- 14. Churchill Engine
- 15. Front-End Architecture Ignore the Single Responsibility Principle At Your Peril
- 16. Game Entities Manage position Manage velocity Manage collision / point intersection Respond to update() calls
- 17. 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.)
- 18. Entity Manager Keep track of entities in the game Interface for adding, deleting, and retrieving entities Provides component interface Dispatches update calls and normalized events
- 19. Multiple Renderers Pluggable renderers, adhering to a common interface Allows canvas/DOM specific caching, double buffering, etc. Builds render queue Makes draw calls to rects
- 20. Core Loop Wrap it all together Dispatch queued server/UI events Make update calls Build render queue Call renderer.render()
- 21. Embracing Constraints Using all canvas rendering in Catan World
- 22. Why? Excessive DOM manipulation is slow and prone to performance/memory issues More consistent support for mobile wrappers Because we can.
- 23. But... The DOM does A LOT of work
- 24. 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
- 25. 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
- 26. Building UI/UX in canvas
- 27. 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
- 28. 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!)
- 29. Hit Detection
- 31. Sage Advice ”Establish & Embrace Constraints” - @kevmoo (or something to that effect)
- 32. On Node, Not Of Node Churchill 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
- 33. Be Modular! Factor out platform-specific feature functionality into modules: File I/O, Network I/O, DB access Supporting a given platform just means having the supporting feature modules
- 34. Use Channels! Discrete message & event channels Abstraction lends itself well to composition and chaining In turn makes transport-agnostic message passing easy Support for TCP socket, in-memory (direct dispatch), and socket.io (WebSocket, XHR, etc) transport
- 35. Emergent Properties! Can run multiple, independent services in the same runtime Makes service composition a sane design decision No I/O overhead incurred for in-memory (direct dispatch) between services in the same runtime Scale!
- 36. Other Neat Stuff Message routing amongst cluster peers Leader election amongst cluster peers Locality-based message dispatching
- 38. Caveats We’re an OS X shop We like UNIX-y things: emacs, bash, sed/awk We’re highly opinionated and not very nice
- 39. Node! Development is node-centric engine is a set of npm modules express app for serving games in dev Cake (make-alike) tasks for mobile client builds, tests
- 40. We Need You! Help us test before launch! http://catanworld.goko.com
- 41. We Need You! Come help us build the next generation of connected games iwanttowork@massivelyfun.com http://massivelyfun.com/jobs/
Notes de l'éditeur
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- Can easily separate CPU-bound services into their own processes and scale them independently with minimal code changes (swap out the message dispatch strategy). You incur I/O overhead, but free up frontline dispatch loops.\n\n\n
- \n
- \n
- \n
- \n
- \n
- \n