Building a JavaScript-Based Game Engine for the Web

Uploaded by GoogleTechTalks on 10.07.2010

Thanks to all for coming. Also thank you to the guys in Santa Monica, Pittsburgh and Kirkland
for video conferencing in. I would like to introduce Paul Bakaus who is going to talk
about his Java, pure Java script-based web game engine.
>> BAKAUS: Thank you. So here we go. So yes, my name is Paul Bakaus. Just for a quick introduction,
I'm the guy who has started jQuery UI for anyone who has played with jQuery and jQuery
UI before. And therefore I'm quite experienced in all kinds of user interface. This led me
to one of my really most sophisticated projects here with which is gaming on the web. And
today I will be talking about how to build a game engine and what I learned from how
I did it. So thanks for joining. So actually first question, why build a game engine for
the web, right? What is the purpose? First of all let me show you how the game development
industry right now looks like. If you look at browser game development versus console
games and PC games, there's really a big difference, but on the end, if you're a developer you
have the same questions to answer first. So you have questions such as what kind of genre
are you building, what kind of game is it being? Do you need a single player or a multiplayer?
What platforms are you targeting? What tools do I need for development? And how does this
game actually scale if it's multiplayer for instance? So the questions, the basic questions
are always the same. However, if you look at the classical game industry, you have a
lot of convenience already available. There's a lot of middleware, countless tools and frameworks
to choose from for any kinds of things for scripting, for 3D rendering, for anything.
So in that picture you will see just some quick names you probably might have read somewhere,
Quake engine, Unreal engine, Unity, all those engines are already available and no game
developer in the industry would start over from scratch, it's just not happening because
that would require many, many years of work. So that kind of--also those frameworks are
really very easy to extend with other genre and with other combinations and modules. So
most of the companies, license a framework and then build up on it, which is fine. However,
if you look at the browser game industry, it's really completely different. So browser
games are often grown from hobby projects and development is often copied from app dev
paradigms instead of actual games. There's no real technical standards, so it's not either
C or java, it's really the open web stack or Flash, or Unity, there's all kinds of techniques.
There's a lot and seriously a lot of legacy code flowing around and I'm going to talk
about why in a minute. Secondly, browser games tend to have a long lifespan and that's the
issue with legacy code, right. And they tend to have a much longer lifespan than a normal
game. If you build a console game and release it, it might be that the sales are holding
on for about a year. If you're building a browser game like Farmville or any of those
competitors, really that game is being there for many, many years to come. And that's the
issue right. You have to maintain a lot of old code. So we are talking to many game publishers
and they mentioned it's a huge pain because they have to maintain code that is 10 years
old some times. So really it's a different work and that code isn't using a framework
so it's really custom. It's not interchangeable which is really tough. If you're looking at
the frameworks, we can use in the web, right, anything that displays in the browser. You
only have a very limited choice. So there's very few good commercial flash frameworks
that you can use. There's no commercial JavaScript frameworks that I know of. And there's a couple
of tiny projects, if you look at JavaScript. Most of them are concepts and most of them
are dead unfortunately. So if there was a framework right now, I would probably be using
it and build my own games but there wasn't. So the logical consequence really for game
publishes, everything is being developed in-house and you're going to have the in-house technical
knowledge and you need to build up on it. You have to build in-house tools and you have
to build your in-house frameworks. But why are there no frameworks, what's the reasoning
behind that? First of all, the browser game industry is really young if you compare it
to the classical game industry. The game industry, the classical game industry has an advantage
of about 25 years which is not to be underestimated. So really, we're just starting; we're just
in our childhood right now. And then also, only very recently, we got powerful enough
hardware to back up games. So to run a lot of crazy JavaScript, new advanced technologies
HTML5, you probably heard the password already, CSS3. All kinds of things popping up and many
companies are behind those efforts right now. It's really changing. And finally we have
the engines like V8 and Chrome, and Nitro and Safari that can power games. So for instance
in our case, we have been building prototypes for the last five years and every half a year
we found out that the time is not ready yet. So we tried again in another half a year,
and once again, once again. And finally last year we discovered it's time to release something,
so this is why I gain all these experience. Additionally--and this is also very important.
There's lots of knowledge needed to build sophisticated games, and many started it as
a hobby. So all the game companies you're seeing, Farmville--I'm not so sure about Farmville
but all the big strategy games--strategy based browser games are really hobby based and they
are grown from hobby. And Eugene was a web developer by himself who started this and
it just exploded very quickly, but there's an issue with that because actual web devs
are seldom good game devs and vice-versa, so we have a problem here. Really, it's very,
very hard to find someone who is experienced with games that can build user interfaces,
can build game code, can do mathematics and combine it with the web world, write HTML,
write JavaScript, write CSS. It's a tough job really. And there's very few around us
that know both worlds. So reality without frameworks really looks like this, countless
iterations of code, you write everything from scratch. This is really how it is. We have
been going to many companies and they all shared their frustration. So--but I say sweet,
right. Sweet because we have no competition right now, there's high demand and you at
Google probably know about this because you're trying to get into gaming big time, so let's
rock. So let's take a look at the open web stack, and how to choose the right technologies.
Right? As I mentioned already we have a huge mess of technologies right now and we have
to care and pick wisely. So if you look at flash for instance. We looked at flash and
we investigated if it would be the right choice. Really from a far ahead approach, so a flash,
has obviously the disadvantage that it works almost everywhere but not any of the Smartphones.
And if you're building a desktop engine that might be fine, right? However, if you're trying
to run on Smartphones, Android, iPhones whatever, right, you're targeting. Flash is not your
choice and-- well I mean, you could say we've been seeing flash in Android. In the newest
version of Android, but it's not there yet and it's not completely there yet for the
customers. So I think personally it would take sometime until we really see flash for
the mainstream audience. So when we analyze flash, we saw the pros obviously. It comes
with a pretty good IDE. So the flash IDE is very powerful and this is why many developers
love to use flash. It's installed in most desktops. Multimedia handling is very easy.
Platform independent rendering obviously and we really have some good communication protocols
as well so it's a lot easier to use binary streams to communicate with the server than
it is in HTML. Well in HTML it's not possible actually. So we still have to find some patterns.
Contra, third party JavaScript APIs and widgets cannot be embedded into flash because flash
doesn't have an HTML rendering engine. So there's no way to actually--it's really a
black box, there's no way to really integrate mesh ups and widgets and the open web in general.
So that is one big hole. Scalable view ports are very difficult to do and I have a nice
example later on. And distributed development is also very painful. It has been getting
a bit better with flex, I think. But still you are compiling your code and it's very
difficult to maintain, and obviously no relevancy in the Smartphone market. So what we choose
obviously is the open web stack. We choose to develop plug in list. And let me show you
what I can say about that, right. So Pro, it works on every mobile device and on every
desktop. It adopts many flash features and recently adopts many flash features. I use
it for instance videos, audio, sockets, there's very easy integration available for widgets.
Most of the time you can-- your services like YQL, Google Maps embed all of these automatically
into your code, there's tutorials floating around everywhere so you can build a really
nice social game with it. It is in fact, closer to hard work-- closer to hardware. So flash
has been getting hardware accelerated for sometime but now we are seeing CSS3 being
hardware accelerated on mobile devices which is quite some big leap forward. So in the
future, the browsers will be a lot closer to the hardware than flask can ever be because
the development cycle is a lot closer. And flash like animations are finally possible.
For instance using CSS animations and CSS transforms we really have some powerful tools
here. And yes, engines are already mentioned. So what's bad about HTML and CSS and JavaScript,
obviously there's no real front-end IDE. Some of you might argue that Dreamweaver is a real
front-end IDE, I won't say anymore about that. The development of great games is very painful
using those techniques, obviously because you have to care about cross browser. You
have very few JavaScript experts in the industry still, even in 2010 and especially with focus
on gaming and those are really the problems that we're facing. And obviously, you have
to combine all kinds of technologies. You're not writing in one language; you're writing
in CSS, HTML, JavaScript. So it's really a mix. so our pick was still HTML, Vanilla HTML
for rendering, JavaScript for scripting on the client and on the server, and Canvas but
not for rendering and I'll show you why in a bit but as a tool. So and this then--for
having cross-browser support, we're using ExCanvas from Google to bring Canvas to a
cross platform and CSS Transforms we're using as well which is now in Firefox and most webkit
based browsers. And we're doing a cross-platform using Transform-e which is a plug-in route
recently that emulates CSS Transforms in Internet Explorer. So, the thing about cross-browser,
right? If your engine is really platform specific, if you're building an engine for Android,
right, then there's really no point in doing cross-browser because you're wanting to do
Android games with it. So example, mobile webkit or mobile whatever, mobile gecko and
there's pros and cons to that. Obviously, you have a limited audience there and you
can't push it to other platforms. However, there's an extreme development speed ups,
so you really have to think if you want to do that or if you want to do a real cross-browser
efforts because it's going to take you three times the amount of work. So that's one thing
to think about, right. Also--and that might help you as well, don't worry about today,
worry about the future. And so you have to pick the technologies from the future because
if you're building a game engine right now and then building games from it, chances are
that you will not be ready by 2012, right--2011. So, really, taking--building an engine and
then building a great game of it will take some time. So think about the release time,
what will be--what kind of technologies can you expect once you release your game. And
that's really a key effort that you have to think about. And, of course, what we're also
using is jQuery and jQuery UI. jQuery mainly because it's a library focused on certain
tasks, therefore it doesn't get in our way. So it would be unwise to choose a really big
web application framework in JavaScript like Dojo because that would really limit us in
some extent, for instance the EXT JS as well. So we cannot have a framework that restricts
us because gaming is so different. And jQuery comes with great event support as well. We're
using a lot of event-driven code for the games. And you'll see later why we need this. Why
jQuery UI? jQuery UI really, we can't use any of the widgets because we're not building
a web application, but jQuery UI comes with some great core helpers from mouse interaction
sensors. So that's why we're using from jQuery UI. And, right. So let's continue. We now
know what we--what kind of stack we're using, right? So let's think about architecture and
API design. So what do you want to keep in mind when building for the web? First of all,
impossibilities; if you think about games you want to build, genres that can't be implemented
now, but pretty soon and for instance, casual 3D games, simple shooters using WebGL. So
WebGL – I know how many of you have tried it out already. But WebGL is a pretty fresh
new standard that brings 3D to the browser using OpenGL, it's a very--it's kind of a
direct--almost direct point of interface from OpenGL. And that also means that you do not
have any advanced shaders or anything you have in a greater framework, so it would still
take some time until you will see really nice 3D games using WebGL. And genres that can't
be implemented now and for many years to come in my opinion are next-gen 3D games. So if
you want to see a new Final Fantasy on WebGL, it will take some time. So WebGL is simply
not as advanced as I want it to be. So we decided to do something different. We decided
to focus on 2D and 2.5D. So 2.5D is isometric projection and 2D obviously allows you to
build puzzles, adventure games, board games, card games, platformers, jump & runs, all
kinds of 2D games. And 2.5D allows you build any kind of 3D game, but I wouldn't build
shooters I guess and I wouldn't build a racing game, but then on the other hand, it's really
great for strategy games. It's really great for RPG's, turn based strategy, real time
strategy, and simulations, SimCity for instance. So there's really a lot of games you can handle
already using those two projections. So we choose really what we wanted to do and we
hired a designer and then figured out what kind of game do we really want to do. And
we choose this kind of game. So this is some proto time mash-ups, proto time screenshots
that looks like a game we wanted to build. So you see isometric projection. This is the
actual world and you see the interior of the homes of people, so it could be a kind of
social experience here. That's what we're imagining for prototype, right. So this is
the kind of game we wanted to build and that was a vision and then we need to--we figured
out what we need for that, right. So if you think about what are the requirements for
that game, you need stuff like free mouse panning, infinite real-time worlds, so I want
to have a connected world, animated characters, chat bubbles, collision detection, pathfinding,
walking into houses, mash-ups, sound effects, scalable viewports, and the list really is
longer than that. There is a lot of stuff you have to care about. So most of you might
say, "Okay this is awesome but it just sounds like the Duke," right? So, really, but, yes.
It sounds like the Duke and it will take forever if you try to develop a classic game engine,
but we're not trying to do that, we're trying to build an engine that is focused on the
web. So we're really optimizing for the web and I will show you what that means. So let's
actually get over to some code. Let's show you some of the techniques that we've found
out works for games. So first of all, rendering; rendering is the most important topic of all,
how do you render 2000 objects on to a map, right, 2000 houses or tiles or whatever. So
do you do that? How do you that? So that is speedy, right, so in our test, in our experiments,
we're trying to render 2000 elements in less than 50 milliseconds which is quite insane.
But that's what we wanted to achieve. And the most obvious idea was to use Canvas, so
yes, we'll obviously use Canvas and we tried that. We tried to use Canvas in render, but
the sad experience with Canvas really lead us to realize that Canvas is a lot slower
than HTML. So why is that? The Canvas image API is pretty inefficient because it first
needs to actually have a DOM representation of the image. So you have to first load it
in JavaScript. Have it load until the end and then render to the Canvas. So there's
a step in between and this makes rendering very inefficient and will take a long time
if you're playing with many graphics. So if you're working with a lot of graphics, canvas
is not your choice right now. If you want to do something that really is abstract, right,
and doesn't use lot of graphics, you might want to do canvas. But in our case, it was
way slower. So what can you do? What can you do with HTML? So first of all, block rendering.
What does block rendering mean? Block rendering means directly replace innerHTML with a huge
string instead of multiple DOM append actions. So this case is a huge performance boost because
that string of HTML you're constructing is directly parsed by the HTML engine, so the
HTML engine is parsing the content and displaying it which is a lot faster than going through
the dominant appending elements there. So it's really fast and reflow and repaint--two
things the browser is doing to display content are only occurring once. That's another big
advantage. So in a DOM operation, you're pending and you're doing the next step and you're
pending and all the time it needs to redraw first until it goes to the next step in most
cases. So--but then on the other hand, we have a huge disadvantage here. The huge disadvantage
is that you cannot reference individual nodes anymore. So if for instance, you're having
500 houses and you want to render into--render into a map, right, you have 500 houses and
then you want to pick out one of them and actually animate it, right. I'll display something
and I will do a click action on that one. There's no reference anymore to that house.
So how can you fix that? We fixed that using lazy node linking which is really fixing the
main disadvantage of the reference and after innerHTML has been set, you simply run a query
and this guy is using jQuery, so basically what it's doing is grabbing everything we
build right now, doing a list from it, and most the browsers have query selectors, so
this is really fast. It probably will take a millisecond or something. And now, you have
the collection of all elements that you just surrendered to the map. And since you know
the order of how you render it, you can reference back. So really, you just have to care about
the order of the rendering and then you can reference back to the actual elements. So
this is how you fix the referencing. So let's move to smart rendering. Smart rendering I
call something different. So, we have that first step and it's already pretty fast and
would probably take around 500 milliseconds still to render 2000 elements. Why is that?
So if you look at the code that gets rendered, right, here on the left--on the right, sorry.
This will be one of those elements. It has a position text, top text, all kinds of CSS
in there, margins, background images--so this is one block and you got to have to do that
2000 times, right. So you have a huge string constructed and--but this is really how most
people are doing it right now. So they're building this and style them via JavaScript
and directly on the style tag, render them through in innerHTML, and that's still kind
of slow, so we really want more. So what did we do? We realized that we kind of forgot
how to build websites. So the web method really is don't ignore the layout layers, so--especially
not external CSS. So, one thing you could do is actually keep the style tag very minimal
for it, only use some class names to actually hook them up to CSS classes which then define
background images and all those things. They're still--it sounds easier than it is because
those external slide sheets later on need to be rendered by the server in real time,
but really, this is fixing so much of your pain because this will render 10 times faster.
So I don't know why, but it seems the parses is really taking much longer time in constructing
bad use string and de-parsing it instead of external slide sheets. So that would be one
method. Also, what else have we mentioned? Everything then is rendered through the CSS
rule, right, including background, margin, padding, et cetera. So that was rendering,
how about delegation? So how do you actually make sure that someone can click on a house?
So first of all event delegation. How many of you have heard about event delegation already?
Some hands? Okay, a few. Event delegation is a technique to forward events to implicit
listeners, so. In web development, that usually means the following; build an--bind an event
to the root Node so to the body type for instance, except for the actual child element, for instance.
If you want to click on a link tag on an A tag and you want to bond a click event to
it. You would usually bind it to the A tag directly, but in this case you bind it to
the root Node and then fill out in the code what kind of Nodes you clicked on. So this
is event delegation, which means if another--if you actually replace that link later on and
bring another one in again, it still works because it's not really bound on the actual
Node it's bound on the top Node and then references back. So the move, the processing efforts
and that's also very interesting really moves from--when the event happens, sorry, to the
event happens. So, usually it takes a long time to initialize all kinds of events, but
what this means is you only initialize an event once and then when the event happens,
the processing is used to calculate, is this what I want to click on? So it really helps
on speeding up your applications. So for us that means we realized we only really need
three events and that are bound on our prototypes. So the one event is mouse move which handles
positioning--position detection and dragging. The other event is mouse down which also handles
drag start and clicking. And then there's mouse up which also handles drag stop and
clicking as well. So those are the kind of events that we're using and we're only binding
them once to the document. And so, cool we have events bound and we can click on houses
now in theory. But, what we also realized, if you see that house here right now, this
is APNG that has some transparency in it. And obviously all these elements are rectangular.
So if the user actually clicks on the left top corner, it will actually still trigger
the click on that house. But, he didn't click on that house graphically so that's not what
we wanted. So what we figured out this kind of sucks and we really want it to match the
user's intent. So, you really need to be creative about that. We choose not to use canvas but,
what we did now, we build click through maps. So what I mean using click, by click through
maps means I build up in pixel map for each of those PNGs and objects that tell us where
the transparent pixels are. And then in the event delegation, I'm filtering those transparent
pixels out so that means if you click on a house and you click on a transparent pixel,
it will not execute that click and this fixes our issue which is really nice. However, building
up those pixel maps is a huge pain because it really is not fun if you want to do it
manually, right? You have to seriously find out all the pixel positions and get them into
a map. So this is really not very effective. So we've realized we can have canvas do it.
So, what we're doing is canvas can actually read the pixel data and from images and then
we can check if our pixel is in fact transparent and save this to a false value into a new
optimized smaller array and that array is build up on real time every time the engine
is loading for any kinds of graphics. So it just works. And this is really the only code
you need for building such a pixel map which is quite efficient. So that's how you match
the click's--the click's intent. A different one; this is actually one I haven't talked
about yet at any of the conferences and any of the talks. It's brand new and we're still
working on it. It's called action surfaces. So, this is something you can do in the web,
but not anywhere else. Action surfaces really mean it's basically a droppable for widgets
or other objects. So if you see the TV here, the black interior of the TV will be the action
surface and the action surface is transformed to isometric projection in real time using
CSS transforms. And that really is cool because it allows you, for instance, to drag, click
your pictures to your action surfaces and those pictures is transformed in real time
to that isometric perspective. And to really show you how it works, I'm going to show you
one quick example in a bit. So this is the code actually that gives you all you need
basically in CSS. So you did define rules in CSS for isometric angles and those tools
transform your elements to isometric. And to have a proof that this is working, in fact,
I made a quick test. Let me quickly switch. So, here we go, this is a simple test to show
you those classes are actually working. So, we got the newest Google logo here, and this
is just a disc with the background image and I can basically append those classes and they
rotate to isometric projection. So, using those, I could build up a simple queue for
instance. So, this really works and it works quite well and it's quite speedy. And let's
see--if you bring this--okay, I'm not going to--but I'm going to show you later on if
you want to. If you bring this to a certain extent, you can build great action surfaces.
So this is action surfaces and I'm going to show you live what it means in a bit. Next
topic, this was all about the front end, but let's talk a little bit about the backend.
I mentioned already we're using JavaScript in the server as well. So why is that? First
of all, why do we use JavaScript? JavaScript really minimize to think, it's really painful
enough already right? If you're working in the backend, you might have that opinion.
Now you want me to work with that in the backend as well and many gave us some very puzzled
faces. But, seriously, why JavaScript? A single scripting language is so efficient per project.
So if you have a single language you're working on it, all your developers are working on,
it makes developing so efficient because you can check code in the back and the front end,
and distribute it to any people and everyone understands what's going on on any site which
is huge to me. And, well, in my opinion also JavaScript is awesome. It's just very a misinterpreted
language and I really hope people would think about it in a different way in the future.
So there's one interesting project we're using, it's called Node.js, it's a JavaScript runtime.
So I'm going to really quickly show you what it means. First of all, JavaScript in the
browser looks like this, right. Many just don't want to work on this server because
they really are afraid that it will hack down the server. But, and that fear, I know where
it's coming from. It's coming from the browser because if you look at JavaScript with a browser
the car is JavaScript obviously and everything around the car is overhead added to it. So
in the browser environment, you have the rendering, you have the DOM, everything--you have timers
all that really slows down JavaScript. But if you really look at JavaScript running without
all those layers on top it kind of looks like this, all right? This is JavaScript in the
backend. JavaScript in the backend is almost as fast as C which is quite significant. So,
really there's a huge performance increase if you work in the backend. And, also, obviously,
you don't have to mess around with cross browser implications. So you only write using one
engine. It really speeds up your coding. So, Nodes features, it's Google V8 running on
the server in the scripting runtime. It is server and scripting in one kind of process
and it comes with some sugar on top. Pretty modules for system service, et cetera and
everything and that's a key fact. Everything is non-blocking in Node. So Node is completely
event driven. File system calls et cetera on non-blocking and I'm going to show you
what this means. Then since its using V8, it's using EcmaScript 5 as well, so you got
some nice sugar on top as well. So for the modules, it's using the CommonJS module system.
It's very handy for organizing code and there's really no way around it and Node.js, without
modules, there's no use for that. Some common modules: sys, file system, http for creating
your server, and process. So EcmaScript 5 already gives you some nice features as well.
Getters, setters some array extensions for each reduced filter and especially JSON support
is really nice. So you got JSON.stringify, JSON.parse and what's the great innovation
about Node anyway? We had RENO before which was a different interface, but Node really
is different. Node is completely event driven. So, for instance, in a normal environment,
if you're program in PHP for instance you're doing a call to a database and then you're
waiting--in the next line, you're waiting until that call is actually finished and then
progress, so it's in a linear fashion. It has some advantages because it's easier to
understand, easier to grasp. When that call, when that line is finished, move on to the
next one. Node is completely different. Node is event driven. So, if you do a database
query, you need to have your query and then for everything you need a call back. So in
that call back, that call back will be executed once your database is ready. And the next
line would be executed immediately, so it's not waiting for your call at all. And if you
look at center code, right? That is running on Node, you have to take this with a grain
of salt because those are early versions but, this is just one of the images I found in
the World Wide Web that really shows how Node is doing. It's doing quite fine. So this is--those
are the requests on the Y-axis, there are requests in 10 seconds, and Node really is
at the top and the congruency isn't bad as well. So, those are the request per second.
So really, Node scales really well and you don't have to fear about any of those JavaScript
mess you have in the browser. But then I also have to tell you that node.js is pretty new,
the API's not frozen yet, and it's really only for adventurous people but everyone who
is building games in the web right now is adventurous already. So the benefits of using
it completely make up for the risks. Okay, what does non-blocking really mean? Non-blocking
also--not only means event driven codes, it also meant--means the server is not threaded
because you cannot thread v8 actually. You do not have multiple processes and it can
serve and handle a lot more requests at a time because it does that. Because it needs
a lot less memory than for instance Apache. So that's really one big advantage. If you
look at the IO/API--I mentioned already accessing external data is always non-blocking, so you
really got that right. [INDISTINCT], it's really hard to stop node from functioning
so it's very efficient to write event driven code. So why do we need that for a game? Obviously,
if we want to build a game that handles, thousands and thousands of players possibly millions
of players, this is really the kind of environment we need. We need event driven environments.
We can build a game that has many hundreds of thousands players on one server using PHP,
it's just not going to happen. So this is--I explained that already. So just very quickly.
So look at the hello world example on node.js. I'm not going to go into this much but this
is really very easy hello world example, you create your server and this server is taking
in requests and you execute any kind of code you want and send back the answers so there
is no need for patch in, no need for second server, it's really just this one time--run
time and it will do everything you need. So finally and this is a very strong message
that I want to give you, finally get rid of limitations. And what I mean by limitations,
get rid of limitations in your hat. So what I also mean about that is do not copy, if
you're looking at the games right now. So, first of all, console games are displayed
full screen on your T.V. This is a no-brainer right; if you put a console game in your console,
it stretches the full screen always, right? How about the browser games, if you look at
browser games, this is one browser game from Germany; Grepolis, very small viewport, right?
It's not full screen at all. Second game--you might realize all those games kind of look
similar. This is from a different company entirely, it looks the same. Next game, Harbor
Hotel, some of you might noticed, Harbor Hotel also has a pretty small viewport, and see
even use some flash. Farmville--Farmville is not stretching to the browser window. Farmville
is not an immersive experience at all, as well. So, think about MMOGs in browsers. Almost
all games are limited to a couple of thousand players per world instance. And what we really
want--we want stretching viewports. We want multiplayer, real multiplayer. Worlds with
millions of players, so no technical fragmentation between words, and more characters than just
20 in a room on a single viewport. This was really--like that's what I mean by getting
rid of your limitations--not just because everyone else is doing small viewports there's
really no reason why you have to. And there is really no reason, and I want to prove that
there's no reason. And this is really how a--test that we did looks like. So we're testing
sometimes on code HD resolutions. This is an early prototype of the engine we are writing.
And as you can see it's a 27 inch iMac which has a bigger significant resolution already
and stretching to a complete viewport and it's really running fast. So, let me show
you what we have been building. So obviously this first part was about how it--how you
build stuff but obviously we have build some stuff and I want to show you. Meet the Aves
Engine. The Aves engine is a professional game engine for the web. It is commercially
licensable. And it's cross-platform, so yes, it works on smartphones. It works on android
hopefully. It works on iPhone and iPad and it comes with all mentioned features and a
lot more. Currently in Alpha so we don't have anything to sell. And I just want to show
you because it's quite cool in my opinion. So, demo time. Here you go. So this is our
new prototype of the Aves Engine. Let's just turn the speaker, I guess. Here we go. So
this is the prototype that we've built. You might have seen this in one of the earliest
slides. It allows you to pan on real time and its loading new patches. The patch loading
kinds of works, like Google Maps. For anything who--for anyone who works on Google Maps or
have worked on Google Maps--so it uses a patch mechanism, all those objects are referencing
in real time so you have those click-through maps going on. As you can see I can drag around
that object, and you can hover it right. So, this is my character and that character can
walk around. You have sprite animations going on here. Path finding--I mentioned, so if
I want to walk across the street--it's actually walking and following rules. So, it allows
you to chat as well. And we have been doing quite a lot of performance test as well, so
right now I'm pretty lonely in this world. But let's add some players right. So, we'll
going to add some hundred players to the map--and you probably can see him walking a bit and
chatting. So, those are hundred players launch the world right now. And still scales very
well. Because it is using a standard slide sheets for everything and it's using all those
techniques that I explained before. So, let's see. Let's actually switch a word instance
so you can move into houses, and switch the entire resolution so, we launched the house,
as you can see our character is bigger. We can switch our character as well so a--see
gets our main character going, and those are the load--those are the surfaces that I was
talking about. There is no wireless available right now, here. At least I didn't turn it
on but you can get the idea here. So this is a surface that is using CSS transforms
and the basic get some surface window and you can drag those widgets to the surfaces
and they transform and drop, and basically you can drop them anywhere where surface is.
So, this is really the kind of vision we're having and our first--our second prototype
that we will also showoff in the next couple of days. Anything I missed--I guess, what
I can also show you, and really if you want to start building your own game engine, 20%
I guess is what you see right now, 80% are the editors, so that means admin interfaces
all that. So we also built some quite nice admin interfaces for Word. You can see them
here. So you can a--you have a tile editor, you can grab some objects, and allowing to
model editor and then add surfaces to it, drag it around and it will also synchronize
in real time in the Word. So, here you go. This is the kind of things we have been building.
So, I guess we're almost finished. Thank you very much for your attention. There's more
[INDISTINCT] and also, in our blogs. We are writing a lot about our technical stuff and
we have a lot of demos using CSS transforms and CSS animations. There's a lot of interesting
things to check out. Follow me in Twitter if you want to, and also, if you do have any
contexts to share with us, we are currently--currently touring California. So, if you have any context
you want to share in the game industry and the PC industry contact us. And I'm really
hoping to see people building games, not only with our engine but if you do something your
own that's perfectly fine and I want to see competition. Thank you very much. Yes and
now we have room for questions. >> Yes, can you tell me a little bit about
what you're doing for audio? >> For audio, that's a very good question.
So we haven't done audio yet in the prototype. We have been playing around with it, and we're
using HTML5 audio. However it's quite buggy still in the most browser, so I hope we will
change in the next couple of months. So we're using HTML5 audio. This has some problems,
for instance, you cannot run HTML5 audio on the iPhone right now. I'm not sure about Andriod,
but it's very hard to start audio in the background in most browsers right now. So, yeah, we haven't
done it yet. Any other questions? >> Sorry, so is this engine kind of geared
towards building these type of isometric games or is it flexible enough to do platforms or?
>> It's really flexible--so, as I mentioned this is just a prototype, right? So--we really
haven't finish the engine yet, and it's just showing one aspect of the engine but yes the
engine is meant to--also allow to build platforms, jump and run games, all kinds of games. All
kinds of games that you had on that list before so 2D and 2.5D. And we simply choose isometry
because it is kind of cool prototype. Yes. Quite a good experience and it's really the
most difficult experience to build so this is why we choose it. So any other questions?
>> How much of a performance difference do you see in different browsers especially mobile
browsers? >> There's a huge performance difference--in
mobile browsers you mean? >> Mostly, yeah.
>> So, if you look at desktop and mobile browsers there's a huge difference already but then
there's just really many kind of quirks you're realizing with--when working with multiple
Smartphones. For instance, we've been working with iPhone and iPad and we figured out that--so
our prototype works really for all [INDISTINCT] on iPhone 3GS and that's really nice. It's
also working on 3G not as fast as 3GS but it's kind of working. However we had huge
issues to get it running on the iPad because the iPad itself is almost as fast as the--it's
a bit faster than the 3GS; however it has a lot--much larger viewport. So the viewport
is much larger which means you need a lot more processing to display full screen. So,
obviously we could leave it as the--at the iPhone resolution bell as I mentioned, this
is really not what we want to do so we had to optimize specifically for all kinds of
mobile platforms, and used techniques for instance CSS transforms and CSS animations.
A hardware accelerated on iPhone, and I think pretty sure--pretty soon on Android as well,
I'm not sure yet but I'm, you have to use features that are hardware accelerated. Anyone
else? All right then, thanks again and have a great day.