All posts by greggman

Sony Playlink

So Sony announced Playlink at E3 this year 2017.

It’s a little frustrating. It’s basically HappyFunTimes.

The part that’s frustrating is in that video Shuhei Yoshida is happily playing a Playlink game and yet about a year ago I saw Shuhei Yoshida at a Bitsummit 2016 party and I showed him a video of happyfuntimes. He told me using phones as a controller was a stupid idea. Is objection was that phone controls are too mushy and laggy. He didn’t have the foresight to see that not all games need precise controls to be fun. And yet here he is a year later playing Playlink which is the same thing as happyfuntimes.

In 2014 I also showed Konou Tsutomu happyfuntimes at a party and even suggested a “Playstation Party” channel with games for more than 4 players using the system. My hope was maybe he’d get excited about it and bring it up at Sony but he seemed uninterested.

Some people don’t see the similarity but I’d like to point out that there are

  • There are happyfuntimes games where you draw on the phone
  • There are happyfuntimes games where you use a virtual dpad
  • There are happyfuntimes games where you tilt and orient the phone like a Wiimote
  • There are happyfuntimes games where you set the phone on the table and spin it
  • There are happyfuntimes games where you’re given various menus of choices
  • There are happyfuntimes games that take live video from the phone and display it in the game
  • There are happyfuntimes games that use the phone like Google Cardboard, multiple people looking in shared VR
  • There are happyfuntimes games that play sounds from the phone
  • There are happyfuntimes games with asymmetric controls where
    • One player is the driver (uses phone like Wii MarioKart Wiimote)
    • One player is the navigator (map only on his phone so has to direct driver)
    • Two players are chefs making pizzas, pretending phones are boxes of ingredients

And many others.

And of course there are also games you could not easily play on PS4 like this giant game where players control bunnies or this game using 6 screens.

And to Shuhei’s objection that the controls are not precise enough

You just have to design the right games. Happyfuntimes would not be any good for Street Fighter but that doesn’t mean there aren’t still an infinite variety of games it would be good for.

In any case I’m not upset about it. I doubt that Shuhei had much to do with Playlink directly I doubt Konou even brought it up at Sony. I think the basic idea is actually a pretty obvious idea. Mostly it just reinforces something I already knew. That pitching and negotiation skills are incredibly important. If I had really wanted happyfuntimes to become PS4 Playlink I should have pitched it much harder and more officially than showing it casually at a party to gauge interest. It’s only slightly annoying to have been shot down by the same guy that announced their own version of the same thing. 😜

In any case, if you want to experiment with games that support lots of players happyfuntimes is still a free and open source project available for Unity and/or HTML5/Electron. I’d love to see and play your games!

PS: this was reposted from my personal blog.

happyFunTimes standalone HTML5 library

I finally got around to making happyfuntimes a standalone library for Electron. This means you can easily make an HTML5 game and ship it as a native app on Windows, Mac, Linux with happyfuntimes support.

As examples I’ve posted 3 of the games on

I also updated the hft-simple example and I added a new “clean” example that uses no external libraries so it should be easier to use as a base to intergrate with other HTML5 game engines.

Even if you don’t plan to use happyfuntimes they might be a good way to look into shipping your HTML5 app as an electron app. In just a few minutes they’ll build standalone app for Windows, Mac, or Linux.

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 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, 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>

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.