 All right, let's see. Where should we start? OK, this talk is about super happy fun times, or happy fun times, depending on the complicated thing. So let's get right to it. Let's see. I still never remember how to switch things in. Pull out your phones. Connect to the Wi-Fi. Happy Wi-Fi fun times. If you have iOS, if you're lucky, just be patient. If you're on Android, yeah, it'll be like 20, 30 seconds. If you're on Android, once you're connected, go to Chrome and go to h.com. Is there sound for the computer? Does anybody have sound for this thing? OK, so I don't know what it is about your guys' projection system, but it should be 60 hertz. Is that something you can set over there? Both the sound and the refresh rate. It's HDMI, but it's going to the adapter, right? So you're probably losing it. Can I just plug it in there and plug it in my computer? Hold on, maybe I can just set the sound. All right, sorry, hold on, hold on. Sound. Output. Internal speakers. Oh, sound. So this is happy fun times. It's a system for making multiplayer games in your browser, or installations, or giant ads you want anybody to interact with. People connect immediately. They don't want to do anything. They connect and they're in. I apologize for the speed. This is the first time I've been somewhere where the projection system doesn't have a good frame rate. Every place else has been 60 hertz. I don't know what button you guys have to press to make this go fast. It's going fast here. This is actually a virtual game console. So you guys are all playing this game. I'm going to switch games. So you're all back in. Those are just controllers. This is a Bomberman. We've got 41 players. I've had 92. You're all going to die. But when you die, you'll be on the edge and you can throw bombs in. Somebody just died. These games are actually in JavaScript and WebGL, just because I used to work in the Chrome team. I know that stuff pretty well. It was easy for me to get started with JavaScript. So if you're on the side, you can throw bombs in. You can actually collect the power-ups to make your bombs bigger, even when you're dead. And you basically try to kill everybody else so you can get back in the game. If you're on the outside and you hold the button down, oh, someone won. Player 24. All right. OK, another game. This game I made five years ago. Before I built the system, I built this game. And then I just sat on it for four years thinking, I should probably turn this into a library. And so this is an example of when you design games like this, you have to take into account how many players. So the way it works is only six people are up there. And all the rest of you are in this waiting list. And you collectively control the ghost ship, which is over there. So if you all press to the right, it'll go to the right. The more you press to the left, the little left of you, the fire will fire to try to kill other people to get back in the game. This is also an example of the system is communicating to your phone. So if you die, your phone will actually make explosion sounds. And if you have your sound up, your shots only last. You only get three shots. So if you keep shooting really fast, you're just going to be really short in front of you, whereas you let off the button, you can get longer shots. But the point about the limited players is that if I let all 40 of you guys up there, it would just be bullet hell. And you'd all die immediately. So you have to really take that into account. The same with Bomberman, like 20 players, maybe you can play, but when I had 92 players, you guys had 41, it's almost impossible to find out where you are when it starts. And so if you're going to make a game, you have to design something around that. If any of you just have player, you can click the little gear box in the top corner, and you can change your name. So I'll show you a couple others. This is the worst game ever, but I wanted to show that I could take the orientation from your phone. So if you can find the color on your screen and you can find the matching color with 41 people that's nearly impossible, then you should be able to tell that as you tilt your phone, it changes that thing to orient that way. People have actually used this to make a Google Glass game, not Google Glass, Google Cardboard games, where everybody out there is in Cardboard, and they're all playing a network game. A couple others I'll show you. Here is one that just moves the dots around. So you slide your finger, and if we don't erase, then where I can ever read? Don't have it here, do I? Paint, there it is. If I don't erase, then you can all paint. Of course, this brings up another problem with group games. Maybe not in Singapore, but certainly in America, somebody will draw a penis, or they'll name themselves penis. So you have to take that into account when you make a game. Let's see. There's also I have Unity plugins. So if you want to make the games in Unity, you can do that. I'm going to leave this small because Unity has problems with things, but here you all guys are in Unity game walking people around. I need to do work on the camera. The camera will at some point just zoom out, and you won't be able to see anything. But you can't see it's working. All right, there it goes. Yeah. All right. Where did it go? Is there anything else I want to show on here? Yeah, that's a bit different now. So a couple of things I want to show are, let's see, should have prepared this. So these are a couple of games that were made last year. This game is from last October. And it's six screens long. And so it's one giant level, and you walk along as you play, and you jump from screen to screen. And this is again, that's actually six machines each running Chrome, running a game in WebGL, going through the system. So it's all JavaScript. So you'll see those three guys jump off the screen and walk on the next screen. And I actually asked them for 20 monitors. I'm glad they only gave me six, because making content for six was enough work. I had some luck. A couple of friends helped out. One of them, his son, is only 16, did all the graphics. So then also last year, UCLA has a game lab. And they used it to make some games. So this is one game that they made. The players are using their phones to control those bunnies. And they are trying to shoot the magic hat. There's a guy under the magic hat using elite motions to control the gloves and like shoo away the bunnies. It was a student project. It was the end of the season project for them. So you can see him standing there using his hands to move the gloves. But that's the kind of thing you can do with a system like this very easily, let people interact with some giant art installation. Another game was this one, which is a risk type of game that some other students made at a game. They started at a game jam. And so you can see they have a giant map. And this is an example where they actually, because they made these maps and they wanted to support multiple players, they actually made a map for four players, a map for five players, a map for six players, all the way through 12. But at some point, that's a lot of work. And they didn't have to come up with some auto map generating system. They also had to make flags and all that kind of stuff. So that became work. It's showing the results of the last moves. And then when the moves are over, the phone screen will change to say, OK, what move do you want to make next? And then everybody makes their move. It's also an example of design problems that since they made it a jam, they didn't have a lot of time to iterate. And so there it is saying, what moves do you want to make? I'm saying, I want a stockpile. Yes, do you really want to do that? And then it goes back for waiting for everybody to make their moves. But what you have with the moves is that people get tired of waiting for other people, like, who hasn't made the move yet? I'm tired of waiting. And then they kind of just leave. So that's one of the things you have to take into account, design your game around people coming and going, or make sure people always have something to do. That's actually what happened in the Bomberman game. It used to be when you died, you had to wait until the round was over, and people would just stop playing. And so, OK, I'll put you on the edge so you can throw bombs in and keep playing. So yeah, a couple of other things. Oh, this isn't going to work anymore, is it? I don't think I can make it. I can't go presentation because I'm offline. That is a bug in, yeah, presents just great out. So one thing that's easy is that the phones are just controllers. So at least at one level, it's much easier to write a game using this than, say, something like, than a normal network game. Because the controller, you can just consider, you know, they're pushing buttons on a joystick. From the game's point of view, it just gets button presses. I mean, you can do more than that. But the point is, like, if you're doing, like, a Quake game or a Doom game, you have to do all that dead reckoning, and you have to do all this latency compensation, all that kind of stuff, because everybody's got their own view. And this one, there's only one view. And so that makes that easy to get something started. Another thing that I mentioned, players can disconnect at any time, so you need to take that into account. A lot of students at UCLA tried to make games that required poor people for the entire game. And if somebody, like, got a message from their friends and picked up their phone, well, they're out of the game. And then the game was waiting for them to play. You need to do something about that situation if you're going to make a game. And as I mentioned before, if players have nothing to do, they're going to leave. So if you're going to have rounds, give them something to do while they're waiting for the round to end. You can have too many players. That's Barman Man with 413 players. Not actually 413 players. It's just, like, made up some simple AI just to see it work. But it works. Another thing which you haven't done a lot is just using the system to do unique things. So the games that I showed you are mostly what I call low-hanging fruit. They're just an old game, like some 30-year-old games, with more players. And really nice to explore things that people haven't done, kind of like the bunny game maybe that you saw. There was another game I mentioned that people did stuff with Google Cardboard, and that was a team-based thing. So one person's looking at the Cardboard, and they're telling the teammate a little bit to the right, and they're doing something a little bit like, no, a little bit down, and a little bit down, and their team's competing. And that's something you couldn't do in an old system just with more controllers. So this is an example like maybe you could put all the phones down and just turn to one big controller and use the system to coordinate them. Another example is making team games. If you look at what's actually on the screen on these shots, like the blue and the green guys are clearly on the same team, because the blue guys got to press them in the green guys' phone, the green guys got to press them in the blue guys' phone, you'd have to be creative in your design so they can't just shout across them, hey, blue, press this, right? But maybe it's big enough. Or even in real games, like if you play a card game with real cards, people can cheat, but they don't. So hopefully people will just participate. Another example is maybe making some of the games where you put an image on people's phones, then you go find people to have the same color background, and they all have to arrange their phones to make some image. And once they've arranged them, there's something they have to trace or something they have to do. They have to navigate something across. I would like to explore that. Other things you can do is because you can have sounds from the phone, you can make things where they put their headphones in, and you give them private instructions for only that person. Or you can make asymmetric controls where every person in the room has different controls. That's something I'd like to explore. There's a few games out there, like if you ever played Space Team, it kind of does asymmetric controls. The controls are just web pages. That's how you didn't have to install any software to play. So that makes them easy to make. The bad thing is, they're web pages, so you have problems like as a iOS 8, if you press anywhere in the top, like quarter inch to the bottom, or the top center, or the bottom center to the screen, these bars pop up, they never disappear. And so those are issues. Android, you can go full screen, and so once you go full screen, you can control that stuff. Hopefully, maybe iOS 9 will add something to fix that. Because of that issue, I noticed that almost all the games I've made have used landscape mode, but it might be easier sometimes to do a portrait because it feels like you have more space. So that's just one thing to be aware of. The last thing is, last month, I was at a game jam, and I was making this work with a friend's game system, which you guys would check out. It's called Pico 8, and it kind of emulates an 8-bit computer, and he's got like a sprite system and a map editor built in, and he limits how much you can do, and the cool thing about it is that because you're so limited, it's very quick to make something really cool very quickly, because you don't have like skies to limit. And so I made, we worked together, and we made Happy Fun Times work with this, and that turned into, I made a HTML5 gamepad API. So what that means is that with one line of code, you can take any HTML5 game engine out there, and if you're supporting the gamepad, it will run through, you can just add one script line, and then you can use your controllers, and you don't have to change your code, it'll just do the gamepad API. Of course, the problem there is that, most people who make a gamepad game are probably expecting an Xbox controller with like two analog sticks and a D-pad and 14 buttons, and you're not gonna do that on a phone. You're gonna have to design something around that, like a one D-pad and two buttons, or just a couple buttons, but I have options to get all the orientation and stuff that through that, so that's an easy way to get started. And that's basically it. It's all open source, it's on GitHub. You can probably start there and find your way to it. There's an app you can install, so if you want to, not an iOS and Windows app, so if you just wanna play it at somebody's house, you can just have them installed on their PC, and they just have people connect to their home network, and they can connect automatically. They don't have to configure their, this is like, the way I have it set up today is kinda like installation mode, where it will auto-connect. In that case, you go to Happy Fun Times on your phone, and it'll redirect you to the local game that's playing. And so, we tried to make it set up so that people could very quickly get, play some games, you made them. So yeah, that's Happy Fun Times. What kind of server space did you use to support simultaneous connections from multiple people? Because I tried doing that with a live audience as well, and just told, I was using all this in free local. Could you talk a little bit about the server space? Okay, so Happy Fun Times itself is just written in Node, JS, and it's just basically a web server to serve the web pages, and then web sockets to pass the messages. And then your game can be in any language, as long as it can speak web sockets to the Happy Fun Times server, and it relays those to the phones and the phones' messages back to the game. And that's basically what it's doing. Of course, that's easy. That took like a day to get working, right? Can you host your servers? No, their servers is running here. Oh, and you have a laptop, and multiplayer can just connect. Yeah, they're going through this. So you guys are all connected to this router, and it's sending them to the server. I wish to host specifications, whether I'm a Rock or either. Well, so it's not really the kind of thing that you would host remotely, right? Because people need to look at one screen. So if you're gonna, they're all gonna be looking at one screen, you can put a computer near that screen. You can run on any device you want, but that's not really the point. It's really like local people playing on one screen. I mean, you also have your screen on your phone, but that's the unique thing about it, right? I guess it's kind of unique. So you can have latency issues when you have it? You do have, I mean, the more people you get, the more latency you're gonna have. If you have a really crappy router, like the router at the apartment that I'm at right now, even though the router's only about as far away as that monitor, there's a wall and it's just horrible. We're gonna ask that question, right? Don't we have connectivity issues when you suddenly get most of the people? Well, so you do have an issue that there's a limit on the number of people that connect to one router. You can connect more routers like you would at an office, right? I also have this router. You guys have probably seen these TP-Link routers. They're like $15 or maybe 20 SG or something. And they only support, well, I don't know if you hack them, but the firmware that's in it only supports 15 connections. So that's like this and four more, but I can just plug it in directly with no power, just powering it off the notebook and I've induced small parties like our, you know, small presentations. So I carry that with me and for testing as well. You can also test through the simulator locally and you can just open up a browser window and just go to a local host and it'll pop up with the controller. So you have the game over here and the controller over there. Yeah, do you have any other questions? Do you have any other questions? I'm not, I'm just visiting, but I know Jason and he was like, hey, here's all these meetups that are happening. I'm like, oh, okay, I'll show this off. And he wants to see it. He's like, yeah, okay. But I'm here from time to time because Jason's here with some other friends. What was that? I was about to place the website as part of the WebRTC. Yeah, so the problem with WebRTC is it doesn't exist on iOS. And when I come to a place like this, I don't know about Singapore, but in the States like 70% of the room will be iOS. Okay, so that's, and there's another issue with going to WebRTC is that it's not reliable. So like if you need to tell the controller, turn to this thing, and they didn't get that message, you're screwed, they're not on the right place. So that means you have to, instead of just coding, you don't have to decide, is this message important? Use this path. If it's not important, okay, I can use that path. And you have to decide that for every message. Right, if the guy's setting his name, you need to know what his name is. But if he's only pressing left to right, you don't care, right? Okay. I know because like I know guys on like the Diablo team, and they all went UDP, and at the end of the day, they said they basically wrote all of TCIP because they needed to be reliable in the end. But they can't do WebRTC as well. Yeah. Well, I don't need to carry a router anyway. I can use the router here, just fine. It just, it has to be NAT because they all have to be, from the point of view of to get them all connected, you have to have some round of the server somewhere, right? Well, so the server can be on the internet whereas actual connection. Right. I already have that set up. So I have a round of the server that works for this. So if you're on a regular internet, as long as you're all connected to the same router, it will route you to each other. Anyway, yeah, I'd love to see WebRTC in there as well. Any other questions? Is the game logic in a browser or around in the middle? The way the game logic is in the browser or whatever game engine you want. I have a C++ library for CIG engines. I have a C-sharp library that I'm using in Unity. That yeah, the whole point is that from the point of view of the game, it's just a game with lots of controllers plugged in. I mean, there's more options because you can send commands back to the controller to say switch the screen or change the color or whatever you want to do. It's your, you write a web page and you receive the message and you choose what happens here. But at a basic level, if all you want to do is a simple controller, it just looks like a controller to your game. So, right? You don't, it's not. You write the game any language you want just as long as you have WebSockets. Anything else? All right. Thanks.