(man) Thomas Palef.

[APPLAUSE] Hi, everyone.

Well, that's a lot of people.

So thanks for having me.

I'm really excited to be here.

So this is going to be a short talk where I'll explain to you how you can start to make your own video games.

But first, let me quickly introduce myself.

I'm Thomas Palef, and I'm currently working full time on the website called lessmilk.com.

It's a website that I created about 10 months ago to teach myself how to make games.

It was a fun project, a side project.

So I started by challenging myself to make one new game every week.

And that was quite challenging because I had basically no experience making a game at that time.

But it ended up working very well.

I made 12 games in 12 weeks.

I got a lot of people interested in my project.

I got a lot of visitors, people looking for what my next games, asking me questions, interviews, looking for tutorials.

I even got invited to conferences, like today.

So amazing experience.

And I also managed to learn how to make games.

Later, I started writing an ebook called "Discover Phaser."

So Phaser is the name of the technology I used to make my games.

So you can make games playable in any browser in HTML5 and JavaScript using Phaser.

So I wrote a book about that.

And more recently, I've been toying with Unity.

So Unity is another game engine focused on making native apps.

So you can download games on your smartphone or on your computer, which is quite interesting.

So yeah, I'm really into games as you can see.

And so all of this is available on my website.

You can learn more over there.

So let's get started.

Why make games? Why does it matter? Why should you care about making games? It turns out that a lot of developers are also gamers.

I am a developer, and I enjoy playing games on my smartphone, my computer, my Nintendo DS, and so on.

Playing games is fun.

It's really exciting.

And making your own games is even better.

Think about it.

You just pick any random idea and you make a game out of it.

You create the world, design the levels, add some traps, some game design.

You do whatever you want and you create your own game.

Then, people can play it.

You can see people playing your game.

It's just a great experience.

So chances are, if you're a developer and a gamer, you should really consider making your own games.

It's just great.

Trust me.

So how can you get started? If you know how to program but never made any game, what should you do? It's pretty simple.

First, you pick a framework.

Then, you make your first game, and then you make more games.

Let's go into more details about this.

So to make a game, you need to have a framework.

As developers, it can be tempting to create your own game from scratch.

Maybe doing a game in plain JavaScript, plain C++, whatever you like.

It's probably a bad idea.

I mean, there are hundreds of gaming framework available.

They're here to help you make games faster and more efficiently, so use them.

The only problem you have is to pick one.

There are so many of them and there isn't one best framework to rule them all.

So you have to choose.

And for that, you need to know what you're looking for.

Do you want to make a 2D game, a 3D game? Do you want to make a game in the browser? Maybe something you can download? Then, on which platforms? Or, what are your favorite programming languages? So you have to answer all of these questions in order to find the framework you want to use.

It takes quite some time, but it's really worth it.

If you really don't know where to start, and you want to make 2D games in the browser, I can recommend you Phaser.

So it's a framework that I used to make all my games, and it's great.

It's free, open source HTML5 framework.

So it's basically JavaScript.

And it will run in any browser on your desktop, on your mobile, tablet, whatever.

If it has a browser on it, you can play the game.

It's simple and powerful.

With just a few lines of JavaScript, you can make full-feature games that run really seamlessly in basically any browser.

And it's getting increasingly popular.

I think it's about one-year-old now and it already has over 6,000 stars on GitHub.

It has a big forum, big community.

You can get answers really fast.

Every few weeks, you have a new version released, so it can be a great place to start.

I really enjoy Phaser.

So just to give you a really quick example of what you can do with Phaser, I made a really simple breakout clone.

And you can see here is the full source code of the game.

So basically, 40 lines of code can make you a real small game.

I don't know if you can really see it, but it's only three functions.

You have the pre-load function, where you load all the assets of the game.

In this case, it's just images.

Then, you have the create function, where you initialize all the objects within the scene.

So you create the [INAUDIBLE] button, a ball, which is going to bounce everywhere, then all the bricks.

And finally, there is update function.

That's the game loop.

That's where the magic happens.

So this function is counted 60 time per seconds and will handle all collisions, player input, movements, and everything.

So yeah, 40 lines of code and you have a game.

I think that's pretty nice.

So OK, once you picked your framework, you should make your first game.

Obvious.

But just be careful because there's a trap.

You will probably be thinking about making your dream game.

Maybe it's an adventure game with dungeons, [? bosses, ?] and puzzles.

Or, maybe you want to invent something completely new, a mix between a platformer and FPS and maybe a rhythm game, I don't know.

Well, don't.

That's really a bad idea.

This is way too difficult for you.

You will spend weeks struggling to make your game.

It's going to be really difficult, painful.

And by the end, you will probably have nothing.

You will just give up.

I know, because I've been there.

It was a few years ago I started my first gaming project.

I wanted to make a real adventure game.

It took me three weeks, painful.

Gave up.

I have nothing to show.

A really bad experience.

And I said to myself, I'll never do any game.

I stopped.

Well, I was wrong.

So instead, try to make a really simple game.

A game that you could compete in just a few days, maybe one week.

This way, the game will still be challenging to make.

It will still be interesting to you.

But this time, you are almost guaranteed that you will finish it.

And finishing a game is the interesting part.

The rewarding part, when you can play it, when you can see other people playing it.

That's what you should aim for, a game that you can finish.

So don't try to make a new Mario game, Zelda, or even less Call of Duty.

It might look interesting.

I know people who tried to do that for their first game.

It was a complete failure.

Instead, do something a lot simpler, like Pong, Space Invader, or Breakout [INAUDIBLE] like I showed before.

These games are a lot easier.

Just a few objects interacting with each other.

No much physics going on.

It's easy.

You can do it.

And it's a lot of fun.

So OK, you made your first game.

Congratulation, that's the first step.

So there's small problem.

Your game is probably not that great.

I mean, first, by design, we decided to create a small game.

So it can't be very interesting.

And then, you don't have any experience in game design.

So do you have an interesting difficulty curve? Is the game easy to understand? Are the game mechanics great? Probably not.

So how do you get from a not-that-great game to making very enjoyable games? The answer is really obvious.

You just make more games.

By making more games, you'll get more and more comfortable.

And you'll be able to make a lot more complex and enjoyable games.

So you can see here a screenshot of the 12 games I've made in my one-game-per-week challenge.

I'm not sure if it's really obvious because it's just a static image.

But on the bottom are the first few games that I've made.

They are basic, not interesting, quite boring.

When you move upward are my latest game.

More complex, more objects, more interesting game mechanics.

Each of these game was made in less than a week.

So there's no time difference here.

It's just experience.

By making more games, you just get better at making games.

You play your game.

You can see what works and what doesn't.

Even more importantly, you look at people playing your games and you see, where are the struggle? If game is too difficult, too easy.

And you adjust everything.

And slowly and slowly, you get really comfortable.

So right now, I can basically make any type of 2D games.

I'm really comfortable with it thanks to going through this process.

So quick summary of what I've just said.

Making games is awesome.

I really recommend you to try it.

And if you want to-- so pick a framework, spend some time, try to find one that really works with you.

Then, make your first game.

Something really simple that you could complete in just a few days.

And then, make more and more and more games.

And you'll get better and better and better.

So that's it.

If you want to learn more about me, you can go on my website, lessmilk.com.

So you can play there all my games for free without any ads.

I also have a blog over there with a lot of tutorials about Phaser, Unity, game design, whatever.

And I'm also on Twitter.

Thank you.

[APPLAUSE] Yeah, we got time for a couple of questions.

So are you targeting mainly desktop with this stuff? Or, have you done work with mobile as well? Right now, it's mostly on desktop.

The technology, you could make it work on mobile also.

But most of my games use keyboard inputs.

So it's mostly a desktop, yeah.

So is that the reason, is it just because of inputs? Or, are there other things making you stay away from mobile? Well, with the time-- I had a short timeframe each time.

I had to make a game in one week each time.

So I tried to focus on basics, bare minimum.

And so keyboard inputs, and that's it.

I'll take care of touch input later.

So is there a particular set of browsers you're targeting this stuff at? What browsers have you been targeting with your games? Phaser works very well in a lot of browsers.

I mean, I haven't checked with Internet Explorer, but every new version of Chrome, Firefox, whatever, it just works.

Also, on your tablet.

It's really working everywhere.

So what's the renderer in Phaser? Is it using DOM, SVG, or is it running straight to Canvas? It's WebGL.

OK.

Because most of the examples there I saw were kind of 2D.

But it's still using the full pedal to the metal? Yeah.

Phaser is a 2D game engine, so you can only make 2D games.

But it's using full WebGL.

So I'm told that if you're doing lots of heavy processing that you have with a game, that garbage collection can be quite a big issue in JavaScript for this kind of stuff.

Was that a problem for you, or was it fine? Well, my game are quite simple.

But I never went into this problem.

So I don't really know.

Thanks.

Well, thank you very much.

Thomas Palef.

(thomas) Thank you.

[APPLAUSE] Thank you.

Right.

Well, we're going to move on to our next speaker pretty quickly.

I've been told off that I am not leaving enough of a gap between the talks, so I'll do that now.

Change over the tape.

Yeah? Excellent.

OK.

Big, warm welcome to our next speaker.

It's Luc Bloom.

[APPLAUSE] It's not on, right? Oh, it's on.

Welcome.

I'm Luc Bloom.

I'm a developer for Blue Giraffe based in Eindhoven.

I have a lot of experience in C++.

Created a lot of games for a lot of platforms-- mobile, desktop, Mac, you name it.

And recently, we've started creating HTML5 games.

Sorry, this is my first presentation.

We've done some ActiveX games in the past, but now we've started with HTML5.

I'd like to share some things that I've learned with you.

We at Blue Giraffe are heavily focused on telling stories.

We create games for mainly a female audience.

And they really like emotion to their games.

So even though the current-- wait, let's talk about that later.

The reasons that we went to HTML5 is it's a new market and anybody can become a big player.

So it's really exciting to see if there will be a big web portal where a lot of players will go to.

You have a large potential reach.

Even, you could maybe play on TV, on any device, without having to port any code over.

And it keeps growing.

I firstly liked that people can start playing without having to install anything, circumvent the security, something like that.

Just open a web page and you go.

Yeah, it's possibly that it's also the definitive way to create games that are truly cross-platform.

Because there are also technologies to run your HTML5 games natively and on a device.

But when we started, we had a few concerns.

From a native developer standpoint, of course, because we had no experience in the front end department, actually.

So we wanted to find out how amazing this technology really was for performance, memory consumption, that kind of stuff.

What's possible to pull off in the HTML5? We thought that we could start right away and there would be not too many problems because, well, it's a web standard, of course.

So it's probably standard across all devices.

Well, we were wrong about that.

There's a lot of combinations possible and not everything works perfectly.

And we were very concerned about security.

We've had to deal with piracy and things like that.

But somehow, we've gotten used that our code is just online.

And we've not really the high-score game yet of games that you have to work with multi-player.

We'll cross that bridge when we get to it.

But until now, we don't really know how to protect the games.

Except for minifications.

So obfuscating your source code.

And one thing we also were questioning was, what if we create these games with a lot of story and they are quite big? Some of our desktop games are 250 MB.

Yeah.

Is the user going to download that every time he plays the game, or how is this going to be solved? And I have really no idea yet how to solve that problem.

And we had no idea about expected revenue that we could get from HTML5 games.

So that's why we needed a partner.

And we decided to start off an experiment with Jango.com.

We needed a game that had proven game-play so we wouldn't fail on that aspect.

It shouldn't be too hard to create.

And it shouldn't really push the envelope on HTML5.

So we would have-- give it a fair chance.

And we wanted to touch both WebGL and Canvas.

And as the previous speaker pointed out, how do you start? Well, you just pick an engine.

We chose Phaser as well.

It's just quick to start.

And we heard good things about it.

Then, we-- let's see if this works well.

We created a little game.

Is this on the screen? No.

How do I do that? Nope.

I'm sorry.

Oh, there it comes Yes.

It's called Hit or Knit.

And it's a basic Zumba clone.

I don't know if you're familiar with that game.

There's a lot of moving things around-- you have to place three of the same colors.

That's the basic game play.

OK.

Let's go back.

No sound needed.

There's many moving objects.

Bezier curve calculations and collision checking going on there in the-- so we had to test the performance of the code as well.

And we figured if HTML5 couldn't create this kind of game, then it wasn't ready for our type of game yet.

And I had a lot of fun creating this game discovering JavaScript.

But also, we saw some issues in the landscape that we needed just to create our type of games.

We experienced the fragmentation of browsers, especially the Android stock browser, which is installed default on devices, on all devices.

It's very hard to develop for.

And you can think, well, those are old devices, we don't care.

But we want to be very inclusive in our demographic.

So you're going to lose a lot of potential customers if you don't optimize for that one.

And the Android stock browser, for instance, it reports that it does WebGL.

But once you try to use it, it has many errors on many devices.

And I've worked with the guy from Phaser to address this issue.

It's always a good idea to create a low-quality version that has lower resolution images.

And it should also drop some of the effects.

And what you get then is-- let's see.

I don't know what's going on there.

Yeah, let's just skip this demo because it's too cumbersome.

I had a demo which showed a game which had reduced animations.

But it looks very boring, but people can still play well on their outdated Android hardware.

And we find out that WebGL, even though it's supposed to be running on hardware, it doesn't.

Things like rotation and scaling are still costly.

You wouldn't expect that, but we found out that was one of the things that made our games slow.

And we also found out that some of the parts that we used to use to create our C++ games were really missing in the HTML5 landscape.

These are not things that have to do with the engine so much as with the things-- the world around it.

We were really missing asset configurations.

We have some 4,500 image files in 8 languages.

And we want to create different resolution sets.

And to manage all those things, we still need a good tool to manage all those resources.

We're also missing localization support.

The resolution classes you might know as media queries, I guess.

And some way of knowing how fast the device is that you're running on, so you can take action in those areas.

And I've talked with Dominic yesterday about some things.

A lot of the time, in the games we'll-- sorry.

I'm out of time, right? Yeah, OK.

OK.

Big round of applause.

[APPLAUSE] I think seeing a game like that which feels to me like something that's very much things you'd only see on native code working in the browser at a frame rate that looked to my eyes like 60 frames a second, I think that is absolutely incredible to see.

It kind of gives me real hope for the future of the platform.

OK.

You mentioned you were working with Android.

The Android version, was that using the same code, or was it like a different URL you would, eh… Yeah.

The engine takes care of things that won't work or work differently on Android.

So the screen on, I guess, a phone, it's a different aspect.

Or were you forcing users to sort of rotate to landscape in order to use the game? I had a very interesting thing about that.

A lot of games, if you hold your phone in portrait, it will display a picture saying please rotate your phone.

And I find that very obstructing because for once in Facebook, you can't rotate your phone in the Facebook web browser.

So if you follow a link there, it won't work.

And why just don't show the game 90 degrees rotated? And then, people will see, well, this game is looking weird.

I'll hold my phone like this.

And the plus side on that is you can game in bed.

Yeah.

That's the number one reason I might lock rotation on a phone.

I think we are on the platform via the manifest spec.

We're getting a way to lock rotation or to specify the rotation, a page's needs.

So hopefully, you'll be able to just sort of-- you won't have to do that kind of rotation stuff yourself in the future.

You'll have a way to declare this only works on these orientations.

What are we missing on the web platform in order to make this stuff work a lot better, or is it ready? Yeah.

I have a lot of things to say about that.

I guess because I've been working in C++ for 10 years, developing my own tools, that kind of stuff.

I'm a bit spoiled in that respect.

But I really do think we need asset management, like things to manage multiple languages, multiple resources.

Things that make sense on a mobile and things that make sense on desktop.

Because sometimes you want to have a graphic that says tap on the mobile.

On the desktop, it says click.

You know, like metadata about images and a publishing process.

Because once you're done with your game, you want to strip out all the debug information.

You want to minify it.

You want to build separate builds for all the platforms.

I think there's a big opportunity for a tool there.

So you said that the stuff you're deploying is quite-- some big files.

You were saying 250 megabytes? Yeah.

That's for the native games.

So the web version is not that? No.

This was a tiny game.

(man) So what kind of size are you deploying with the web games? I can't say right now, but I think it's 25 megs.

Have you experimented with anything such as downloading the assets that you'd need for like the intro screen and first level ahead of time? Yeah.

If we're serious about pursuing the HTML5 games with the type of games that we create now, we definitely need something like that.

Yes.

I think it's great to see that the PS4, with their kind of recent promotion and stuff, they've been promoting that as a feature.

They're saying, hey, you can download the bit, but we can still give you that.

And I'm like, the web's had this for years.

We can maybe do this better.

So I think it will be interesting to see how we can make the most of that.

Well, thank you very much.

Big round of applause for Luc Bloom.

[APPLAUSE] Thanks.

Right.

Time for the awkward change over bit.

Bye.

Change over the tape.

Hello.

How's it going? OK.

So we're going to our final speaker of this lightning talk section.

Please welcome to the stage, it's Dominic Szablewski.

[APPLAUSE] Hey, thanks for having me.

So as my name was so lovely pronounced, it's Dominic Szablewski.

And most of the stuff I publish online is published under the name PhobosLab.

As you may know, Phobos is one of the two Mars moons.

And the Phobos Laboratory is actually the place where the first Doom game happened, which was quite ridiculous based on the size and potato shape of this moon.

So a few years ago, I published a game engine called Impact, and it's been called the first truly professional JavaScript and HTML5 game engine to hit the market by the "Game Developer" magazine.

And it's a commercial game engine.

I tried to sell it and it actually worked out pretty well.

So it's now my full-time job.

The game engine is primarily concerned about 2D games.

So think about anything the Super Nintendo was good at.

So a bunch of background layers and many sprites in front of them.

So it's mainly meant for action games.

And you can see a lot of examples here from other people.

And I actually published my first Nintendo Wii U game a few months ago, which uses the Nintendo web framework, which is basically just a web kit browser on their system.

And they have optimized the canvas 2D context pretty well for their system, so you can build games like this.

So the game I want to show you today is a different one.

And in 2013, there was a game competition called Seven Day FPS, where you were supposed to build a first-person shooter in just seven days.

And I'm proud to say that I managed to miss this deadline only by one year.

So most of the people that participated in this competition used a game engine that was meant for 3D stuff.

So like Unity 3D or even the Unreal Engines.

But of course, I wanted to use my own game engine.

The problem is my game engine, as I said, is actually only meant for 2D games.

So I had to cheat a bit to make it work.

And let me just show you what I ended up with.

So the game was called Xibalba.

Xibalba is the place of fear in the Mayan underworld.

It has a bit of story attached, but I don't want to bore you with it.

I hired an artist from Reddit, Justin Spice, who was extremely talented and did all the-- most of the ad work for the game.

So let's just run through the game real quick.

There are a lot of-- it's very original.

There are a lot of beautiful animations that were hand-painted.

But as you can see, these monsters are just 2D sprites.

All the items, they are just cardboard and are flat.

As I walk farther through here, you can see some other enemies.

And as you notice, the lever geometry is pretty simple as well.

And that is the main trick for the game.

So it's a 2D game engine.

And what you're seeing is a level that has just a floor level.

So there are no floors above other floors.

No staircases.

So you could essentially play this game from a top-down view as well.

So the game physics are all two-dimensional, but the view port really is 3D.

Notice how when I walk through here, you will see some enemies spawn.

And I will show you later how this is done in the [INAUDIBLE].

And I do have some cheap effects, like the fog over the lava here.

And yeah, let me show you how this level looks like in the editor.

[APPLAUSE] Thank you.

So this is [INAUDIBLE].

It's the [INAUDIBLE] for Impact.

And you can see the level we just played from the top-down view here.

We have the player start point and the whole way we walked around here.

And here is actually an interesting bit.

Here's a trigger.

And when I walk into this trigger, you'll see that these other objects get triggered and they spawn the enemies that you saw.

So the whole level is comprised of several layers.

You start with the floor layer, with all the floor tiles.

Then, you have a collision layer that is actually invisible in game.

But it just tells the game engine where the walls are.

So you could have walls where you could walk through.

Then, you have the walls layer with the actual visible walls.

Let's just turn this off.

Then you have the ceiling.

And a light layer.

And this is pretty important as I figured out.

The slide layer has all the light values painted in.

So you see you can have lights in your level and have dark spots in there.

And it's really, really important to have a dense atmosphere to have the lighting [INAUDIBLE] right.

And then, of course, you have the entities layer with all your game objects.

You can see the player object, items like the shotgun ammo, and stuff like that.

The triggers and all the enemies.

So let me just build a secret room here.

First, we need some floor.

And I can bring up the tile set.

The tile set is compromised of just 16 by 16 pixel tiles.

So it's pretty tiny.

But I think it still looks nice in the game, if you like that kind of style.

So let's pick some floor tiles and paint something in.

That's a nice secret room.

Get on the walls layer.

And we need, actually, this tile gone.

And put some walls in there.

And let's go on the ceiling layer and put in some ceilings.

Let's go back to the walls layer and put in some lights as well.

These are just the graphics for the lights on the wall.

Let's go to the light layer.

And actually, paint in light values.

This looks really tedious.

And I thought about automating this so that you just specify that you have a light bulb somewhere and the engine calculates everything on its own.

But I really like to have the fine-grain control of all the light values.

And let's, as a final thing, go to the entities layer and put in a rocket launcher because I'm a dirty cheater.

Let's just save this.

And if we go back to the game-- I should get rid of this loading animation.

You'll see there's the secret room.

And my rocket launcher.

And it works pretty well.

[APPLAUSE] So the beautiful thing about HTML5 games is that games are the subset of apps where you can really say write once, run anywhere.

Because you have a custom interface, you have custom controls anyway, so the game works really well on all modern browsers.

Chances are if you pull out your Android phone and go to the URL in the bottom right corner, you can play the game right now.

There's also a native version that I made for iOS.

Because as you know, iOS only got WebGL support with the latest version, iOS 8.

And before that, I used my framework ejector, which is sort of like a Canvas and JavaScript context with all the browser stuff gone wrong.

So I had this native version in the App Store as well.

The most complicated thing, actually, about getting the game onto mobile was to get the controls right.

On the desktop PC, you have the keyboard and the mouse, like first-person shooters are meant to be played.

And you don't have those on mobile devices.

And I experimented a lot.

And in the end, I came up with this control scheme where you have the whole left half of the screen dedicated to moving your character and the right house to turning left and right.

And just a button to shoot.

So using the whole surface of your device as the control input worked really well for this game.

So everything you saw here is packaged up into a plug-in for Impact.

I've called this plug-in 2.5 as an homage

to the excellent three.js 3D engine.

So it's not quite 3D, not real.

You can use this plug-in and put it in your Impact game.

And you change a bit of the entities around so that you get the camera angle And you have a 3D viewport of your 2D game.

To start it as open source but again you need the Impact game engine for this to run.

So everything I talked about you can see on the URL here, phoboslab.org/fronteers2014.

There are all the links of the projects I talked about.

And there's also a link to buy Impact for half the price.

If you want to, you can follow me on Twitter.

My handle is @phoboslab.

And yeah, that's it.

[APPLAUSE] I kind of want to play Duke Nukem now and watch "Strong Bad."

It's been a real nostalgia trip for me this afternoon.

So Impact.

Yes.

Why not Phaser? Because that's what the other guys are using.

I wanted to make a game.

And I looked-- this was back in 2010.

And I looked at several game engines and most of the stuff was for Flash.

And I wanted to make something that could run on mobile devices as well.

So I started to make my own game engine, which for me has been a great decision because it's fun to get into the gritty details.

But I wouldn't want to do it again now.

So any hunger for making it open source? Or are you making too much money from it right now? I'm still making money off it.

But the plan is to release Impact 2.0 sometime soon,

and then open source the old version.

So Impact was rendering-- was that rendering using-- you mentioned both WebGL and Canvas 2D.

When does it use one? When's it use the other Usually, Impact just gives Canvas 2D for all the 2D games, which uses Canvas 2D.

And this was a bit of a problem a few years back, but the Canvas 2D renderer has been getting pretty quick.

Especially on mobile devices, it's amazing what you can do with it.

So the Duke Nukem-style game, was that rendering 2D? That was rendered using WebGL.

So the plug-in that you put into Impact transforms the Canvas context and uses a WebGL viewport to render everything.

So how has your experience been on mobile? We saw some screenshots.

Have you been able to support a range of devices? How tough was that? It has always been a dream of me to get onto the big consoles, like the Sony PlayStation and Xbox and Nintendo Wii U. And Nintendo

is really focused on making it easier for indie developers to get in there.

And they have, as I said, this web framework where you basically take your HTML5 game, change the controls around a bit so that you can use the game pad, and you're done.

It runs beautifully on the console.

I remember Sony were threatening to put WebGL in their browser.

I don't know if they did in the end.

Is that something you've done testing with? I don't think it's exposed to developers.

I think the whole user interface of the PlayStation 4 is rendered in WebGL in the browser.

But I don't know if you can make games with this.

If you can, they are pretty secretive about it.

I don't know.

It will be great to have a console platform that was running on the web that we could actually get access to.

I want to bring the issue of garbage collection up again.

Is that something that you run into issues with JavaScript? Did you have strategies to work around that? Yes.

But it's getting better.

In the early days, especially in Firefox, you saw some garbage collection pauses every few seconds.

But nowadays, you could probably do anything you want and not care about it too much.

Impact has some built-in facilities to reuse entities.

So if you have a lot of particle spawning and you have to get rid of them again and kill them from the screen, and then spawn another bunch of particles, they are not recreated, but the old ones are reused.

So that helps a lot with garbage collection.

Are you keeping those just within a normal array, or are you using the typed arrays for stuff like that? Have you found performance benefits there? I haven't used the typed arrays for any 2D stuff yet.

They are used in this WebGL example, of course for drawing.

Which was actually pretty interesting how much you can push through this, even on mobile devices.

Have you experimented anything with asm.js?

Like the kind of small subset of JavaScript that Firefox-- I tried to.

I failed miserably.

There was a thing called-- I don't know what it was called.

A language based on JavaScript, but that compiled to asm.js.

[INAUDIBLE]? No.

Not the native one.

Something more related to JavaScript.

I can't remember the name.

And I couldn't get it to work.

And then I tried to write asm.js by hand.

(man) Oh, you're insane.

I am, yes.

You're a monster.

I've gotten insane by that.

So I'm from a web background, so this stuff's really new to me.

How would you go about testing something like we saw there? Are you using automation, or are you just walking around each corridor and making sure nothing blows up? Well, except the stuff that's suppose to blow up.

Yeah.

I have to confess that I don't do much testing at all.

(man) That's pretty incredible that it works as well as it does.

That's amazing.

What kind of stuff do you want from the web platform in order to make it easier to do the kind of stuff you want to do or the stuff you're currently doing? There's a lot of stuff that I really don't get, especially from the open web manifesto [INAUDIBLE] everything is really low-level.

And we had an HTML5 audio API a few years back.

And I used it for my games and it still doesn't work.

So now we get the lower-level Web Audio API and this works.

But sometimes, I just want to create a sound effect and play it and not go create an audio node, and the game node, and the master node, and connect all of these, and then hit play somewhere.

So I would like to see some easier-to-use stuff.

And I think Canvas 2D was actually great in that regard because it's a really, really easy-to-use 2D drawing API.

And we've distanced from that again with WebGL.

So I think we should provide some high-level APIs for a subset of things that we want to do.

Do you want to see that in the engine space? Because we see Free JS, a lot of engines built on top of that.

Do you think it's beneficial at the moment to have all of these engines competing? Or do you think now's the time to try and standardize around a particular way? Even if it is something like Free JS, just a little bit further up than WebGL.

Well, the other 3D stuff is pretty intense on the CPU and GPU if you go through a high-level API.

So I understand that it's lower level.

I'm just saying that some things should be done with a high-level API so that you have an easy option.

If you want to make a 2D game from scratch, you shouldn't need to go through all the OpenGL abstraction.

That's actually what I liked about the Canvas 2D stuff because before Canvas 2D and Flash, you only could build native games.

And if you want to have a simple 2D native game, you had to code three, four pages of C++ to even get a blank screen to set up your window and stuff like that.

And it's been really easy with Canvas 2D.

I think we need stuff like that to get new developers engaged with this.

Cool.

That stuff was absolutely amazing.

A big hand to Dominic Szablewski.

[APPLAUSE] Thank you.