This presentation was given at the jQuery conference 2010 in Mountain View and featured the first public premiere of a sneak peek video of our upcoming JavaScript game engine. The video preview can be found here: http://youtu.be/Ol3qQ4CEUTo Enjoy and follow me at @pbakaus on Twitter!

1. ..to boldly go where no web developer has
gone before.
Building a game engine
with jQuery

2. Why build a game engine?
Aren‘t there enough already?

3. Game development
Browsergame development vs. game industry*
* PC/Console game publishers

4. Same basic questions
What kind of genre for my
game?
Singleplayer or multiplayer?
What platform(s) am I
targeting?
What tools do I need for
development?
How does the game scale?

5. The game industry

6. Convenience
Countless tools and
frameworks to choose from
Frameworks can be
extended with more genres
Modularity gives you flexible
combinations inbetween

7. The browser game industry

8. Browser games are often grown
hobby projects
Development often copied from app
dev paradigms rather than games
No real technical standard (i.e. C++)
a lot (no seriously, a lot!) of legacy,
custom code

9. Frameworks
Few good commercial flash
frameworks
No commercial JavaScript
alternatives
A couple tiny projects
most of them concepts
most of them dead

10. Why no frameworks?

11. Browser game development is pretty young!
Game industry has an advantage of ~25 years

12. Only very recently, we got
powerful enough hardware
to run lots of crazy JS
new advanced
technologies: CSS3,
HTML5
highly optimized rendering
engines: Nitro etc.

13. Additionally...
Lots of knowledge needed to build sophisticated
games
..but many started it as hobby
Actual web devs are seldom good game devs – and
vice versa
Very few allrounders that know both worlds

14. Reality without frameworks:
Countless iterations of code!

15. Sweet!
I have no competition
There‘s high demand
Let‘s rock!

16. The open web stack
Picking the right technologies

17. Cross-browser?
If your engine is platform specific, no need to care
about cross-browser
Example: Engine for mobile WebKit
Pro‘s and con‘s
Limited audience
Extreme development speedup and advantage

18. Don‘t worry about today Your game won‘t be
ready tomorrow!
Pick technologies from
the future Predict wisely

19. Our pick
Vanilla HTML (rendering)
JavaScript (scripting, client + server!)
Canvas (as tool, not for rendering)
(mostly) cross-platform via ExCanvas
CSS Transforms
cross-platform via Transformie

20. ..and of course

21. Architecture and API Design
What to keep in mind when building the web

22. Impossibilities
Genres that can‘t be Genres that can‘t be
implemented now, but implemented for many
pretty soon: years to come:
Casual 3D games, Next-gen 3D games
simple shooters
WebGL is not
Using WebGL advanced enough (yet)

23. So what is left?

24. 2D 2.5D*
Puzzles RPG‘s
Adventure Strategy
Board games turn based
Card games real time
Platformers Simulation
Jump & Runs etc.
* isometry

25. We chose...

27. I want...
Free mouse panning Pathfinding
Infinite real-time worlds Walking into houses
Non-rectangular objects Mashups with normal
HTML content
Animated characters
Sound effects
Chat bubbles
Scalable viewports
Collision detection
MMO-ready server

28. Awesome! Sounds
just like the Duke!

29. Errr...
Yes, if we try to develop a
classic game engine
We‘re aiming for the web
though, let‘s cheat!

30. Advanced Techniques
Two examples

31. Rendering
„How do I render 2000 objects in < 50ms?“

32. Uh uh, obviously I‘ll use
Canvas!

33. Oh noes! Canvas is a lot
slower!
Canvas‘ image API is pretty
inefficient, as it needs a DOM
representation of the image first
Which means if you‘re working
with lots of graphics, Canvas is
actually way slower than generic
HTML

34. Block rendering

35. Block rendering?
Directly replace innerHTML with a huge string instead of
multiple DOM append operations
Huge performance boost:
Native parsing of HTML engine is really fast
Reflow and Repaint occur only once
Huge disadvantage:
No reference to individual nodes!

36. Lazy node linking
Fixes the main disadvantage of missing references
After innerHTML has been set, run:
var elements = $(‘ *‘, container);
Now you have a collection of all elements!
Since you know the order of the construction, you can
reference back

37. Smart rendering

38. Conservative method
Build <div>‘s and style
them via JavaScript (on <div
style="position:absolut
the style tag) e; top:122px; left:
145px; z-index:102;
Render them out en background-image:url
bloque through (house_1.png); margin-
innerHTML top:-10px; margin-
left:-10px; background-
position:10px 33px;"></
Ugh, still kind of slow... div>
I want more!

39. Dummy, forgot
how to build
websites?

40. Web method
Don‘t ignore the layout
layers
expecially not external
CSS
Keep the style tag of the
<div> Object minimal:
z-index, top, left

41. Web method
Everything else is
rendered through a
CSS rule
i.e. model-134
Includes background,
margin, padding etc

42. Delegation
jQuery events and click-through maps

43. What is event delegation?
A technique to „forward“ events to implicit listeners
In web development, usually the following:
Bind an event to the root node except for the actual
child element
When an event happens (i.e. click), find out if the
target or an ancestor matches the child element
Moves processing efforts to when the event
happens, scales really well

44. One event to rule them all
„mousemove“
Handles position detection, dragging
„mousedown“
Handles drag start, clicking
„mouseup“
Handles drag stop, clicking

45. ..and with jQuery?
With jQuery, it‘s even easier
jQuery has live/die methods that
work like bind/unbind
abstracts event delegation so..
..you don‘t need to worry about it
Sweet!

46. live/die on objects
Yay, I can click on
houses!
Mh, I can click on
transparency, too..
This kind of sucks!

47. Be creative!

48. Click through maps
Build up a pixel map for each object that tells us where
the transparent pixels are
If transparent, check behind until you find a valid target
Checking behind can be done, since you control the viewport, and you know
where your elements are
W00t, this fixes our issue!

49. Building up those pixel maps is amazingly
crappy work!

50. Let Canvas do it!
Canvas can read pixel data from images
Then, we can check if our pixel is in fact transparent
...and save this 0/1 value in a new optimized, smaller
array
var clickMap = [];
for (var i = 0, n = imageData.length; i < n; i += 4) {
var row = Math.floor((i / 4) / width);
var col = (i/4) - (row * width);
if(!clickMap[row]) clickMap[row] = [];
clickMap[row][col] = imageData[i+3] == 0 ? 0 : 1;
}

51. Server-side JavaScript
Bridging the gap

52. „JavaScript is painful enough already, now you
want me to work with it in the backend as well?“

53. Why JavaScript?
A single scripting language per project dramatically
speeds up development
Great portions of client side code (i.e. for calculations)
can be reused without costs
JavaScript is awesome!

54. Meet node.js
„So sexy it hurts“

55. „The most revolutionary
technology for web developers
since jQuery.“
Paul Bakaus

56. JavaScript in the Browser

57. JavaScript in node

58. Node‘s features
Google‘s V8 engine running on server
Server and scripting combined
Comes with sugar (pretty modules for system, servers
etc.)
EcmaScript 5

59. The great innovation?

60. Node is completely event-
driven.
db.query(‘ select..‘, function(result) {});

62. ?
Professional game engine for the web
Commercially licensable
Cross-platform (yes, works on iPhone!)
Comes with all mentioned features (and more)
Currently in alpha Contact us for availability and pricing!

63. Show me the video!
http://tinyurl.com/dextrose-aves-engine-sneak

64. Thanks for your attention!
More at dextrose.com & paulbakaus.com
Rate this talk at http://spkr8.com/t/2986
@pbakaus
We‘re looking for investors and
partners!
Contact us at contact@dextrose.com
for more information.