Defender's Quest 2 Engine progress - resolution!

A big thing I'm trying to work on for the DQ2 engine is robust support for multiple resolutions, particularly HD. The previous game was hard-locked to 800x600.

Here's a screenshot from today's build of the DQ2 engine, using the DQ1 data set:

I'd post it in 1080p, but that's so big I need a fancier screenshot solution and I'm lazy so you can have 1600x900 for now.

I want to really nail this feature down as so many other things depend on it. The user interface has to scale properly (part of why I'm investing so much effort into that feature, source code available for free as flixel-ui, which has been adopted as the official UI solution for HaxeFlixel).

So far the current build lets me play through a lot of the DQ1 content (even importing old save files) -- of course battles and cutscenes are stubbed out for now until I can deal with scaling issues from resolution stuff, but this is great progress.

This does mean that technically we could re-release DQ1 in the new engine, but we're not committed to that just yet (though it remains an option).

You can read more in my Defender's Quest II devlog in the official Level Up Labs forum.

An Algorithm for Discovering "Hidden Gems"

So you've probably seen that Ars Technica article that has magically reverse-engineered every steam game's  gross (sales+free-key-redemption) numbers.

Everyone's talking about this graph:

The obvious first statement is "WOWS! Video games are a hit-driven business!!!" For what it's worth, our game Defender's Quest is probably located somewhere between 800-1200 on that graph, and we're doing just fine.

But what about the game at 2600? And what's going to happen when Steam totally opens the floodgates?

Every developer I know has a list of obscure indie games they know are great, but just can't get the exposure they deserve. Jay Barson talks about this phenomenon in his recent article The Best-Kept Secrets. (Incidentally, if you like CRPG's and haven't bought Frayed Knights yet, do yourself a favor and grab it)

Here's Jay (emphases mine):

A friend told me about an experiment in inequality and the “cultural” marketplace. Test audiences were exposed to new music, and invited to download and keep some songs. The songs had indicators of how much they’d already been downloaded. Some of the songs had an artificially inflated number. What they discovered is that the artificially inflated number helped the popularity of some songs within the controlled audience, but could not others.

In other words – some songs had hit potential and others did not. If a song had both hit potential and an apparent wave of popularity behind it, it could take off. A song that sucked rarely did well. Hit potential could not guarantee success, but it’s lack could guarantee the lack of success – or at least a large success. In other words, the distorted perception of popularity had some effect, but was not the sole contributor to the success or failure of the song.

Right now stores like Steam and the App store are dominated by "top selling/grossing/downloaded" charts, which all suffer from the same problem -- the charts are self-reinforcing and prone to freezing, thus encouraging shady behavior. You can mitigate this effect in various ways (such as sampling over a shorter time, as Steam seems to do), but the problem remains -- the games on top stay on top.

My twitter friends are constantly trying to personally give visibility for such "hidden gems" and I think that's admirable, and we should keep doing stuff like that. At the same time, I think we can supplement those efforts with some mathematical tools.

Here's the idea -- if the above experiment's results are applicable to video games, there might just be a way to build a "hidden gem" detector, given access to the right data. What we're looking for is some quantifiable way to find a game that people really seem to like, but that hasn't yet had a chance to be popular. The kind of game my twitter friends are talking about when they say, "RT! Man, <game X> is wonderful, such a shame no-one has heard of it."

Building a "Hidden Gem" detector

What we're looking for is games with high engagement stats but low overall popularity. The data Ars Technica has been working with is truly awesome, but for these purposes it's a bit thin -- all we've got is gross units owned by players (lumping together actual sales with steam key redemptions), and some play time stats which have some known reliability issues.

But Steam has access to better data than that. Steam knows exactly how many copies of each game have been sold as well as the number of concurrent players, all down to the hour, region, and platform. It also has overall playtime stats per player, though that might be less reliable. There's also conversion rates for games that have demos, achievement data, and more. And of course, there's also the recently-added user reviews.

In short, Steam itself has plenty of data, both private and public, to make a pretty good guess at overall player engagement for a particular title. For "traditional" games, a higher-than-average playtime is a good heuristic for engagement, and for short-form games like Dear Esther, some metric for "completed the experience," such as a specially marked achievement, could work. Or we could just follow Kongregate's example and simply go by user rating, as I suggested in a previous article. (I personally prefer something closer to the Tomatometer over anything like MetaCritic scores).

The key is you have to be careful not only with what you measure, but how you measure it. Give these two articles a quick read before proceeding. It'll just take a minute:

How not to sort by average rating
reddit's new comment sorting system 

Back already? Great.

As those articles detailed, the ranking system should measure something other than raw popularity. Otherwise, the first item to get close to the top gets seen more, and thus collects more (sales/upvotes/downloads) and the cycle continues. The ranking system should also automatically take into account uncertainty based on sample size.

If you're ranking based on an engagement stat like play-time, or by user rating, then getting to the top does not guarantee that a game will stay there. In fact, the influx of new eyeballs will more than likely kick the game down a few notches as it gets exposed to a wider audience. This way, only games with high engagement --regardless of popularity-- will be able to stay at the top of the charts for a long time, which is how it should be. The chart is self-correcting rather than self-reinforcing.


Quick example: imagine a single-player RPG with median playtime of 5-10 hours -- well above the average for Steam games, but with less than 2,000 sales. This should be easy to detect. Or one of those crazy avant-garde "experience" games, the kind you only play once but it's amazing. Say that game has 2 hours median playtime, but 90% of it's 3,000 or so players have gone all the way through. This should stand out, too.

We don't have to get super-detail-oriented with this. In a world where 37% of player's Steam games haven't even been loaded a single time, it should be easy to make some simple broad-strokes guesses and pick out games that make you say: "wowzers! A small niche of folks really love this thing."

Let's make a "hidden gems" list for those.


Limitations

The "hidden gem" detector isn't a silver bullet. It doesn't make the game of platform power go away, nor does it solve the structural, sociocultural and/or economic issues that favor the big boys. It also does nothing for games that aren't already on Steam (though Valve has given every indication they're going to let just about everybody in eventually). Here's a few other issues.

Beloved by Niche, Hated by Mainstream
If the "Hidden Gems" list is featured right on the steam front-page, then a lot of cool, weird stuff that's beloved by small fanbases will shoot to the top of the list. Immediately afterwards, there's a fair chance the mass market will cast its withering gaze upon it like the Eye of Sauron and mercilessly smack it down faster than you can say "Walking Simulator." So, perhaps hidden gem lists should be segregated into their natural niches, using steam tags, or an amazon/netflix-style recommendation engine?

On the other hand, you never know what seemingly crazy game idea will actually catch on if it's just given a chance with the mass market. This is exactly the kind of tool that could bring us the next Goat Simulator.

Different Strokes for Different Folks
As I mentioned above, you can't use a one-size-fits-all engagement heuristic to catch all the gems. "Did you finish it?" is much more relevant to judging overall engagement for Dear Esther or The Stanley Parable than it is for World of Warcraft or Dwarf Fortress. Since the whole point of this is to identify interesting things that would normally be passed over, special care will have to be taken with the various heuristics used. And what about things that are harder to measure like Proteus? I'm confident there are ways to detect people's interest in these things, but we'll have to be smart about it.

We Won't Find Everything
This method can't possibly find all the gems, nor should we expect it to. It's just another tool, and that's important to remember. It won't fix everything, but it could help make things a lot "less worse."


Gaming the Charts
Anytime you have a system where charts drive sales, it encourages people to game the charts. If it measures downloads, you drop your price to zero, cross-promote, and use your own money to inflate your stats. So I could easily imagine similar scams if we're measuring user playtime -- with proverbial goldfarmers idling steam games to inflate their client's chart positions. Safeguards could be put in for this -- it should be pretty easy to look at other metrics to detect if someone is "idlefarming" for chart position. Of course, cheating of any form is always an arms race, with the only final solution being to make it not worth the cheater's time and money to cheat in the first place. Which brings me to my next point.

Moving beyond Charts

By itself, I don't think another chart on the steam front page is going to make a huge difference -- being hand-picked for a feature still makes a world of difference and most Steam developers put their marketing efforts into securing that rather than trying to micro-manage the charts.

Valve has said their vision for Steam's future is that anyone can make a steam front page and curate it themselves. The algorithm I've described above could be used not just by automated charts, but by actual human curators. You wouldn't have to expose any sensitive data (like sales or playtime), just give curators the ability to look for these kinds of patterns with advanced search tools.

Right now, if I want to promote an obscure indie game, it has to already be on my radar. How cool would it be if I could just whip out my Hidden Gem Detector and go treasure hunting instead?

Nobuo Uematsu to work on Defender's Quest 2

So I promised everybody some news. I was originally going to post this yesterday, but that just happened to be Liar's Day, so we decided to wait one more day.

Here's the press release we sent out to some journalists:

Level Up Labs is pleased to announce that Defender's Quest II: Mist of Ruin, will feature a main theme composed by none other than Nobuo Uematsu, the world-famous video game composer best known for his work on the classic Final Fantasy series. Collaborating with him will be Kevin Penkin, the composer for the original Defender's Quest: Valley of the Forgotten.

"We're extremely excited to be working with Uematsu-san for our next project." says programmer Lars Doucet. "I remember playing the first Final Fantasy game when I was just a kid, and in an age when most games had nothing but simple electronic blips, I was struck by how I was listening to real music. His music elevated the story-telling and really set the standard that all games are based on today."

Defender's Quest II is currently under development for Windows, Mac, and Linux, and will also feature the artwork of famous animator Dean Dodrill, best known for his million-selling indie blockbuster, Dust: An Elysian Tail.

We are incredibly excited to finally be announcing this. We are very grateful to everyone who helped us with this, particularly Kevin Penkin and Hiroaki Yura.


In case you missed it, we posted a big update about Defender's Quest 2's progress yesterday. We're still taking preorders for Defender's Quest II, and if you haven't played the original yet, or want to grab a cheap copy for a friend, there's still a day or so left on the Humble Weekly Bundle: Celebrating Open Source, which offers the original Defender's Quest.

Allow me to repeat:

THIS IS NOT AN APRIL FOOL'S JOKE. THIS IS REAL!!!

If you have any questions, find Myself or Kevin on twitter (and here's Kevin's facebook page).

In semi-related news, I will be part of a group reddit AMA later today at 12:00 Noon Central standard time (I believe that would be 5:00 PM GMT) I will update this post with a link when that goes live. The AMA topic will be in the /r/iAmA subreddit, and the title will be:

"We are the game developers of Anodyne, Defender's Quest, Incredipede, and NEO Scavenger, and the developers of open-source game tools Haxe/OpenFL. Ask Us Anything."

Kevin and I will be there, and since you're free to ask us anything, you can obviously ask us stuff about this news :) Just be sure to also ask the other cool people about the stuff they're doing!

UPDATE: our reddit AMA is live right now!

Defender's Quest 2 March Update

Alrighty! Time for an update on where we are in Defender's Quest 2.

Those of you who follow me on twitter know I've been active, but I sometimes forget that our followers are spread out over multiple channels - our forum, our steam page, our gog page, our newsletter/website, our blog, etc. So, I'm going to try to shift from my "ignore everything but twitter" mode that I've unconsciously slipped into. From now on I'll try to supplement my daily twitter spew with decently-sized blog posts from time to time, and then link to them in all our forums, etc.

What We've Been Doing

First of all, until very recently we've been finishing up the last bits of legacy support for the original Defender's Quest. Now, you might ask, "Why would you spend all that time supporting an old game when you have a shiny new sequel to work on?" Several reasons:

1. It builds up sustainable long-term revenue
2. Our strategy is to slowly build DQ2 preorders over time to avoid Kickstarter-style pressure.
3. Send a clear signal that we really do support our games long-term

We have been doing some DQ2 work in the last few months, of course, but it's mostly been pre-production and part-time engine work. Lots of game mechanics and design depend on the story, and we wanted to give James (our writer) the proper amount of time to go through several drafts.

Oh, and my wife and I had our first baby (as did Anthony and his wife) about 8 months ago. So that's been a little bit of a time-sink :)

All that said, we have gotten plenty of stuff done and have some things to show. Alpha and Beta are still a ways off, and the official final release date is "When It's Done."


First I'm going to talk about the DQ1 legacy support we've been working on, then I'll get to the DQ2 stuff.

DQ1 Stuff

Six languages!

 

The biggest thing we've done for DQ1 legacy support is add five foreign language packs -- German, Japanese, Czech, Korean, and Russian. We contracted Fabian Bindel and Thomas Faust for our German translation, and worked with PLAYISM, a Japanese PC games publisher, for our Japanese translation. The japanese version just recently launched on their site (english page here).

The Czech, Korean and Russian translations were generously provided by awesome fan volunteers. (The Czech translation was provided by our own forum superstar 'coyot', the Korean translation was done by Team.SM, and the Russian translation by a large group of fans). It was a lot of work to get all these translations working, particularly when it came to user interface and font stuff, but we've learned a lot from the experience, and thanks to all that, DQ2's localization process will be a lot smoother.

In fact, we've already written the framework and released it under MIT license on Github, behold -- FireTongue! Like the rest of DQ2, it's written in Haxe, and is already being used in other cross-platform games, like this one! It was even featured in a brief talk at this year's GDC localization summit.

SteamOS, bugs, etc

We fixed a lot of bugs and  have been working on getting DQ1 running on SteamOS ever since we attended Steam Dev Days. Since DQ1 is still stuck with Adobe AIR, this is not an easy task. Although we have a good solution for regular Linux distributions (Ubuntu, Mint, etc), SteamOS is harder to get working. The difference is that SteamOS has a unique default setup that changes how the default user interacts with commands like sudo.

It's easy enough to work around it on my SteamBox by messing with the configuration, but we need to create a simple script that will work flawlessly for any user using only default factory settings. Thanks to the heroic efforts of Alexander Sturm and the nice folks at Valve, we've finally figured it out, but it's not up and running *just* yet. As you can imagine, I can't wait to have all my tech running natively on Linux via Haxe rather than AIR, as I blogged about recently.

We also need to get a Linux build ready for GOG Linux. Given that the intersection of GOG players and Linux users are solidly unified in their hatred of Adobe AIR, this is more of a delicate communication problem for us to solve rather than a technical one, but we'll get it sorted out soon enough.

Thagomizing

Finally, I've been steadily looking for opportunities to chase DQ1's "Stegosaurus Tail." You can read the linked article to get the full story, but the short version is that we've made more money in the second year of release than in the first.

By relentlessly chasing down promotional opportunities, we can keep introducing brand new people to DQ1, keep the bank account afloat, and thanks to our silly mini-ARG update, let new players know about DQ2 and drive pre-orders. Maintaining DQ1 sales is important because we don't want to rely entirely on pre-order revenue; the entire purpose of running a low-key "anti-kickstarter" is to avoid the intense pressure and hype usually associated with traditional crowdfunding drives.

FUN FACT: in the aftermath of writing the aforementioned article, I learned that the proper scientific term for the spiky bit of a stegosaurus tail is a "Thagomizer", originally coined by Gary Larson in a Far Side cartoon, and has since been officially adopted by paleontologists!

So from now on, I'm using the verb "to thagomize" to refer to the act of pursuing promotional opportunities for an old video game in order to drive further sales spikes on the long tail. 

"What you been up to lately?"
"Oh, the usual - coding, blogging, thagomizing."

DQ2 Stuff

Okay, so you probably want to hear about all the DQ2 stuff we've been doing!
Before I go any further, allow me to properly deflate your expectations with a metaphor.

The Iceberg Effect

Here's a picture of an iceberg. Notice that almost all of it is under water, and only a tiny bit pokes above the surface:

Via Wikipedia (source)
Uwe Kils (iceberg) and Wiska Bodo (sky).

A lot of work goes into making a video game, but the only part you can really experience as a player is the bit that pokes above the surface of the water. You see the graphics, the audio, the controls, but you can't see the thousands of lines of code behind the surface that keep the whole structure in order. And even if you could, you couldn't see all the planning, discussion, communication, etc.

When you're watching a game in development, what you're going to see is a whole lot of nothing for a long time, and then suddenly it will seem as if there's a sudden flurry of activity close to the end as stuff finally starts to poke up above the water line.

Only a few of you were following us back in DQ1 pre-alpha days, and absolutely nobody was following us for the whole first year of its development. For most of you (especially post-Steam), DQ1 just arrived fully-formed without having to wait for anything. So, please understand that "visual progress" is a really terrible metric for actual progress.

With all that said, here's what we've go to show for ourselves so far.

Arts!

Karen Petrasko has been working on some new concept art! Here's what the inside of a domed city might look like (click for hi-res mockup):

You can expect the same level of detail/visual fidelity in our battles, though I doubt very many will take place inside of a town. The above is more likely to be used in our in-engine cutscenes for when our characters are in a domed city.

And here's some random bits of concept art:


Top: Domed city exterior and interior Bottom: Emperor, soldiers, scavengers exploring the surface.

Here's a sketch of what our overworld map might look like:

And here's a new character we've been working on, who just goes by the name "Smug Captain" for now:

Dean Dodrill is still on board for this project, but he's had to take some time off to properly support/thagomize his last project, Dust: An Elysian Tail, and recover from a brutal, multi-year development slog. So we don't have any animations to show just yet, but we'll let you know when we do.

Musics!

Meanwhile, Kevin has been working on some of our first music tracks, which you can listen to here:

Defender's Quest 2 concept piece (mp3)
"Enemy City" WIP piece (mp3)
Untitled WIP piece (mp3)

Kevin wants me to SUPER EMPHASIZE that NONE OF THIS IS FINAL, it's all very early/rough work, and it will almost certainly change before the game hits final release.

Programmings!

We've made a lot of progress porting the Defender's Quest engine (known internally as the "TDRPG Engine") over to Haxe/OpenFL. I'm a big fan of open source development, so I'm releasing whatever bits I can as open source, under the MIT license. Since I started doing this, I've been officially accepted as a regular contributor to the HaxeFlixel project, and two of my libraries have been officially adopted into HaxeFlixel itself. The TDRPG engine itself remains private, but I like spinning off little bits of it wherever it makes sense to do so.

My most notable contributions include:

1. flixel-ui: a GUI library made entirely of flixel-native widgets, so you can intermingle them with other flixel objects, rather than awkwardly overlay a UI pane over your flixel canvas. This started by porting over legacy DQ1 code, but has since been massively improved. It's also easy to integrate with firetongue, so automatically making buttons twice as big in German mode is easy!
   
   

   

   This is just a demo -- DQ2 will look much better

   Defender's Quest has an enormous amount of interface, so this and the battle engine represent the bulk of the coding work.
2. flixel-editors: a set of editing tools for flixel. Right now it only has my "Animator" tool, but it should have more stuff soon enough.
   
   

   

   The Animator tool is not for building animations from scratch, but rather for previewing spritesheets in-engine, and building individual animation sets out of frame indeces. It also lets you set "sweet spots" to define where projectiles (for example) should originate in an attack animation, and various other features.
   
   It also comes with built-in support for re-coloring both pixel-based and "HD style" sprites. In the screenshot you can see an example of the latter -- I'm using a sprite from Glitch to test with for now while we work on getting more our own stuff ready.
   
   It's important for us to know what the basic limitations of our tech is so it also has the ability to run rudimentary stress tests. We'll need better benchmarks to really know where the boundaries are, but initial results seem promising, and way better than what DQ1 could handle:
   
   
   We plan on having a cutscene and level editor eventually, too. I haven't decided yet whether those should be open-source, too, but I'm leaning towards it.
   
   Why am I spending so much time with tools and stuff?
   
   50-75% of DQ1's development time was CONTENT CREATION, and LOTS of time was wasted manually processing/integrating content with bare-bones tools (text editors and photoshop, basically).
3. firetongue: my localization framework. Originally ported from DQ1 code, but massively improved.
4. flixel-demos: I didn't create this repository, which showcases various flixel features, but I did contribute these individual demos: cursor, heatmap pathfinding, blend modes, rpg interface, file browse (Note: file browse has to be compiled on native targets to see its full functionality). All of these demos are the result of me testing features we needed for DQ2.
   
   
   

For the rest of my stuff you can see my github profile or open source report card.

NOTE: this is open-source development, so all "my" stuff has received lots of bugfixes and improvements from the HaxeFlixel community, for which I am very grateful.

What's Next?

So there's still a lot of work to be done. I really need to dig into the new battle system engine, and story material is starting to mature. Then we can draw on that for a few story announcements, we can get art from that, get music from that, etc, and roll that all back into the design.

When will Alpha be? I hope to have something playable before the first half of the year is over, but no promises.

Other stuff we're looking into is whether it's worth it or not to plan for a console release. Now, there's no chance we'd be interested in from-scratch ports, so everything depends on us being able to get the Haxe/OpenFL stack working for those systems. In theory, it's possible, it's just a matter of building out the native targets. So far we've made some good progress using HTML5 (believe it or not) for the WiiU's Nintendo Web Framework, but what we'd really like is truly native support on everything, especially the 3DS and PS3/4. We're putting little feelers out and seeing if we can find the right people for this, because I sure as heck can't build it myself. So far we have some promising leads but we can't announce any of that just yet. Let's just say I'm not regretting switching to Haxe.

And in any case, our top priority is getting the game running on Windows/Mac/Linux. If -- and I do emphasize "IF" -- we release on console, we will make sure that is most certainly not at the expense of PC development.

Flash is dead, long live OpenFL!

I've been a stalwart Flash developer for 15 years, so nothing bothers me more than greatly exaggerated reports of Flash's premature demise. Even today, Flash remains a very viable platform with a large install base and a relatively healthy commercial ecosystem. Many awesome games have been written in Flash and/or Adobe AIR, including our own Defender's Quest, which to date has sold over 125,000 copies.

But even a long-time Flash booster like myself can read the signs of the time. Flash may not be dead, but it is certainly dying, and the killer is not Steve Jobs, mobile devices, or HTML5, but Adobe. They are slowly neglecting Flash to death.

They dropped support for the mobile flash player as well as AIR on Linux, handed Flex over to Apache, and cancelled the long-awaited ActionScript 4 standard. Although right this minute the flash player still has a big install base, and AIR remains a great way to reach mobile devices, there's no signs of strong future support. Flash just doesn't seem like a priority for Adobe any more. And MochiMedia's recent shutdown is the canary in the coal mine. As a developer, I don't give a damn whether this is a good financial decision for Adobe -- they yanked the rug out from under me after 15 years of loyal support. "Sorry you invested in our platform and tools, you suckers! But hey, you can totally trust us to support you next time! Subscribe to Creative Cloud!"

So where do we go from here? Unity3D is a popular answer, but it's got major downsides - I have to pay for each platform I want to support, and the web browser target depends on a clunky plugin with a low install base.  But worst of all, it's just another proprietary platform. Sure, Unity is the bee's knees now, but who's to say it'll always be that way? Just ask all the loyal XNA developers who Microsoft left hanging out to dry. And if there's a bug or missing feature, I have to wait for Unity to get around to fixing it. This works for some people -- and I wish them all the best -- but it's just not for me.

I've learned my lesson -- whatever my next platform is, no-one should be able to take it away from me.

I could try HTML5, but that precludes releasing high-performance desktop-ready games for Steam.

I could try going with a custom engine in raw C++, or something like Java or C#, but it'll be a lot of manual work to get true cross-platform support, especially if I want a unified code base to compile it all from.

I need something open-source, so I don't have to wait months or years for basic features or bugfixes. And shucks, it'd be nice to have the same API as Flash so porting my old code isn't a nightmare.

What's that you say? This magical chocolate pony of dreams exists? Why yes, it's called OpenFL!

 

OpenFL is an implementation of the Flash API written in the Haxe programming language. Never heard of it? Maybe you've heard of a certain BAFTA-award-winning game that makes use of it:

Basically, you write your code in Haxe, then you link against the OpenFL library to get the functionality of the Flash API. This means:


You just keep making flash games, but you also get mac, windows, linux, and mobile targets, all at native speed!

Even better, you can keep using a lot of the same tools. The FlashDevelop IDE, very popular with Actionscript coders, has excellent support for Haxe. "Fine, fine, I can port my code over easily enough. But what about all my flash art stuff?" Not to worry - you can keep using the Flash authoring tool and its native flash vector animations if you like. That's because OpenFL recently released their swf library for free, which lets you use SWF animations and assets in both your flash and C++ targets.

Don't believe me?

That's an animated gif recording of a C++ build I made in Haxe/OpenFL about 20 minutes ago. 

Here it is in flash SWF format. 

Here is is in windows EXE format.

Here's the original source code.

Many of you might have heard of Haxe and/or OpenFL before, and I admit it can be really confusing to get started, so let me break everything down real easy. 

Our particular tech stack for Defender's Quest II: Mist of Ruin looks like this, with the highest-level abstractions on top, and lowest-level stuff on bottom:

(Don't try googling TD-RPG, that's my own proprietary engine. The rest of it is all online and free, though!)

Haxe - the language layer

At the very bottom you have Haxe itself, the language you're using to write code in. Basically, you write code in Haxe, and the special Haxe compiler turns your high-level Haxe code into source code from other languages depending on what flags you pass in. Using Haxe by itself requires little more than a command line and a text editor. 

You can certainly write cross-platform games using nothing but Haxe, but that's kind of hard-core. The haxe compiler will just spit out a bunch of c++ code, or javascript, or whatever, which for idiots like me isn't very useful. This is where OpenFL and lime come in.

I should mention that I'm simplifying things a bit here. Before we get to lime/OpenFL, there's some crazy magical bootstrapping that happens in the background, with the Haxe compiler using the hxlibc and/or hxcpp libraries, but I'm trying to make this as friendly as possible for newcomers without getting lost in all the details. Just keep in mind that I'm giving you a broad-strokes overview.

Lime - low-level graphics layer

One step up from bare-metal haxe programming is lime, which stands for "Lightweight Media Engine." Lime is part of the OpenFL project, and provides a simple, lightweight, and cross-platform drawing API. This handles things like windowing, asset loading, blitting pixels, drawing routines, and interfacing with OpenGL, OpenGL ES, and SDL stuff.

Also, lime makes cross-platform support a bit easier. Whereas Haxe has output targets like "c++", "javascript", "c#", etc, lime has output targets like "mac", "windows", "linux", "android", "ios", and so forth. Mac, Windows, and Linux targets all use C++ code, but they need special tweaks to properly handle file i/o, windowing, etc. The Haxe compiler and hxlibc/hxcpp libraries bootstrap your native targets, and lime sets up all the input/output/display boilerplate for you.

You can totally make games just with lime, without ever touching OpenFL. In fact, having lime as a separate library is a recent development -- before all of those routines were just part of OpenFL. This caused two problems:

1. OpenFL had a lot of boilerplate stuff that wasn't related to the Flash API, which was confusing
2. Some Haxe developers wanted cross-platform support, but didn't want the Flash API

Splitting lime off into its own lower-level thing solved both problems. Now all the basic drawing guts are in lime, and if you hate the Flash API and wish it would to die in a fire, you never have to touch it -- just use lime and be happy!

OpenFL - high-level graphics layer + the Flash API 

On top of lime is OpenFL itself. Here we have higher-level graphics calls, with abstraction layers and a flash-style display list. In fact, we even have the same package structure. In Flash Actionscript, you could always do stuff like this:

import flash.display.Sprite;
var mySprite:Sprite = new Sprite();
addChild(mySprite);

In OpenFL, you can do the same exact thing. Sprites, MovieClips, the display list, the stage, events, etc, are all handled just like in Flash.

Some minor differences include audio -- it works fine on different platforms, but since OpenFL is a fully open-source project, they can't cover the draconian world of mp3 licensing the way Adobe can, so mp3 playback only works on flash target. For everything else, you use ogg or wav files. In my experience, this isn't a huge downside since I really hate the limitations of the mp3 format (every Flash dev who's ever tried to get seamless mp3 looping to work knows what I'm talking about!)

One thing to drive home -- if you use OpenFL, you can create exactly the same flash content you can create right now in ActionScript. That's because in the Flash target, you're making an actual swf file, and all you have to do to access the Flash API is use it -- the flash player has all that functionality built-in. On native targets, the OpenFL developers had to actually re-build the same functionality with C++ code, etc. So far there's feature parity for pretty much everything except for some of the less-common features (filters and shaders, as well as right-to-left font support for Hebrew/Arabic text, for instance). It's open-source of course, so those little gaps can always be filled later. At the moment, mirroring the Stage3D API on non-flash targets requires some special libraries, and there are many alternative 3D engines for Haxe (see below).

OpenFL also tacks on a few quality-of-life features that the Flash pipeline doesn't have. Chiefly, asset libraries. In the old days, if I wanted to embed audio or image assets into my swf file, I had to add them all line by line, and set up individual class names to instantiate them with in my code. With OpenFL, thanks to the crazy black magic of Haxe Macros, OpenFL scans your game's asset folder at compile time and automatically generates all the necessary embedding boilerplate. All you have to do is put assets in the folder, then fetch by filename with one line of code:


var image = Assets.getBitmapData("filename.png");       

Whereas embedding hundreds of images in Flash games is a huge chore, in OpenFL it's as easy as hitting "compile!"

Many game developers will want to stop at this layer -- at the OpenFL stage, you have the same amount of functionality as you'd have using the FlexSDK to make a flash game. But some of us like fancy game frameworks like Flixel, FlashPunk, and Starling that handle cool stuff like collisions, states, controls, cameras, etc. These and many others have been ported to Haxe as HaxeFlixel, HaxePunk, and HaxeStarling.

HaxeFlixel (my personal favorite), is the most popular, and I can't recommend it highly enough. The others I've never used so I can't vouch for them directly, but I have heard many good things about HaxePunk.

HaxeFlixel - game framework layer

HaxeFlixel is the Haxe project that I use most. Not only is it the #1 most-starred Haxe repo on all of github, it's simple, easy-to-use, and comes chock-full-of documentation and examples. Contrary to what many of the pixel-tastic example games might imply, it handles HD-style graphics just fine.

HaxeFlixel has built-in support Nape Physics, Gamepad support, Collision & Grouping, Cameras, Tweening, User Interface, and much more! Some of these features (physics, gamepad, etc) come from separate libraries (Nape) or emanate from lime/OpenFL (Gamepads), but HaxeFlixel wraps them up and makes them easy to use in games. Do keep in mind all those web demos use the flash target -- the native targets are so much faster.

Obviously, I'm biased since I'm now part of the core HaxeFlixel team --  I maintain the flixel-ui and flixel-editors add-on repositories.  Some other Haxe projects I've contributed to include my open-source localization framework firetongue (as seen at GDC 2014 localization summit!), and my economic simulator, bazaarBot.


If you want to get started making a nice 2D game in Haxe right now, and you want to deploy to Flash, Mac/Windows/Linux, Android, iOS, or OUYA, HaxeFlixel has got your back.

What about HTML5?

So, HTML5 is a buzzword these days -- how does Haxe/OpenFL stack up in that regards?

Well, at the lowest level you can just write JavaScript in Haxe, and it will generate JS just fine, with the added benefit of enforcing type-safety and other niceties that make JavaScript development more palatable.

If you don't want to reinvent the wheel, you can use OpenFL. Now, OpenFL's HTML5 target, as of this writing, is the least mature of all its supported platforms. However, it's been getting a lot of love recently and in the last few weeks has made some amazing strides. I predict we'll have a fully mature HTML5 target very soon.

How cool will it be when you can natively compile your game not just for mac/windows/linux, iOS, Android, and flash, but ALSO HTML5, all from the same source code base?

UPDATE:
Just a few hours after I posted this, OpenFL just posted this on their website:
Flash AND HTML5, Unicorns exist!
Nice!

What about consoles?

Okay, so Haxe/OpenFL can target all these amazing platforms. What about consoles?

First of all, Haxe/OpenFL already has great support for the first wave of "Microconsoles," such as the OUYA, Gamestick, Nvidia Shield, MOJO, etc. Also, Grapefrukt Games' Rymdkapsel uses Haxe/OpenFL and some crazy black magic to somehow run on a PlayStation Vita. As for Valve's Steam Machines, those run SteamOS, which is just linux, so that's already in the bag.  Theoretically, there's no reason the community couldn't get Haxe up and running on any arbitrary platform, even your toaster. Heck, it's already running on a Raspberry Pi!

"Fine, fine, fine, but what about Next-Gen Consoles!?"

In practice, adding support for tightly-controlled proprietary consoles is tricky -- the biggest problem being the "NDA veil." The good thing is the whole Haxe/OpenFL stack is MIT-licensed, so there's no skittishness from console partners the way there is with GPL code. However, if OpenFL were to build a, say, native PS4 target, any proprietary bits could only be shared with other developers also under NDA's, which makes code hosting and collaboration difficult -- you can't just stick it on a public Github repo. There's currently a lot of community interest in WiiU, 3DS, PS4, and PSVita, but this will probably take some time (and paperwork!).

I think we will eventually make headway here as Haxe/OpenFL continues to gain adoption, but in the meantime we have an unexpected secret weapon:

 HTML5.

It's public knowledge that the WiiU has Nintendo Web Framework, a first-class HTML5 target for making games and apps.  It's also public knowledge that the PS4 uses WebGL and HTML5, though I don't know if any games actually use it just yet. And I've heard credible rumors that XBOX One might eventually have the same functionality -- it's in IE 11, after all, and they pushed it hard on their phones and tablets.

Based on some preliminary results, openfl-html5 has been able to push a pretty large amount of 2D sprites in HD resolutions when running on PC web browsers. That's more than enough for a 2D game like Defender's Quest, and it seems like a good way to get our foot in the door. Native console development would be way more powerful (and way more expensive) but if we don't need the horsepower, why not take the easy road for now?

Even better, on consoles, one of the big limitations of HTML5 goes away - cross-browser compatibility. Whatever HTML5 support they have on a console is a non-moving target, so you can just create a specific configuration optimized for Nintendo Web Framework, and whatever hypothetical things Sony and MS may or may not announce.

There's also another alternative HTML5 backend in the works, openfl-bitfive, which seems promising and should let us do similar things.

Limitations

Okay, so what's the catch? Haxe/OpenFL can't be all roses and sunshine, right? I'd be remiss not to mention some of the downsides.


Documentation is a bit thin
Haxe hasn't been well documented in the past. The community is steadily improving this, but the go-to way to learn Haxe still remains: "Find someone who knows Haxe and ask them lots of questions." Now that we've finally got actual organizations like the Haxe Foundation and OpenFL Technologies driving things forward, things are gradually getting better.

Here's some good starting points:
Haxe Reference Guide 
Haxe Manual (Work In Progress)
Haxe API
OpenFL's getting started guide
HaxeFlixel's getting started guide

One thing to keep in mind is that the OpenFL API mirrors the Flash API -- so 90% of the time, you can just use the Flash API docs and the behavior should be the same. This isn't a perfect replacement for in-house docs, but it's still quite handy.

Also, I highly recommend looking at code samples. HaxeFlixel in particular has a large demo section, all with code samples and links to the relevant Github pages.

The best way to learn Haxe is to get involved with the community. There's a lot of really smart people there, even if it's a bit small. The best places to find Haxers:

#haxe IRC channel on freenode
Haxe forums
OpenFL forums
#haxe and #openfl tags on twitter
Haxe Foundation on Github
OpenFL Technologies, LLC on Github
Haxe and OpenFL google+ communities

Open Source Be Crazy
You can get by just fine by using only the latest releases of OpenFL and Flixel, etc, but if you really want to dive deep you have to learn how to work with the flow of Open Source development. This means getting friendly with Git and Github, and interacting with people in the community. You'll want to get really good at using the "haxelib" tool that serves as a sort-of package manager for haxe libraries. It's crazy powerful, but it's not as simple as just opening Unity or GameMaker and having your legos all in one box.

Haxe Doesn't Hold Your Hand
One of the chief draws of GameMaker, Unity, and Flash (back in the day) is that they're easy to get started with, well-documented, and come in one monolithic box. Haxe is more of a constellation of little tools all working together, not unlike Git. It's fiddly, and it's not intuitive from the get-go. We're getting better at improving the early-user experience, but I'm not going to lie to you -- if you want to get started with Haxe, find someone who knows it already.

It's Not Magic
This is the most important caveat. Haxe/OpenFL is not some magical pixie dust you can sprinkle over your code and have everything Just Work on every platform. There are minor differences in visual output between C++ and flash targets, for instance ((the exact way rounded rectangles rasterize, etc).

Furthermore, you need to know where and how the abstractions leak, and shift your mindset to the meta-programming model. Most of you probably won't have to ever roll up your sleeves and add raw C++ code to one of OpenFL's native backends, but it's definitely possible. You also need to learn the subtle differences between the targets. It's also advisable to get good at understanding how haxe generates code for different platforms. That said, as long as you don't overload on premature optimization, you should mostly be fine.

The easiest way to start is to just use Haxe to keep making flash games -- that requires *very* little additional effort, and it will get you the same exact results as coding in ActionScript. You can even package swf files created in Haxe as AIR games if you want! (That's what Monster Loves You! did -- it's written in haxe, compiled to SWF, packaged in AIR).

C++ Debugging is still a WIP
Technically, nothing's stopping you from running a command-line debugger like gdb on the generated C++ code Haxe outputs, or trying to run it inside Visual Studio, but that's not exactly easy. You can, however, very easily use an IDE like FlashDevelop to debug your flash code, and if there's an error on flash, there will likely be an error in the other targets as well. That said, we really want 1st-class, integrated, easy-to-use, FlashDevelop-supported debugging for C++ targets.

Don't worry, it's coming:

That's a screenshot I took the other day of native Haxe C++ debugging in FlashDevelop. It's an experimental feature for now, but hopefully it will be ready for release soon.

To be clear, you really pretty much *never* need to directly touch your C++ code. The feature I'm alluding to above is being able to step through your original Haxe code line-by-line while running your generated C++ program in debug mode, to see where the errors are in your original source. And we're almost there!

Other Important things of Note

There's a bunch of other little things I want to mention before we go.

What's NME? What's Neko?

If you've looked into Haxe/OpenFL before, you've probably heard about "NME" and "Neko" and wondering what those are. First of all, Neko is Haxe's own interpreted virtual machine, not unlike the Java VM or the Flash player; Haxe can output to Neko bytecode that will run in the Neko VM. Entry-level haxe developers can safely ignore Neko -- it's a cool little cross-platform VM, but it's usefulness is mostly relegated to command-line tools, server-side programming, etc. I will mention one useful fact -- Neko uses the exact same rendering logic as the C++ targets, but compiles much, much, faster, so it's useful for testing your C++ visuals when you're impatient.

NME, which you'll see tons of references to still, is the predecessor to OpenFL. Basically, NME was created back in the day, then it got re-branded as OpenFL, then lime was spun off of OpenFL, and for a while NME was basically obsolete. Now that OpenFL has taken over NME's original mission of mirroring the Flash API, NME's original creator has revived the project to take it in another direction. 

Confusing, I know. Basically, NME gave birth to OpenFL, OpenFL took over the Flash API business, and now NME has slimmed down into something very similar to lime that is now forking off to do its own, different thing.

What's Flambe?

I'd be remiss if I didn't quickly mention Flambe. Flambe is an alternative Haxe media engine to OpenFL/lime, with a focus on web and mobile. Its chief targets are Flash, HTML5, iOS, and Android, and also lets you you render SWF content in the non-flash targets. For its mobile targets, Flambe exports your game as a SWF uses Adobe AIR to package it.

Flambe has attracted a lot of attention from the commercial sector, notably from Nickelodeon and Disney. So it's worth looking into. The top priority seems to be 1st-class HTML5 support across all platforms.

The biggest difference between OpenFL and Flambe seems to be that Flambe has more high-level stuff. So in Flambe-land, functionality that would normally be supplied by 3rd-party libraries like HaxeFlixel and HaxePunk in OpenFL-land, are built right into the core of Flambe.

Flambe is more monolithic, as it were. So if you're more of a "I want all my legos in one box" type person, check it out. Flambe also supports the new Firefox OS, and just hours ago OpenFL announced the same thing. Go Firefox!

Other Cool Stuff

OpenFL supports the new fully-open source Tizen mobile OS, which some are speculating might be replacing Android on mobile devices. 

There's also Reach3DX, from the creators of Gamebryo, which is built on the Haxe/OpenFL tech stack.

And if you're really interested in making 3D games with Haxe, you might be interested in these Haxe 3D libraries:

Away3D
BabylonHx
OpenFL-stage3d
H3D (as seen in EvoLand)

Other miscellaneous tools include:

Spinehx (skeletal animations)
haxe-openfl-ffmpeg (playing video)

And much, much more!

Server-Side Fun

Whether you use OpenFL or note, Haxe has one last really cool trick up its sleeve - server-side code. Haxe code targets include PHP, Java, JavaScript, C++, and Neko.  All of these can be used for server-side code. A common problem in game development is having to write your gameplay code twice -- once for the client, and once for the server, so you can do proper client-side prediction (or whatever).  This usually means writing in two different languages, one optimized for desktop, and one optimized for the server, which can be a nightmare keeping them coordinated. 

Or... you could just use Haxe, and output whatever pair of client/server languages you happen to need. That way, when you update or bugfix your Haxe code, the changes can propagate to both the client and the server. This is exactly what Proletariat Sloth did in their game World Zombination. Even crazier, in the process they created a Haxe-->Unity library called HUGS (Haxe + Unity Glue... Stuff!)

Signing Off

Okay that's what Haxe/OpenFL is and why it's cool. If you think it's cool you should check it out.

The end.

Thanks to these fine folks for providing useful information:
Joshua Granick, Nicolas Cannasse, Hugh Sanderson, Nilsen Filc, Bruno Garcia, Jesse Kurlancheek, Philippe Elsass, Damjan Cvetko.
Haxe, OpenFL, HaxeFlixel, HaxePunk, and Flambe communities.
(And anyone I left out)

Playing Defender's Quest with the Steam Controller

So I got back from Steam Dev Days. You might have heard that everyone who attended got a Steam Controller prototype from Valve, as well as one of the many Steam Machine models (courtesy of Intel).

Bottom line -- it's pretty good! Read on for more details.

This is the prototype we played with (picture nabbed from internet, but I have the same one):

The back looked like this:


So, basically it has two circular trackpads, two shoulder "bumpers", two shoulder "triggers", and two back "paddles." It has 8 face buttons - 4 weird triangle button thingies, and 4 weird square thingies, then three "reserved" thin rectangular buttons on the bottom. At the conference, Valve said these controllers were from the same manufacturing run that they gave to the 300 Steam hardware beta participants. 

They've already committed to a new iteration, that looks like this:



They have finally seen the light and are changing the weird mess in the center into a proper set of face buttons, neatly arranged in two diamond patterns of four each that mirrors the classic "D-Pad + XYAB" that we've grown accustomed to. I saw one of these at the conference, freshly 3D-printed, so we can expect the final design to be based off this.

At any rate, in all models I've seen they've punted on the digital touch-screen that they had talked about before. In early tests it just proved too distracting, and was of marginal use for a pretty substantial increase in manufacturing cost.

So basically the new design represents what's coming next, and the images at the top reflect what I was actually able to play with today. 

Legacy vs. Native

The Steam Controller has two modes: Legacy Mode and Native Mode.

In Legacy Mode, your computer literally cannot tell the difference between your controller's input and the input of a mouse and keyboard. The controller is actually sending low-level mouse+keyboard events.

In Native Mode, you compile your game against the Steam SDK, and get to look directly at what the steam controller is doing -- get X/Y coordinates for each trackpad, controller input for each button, etc, and one more thing - you can have up to SIXTEEN of these plugged in at once. SIXTEEN.

The Steam controller configuration stuff is actually already in the steam client, too -- if you open big picture mode, and IF you have a steam controller hooked up to your computer, you can see the controller configuration for your current game. This is legacy mode configuration -- mapping mouse/keyboard events to the various buttons for this particular game. What's cool is that Steam is NOT sitting in the middle like Joy2Key, and translating on the fly. It's not going, "You pressed the X button, let's see... that's the "E" key on the keyboard..." Instead, what happens is whenever you load up a new game and grab a controller configuration, it re-flashes the controller's firmware, so now pushing the X button just IS the same as the E key on the keyboard, or whatever. Again, your computer just gets mouse and keyboard input.

It's also cool how they deal with user configuration. So, if you make a controller configuration for a game, by default you're sharing it with everyone, unless you set it to private. And whenever someone else uses it, it gets an automatic upvote. When they stop using it, it gets downvoted, and then the most popular configuration becomes the default for all steam users, and the others are ranked somehow, with the best ones bubbling up to the top. Hopefully they're also doing the sorting right to correct for the recency bias in the "first configuration gets all the votes" effect.

How does it play?

So how does it work with Defender's Quest? Pretty well, I'd say. Here's the configuration I'm using right now:

 

It maps the right pad to mouse movement, and assigns left-mouse click to clicking the right pad, as well as the right shoulder bumper. Clicking on the pad is intuitive, but it's not ideal because it's easy to move the cursor a bit as you click, so I prefer to have a second dedicated "click" button for precision. When I played Portal at Steam Dev Days, I noticed they had the same setup. (The game doesn't use right click for anything except deselect, but I mapped it to the left bumper for good measure).

I've noticed most Defender's Quest players use the mouse for near everything. And of those who use hotkeys, only a fraction use them all. Pause (spacebar) is by far the most important hotkey, followed by speed up/slow down and boost.

Speed up/down are mapped to the shoulder triggers, and boost is mapped to the left back paddle. Back/deselect is mapped to the right back paddle.

With just these few keys, the game is very playable. The mouse movement is surprisingly good, although I'd like to adjust the sensitivity and switch from relative motion to absolute (basically make the track pad behave like a wacom tablet). Valve has assured me that sensitivity is configurable but not yet exposed in the menu, and I'm waiting to hear back on absolute vs. relative motion. (In native mode I could easily do all this and more myself, but that means specifically programming for it).

I do love the haptic feedback in the track pads. For those who are wondering what it's like, basically all it does is give feedback about acceleration and momentum to your motion. It feels almost like you're spinning a trackball, but of course the surface is flat, and you don't have any of the physical disadvantages of a trackpad (weight, hugeness, grime and gunk getting inside your controller). 

For most players, just what I've described above should be enough to sit down and play Defender's Quest on your big screen from your couch without too much trouble. However, there's a few other things I added for convenience. I mapped the left pad to the arrow keys, so you can pan the overworld map with it. And as a stopgap feature, I mapped tab navigation to the two top face buttons. This way, you can technically reach any UI element on screen just by tabbing to it. 

There is one glitch -- tabbing uses my "virtual mouse" control feature, and for boring reasons I won't go into right now, a real mouse click event (as opposed to the faked "virtual mouse click", bound to ENTER by default), will click wherever the mouse was last, not on the currently selected element you jumped to with TAB. I think I can re-program the game to fix this, so that if you've just tabbed to something and haven't touched the mouse since, the next mouse click (real or virtual) will let you click it. 

Assuming I get that fixed, you can easily navigate the game's menu without having to point at everything directly. 

One thing I wasn't able to do was map all the spell and character selection hotkeys (all 18 of them) to anything useful, so I just left them out. (123456 mapped to spells, QWERTY mapped to classes, ASDFGH mapped to characters of the current class).

If I was able to do some "chording" I could conceivably work around this issue. "Chording" is when you click one button to change the function of another - the most obvious example is the shift key, which changes "a" to "A." What I wanted to do was have some button work as a "switch", so that -- at a low level -- when I press face button "X" by itself, it means "1", but X+(some switch) now means "Q", or whatever, so I can switch between what "row" I'm targeting. Then all I need is 8 free buttons -- 6 for individual items, and two for creating the categories. Of course, that might be horrible overkill. In any case, it's impossible in legacy support, but could be done using the Native API.

Bottom line time -- is the steam controller a viable "don't look back" replacement for a mouse and keyboard? Probably not -- it's a different device and it's just not the same thing. For instance, text input is laborious -- you have to bring up this virtual keyboard thing. And no matter what magic I work with chording, it will never be the same as a giant sea of hotkeys at my fingertips. 

All that said, I can say it works really well for Defender's Quest, even after only a few days. My wife was able to pick it up in just a few minutes, and after a few hours of practice I think I could really get good at this method. Legacy support is surprisingly powerful even with its limitations, and with a little extra programming there's basically nothing I couldn't do with the Native API. The big grain of salt to take this all with is that Defender's Quest is a game you can pause, speed up, and slow down at any time. It often requires precision mouse control, but it doesn't also add time pressure to the mix. So I can't speak to whether this is a good control method for, say, DOTA or StarCraft.

Hope this helps someone!

WhoLetsPlay - 2014 plans

Hey everybody!

So, now that it's officially 2014, I thought I'd lay out some plans for how to get this little movement off the ground before all of our momentum peters out.

So, here's today's agenda
1. Communication structure
2. Removing me as a bottleneck
3. Legal stuff
4. Web stuff
5. Raising a small amount of money

Communication structure 
Right now, I'm the one doing all the talking, and I want to fix that. For now I'm setting up a google group that we can use, you can find it here:
https://groups.google.com/forum/#!forum/wholetsplay

 If you have anything to say, post it!

Removing me as the bottleneck 
 If this movement's going to survive long-term, it can't depend on me for everything. For instance, because of the wikia page's lackluster settings, people are emailing and tweeting me directly asking me to update the list, which is getting unmanageable.

Right now the wikia page only has two security settings -- too strict for new users, and too open to prevent spam/vandalism. Hopefully we can get a better system set up on www.wholetsplay.com to replace that, with settings that are "just right."

And as glad as I am to have gotten this thing started, I have a full time job and a new baby, so my time is limited. If you'd like to help carry the WhoLetsPlay banner, or even offer to become the new leader of the movement, I'd love to hear from you.

Legal Stuff 
One of the things I'd like to do with WhoLetsPlay is to consult with some legal experts in the field of games, new media, and intellectual property to see what can be done in terms of straightening out the thorny situation with streaming rights, music licensing in particular. I'm in touch with several lawyers, and so far I think our best prospect is Mona Ibrahim , who has a lot of expertise in those specific fields, which is pretty rare. I've also worked with her in the past with Level Up Labs over the years and can vouch for her personally. I'm also reaching out to anyone else who will talk to us, such as the Creative Commons .

Web Stuff 
 The current http://www.wholetsplay.com site is, in a word, butt-ugly. I'm looking for a good web developer to fix it up, and also get some advice about what the best wiki to install should be. My preference is for something simple, easy to maintain, easy to edit as a user, and easy to moderate/secure. I'm in touch with a few people, but haven't made any final decisions just yet.

Raising a small amount of money 
 I'm more than happy to accept people's volunteer efforts, but judging from past experience, we're going to need a *little* working capital to get some good results. I just put a simple PayPal donation button up on the http://www.wholetsplay.com site for now, and my goal is to raise about $500 USD to get started. I'm planning on spending this on legal and web stuff. I haven't set up an IndieGoGo campaign or a Kickstarter or anything because those can be all-consuming affairs, and frankly, I just don't have the time. I also don't have an official non-profit company or anything set up for WhoLetsPlay, and currently don't have any plans to do so (at least not by myself).

But if YOU would like to put the time and effort into setting up any of those things, please do get in touch and let's coordinate :)

So -- action items for those of you who want to help.

1. Sign up for the google group and start talking!
2. Donate at the web site
3. Spread the word! Tell your friends!
4. Contact major Youtubers and game developers and ask them to get involved!

Thanks everybody! With your help, we can make 2014 the year made video game streaming/youtube'ing awesome again.

 Lars Doucet
Level Up Labs