nwinter

I've had to do a lot of this recently for CodeCombat's transpiler, Aether: https://github.com/codecombat/aether – it uses Esprima, Acorn, JSHint, and a bunch of other JS tools. There's a ton of great stuff out there, and it's easy to put them together since they all operate on the Mozilla SpiderMonkey Parser API abstract syntax tree format.

I like node-falafel better than estraverse, which is more concise to use: https://github.com/substack/node-falafel

If anyone likes this stuff and wants to write an open-source, in-browser parser from another language like Python, Haskell, or Ruby to the Mozilla AST format, we'd love to make it worth your while. See https://github.com/codecombat/codecombat/issues/72 and then email me to work out an arrangement.

We aren't experts, so perhaps we'll eventually run into similar problems, but it seems like supporting a contributor to do something major might just be a case where it doesn't always make ROI on the first feature, but the point is to attract that contributor as a member of the core dev team, since every subsequent major improvement that contributor makes will become easier. We are trying the wizard avatars for significant contributions to try to motivate people to really join the Archmage team.

The other ingredient might be excitement to do things. People will spend more time figuring out how to make changes they care about if they're psyched; if they just want to fix some bug, they'll give up more quickly and need more time from you. So highlighting some cool things to do might help. I notice that you link to small tasks issues, but don't have any open right now. Always taking the time to write good issues that explain how to do a thing, even if you think you'll probably do it and aren't planning on doing it soon, is a good practice, because it'll be easier when you go to do it, and some contributor might see that and get inspired–then they'll know how to do it instead of needing to ask you where to start. Here's an example where I wrote up a lot of info on how to do a task and a contributor put in a lot more time to finish it afterward: https://github.com/codecombat/codecombat/issues/23

No one will see the value in doing what you're doing and want to clone you until then. Even if someone saw the genius in your approach early on and decided to clone you and start competing with you, you have to be confident that your version of your idea will continue to be better than their version. You still have all the advantages of branding, community, and users, whereas their version has no advantages except perhaps a lower price (which doesn't apply to many products, like your AirBnb and Youtube examples).

We find jobs for our more experienced players and collect placement fees from the employers.

Mostly Firepad, which is an adapter for CodeMirror that uses Firebase to add real-time collaborative text editing to it: http://www.firepad.io/

We are using ACE, not CodeMirror, so I added another adapter to hook Firepad up to ACE: http://ace.c9.io/

We also use Firebase to sync the wizard presence, position, chat, and game script state.

We'll definitely be up front on how necessary an H1B turns out to be once we have that info from our employers. Preliminary results suggest that around 2/3 of companies are fine with sponsoring H1B transfers, but we don't have data yet on sponsoring new H1Bs, which I guess is the big question.

You're almost certainly right that I'm underestimating the detriment of US-centrism, since I don't quite understand what you're suggesting–maybe you can explain some more?

Seems the only three things we can do with skilled non-US candidates are 1) try to find them work in the US, 2) try to find them work outside the US, and 3) not try to find them work. We are of course focusing on 1), since we currently only have manpower to do matching in person and we live in SF, which happens to be in the US. 2) would be nice if we grew big enough, and we have one employer in Australia so far. 3) would be an unfortunate necessity if we couldn't get an international employer network and it proved way too hard to convince US companies to sponsor visas. But it's going to be up to our employers, not us, to decide whether that's worthwhile.

Sure, that's what CC-BY is all about. Will be happy to see the art used in more places. (We don't actually draw the stuff ourselves; we're hiring an excellent game art studio to draw it for us, RetroStyle Games.)

Right, this is an old export, and the latest batch of units have never been exported in raster. Let's keep discussing the best way to get the exports here–Scott has come up with a better idea for it that'll stay current: https://github.com/codecombat/codecombat/issues/94

The SWFs are also part of the old format, so they won't be kept up-to-date; I wonder if we could just build some process around the vector -> raster export Scott's talking about through our site and still be useful.

I just put some exported .png copies of some of them in the Dropbox folder you shared with me, but I'm realizing that without the associated metadata it's not going to be very useful (I can perhaps find where that was put later but it's not in the places I'm looking). Would you be able to use them in .swf form?

We are so new to this that I'm not sure how big a deal it is going to be. We'll definitely find out soon, as a lot of great candidates are not US citizens.

Sure! This is what we are trying first: http://blog.codecombat.com/beat-this-level-get-a-programming...

Now we know we can definitely have enough skilled candidates, and though it's only been a week, it is looking really good on the employer end as well.

Brunch is amazing. I was using Grunt in another project, but Brunch is so, so much faster to recompile changes, since it's very clever about caching.

Oh yeah, those sprites were in the repo as raster files, but we managed to move them all over to our awesome vector-graphics-in-the-database system just before launch. Check the DB dump to get a copy: https://github.com/codecombat/codecombat/wiki/Developer-envi...

(We did a ton of cleanup work before open sourcing, which managed to get our gzipped GitHub clone download from 203MB to 3.5MB.)

It might be hard to use these art assets in another game unless you take a lot of CodeCombat code on top of EaselJS to render the sprites directly from the vector graphics data, though, because of how they are stored: https://github.com/codecombat/codecombat/wiki/Surface#vector...

I could send you the old raster versions if you did want to use EaselJS for their animations but not go whole-hog with the CocoSprite solution.

I had a personal blog post about that story that someone posted to HN, and the top comment thread there was very helpful to us in the decision to open source anyway:

https://news.ycombinator.com/item?id=6601712

sillysaurus2 and highCs made some excellent points about ignoring what the gaming industry as a whole was doing, and this went a long way toward allaying our concerns. Then we talked to everyone we could think of who might have reasons why this wouldn't be a great idea, including some good lawyers, and no one could think of anything.

For a startup like CodeCombat where the audience may be interested in the code, open source should be the default choice, and hopefully we can succeed in this and start to make that happen by example.

I just had a Chrome extension refreshing the page every couple minutes is all. I think it was actually a bad decision, because we were #40 on the new page in under 10 minutes with everyone doing the same thing. I just posted it because it's news today, and fortunately some people like it.

If someone makes a level on another CodeCombat server in their own database, they can share that with other CodeCombat servers all they please. We are just being cautious about the levels that end up in the main codecombat.com database, because at some point we might want to either make premium-only campaigns or allow others to sell access to their campaigns, and we can't do that if the levels are all MIT.

Hopefully we can keep all levels free for everyone anyway, since recruiting is looking pretty good as a monetization strategy so far.

I also agree with all these points. (I wrote this one.)

That's fine, too--we'll have your code, but you may not (after you change browser sessions). Well, until we reply to your email.

To those playing: if you want to be able to find your code again later, go to the CodeCombat home page and sign up for a free account! Sorry, we derped out and didn't put any signup form accessible from the Gridmancer level.

Also, we're sorry that we left you without good debugging tools: https://news.ycombinator.com/item?id=6976883 -- this is the #1 problem uncovered today. We will retreat in tearful shame to our code lairs until we can blow your minds with our timeless debugger.

You are amazing players--so many good solutions here. Thanks for playing! To those who sent in solutions and are looking for dev opportunities, we'll be in touch this weekend to see what we can do and learn about what you're looking for.

That's how all the CodeCombat game engine works (things are positioned by their center points), so because this challenge was taken from an algorithm used in two places in the engine, it maintains that. I know it makes it a bit more complicated to write the code, but it's a lot easier for us to then snatch the winning solution to make CodeCombat faster!

You are so right, I am ashamed. See also this comment: https://news.ycombinator.com/item?id=6976883

We could try doing placements outside of California later, but for now we don't have much of a network outside of the SF Bay Area. (We're quite young as a startup.)

Oh cool, I'll check those out tonight (and a bunch of Python parsers people have pointed me at). CodeCombat's challenge is to transform other languages into a Mozilla AST so that we can apply our crazy transpilation stuff to it. So anything that makes that easier brings us closer to supporting those languages in our levels.

This is a good point. Traditional recruiters have different ways of knowing how good you are at programming (often they don't). By starting with your Gridmancer competency, we can potentially find and qualify you for opportunities that traditional credentials couldn't. (And we're not going to send candidates who aren't good enough to higher-skill positions.)

One weakness is that we don't have a good way of measuring how much software development (as opposed to core programming skill) you have. In this sense, we don't yet have an advantage over traditional recruiters.

Traditional recruiters do have better connections, for now, but we are going really high-hustle for this initial batch of players, so it's not like we're just sending off resumes.

Oh, okay. I thought I had a performance improvement at hand, so I was excited! Thanks for digging into that.

Would you have played if you could choose Python or CoffeeScript, or would we have to be epic and write a Haskell -> JavaScript transpiler to pass go?

Thanks guys! Happily serving more concurrents right now at 10% CPU than during that first big traffic spike that took us down.

This is for our multiplayer game list, which we haven't quite turned on for non-admins yet: https://www.dropbox.com/s/n956u62zdlghqjw/Screenshot%202013-...

But it should only take one screenshot every 30 seconds, and only when something changes, so this is a bug! I will fix. Thanks so much!

I'll change the default code comments. We were much less ambitious before our playtesters blew my algorithm out of the water.

I know, I know. Try this.say() for a poor man's replacement.

We haven't improved it much because we are going to make an awesome timeless debugger, where you just hover over the variables to see their values at any point in time as well as scrubbing forward and backward through your entire program's execution (like jsdares does), all without any breakpoints, but haven't quite got it yet.

We, uh, don't! That sounds like a bug that I would love to slay. Can you give me some more info?

Clever! In an ideal world, we'd have logic to prevent incorrect configurations so rectangles couldn't touch walls. There would also be ogres dying and explosions and battle music and such related to the efficiency of your algorithm--you know, actual gameplay mechanics, like our other levels. Didn't have time to get those in yet, though.