
Unreal Engine in JavaScript/HTML5 – Citadel demo - AaronMT
http://www.unrealengine.com/html5/
======
jfaucett
I love the fact that Mozilla keeps pushing javascript to its limits. They seem
to be doing a lot of things really well lately, this is awesome!! Plus you
have Firefox OS, which pushes web-standards to native mobile. Now I just wish
the devtools would get up to paar with those on chrome/chromium and I'd be
switching back to FF in a heartbeat.

I wish google would stay on board with JS since they have the engineering
power to do a lot in this area, but to me it seems after V8 they've kind of
abbonned JS in favor of Dart (As oppossed to supporting asm.js). For instance,
I just did the "try anyway" in chrome 26.0 linux and everything crashed. Did
anyone get it working in chrome?

~~~
eslaught
From the FAQ:

    
    
        - Chrome currently crashes, but is expected to be resolved by the Chrome team soon.
    

<http://www.unrealengine.com/html5_faq/>

~~~
tomwalker
I wish I had read that first :/

Crashed my whole system

Chromium 25.0.1364.160 Ubuntu 12.04

~~~
laumars
How? Couldn't you even drop to another TTY and kill the process?

~~~
OGC
I'd bet money OP didn't even try or doesnt know how to do that.

~~~
laumars
This is what I thought to.

I've never once had an application in Linux crash the whole OS - or at least
not so long as I've had physical access to the machine (I've had rouge
database requests brick a server before because it took down sshd - but that's
a different story)

In fact on the laptop I'm on now, the parent link crashed Firefox. But it
OOM'ed and got killed before I even noticed there was a problem (and that's on
a beefy desktop environment with compositing enabled too)

~~~
nkozyra
You should tell your database to go easy on the rouge - a _lady_ keeps it
subtle.

------
MatthewPhillips
This is so awesome that I never want to see another WebGL demo again. This one
proves it; you can make awesome games in WebGL. From now on I only want to
read about non-demo WebGL games that are in development with a real release
date.

~~~
Rinum
The biggest issue I see is with distribution.

For example:

I'm not a fan of DRM, but there's nothing preventing anyone from downloading
the game and selling/giving away copies with ease.

~~~
mtgx
I hate how DRM is being thrown around as a "turn-key" solution against piracy,
because it's simply wrong. What's stopping anyone from selling copies of
heavily DRM'ed - but cracked - games right now? Nothing.

Actually, WebGL games would be a lot more secure from piracy, because they
would be online, and you could easily stop 99% of the piracy by requiring a
login for the game. It's basically like the Diablo 3 model, only better.
Because Diablo 3 should be easier to crack and play on private servers (not
sure if even that has happened yet).

Making an "online game" instead of a native "PC game" is the best way to stop
most of the piracy.

~~~
Strom
Diablo 3 is definitely not easier to crack. You need to know x86 assembly, and
on top of that beat Blizzard's reflection-ish protection that checks for
modified code. JavaScript is much easier to deal with.

In addition to that, just cracking the Diablo 3 client isn't enough, because a
lot of the game logic runs exclusively on the server. For example, even with
tens of thousands of test runs of a specific monster, you still won't know the
correct item drop probability table, because that table is never sent to the
client. Only the result of the server-side dice roll checked against the
server-side loot table.

~~~
__--__
>Diablo 3 is definitely not easier to crack.

Moot point. Any client software can and will be cracked, regardless of how
difficult it is to crack. Which is mtgx's point - online games are easier to
secure because you can put logic and validation on a remote server. No DRM
needed. Your example of Diablo 3 only proves his point. It's not the DRM that
makes Diablo 3 hard to crack - it's the server side logic and validation.

------
asperous
If you aren't on firefox, you can enjoy the same demo in flash.

<http://www.unrealengine.com/flash/>

~~~
Oxxide
thanks for this.

------
matthew-wegner
This is actually very old demo ported to the browser. The original Epic
Citadel was/is an iOS demo released in September 2010. It runs well on an
original iPad: <http://en.wikipedia.org/wiki/Epic_Citadel>

Comparatively, this runs a little sluggishly on a MacBookPro8,2 (early 2011).

~~~
yottabyte47
"very old"

~~~
matthew-wegner
Heh, sure. But it was a demo for the _original_ iPad, which is easily a
quarter of the performance of current iOS devices.

~~~
ricardobeat
Dude. (sorry)

This is Unreal Engine, with physics, cloth simulation, particles, light &
glare effects. It's not C++ on Native Client or a plugin, it's _running in
javascript_. Just yesterday you couldn't draw a circle on a 2d canvas at
30fps.

~~~
matthew-wegner
It's probably a subset of the Unreal Engine.

And it only works in Firefox, and even then only very well in Firefox Nightly.

Those points aside, though, this _is_ pretty amazing. I fully expect multiple
engines to target HTML5 in the same way Unity/Unreal/etc were cross-compiling
for the Flash runtime. It's just not quite there yet...

(And it's good that demos like this exist to put pressure on browsers to fully
support them).

~~~
BrendanEich
No, not a subset. It's UE3 cross-compiled by Emscripten from ~1MLOC of primary
C++ source. Some configury to use OpenAL (mapped to WebAudio), and of course
OpenGL-ES (mapped to WebGL).

/be

~~~
Arelius
It's really not. It's the UE3 Mobile Engine. Which while it's compiled from
the same C++ source, It has enough things stripped during compilation to not
really be considered 'full UE3' custom shaders for instance are not supported.

And atop of missing some things from UE3, Citadel is designed specifically for
limited devices.

While still a very impressive feat, let's not confuse this with running GoW or
The Samaritan demo in the browser.

~~~
azakai
As mentioned in other comments, we also ran other UE3 games, like Sanctuary.
We demoed that in a booth at GDC last month where people could play it. That's
a full UE3 desktop game with bots, AI, normal FPS mouse control (not tablet-
like), etc. etc. You can see it in action in the 2nd half of this video

[http://www.youtube.com/watch?v=BV32Cs_CMqo&feature=youtu...](http://www.youtube.com/watch?v=BV32Cs_CMqo&feature=youtu.be)

And it's using the _exact_ same code as this demo. You literally use the same
compiled JS, and just swap in a different set of game assets.

~~~
Arelius
If so, something like that would be a much more impressive demo. Citadel just
frankly isn't that impressive.

------
vrodic
Not directly related, but highly relevant: IE seems to be getting WebGL
support: [http://www.theverge.com/2013/3/30/4165204/microsoft-
bringing...](http://www.theverge.com/2013/3/30/4165204/microsoft-bringing-
webgl-support-internet-explorer-11-windows-blue)

------
ineedtosleep
Ran this on a laptop on Firefox 20 (stable) with Bumblebee and it's
surprisingly impressive and smooth.

I have a gaming desktop at home that runs all new games at 50+ FPS, but for
some reason looking at graphics that a late-era PS2/early PS3 game would have
_in a browser_ is more impressive than running a game like Crysis 3 for the
first time.

------
an_honest_idea
What's the point of having these massive javascript virtual machines & webgl
systems in our browsers? How does having a separate implementation of a
specification help us build a safer, more open web?

My theory is that Mozilla and Google are in a race to develop the most
advanced html5 engines because they know that if a killer html game or app
gets developed in their browser, everyone who wants to use the app will switch
to them while the other implementations tries to catch up.

It will also prevent new browsers from trying to pop up, unless they simply
fork and try to keep up with one of the two major engines. Google and Mozilla
know they can outpace any competitors that are trying to innovate in the web
space by having the "latest" html5 features integrated. In example, unless
Microsoft pours a bunch of money into it, or Internet Explorer forks Mozilla
or Google, they can pretty much count that competitor out.

Is this supporting an open web?

What's the problem with focusing on open source plugin virtual machines that
can work in every browser regardless of that browser's version?

~~~
ndesaulniers
> What's the point of having these massive javascript virtual machines & webgl
> systems in our browsers?

Because the safety model of JavaScript has been sound for the past few years.

> How does having a separate implementation of a specification help us build a
> safer, more open web?

What seperate implementation of what specification? If you're referring to
asm.js, asm.js is just JavaScript, any browser can run it. The "specification"
is a gift to other engine implementers to super charge evaluation of compliant
code.

> Is this supporting an open web?

<http://asmjs.org/spec/latest/>
<http://code.google.com/p/v8/issues/detail?id=2599>

------
tfb
This ran surprisingly well on my 3+ year old Asus laptop with integrated
graphics. By surprisingly well, I mean I doubt I ever got over 30 fps
(probably 15 fps on average) but there were little to no hitches when loading
new areas.

I wouldn't be able to play a fast paced shooter like this, but I could see it
being more than tolerable for playing a slow paced role playing game or
something in the browser, with the added ease of connecting with other
players, possibly MMORPG-style.

On a side note, it'd be nice to make it capture the mouse instead of having to
drag it.

------
fosap
Controlling the spectator is remarkably bad. I hope this is not how i am
supposed to play video games. Even Dead Space 1 is better, and that was so bad
i could not stand it for more than 30 minutes.

~~~
TazeTSchnitzel
Well, unusually, this demo isn't using the Pointer Lock API to do normal FPS-
style controls. It's fully possible to do them, but this demo doesn't for some
reason.

~~~
wlesieutre
It's using the control system from the iOS version, which is what Epic Citadel
was originally a demo for.

~~~
TazeTSchnitzel
I noticed that. It makes sense, since iOS is an OpenGL ES platform and WebGL
implements OpenGL ES.

~~~
kevincoughlin
For what it's worth, I was able to navigate fine using WASD and the arrow keys
on my laptop

------
skore
The "Compiling Javascript" loader takes _way_ too long (at least on my system)
to not give any indication as to how long I will wait or whether it's still
doing anything. At least a "this might take up to X minutes".

Demo itself ran halfway ok, clicking on 'Benchmark' (which I had to guess was
in the upper pulldown) immediately froze everything for me (Firefox on
Kubuntu).

Still: I do appreciate a demo that even kinda-sorta works on gnu/linux.

~~~
azakai
> The "Compiling Javascript" loader takes way too long (at least on my system)

It is actually both downloading and compiling during that time, and probably
spending far more time in the download.

It would be nicer if the text said "retrieving code" as opposed to "compiling
code" at that point.

edit: looks like the demo site was just updated, the message is better now :)

------
frakkingcylons
I just want to emphasize for Chromium users that if you try to run this, it
might crash, and crash hard. I had to reboot my system.

------
kirbyk
I actually just installed Firefox for that. Totally worth it.

------
kalleboo
What continues to impress me about these demos is that JavaScript has gone
from "not useful for much more than form validation" to "can compile and
execute a 52 MB block of what's basically assembly code".

52 MB of JavaScript is... a lot (even if half of it looks like data tables of
some kind)

------
dombili
I'm on a pretty old laptop and this runs extremely well on Windows 7 (using
Nightly). I also tried it on Xubuntu 13.04, but I couldn't get it to run (I
tried it on Chromium and Firefox).

As for the demo, I'm stunned. It's incredible.

~~~
theon144
I'm on a pretty new (if a bit budget) desktop, and during the benchmark I had
the FPS drop to 16 during the flythrough of the streets :\

Still, it's pretty amazing.

------
drawkbox
Definitely awesome, still a while before this is usable in the market (across
many browsers) and load times seem longer than Unity/Flash. I can't wait until
browser support of emscripten/asm.js is better.

------
hpaavola
Some stats from the benchmark running Windows 8 and Ubuntu 13.04 on Asus
Zenbook UX21A (Intel HD Graphics 4000, Intel Core i7 3517U, 1920x1080):

    
    
        OS            Browser      Avg. FPS    Min FPS
        Win8          Fx 20        26          16
        Win8          Fx Nightly   46          34
        Ubuntu 13.04  Fx 20        17          16
    

For me those numbers tell that if ams.js does not catch on in other browsers,
browse based games just will not fly. Also, graphics drivers on Linux still
suck and that's why I still need to double boot.

------
snarfy
It doesn't work for me. I downloaded Nightly using the provided link, but when
I open the URL it still says unsupported browser. It also doesn't have the
option to 'try anyway' like Chrome does.

~~~
TazeTSchnitzel
Upgrade your graphics drivers.

------
alexvr
I'm impressed. But I wish they modeled the citadel after Hogwarts.

------
polutre
On Firefox 20 on Windows on my 2500k with a 7970 it seems CPU bound and can
only achieve 43fps benchmark at 1920x1200, while having some clear artifacts
from lack/too little texture anisotropy on the floor and antialiasing issues.

Also, the textures are not fully detailed when looking directly at the floor
and walls.

If this is supposed to be a full quality benchmark (ala Unigine Heaven when it
came out), it needs to improve.

~~~
Offler
FF 20 does lack the asm.js integration.

~~~
arbult
Firefox Nightly is indeed much better CPU-wise, keeping 60fps with around 80%
single core usage at most.

However, it still has poor graphics, with low quality textures,
low/nonexisting anistropic filtering and no AA or bad AA.

Also just noticed that stuff like bracers that should be rounded (using GL 4
hardware tessellation) is not and has visible polygonal edges.

Not really a great showing as a demo.

~~~
asadotzler
You got a better demo that runs in a web browser without plug-ins?

------
rikacomet
Not working on chrome? UNREAL!

------
grayrest
Dear lazyweb,

Is anybody able to get it running on android? The nightly has both asm and
webgl but is showing up as unsupported (and not just doing UA sniffing).

~~~
grayrest
I asked via twitter:

<https://twitter.com/vvuk/status/330119715546624000>

    
    
        some known bugs that cause us to use way too much transient memory while loading. Fixes incoming.

------
oddshocks
Aw yea that was so cool! It slowed down my box to a dying crawl and then asked
to store a bunch of data on my local machine! Nice!

~~~
Oxxide
try the flash version. it's pretty goddamn awesome.

------
tjbiddle
Very impressive. As an FYI - You don't need to click on the screen; ASDW for
movement and arrow keys for screen rotation works.

------
shawndumas
I love the "try anyway" option!

~~~
dguaraglia
Doesn't work on latest stable Chrome on OS X though :(

------
WalterSear
That crashed firefox on my macbook pro even faster than I thought it would.

------
dreen
This is awesome! I wished I could run cause its slow to walk around but then I
discovered you can alt-tab to another window and keep the event for W active

~~~
dreen
OK, just discovered you can double click for the dude to walk over there too
;p

edit: although there is no path finding

------
jayarcanum
Why do you even need this engine when the beautiful physics of the Quake 3
engine already have roots in HTML5? You do not, that's the answer.

------
jebblue
Although I'm not a fan of programming in JS, this is pretty darn cool, got 19
FPS on Ubuntu 12.04 with regular FF from the repo.

~~~
ahoge
It's written in C++.

~~~
ndesaulniers
Over a million lines of it!

------
just2n
I take issue with calling this JavaScript/HTML5. This is powered by asm.js.
The source is emphatically NOT JavaScript, it's a subset that's meant to be a
target for compilation (like a bytecode in .NET and the JVM) and is treated
entirely differently from JavaScript by the JIT. We don't call everything that
runs on .NET C# nor everything that runs on the JVM Java.

Additionally, asm.js is not part of HTML5. It's interesting, and this demo is
cool, but it's not JavaScript/HTML5.

~~~
elisee
Even though it's using JavaScript as a kind of bytecode, it _is_ just
JavaScript / HTML5 (and some CSS, but that's pretty anedoctical I guess).
Asm.js is a subset of JavaScript. As soon as Chrome fixes the crash, it'll run
in a browser that supports just HTML5 (for presenting the page / the DOM / the
canvas) and JavaScript with no special asm.js optimizations, and we'll have to
see how fast/slow it is then.

To correct your analogy: it'd be like using a subset of C# as the bytecode
rather than a language. It's still actual C#, it's not just .NET bytecode, but
it's being used differently.

~~~
just2n
I understand that. Take a read of this: <http://mrale.ph/blog/2013/03/28/why-
asmjs-bothers-me.html>.

I have a lot of respect for Egorov, and I agree with his views on this matter
quite entirely.

The sole benefit of embedding a bytecode in a language is that you get the
side effect that it can run anywhere that language runs. But in general, this
implies performance penalties, especially when the language is relatively slow
to begin with.

But in this case, this demo is made usable (ie: the impressive part) by
writing a compiler specifically for the bytecode itself. So it works well in
spite of the fact that it's a bytecode embedded in JS, not because of it. The
really cool things about this demo are precisely 2 things:

1\. asm.js makes running C++ code that would render to OpenGL in the browser a
possibility, and with relatively good performance. Kudos to Mozilla.

2\. It runs on browsers that don't know about asm.js, but it's effectively an
emulated machine, and it's slow.

I just take issue with calling this an example of what JavaScript/HTML5 can
do. I think seeing an application written in JS using WebGL or Canvas as
something much more impressive, and there are Q3 renderers that are natively
JS that run with amazing performance in the browser. This is just dressing up
the fact that turing completeness is a thing and calling attention to it. The
real thing to get from this demo is that there are enormous benefits to having
a bytecode for the web over trying to optimize a fully dynamic language like
JS. I feel like that is relatively lost by the title.

~~~
azakai
> 1\. asm.js makes running C++ code that would render to OpenGL in the browser
> a possibility, and with relatively good performance. Kudos to Mozilla.

> 2\. It runs on browsers that don't know about asm.js, but it's effectively
> an emulated machine, and it's slow.

Do you have benchmark numbers to support that? In my experience, asm.js code
is quite fast even without special asm.js optimizations. It depends on the
benchmark obviously, but look at

<http://kripken.github.io/mloc_emscripten_talk/#/27>

Many of those benchmarks are very fast in browsers without special asm.js
optimizations.

All they need to do to be fast on asm.js code is to optimize typed array
operations and basic math, and those are things browsers have been doing for a
long time. Google even added a Mandreel benchmark to Octane for this reason.

Emscripten and Mandreel output, with or without asm.js, tends to be quite
fast, generally faster than handwritten code. asm.js is often faster than
that, because it's easier to optimize, even without special optimizations for
it. Those special optimizations can help even more, but they are not necessary
for it to run, nor are things "slow/emulated" without them.

~~~
Hnefi
That link is misleading in the context you present it. Those are
microbenchmarks, which a JIT can optimize relatively well. But if you look at
the very next slide at <http://kripken.github.io/mloc_emscripten_talk/#/28>
you will see that for a larger application, non-optimized asm.js performs
abysmally, as does JS in general. A performance penalty of ~1000% of native is
what you should expect for a nontrivial JS application, and asm.js does not do
much (if anything) to alleviate that unless you run odinmonkey.

~~~
azakai
I was purposefully linking to that slide + the one after it.

Yes, there is a factor of around 4x slowdown between asm.js optimizations and
without them, on the next slide. But even 4x slower than asm.js is quite fast,
it's enough to run the Epic Citadel demo for example (try it on a version of
firefox without those optimizations, like stable release - as others reported
in comments, it runs ok). A lot of the work in Epic Citadel is on the GPU
anyhow, say it's about half, so the difference is then only something like 2x.

2x is not that much, we have similar differences on the web anyhow because of
CPU differences, JIT differences, etc. That's within the expected range of
variance.

Also, asm.js code is faster even without special optimizations compared to
handwritten JS (see for example
[http://blog.j15r.com/blog/2011/12/15/Box2D_as_a_Measure_of_R...](http://blog.j15r.com/blog/2011/12/15/Box2D_as_a_Measure_of_Runtime_Performance)
and <http://blog.j15r.com/blog/2013/04/25/Box2d_Revisited> ). So even without
those optimizations it is worthwhile.

~~~
just2n
It's faster than "handwritten JS" because it's using a subset of JS that's
already tuned to near the peak level of performance that you can achieve in
JITting JS, which is tightly looped arithmetic with everything inlined working
on SMIs. In V8, that's ~2.5x slower than the equivalent C code with
optimizations. That's basically best case.

The problem is that it's still dynamic, and at any point a null can come along
and force you to throw away a JITted function, so you have to have these
checks everywhere just in case. Further, ECMA compliance does not require JIT
compilation, which means to expect performance, especially on the web, is
dubious at best. I can see merit to expecting performance metrics in something
like Node.JS since it assumes V8, but the web does not have 1 JS engine, and
the standard does not require such performance metrics.

The "benefits" of building a bytecode in that's represented in some subset of
JS are essentially red herrings since they're effectively lies and the
downsides are a lot more significant, IMO. Instead, we should be focusing on
actually building a bytecode for the web such that all implementations are
expected to have certain performance metrics.

------
Bryan22
I was really impressed by this, but is it actually a game, or just walk around
and check out this cool thing we made?

------
Esarahs
Runescape got a full MMORPG running in HTML5. They currently have a beta for
several players also.

------
oftenwrong
Very cool. Unfortunately my firefox segfaulted about 10 minutes into my
exploration. FF nightly 23.

------
martin_
I wonder why they're using jQuery 1.5.2, which is nearly 2 years old?

~~~
path411
Doesn't really matter for the demo. The demo is just all native. You don't
really need jQuery when working with canvas.

------
ep103
Where is the source? I would love to learn how they did this

------
chenster
It won't load. It stucks infinitely at "Loading Data...".

------
CamperBob2
Looks OK, can't even begin to get used to the controls.

------
sprayk
Looks cool, but crashed X w/ opensource radeon drivers.

------
whiddershins
Absolutely awesome.

------
crankycoder1975
we need Louis CK here: "You're in a BROWSER!"

------
cowls
This crashed my i7 windows machine :\

------
CmonNoReg
So it basically means that C++ got another reasonable compilation target. Not
much to do with applying JavaScript to large-scale games. Also it is not HTML
5, it is HTML FF23.

~~~
ndesaulniers
Factually, all code emitted from emscripten is JavaScript. It may look funny
with all the bitwise operators that are barely ever used by web developers,
but it's just JavaScript. It doesn't run correctly in Chrome right now because
they have issues with their JavaScript environment not supporting large
numbers of variables for a given context. It doesn't run in IE because IE
doesn't support webGL. Both of these will be fixed in the future.

