New HappyFunTimes for Unity Coming Soon

TL;DR: HappyFunTimes for Unity will soon be a stand alone library.

HappyFunTimes started as a HTML5 project with HTML5 based games and therefore needed an HTML5 based server to serve those games. Originally I put all my sample games into the same repo. As I wanted to make it easier for others to add games I came up with a way for the games to live outside of the main HappyFunTimes app/folder. This also made HappyFunTimes kind of like a mini game console since there was a menu to pick games from.

That design influenced how the Unity version worked where games also needed to be installed because a web server needed to serve the files to the controller and a websocket server needed to pass the messages from the game to the controllers.

Well, I’m pleased to announce that’s changing. The “game console” like feature of HappyFunTimes isn’t really much of a feature for most people. Most people make a single game for a game jam, event, or installation and that’s all they need.

So, lately, I’ve been working hard to make the Unity plugin do everything on its own. I’ve put in a web server and websocket server. This means you should be able to just stick it in any Unity project. No need for special ways to export. No need to “install it in happyfuntimes”. Just export from Unity like a normal unity project then run the project.

This also means theoretically you could export to iOS, Android, PS4, etc, run the game there and have people join with their phones. I say theoretically because I haven’t tested those platforms yet.

It also means making controllers is simpler. In the old version the server was doing lots of stuff. Your controller files got inserted into templates. The templates used requirejs, something most Unity devs were not familiar with. The new plugin, since it doesn’t have to integrate with anything else, means all that has been simplified. Make your own full .HTML files however you want. No more templating getting in your way or messing up your CSS.

Yet another thing you should be able to do is turn it on and off from Unity. In other words you could make game that supports 1-4 players using traditional gamepads but have an option to use HappyFunTimes for more players.

Installation mode should still work as will multiple computer based games.

Crossing my fingers people find this more useful.

Apparent lack of Progress

a bloggy post…

It’s been just over year since I publicly announced HappyFunTimes. Back than I showed the system at Picotachi in Tokyo and since then, at least visually, NOTHING HAS CHANGED 🙁

By that I mean I spent April last year making the games and examples and since that I’ve done nothing but infrastructure. And, it’s hard to stop doing infrastructure. It always seems like there’s more to do to make HappyFunTimes more approachable and more to do just to clean up.

In that year a lot has happened and if you look at all the code that’s been checked in to all the HFT repos i’ve don’t a buttload of stuff. There’s the Unity3D plugin. There’s the fact that the Unity3D plugin has effectively a 1 step install (after watching art students struggle with the more programmer oriented way it used to be). That includes making installers for Windows and OSX and a native (but ugly) app for OSX. It includes making more docs and even making a mobile app (though I’m not sure I’m going to push it much because I feel it also breaks a bunch of stuff. Maybe I’ll bring that up in another blog post).

There’s also a ton I feel like I’d kind of like to do. For example I’d like to re-do superhappyfuntimes.net to not use meteor. I’d probably like to re-fashion it more as a gallery with much larger pages about each project. Especially because many HappyFunTimes projects seem to be installations rather than things you can play at home at a party. But that’s lots of work not making games.

I’ve thought about switching to use something like Node-Webkit or Electron as the desktop app. That would make it easy to make UI related stuff cross platform. For example all the hft command line switches I could make a cross platform UI for. It would also make it launch with a clear app on all 3 desktop platforms vs just a command line wrapper. But again that’s more work that’s not games.

That HTML5 Gamepad Emu lead to the idea that maybe the basic Unity3D plugin should use the same code so that people just getting started have far less work to do. If they just want a simple controller they can add it to their game in a few lines. Unfortunately Unity3D’s input system isn’t really designed for 100s of players so I can’t just emulate it but I can probably make the changes needed minimal. Still that’s more work that’s not games.

And, the truth is, games are all that matters. Games are what people will see. Games are what people experience when I show it off and so far while there are a ton of ideas I’ve pretty much done none of them. The games I have to show are either low-hanging fruit of 30 year old games with lots of players or else simple tech demos just showing that the system works.

So … I’m trying to whittle down the list of must do infrastructure and then concentrate on more games. If you want to collaborate please speak up!

More coming soon

I’ve spent some time getting a native phone app working. I don’t like the idea of an app because it can make things complicated for the user (attach to HFT WiFi, wait you didn’t download the app? Detach from HFT Wifi, download app, reattach to HFT wifi, launch app) Ugh! Or, if your HFT Wifi has internet then you probably get the problem of everyone using it to watch youtube videos and post images to fb/twitter/instagram and eating all your bandwidth making interacting with your installation really laggy 🙁

But, Eddo at UCLA can’t or won’t find creative solutions for the limits of the browser on iOS so he wants an app. So I’ve made one. It seems to work but will still take weeks to get on the app stores (iOS and Android). I’m worried it will ruin HappyFunTimes though. Devs will assume they should use the app. The experience will suck. No one will get it.

On the Android front though I made the non app (browser) version go fullscreen. At least on my tests it works. One of the problems with HappyFunTimes and phones it’s (a) it’s hard to test anything without more people and (b) it’s hard to find out what issues there will be without lots of phones.

Anyway, that removes some of the need for an app on Android. Once the browser has gone fullscreen there’s no more address bar, back button, etc and you can control the orientation (no more “please turn your phone” for landscape controllers.

The app also means I can prevent the phone from going to sleep. On the other hand you still have all the normal phone issues of different phones with different screen sizes and different versions of their internal webview so you still need to be conservative and/or creative in your designs.

One thing that’s killing me is all the testing required to get this stuff to work. Examples: Need to test launching the app on iOS and Android. Does it connect to your game. Need to test both apps, do they correctly disconnect if you exit the app. Need to test do they recover from a bug in the controller. Need to test they switch games correctly. Need to test if you use the browser to go to the game it switched you to the app. Need test if you use the auto-connect installation mode all those paths work. That adds up to hours of testing. People might say find an automated way to test but given there’s 3-4 moving parts (the phone or simulator, the phone’s browser, happyfuntimes running somewhere, happyfuntimes.net running locally, etc) and you need touch guestures on the phone and exiting and re-starting the app for certain tests I’m at a loss of how to test other than manually. Even if there was a way I suspect it would take 4-8 weeks of work to get it setup.

That doesn’t include the testing I need to do just for HappyFunTimes itself like testing OSX and Windows installers work, that the Unity plugin works on both platforms starting from a fresh install, and other things. I fact I shipped a broken version, 0.0.26, where I had quickly changed the buttons on several samples from text icons to svg images. At a glance it seemed to work but then it turned out of you long pressed both Android and iOS would pop up a “Save Image?” message. DOH!!! Preventing that required different workarounds for both browsers. 0.0.28 should be up that fixes that.

I’m also working on getting HTML5 Gamepad emulation working. Actually I have that working and am in the process of cleaning it up. With that, if you already have an HTML5 game with gamepad support you can just add a script to your page and get HappyFunTimes support. I’m mixed on if that’s a good idea because most games designed for the gamepad API probably need a full Xbox style controller with 12 buttons, 2 analog sticks and a d-pad. Using HappyFunTimes for that will probably make HappyFunTImes look bad because as we all know touch screen d-pads suck! On the other hand though if someone is at a gamejam and they’re using an HTML5 based game engine they can use HappyFunTimes with almost no changes, just design the game to handle as many players as possible, add the script, bam! It also means once Unity5 and Unreal start supporting the HTML5 gamepad API (assuming they don’t already) then you could use that too. …Although I’m just going to guess without looking that they put some artificial limit on the number of controllers in their API 🙁

The reason that came up is we had a short 2 button game jam at the Pico Pico Cafe in Tokyo where Lexaloffle Games is based. We decided to try to make it possible to interface Pico-8 with HappyFunTimes and in the process I realized it would be pretty easy to emulate the HTML5 Gamepad API. Of course if you use that you’re probably not really taking advantage of all the interesting creative ways you could use HappyFunTimes but I’d rather you use it then not. Maybe you’ll be inspired to take it to the next level 🙂

Thinking outside the Box – Making HFT Games

UCLA ran a game jam for HappyFunTimes in December (2014). At the start of the jam I gave a short presentation about HappyFunTimes. It seemed like there were some ideas that would be good to pass on so here it is reproduced.

super happy fun times game jam

The presentation started with some of my history of which you can find too much of on my gamedev blog. Otherwise I started off with actually showing the system and letting people play through it. I really need to find a video of that because the videos I have really don’t do HappyFunTimes justice IMO.

So after that we got into a few specifics

Why it’s Easy!

Phones are just controllers

Most networked games require all kinds of crazy tech. For example an FPS requires that one computer “run the game”. The other computers send their input to that computer. That computer then sends back the new player positions and results. But, because that takes time each computer running the game just goes ahead and renders the game assuming it knows what’s really happening. When it finds out from the main computer what really happened it to morphs from where it is to where it’s supposed to be. It’s a lot of work and a PITA.

HappyFunTimes games on the other hand there’s only one computer running the game. The phones are just controllers. That means it’s easy. From the point of view of the game it’s just like 10, 20, 100 joypads being connected. Super easy!

Design Considerations

  • Players can connect or disconnect at anytime.
  • Players with nothing to do will leave

Even though I mentioned this issue many people forgot about it in their designs. So let me re-iterate PLAYERS CAN CONNECT OR DISCONNECT AT ANYTIME! To give an example of issues, many people have made games that require a specific number of people. Say for example exactly 8 players. If you have 20 people in the room which 8 get to play? Anyone can connect to the game. It’s possible someone might connect and not even be paying attention. On top of that people can disconnect. Maybe they get a call on the phone and answer it. Maybe you made a turn based game and they got tired of waiting for everyone to take their turn. You’ve got to take this into account in your designs.

There are solutions. One, you can design a game where people can come and go whenever. Another is you can save some kind of session id on the player’s phone so if they disconnect then when they reconnect you and restore their state. But, the point is you have to take that into account. For example one team made a Risk like game. They expected everyone to stay in the game the entire 10-30 minutes. What happens if someone leaves? Their game didn’t take that into account.

In my own learning experience I made the boomboom game. It has 2 minute rounds. Originally when you died you were out until the next game. The first time I showed it at a party I noticed people who got knocked out just left the game and stopped playing. The solution was to let them play even after they got knocked out. In Boomboom players that die get put on the edge of the arena where they can throw bombs in and collect powerups. That way they still have something to do. They can try taking the other players out to end the game sooner.

Too Many Players?

Can you have too many players? HappyFunTimes has no limit. The limit is only your networking equipment and whatever latency issues you end up having. A gazillion players will certainly have latency issues. But, even with only 30 players it quickly gets impossible to find yourself. The picture above is boomboom with 413 players. In that particular case 400 of them are random AI players but it gets the point across. Players can’t easily find themselves even with 25 players. I’ve run boomboom with 92 players once. Most people are dead before they even figure out where they are.

What that means is you should consider how many players you want to support. Maybe you’re fine with 10-30 players but if you want to make a game that supports 50-100 players you’re probably going to have to have teams or put a radar on the phone or do something to help players have a meaningful experience.

Multi-Screen Simon

At the time of this presentation the majority of the sample games I’d made had been what my friend Atman would call “low-hanging fruit”. They’re just old games with lots of players. The phone is just simulating a simple game controller. That’s great and there’s nothing wrong with that but there’s so much else that can be explored. The phone parts run in HTML. You could easily make games where there’s 50 buttons on the screen. Or games where every player has different controls. Games with sliders or dials or a simulated slingshot. You can use the device orientation. On Android/Chrome you can use the camera and the mic. Games where the controls change by game mode. The point is THINK OUTSIDE THE BOX.

For example what about some kind of giant Simon game. I’m not saying a Simon game is going to be super fun but using everyone’s phone to make a large control surface sounds like it could lead to some interesting ideas.

Team Games

How about team games. In the game above blue and green form one team, red and yellow form another team. They need to go find each other in the room and press the correct button on their partner’s phone.

Of course I suppose Red could just shout out “Hey, Yellow Player! Press the Airplane!” so you might have to design it such that it’s harder to cheat. On the other hand people play board games and card games all the time where it would be easy to cheat and the don’t so maybe you don’t have to worry about that.

Another thing this example points out is you don’t have to use the “one” big TV screen. A game could just be played one phones. Maybe all the “one” big screen does is announce the start of rounds and the winners.

Yet other idea is using HappyFunTimes to make games that help people to be more social. Maybe a game where you have to walk around the room and introduce yourself to the person who’s phone matches the color on your phone and ask them whatever question is on the phone.

Team Trace Race

In this example players are put in teams by color. So for example everyone with a blue background is on the blue team. One the game starts the blue players need to find each other and then figure out how to arrange their phones to make the figure complete. Once they do that they then have to trace the figure. First team to trace their figure wins. The game can know if they cheat because it knows the end of the figure on phone #1 needs to be touched before the start of the figure on phone #2 etc..

Controllers are Web Pages

    <div id="buttons" class="hft-fullsize">
      <div class="button" id="left">◀</div>
      <div class="button" id="right">▶</div>
      <canvas id="avatar"></canvas>
      <div class="button" id="up">▲</div>
    </div>
  

Making controllers is easy because they are just web page. Just make some HTML, use any frameworks you want. JQuery? Pixi? Three.js? (although if you use WebGL you’re limited to players with Android and iOS8+).

Controllers are Web Pages

But, at the same time, it’s a webpage. That means the browser can get in they way. For example iOS8 added these bars you can’t get rid of 🙁

Easier or Less Easy

So, it might be easier to make portrait controllers instead of landscape controllers. On Chrome you can use the fullscreen API to get rid of all the browser UI. Hopefully iOS 8.1 or a future version will add something similar.

Chome Dev Tools FTW!

Chrome dev tools (and I’m sure Safari and Firefox and maybe even IE11+) have some incredible features that can help you design your controllers.

It’s important to remember your players will have a variety of phones from a tiny Android to a giant iPhone 6+ or Samsung Note 4 or even an iPad or Android tablet.

What does that mean for you? Well for example one team made a Risk like game with really beautiful controls for choosing your move. But, they were using an iPhone 5s to build it on and when it came time to actually play the game some players had iPhone 4s and the controls didn’t fit on the screen. How you solve this is up to you. For a turn based game it might be okay if you can scroll through a larger controller. For an action game it might be best if you keep the controls as simple as possible. Another solution is to make multiple controls, one set for people with small screens, another for people with midsized screens, yet another for people with giant screens. That’s up to you it’s just important to be aware of.

Phone Simulators

Phone simulators are your friend. At least the iPhone one in XCode if you’re on OSX is fast and easy to use. It’s not perfect because you can’t easily simulate device orientation for example but if your game doesn’t need that feature it’s great. Apparently the new Microsoft Android simulator can simulate device orientation. The normal Android SDK simulator is crap so don’t waste your time with that one.

Also be aware that you can remote debug both iOS Safari and Android Chrome which can be a huge help.

Use Browser Windows

You can simulate lots of players by opening browser windows. That much much MUCH faster and easier than connecting phones every time or using the simulator. For action games it’s often a good idea to include keyboard controls which is much easier to test on your computer then using the mouse to simulate touch controls.


And that’s about it. After that we made games. I’d love to show you the games. I’m waiting on the UCLA Game Lab to post some stuff from the jam. Until then here’s a small preview of one game from the jam.

Tonde Iko, a 6 screen 50 player game

Some friends and I made this game using HappyFunTimes for the 2014 Steam Carnival

There’s a little bit more info here

I learned that I really hate working alone. If anyone wants to partner up please hit me up. I can’t guarantee I’ll say yes but I am looking.

I also learned that like HappyFunTimes you just have to make something and iterate. Lots of things got added to the game as it was made.

It started because John Alvarado, the tech lead of the Wasteland 2 sequel, saw HappyFunTimes and some how knew about Steam Carnival and thought it would be a good match. His boss, Brian Fargo, was apparently friends with Brent Bushnell and introduced us and they immediately sounded interested.

They asked what I needed. I said something like “Imaging you had like 15 projectors projecting along a 100ft wall”. I think I asked for 20 monitors. They gave me 6. Good thing too because filling 6 with content was a lot of work.

The game started as a fork of jumpjump. The first thing I did was add the ability to run multiple games and have them talk to each other. My test was using JumpJump. That worked pretty quick. I made portals, when you jumped into a portal you’d appear the corresponding portal in the next game.

My initial plan was just to basically keep the game just like jumpjump used to be. I wasn’t planning on making it prettier.

But then I needed to be able to design levels faster than typing them in in ascii in source code I googled “open source tiled map editor” or something like that and the first hit was Tiled.

I downloaded it and set out to write code to read its files. I saw that by default it used .TMX files which were in XML so I wrote some code to parts the XML and create data the matched jumpjump. Once I got it all working I submitted it to the Tiled issues incase someone else needed it. That’s when I was informed that Tiled directly supported JSON. DOH!! I had just wasted a day.

I switched my code to use the .json then made it load the graphics as well. I then went and searched for open source art. I found several tilesets and tried to use them. I made 3 of 6 levels. It took way longer than I expected.

I also made the levels 1920×1080 and it was working great. The steam carnival guys asked me to stop by and show them how it was going. I showed them and Brent suggested players should be able to jump/walk off the edges of the screens to go from screen to screen instead of having to go through a portal. I have no idea why I didn’t do that originally. I think maybe it was because I was hoping for a more random arrangement of monitors. Anyway, I added that in and that was clearly better.

I also found out the game would be running on Intel NUCs. Specifically I3 NUCs with Intel 4000 graphics. I borrowed one, tried the game out, it ran too slow on a NUC at 1920×1080. The Steam Carnival guys had said they’d figure something out if that was a problem but I didn’t want them to have to go buy new machines so I just decide to make the game run at 1280×720. I made a test level and I could get 3 layers of tiles at 60fps at that resolution.

That turned out to be a blessing. I was using 32×32 pixel tiles and at 1920×1080 they were pretty small. I was hoping the TV would be large but they ended up being 42inch TVs. 32×32 pixel tiles at 1280×720 on 42inch TVs turned out to be just the right size.

At this point I was freaking out a little though. Given that it had taken about 8 hours per level to make and given that I had to redo all the levels I was a little scared about how it was going to turn out. I tried to tell myself if it just looked like the original JumpJump but 6 screens maybe that would still be okay.

Fortunately John and his son Zack said they would help. I warned them it was going to be a lot of work. John has a full time job and Zach is still in high school. John assured me the really wanted to contribute and that they could put in the time. I’m so thankful they were able to do that.

Zack has apparently been making pixel art for his own games for a while now so he set off to make new tilesets. I had originally assumed he’d probably make only 1 or 2 and we’d use the open source ones I had found but Zack is amazing and did 5 tile sets. I really helped that he had lots of experience so he knew exactly how to make efficient sets that could easily build levels.

Zeyu, a student at UCLA, offer to make backgrounds, graphics that go behind the level. I was really worried that he might make something gaudy that clashed with the levels and made it hard to see what’s level and what’s background but what he added was perfect. Exactly what it needed to be.

John freaked me out a little because he wanted to add lots of stuff and all I wanted to do was be done. Fortunately he assured me he could get the stuff he wanted to add in done quickly and he did. He added a kind of basketball game. He added a present you could collect and exchange for a birthday hat at the end of the game. Actually there’s a funny anecdote there. On the last level there’s a cake. If you have a birthday present when you get there you get a birthday hat + 500pnts. After that it is literally 1/4 screen to the end of the level. In other words it’s like 2-3 seconds before the end of the game. I was thinking no one was going to care about the birthday hat. In fact I thought no one would even notice because I thought they’d make it to the cake and then immediately head to the exit and not even notice. Well, the first day one of the first kids that made it to the end of the game, when he go the birthday hat he shouted and jumped up and down “I GOT A BIRTHDAY HAT! I GOT A BIRTHDAY HAT!”. In my defense I didn’t suggest getting rid of the hat. I suggested more fanfare to make it very clear. We did add more fanfare. There’s 5 shots of confetti that cover the screen when you get the hat so I hope that helped 😀

John also ended up designing most of the levels.

Another interesting thing was just watching people play the game. We ended up changing things every day. In fact we even changed a few things while players were playing.

For example we saw places players seemed to get stuck. Places where jumps were too hard or where because of previous moves they’d likely fall some place over and over and over. We fixed those over a couple of days.

Another example was the portals. Originally you’d get stucked into the portal and then magically pop out at it’s destination. They were color coded so a red portal would take you to a red portal exit but players would get lost. John made it so the player would go in a line from the portal to its exit while spinning. That made it easy to see where your character went and really made that feature work.

Another one was the doors. I had decided to put doors in the game. If you got near one a progress meter would appear which would count down for 5 second at which point the door would open. There was also a switch you could stand on that would open the door immediately but it was too far from the door to allow you to get through after you jumped off the switch. The point was supposed to try to force players to help each other. One player could stand on the switch and keep the door open for another player but if there were no players around a player could still just stand by the door and it would eventually open. Well, no one seemed to get it.

We changed to so standing on the switch the door opens immediately and the progress meter starts filling up. As soon as you get off the switch the meters starts going down and the door closes when the meter is empty. People immediately got this. You can still help each other through the door and it still does help a little in nudging players together but with the new behavior people don’t get confused. It often takes 2 or 3 tries but they figure it out which I think they also enjoy.

Even with all that and it looking really good when I went to show it on a Wednesday night, 3 days before the main event, it wasn’t working. 3-4 people could connect but then no one else could. I’d reset the whole thing and even then people could rarely connect. I was really sweating bullets.

I bought 2 new routers, an Apple Airport Extreme and a ASUS 2700 something or other. I bought a new network switch and I brought my Macbook Pro to run the happyfuntimes server. I have no idea which one of those things fixed it or if all of them contributed but fortunately on Friday it was working great and it felt really good to see people enjoying it.

I’m glad we got a chance to make it. I’m really glad Zack, and John, and Zeyu were there to make it way more awesome than I could have done myself. I hope I can find more people to help make more cool HappyFunTimes games.

Why No NetGame Object?

It’s hard to know what the best way to design some API is. I have no idea if the designs I picked for HappyFunTimes are good or bad or what. There are a few minor things I’d change if I started over, mostly cosmetic but otherwise I’m mostly happy with it.

But, a few days ago I decided to add a feature to allow multiple computers in a single game. Up until this point HappyFunTimes has been about 1 computer running the game and a bunch of phones as controllers but there’s a project I wanted to make that used multiple machines, in particular I wanted to make an extremely large platform game where you’d walk down a wall or hallway with say 10-15 meters of screens and take your character from one screen to the next. Each screen would be controlled by a separate computer running the game on that screen.

For that all I needed as the ability to move a player from computer to computer. I added that feature in a few minutes, tested it and it worked. Awesome!

I’d done some other projects across computers before and in every case I’d just have to have a special URL for each computer that specified which part of a larger virtual display that computer represented. For example the WebGL Aquarium does this Doing it that way is great if you already know what the layout and dimensions of your monitors will be but I’d always wanted to make a monitor layout editor similar to OSX and Windows. To do that I needed to enable games to talk to each other so that they could all inform at least one of them their dimensions and so that at least one of them could send commands to the others about what part of the large display they were supposed to represent.

And so I set out to write that.

My first thought was I’d have some kind of sendMsgToGame function that took the msg you want to send and an id for the game you wanted to send it to. It would be up to you either make up an id yourself, probably from a url, or the system could make one up for you.

But then I thought maybe, just like players have a NetPlayer object that is used to handle the communication between a player and the game I should have a NetGame object that does the same thing for games. This would mean, just like a player, there would be a ‘gameconnect’ message and you’d get passed a NetGame object. If you wanted to send a message to that game you could use someNetGame.sendCmd and anytime a game sent you a message it would arrive on that object.

someNetGame.addEventListener(
    'someMsgIExpectThisGameToSendMe', 
    handleThisTypeOfMsg);

I got that all working, wrote tests, made sure you could send and receive messages, that a disconnect message would get emitted as well.

But… Then the last thing I did was try to implement a broadcast function, broadcastToGames. I knew this was a useful function because I’d used it in the WebGL Aquarium demo I’d linked above. I’d put some camera settings sliders on one computer and broadcast them to all the computers. Broadcasting in this way meant you’d get the same message send back to yourself so you didn’t need custom code. All the machines received their settings from the network, even the one deciding the settings. This was a great way to propagate the settings to all the computers. But, when I tried to implement on top of NetGame it I ran into a problem.

To broadcast you’d call someGameServer.broadcastToGames but given the way NetGame worked all the other games would receive the message on the NetGame object that represented the computer that sent the message but, the computer that sent the message would get the message back on its GameServer object, in this example someGameServer.

That meant it wasn’t at all symmetrical. For the camera settings example in order to accept settings from any computer you’d have to write code like

// when a new game connects
someGameServer.addEventListener('gameconnect', function(netGame) {
  // setup a listener to handle setting the fov
  netGame.addEventListener('setCameraFov', setFov);
});

// Setup yet another listener for when we broadcast 
// a new fov setting because that will
// come back to us here
someGameServer.addEventListener('setCameraFov', setFov);

function setFOV(data) {
  camera.fov = data.fov;
}

That just smelled bad to me. Why should you have to set things up twice? I didn’t have to in previous games. Plus, you had to track all these NetGame objects.

I ended up getting rid of the NetGame objects. There is no gameconnect message. Instead, messages to a game from another game always arrive on the GameServer for that game. So previous example of setting the camera fov removes the second case

someGameServer.addEventListener('setCameraFov', function(data) {
  camera.fov = data.fov;
});

Much simpler.

If you want other games to know you connected broadcast a message to them

var server = new GameServer({id: "foo", allowMultipleGames: true});
server.broadcastToGames('imAlive');

The other games will receive the message along with your id.

// some other game
var server = new GameServer({id: "bar", allowMultipleGames: true});
...
server.addEventListener('imAlive', function(data, id) {
  console.log("some game just joined. Its id is " + id);
}

This will print

some game just joined. Its id is foo

Of course when you broadcast that message will come back to you so you might need to filter out your own id

var ourId = "foo";
var server = new GameServer({id: ourId, allowMultipleGames: true});
server.broadcastToGames('imAlive');
...
server.addEventListener('imAlive', function(data, id) {
  if (id != ourId) {
    console.log("some game just joined. Its id is " + id);
  }
}

Of course depending on your needs maybe you don’t want to filter. For example if you made a screen position editor like I referenced above ideally you’d just display the id of each machine with a rectangle to represent it. If you created those in your imAlive message then not filtering would automatically give you an entry for yourself.

If you don’t supply an id it will be provided on connect.

server.addEventListener('connect', function(data) {
  console.log("my id is: " + data.id);
});

That id is also available on the GameServer object but it is not available until it has connected.

Good:

var server = new GameServer();
server.addEventListener('connect', function(data) {
  console.log("my id is: " + server.id);
});

Bad:

var server = new GameServer();
console.log("my id is: " + server.id);  // ERROR! id not available yet as server has not connected.

Finally you need some way to know when a game disconnects so there’s a gamedisconnect message

server.addEventListener('gamedisconnect`, function(data, id) {
  console.log("Some other game " + id + " disconnected");
});

I don’t know if this post made any sense. It kind of ended up being like docs. Partly I just wanted to document the iterations. I spent a lot of time making the NetGame implementation and testing it only to throw it all way. Even after I threw it away I went through a few more smaller refactorings.

The first one was I made up a gameid command to pass back the gameid. I didn’t like that at all though. It took me a while to figure out how to pass it back on the connect message where it seemed like it belonged. Another thing that happened at the start was I had a 2 ideas per game. The generated id AND a user assigned id. It took a while to come back to just 1 id. Either the on you assign or the one you let the system assign for you.

I’m feeling relatively confident that what I ended up with is a good solution. I guess one more thing though is that I didn’t push out a version until I felt good about it. Sure there aren’t lots of devs yet but taking this stuff seriously will hopefully more confidence that I won’t have to make future breaking changes.

The Story of HappyFunTimes

I never intended to make HappyFunTimes what it is today. This is I guess an example of what happens when you just do something. Things happen.

It started off when I was working on Chrome. I learned about WebSockets. I might have seen some tutorial on how easy they are to use. I think I read about Socket.IO, a popular library that can use WebSockets and it just occured me, as it has several others, that it would be easy to use WebSockets to make certain kinds of games.

My first game was PowPow. You can see the commit history shows it was made around April 10, 2011. That’s 3 years before I started on HappyFunTimes. In fact the video linked to on that page is from April 8th. At the time I had people using their laptops as controllers. After that one day playing I tried making phone controllers. Being April 2011 it was still common for Android phones NOT to have multi-touch or to have broken multi-touch so if you go look at the code in that repo you’ll see the iPhone controls are Left/Right/Fire (3 fingers) but the Android controls are “point the direction you want to go, tap to fire” (1 finger)

At the time I thought it would be good to make a library but when you’re working full time, or when I am, it’s often hard to find motivation to do things outside of work. I suppose that’s kind of stupid since I made PowPow outside of work but it only took a few days. So, I guess I have no idea why I find motivation for some things and not others. If I had infinite time and infinite motivation there are sooo many things I’d work on.

As a side note, in 2012 I used the same tech for our Molyjam game, “Octopi Everything” which I plan to port to HappyFunTimes (if I can motivate myself :P)

Then last year in June 2013 I quit my job at Google. I traveled and goofed off and didn’t really know what I wanted to do. In March I found myself in Kyoto for Bitsummit. There I met Eddie Lee and Kalin of Funktronic Labs along with Sagar Patel, Andrew Palmer, and Edwon. Also in Tokyo I had previously met Alvin Phu and they were all so inspring. Everyone was working on something. Alvin in particular had a fulltime job with crazy Japanese overtime and still was working his ass off on his own game.

So, I started feeling like I should get off my ass and start working on something. I still had no idea what but I should at least spend time making something, anything. I thought about it and though, “ok, fine. I guess I’ll turn that code from powpow and octopi into a library finally and then maybe make a mobile game after”. I thought it would take at most a couple of weeks. I didn’t intend to make any money. I just thought it would be fun to put out the library and maybe have a game jam (which I still need to do!)

And, it did only take a couple of weeks at most. A few days to pull out the library. A few hours to make the first sample. But, if you’ve been to a game jam in the last few years or paying attention to indie dev everyone and their sister is using Unity3D. So, I felt like if I wanted to get any usage I needed a Unity3D version so you could make the games in Unity. Since the controllers have to be written in JavaScript I needed JSON support for Unity because JSON is how JavaScript communicates. There’s something called JSON.Net but it didn’t fit my use case. It’s a fine library I guess but in order to support the features I needed it required .NET 4.0 and Unity only supports .NET 2.0. So, I had to write my own. That was probably several days of work. As another aside I find it super frustrating to think “I’m going to do X and I’ll be done in a couple of hours” only to find that I first have to do “Y” which itself is going to take hours to days. I did get to learn some deep dark secrets of .NET though and with that working I reproduced the simple example in Unity

Next up I thought I should try dual stick controls. Partly because I wanted to make a unity example that shows walking a character around. So I hacked together ShootShoot.

With that working I got a unity character example working which didn’t take too long but took longer than expected dealing with UnityScript vs C# issues.

After that I wanted to see how a platformer would play so I threw together JumpJump and shortly after that I decided I wanted to make something showing off round based play among other things and wrote BoomBoom.

I ran into another issue which was I could not get consistent performance out of Chrome using the Canvas 2D api so I ended up writing JumpJump and BoomBoom in WebGL. That ended up making some useful libraries like a single quad single draw call tile map renderer as well as a runtime color adjustable sprite system.

In writing these games though things kept popping up. For example, originally you’d need to go to long and complex Urls. To play jumpjump for example you might open a browser and go to http://localhost:8080/examples/jumpjump/gameview.html then you’d get out your phone and go to http://192.168.2.9:8080/examples/jumpjump/index.html. That’s a lot to type, especially on a phone. Of course I used bookmarks and other things to make it go faster but eventually I got tired of typing so I thought, “hmm, I’ll write a script that generates an index.html that lists all the controllers”. I wrote that. I also wrote ones to list the games. Now I could go to http://localhost:8080/games.html to pick a game and controllers could go to http://192.168.2.9:8080/ and pick the corresponding game. That was much better. So much less typing.

But then, I realized if there’s only one game running why not just send the controller there automatically. So added a script to the page contollers go to that lists the games to check which games are running. If there is only one just go to it. This was awesome. Now I’d start a game, then on the phone I’d just go to http://192.168.2.9:8080 and it would automatically join the game! It seemed so awesome!

That led to the next step. Using the same code, when game disconnects the phones get notified so I used the same code that checks if any other games are running. If there is only 1 game running I jump to that game. The effect was that the system felt like a virtual console. I’d start it up, phones would connect, they’d jump into the game, and if I switched games they’d all jump to the new game. This was feeling really really great. There was even the added and unintended bonus that I reloaded the same game the controllers would see that as the one game running and reconnect. That was great for development. I’d tweak the game and click “reload” in the browser. That would have the effect of having all the controllers auto-reload. Faster iteration times FTW!

It still sucked though to ask people to go to their phone and type in something like http://192.168.2.9:8080. I knew about Captive Portals. They are those things you see when you use hotel WiFi or coffee shop WiFi and it asks you to log in inside the browser. If I could get HappyFunTimes to support something like that I could make it so when players connect to the WiFi they automatically connect to the game, no typing anything at all. It took a few days but I got it working. Note that feature only works on iOS and it only works if you configure your router a certain way to let HappyFunTimes respond to certain requires but the effect is pretty amazing. On Android some of the same code means if HappyFunTimes is setup this way users can just got to any Url to connect so I tell them go to to h.com or something like that and they connect.

These things are simple to explain and maybe it seems obvious but my impression is most people don’t really get it until they see it in action. I think even tech heads think “Yea, type some long address and you’re in” but when I actually demo HappyFunTimes in a room full of people and they see everyone effortlessly connect and play some games and they see me switch everyone to new games and go through all the demos it’s pretty impressive.

Announcing HappyFunTimes got a few people using it and I quickly realized I had some problems. All the games had to be checked into the same repo, or at least there was no easy way to separate individual games from the system. On top of that I had tried to show it at a certain event run by industry people. I sent them a link thinking “these are game developers, they won’t have a problem following the 5 steps to install to check it out”. Instead I got back a message something like “Wow, that looks hard”. Of course at the time I didn’t intend for end users or regular gamers to install it but gees!!, if an actual developer was bitching about installing node.js and cloning a git repo then there’s no way anyone else is ever going to get anywhere except for the most dedicated.

So, those two issues led to do things.

  1. I absolutely had to make an installer for at least Windows and OSX

    It had just install and work, no setup.

  2. I had to find a way to separate the games and make it easy for others to add their own games to the system.

Those two things led to several features. For the installer it wasn’t enough just to install. I also had to come up with a way to easily connect phones to the local game without having to configure your router and without having to type long cryptic Urls.

My first solution was to make happyfuntimes.net and write a script that scanned for the local happyfuntimes. Basically if you’re running Chrome on Android it could figure out your local ip address. Say 192.168.2.37. It would then ping every address on that network and see if it got the correct response. It worked! But, iOS Safari doesn’t have the feature to look up the local ip address. My next solution was if I can’t find out the local ip address then I’ll just guess. Most routers use a common set of addresses. I’ll just try them all. Unfortunately trying them all took > 5 minutes. I added some heuristics to guess better and therefore faster but it mostly didn’t work well.

Then the more obvious ideas was I should change happyfuntimes.net so when happyfuntimes starts it tells happyfuntimes.net its ip address. When a phone goes to happyfuntimes.net, happyfuntimes.net can see the matching ip address and tell the phone where to go. Problem solved!! Telling users to go to happyfuntimes.net is not as nice as auto-connecting but it’s not a cryptic Url so it’s easy to explain to users. Of course I wish is was just hft.com or something simularly short but short URLs are expensive 🙁

Next up was separating the games. npm, the node package manager, suggested a way to do it. It took a lot of trial and error though to finally get it working but the result is http://superhappyfuntimes.net and the related system.

The funny thing is though I never intended to take it this far. Each piece is just the next logical step as I built things up. I don’t know if there is anything to take away from that except that just doing stuff for the hell of it often leads places. Make some simple game or demo or app and you’ll likely end up with pieces of code or tech that you can use on the next thing or you’ll see how to tweak what you’re making into the something else and after a while you’ve made way more than you ever expected. I guess like they say, “Just do it!”

Why JavaScript

There are several reasons.

  1. It means no install required. Users can show up at some event and participate immediately.

    Potentially even other phones like Firefox OS phones or Windows phones or Xiaomi Phones should all work.

  2. It requires no approval from Apple.

    I’m happy that Apple seemingly does a good job of keeping malware off of iOS but I’m not so happy that they have to approve every app. Even if your app is not malware they might say no.

  3. It lets anyone make a custom controller.

    Theoretically you could use any language but Apple strikes again. Even if I decided to make an app Apple does not allow code to be downloaded into an iOS app except for JavaScript executed by Safari embedded into your app. So, even if I made an app, JavaScript is the only choice Apple allows. Of course you’re always free to transpile from some other language into JavaScript. With iOS8 now finally supporting WebGL that means in the near future the sky’s the limit on where to go with controllers in JavaScript! I’m looking forward to what people come up with.