Transcript Slide 1

We’re building the global gaming platform of the future.
In JavaScript.
Seriously.
Me
•
•
•
Hernan Silberman
Server Engineer at
ngmoco:)
[email protected]
What we do...
Mobile vs. Web Development
•
Mobile and web based free to play games have similar goals
but the development ecosystem is different
Mobile
Web
cross platform
no
yes
live updates
no
yes
Client-Side Game Engineering
• 4-6 Week Development Cycle
• 2-3 Weeks of feature development
• 2 Weeks of bugfixing
• About 1 week turnaround after a submit to Apple
• Fastest turnaround: 1 day
• Slowest turnaround: 39 days (Touchpets Cats 1.0)
• Always the possibility that a game will be rejected, sometimes for baffling
reasons
• Very un-web 2.0
• Hard to build a business with uncertainty and long turnaround times.
• Have to manage game the game submit process
• “We would do daily client updates if we could”
Server-Side Game Engineering
• Prepare games for production
• Make sure we have a good scaling story
• Usually: Do load testing and deal with the fallout:
• Application and database tuning. Caching. Sharding
• Security/anti-botting pass
• Make sure the game is drivable
• Often involves writing lots of code in a short period of time.
• Support live games
• Build new features
• Update existing features as games scale up.
• Fix bugs
• Put out fires
• Iterate quickly: scheduled weekly live code pushes, more if necessary
• Two content updates each week
Most of our game servers are
glorified web applications
Goals
•
•
Build platform-native quality games and applications with a
common codebase that targets iOS, Android and the Web.
Give mobile gamemakers a development ecosystem that allows
for continuous iteration, just like the web.
Why?
•
•
Why build another game development framework?
Isn’t there something out there already?
Evaluating Existing Solutions
What existing options solve these problems on mobile?
•HTML5
•Performance is poor on mobile
•Implementations differ by browser
•3D support is very immature
•Flash
•Only recently allowed on iOS
•But can’t interact with native code
•Performance is often poor on mobile
•Cannot update remotely
•PhoneGap or Titanium
•No OpenGL support
•Not designed for high rate updates
•Required for game simulation and animation support
ngCore
•
Custom solution to meet requirements
•
•
•
Write games in JavaScript so developers can iterate quickly
Bind JavaScript to platform code to get native performance
Build backends for iOS, Android and Flash
ngCore Features
Feature
Description
2D Sprite Engine
Optimized 2D sprites with animation and transforms
2D Geometry Engine
Arbitrary 2D textured mesh geometry
Native UI Bindings
Native platform widgets such as buttons, scroll views, lists
Physics
Native code executed Box2D physics
Social Services
Full Mobage integration
Audio
Multichannel audio and mixing
Multitouch
Common API for multitouch across devices
Motion
Accelerometer, gyroscope, compass, GPS
Text and Fonts
Full font rendering
Mobage SDK is available today: developer.mobage.com
The Server Side
All of our games are social
We run lots of backend infrastructure...
Ops
One data center (West Coast US), two by June, more to follow quickly
20 racks
450 servers (16 virtual cores, lots of RAM)
A few additional racks hosting virtual Linux instances.
Ubuntu Linux
Akamai/S3/Cloudfront for delivering static content
60+ EC2 instances
The usual assortment of monitoring tools:
Nagios/Munin/Cacti/monit
We also use (and love) New Relic
Servers...
Servers...
Servers...
Daemons
nginx
apache
ruby/rails/passenger
mysql (100+ instances)
redis (95 instances)
cassandra (40 node cluster)
memcached (lots)
resque/resque-scheduler (lots)
hadoop/hbase (analytics)
ejabberd
mark logic
mongodb
Code
Client
Server
Objective-C
C/C++
Java
JavaScript
Ruby/Rails
PHP
Erlang
C/C++
Python
JavaScript
Why we’re building services
with node.js
Performance
• Node.js performance is shockingly good
• In some cases an order of magnitude better than
our Ruby/Rails deployments
• We can build scalable architectures with just
about anything but as we scale up we can’t ignore
performance
JavaScript
• We’re writing game clients in JavaScript. Being able to
write services in JavaScript has major advantages.
• Code reuse
• Our unit of reuse is an entire library
• We tend to build games in a hurry. Being able to run
the same game logic on the client and server is huge
(e.g. validation of game rules).
• Tool/Knowledge reuse
• Developers don’t have to context switch
Our experience so far...
• Performance gains are real
• Community is growing quickly
• Lots of innovation
• Libraries usually exist but quality does vary
• Writing good async code is a skill
• Experience in the browser is useful but it takes practice to
be competent on the server
• Writing bad async code is not an option
• Testing is extremely important
• Debugging tools are getting better
This is hard to do in Ruby/Rails
This is easy to do in Ruby/Rails
Core tools...
• npm
• expressjs/connect
• jake
• jasmine
• node-inspector
• log4js
• ... and lots of
additional support
modules
“So you’re interviewing for a
server developer position... how
do you feel about JavaScript?”
The Game Service...
• Create a platform for our game developers to build compelling
game services easily in JavaScript with all the features they have
a right to expect
• Provide a developer experience that allows for quick iterative
local development and easy production deployments.
• Provide a development model that allows developers to focus on
writing domain-specific code instead of infrastructure.
We’re Hiring
ngmoco.com/jobs