So we had this fantastic idea about how to teach coding to kids: it’s like a marble run. A marble (or rather, flow-control) starts at the top, and works its way down. Each plastic component is a keyword, variable, or expression. The marble may skip parts, repeat parts, or fall off the run entirely (exception thrown!) Multiple marbles? Multithreading. Of course, most marble run toys don’t have switches, but we’ve all seen enough Lego great ball contraptions to know what it would look like.

Naturally, as soon as we started telling people about it, they were all “so it’s just like Scratch”. Sure...in the same way that sushi is just like tiramisu because they’re both food. While it’s true that Scratch and this game idea both have objects that hook together, that’s where the similarity ends.

• Scratch is mostly educational. We want this to be entertainment, while still packing a huge educational punch. We hope Fruit Coder gets into schools, but we're primarily targeting couches and van-rides to soccer practice.
• Scratch uses words, while we’re trying to create word-less mechanical objects that easily convey the underlying principle (switches, slides, suction tubes, boxes that encapsulate components, etc).
• With Scratch, you code on one side and watch the results on the other. For the first half of our new game, we want to stay entirely inside the code, so players don’t have to divide their attention between two halves of the screen. Later, we’ll switch to a more Scratch-like split screen interface for handling the events on a pinball table, wiring up a drone, etc.

Long story short: we want something that does what Scratch does, but so ridiculously easy to grasp that you can play it on your bed while MLP: Friendship is Magic plays in the background. We want to sneak education into their downtime.

The next thing we had to decide was whether to make this game for kids in general, or target girls specifically. After a ton of thinking, talking, discussing, mulling, and other action words, we came up with 2 big thoughts:

1. Females are massively outnumbered in the software world, so we should probably be doing as much as possible to get more girls in the door.
2. Just because we design this game for girls doesn't mean boys can't play. After all, girls are expected to hop over gender lines all the time (for example: when choosing software development as a career). This game isn't about exclusion, it's about including those who aren't currently included enough.

In much the same way that people think this is Scratch, making a game for girls comes preloaded with some truly delightful assumptions. “So you’re making Princess Rainbow Pony Pet Salon Cafe Makeover Hospital, but for coding?” Yes. Totally. As in totally not ever.

We had to do some really deep thinking as to what “a game for girls” even means. We’re fairly certain of what we DON’T want:

• Lots of pink
• Scaled down from the version you would give the boys
• Focused on makeup, nails and a great hairstyle
  
• An inordinate fixation on picking the right pair of shoes for that blouse

We know we want to feature a female main character. Someone girls can easily connect with.

Joy, the main character

A brief empirical survey indicated that having some sort of sidekick characters to take care of might make the game resonate better with a female audience. Cut the Rope, Angry Birds, and Candy Crush all have this dynamic, so we’re giving the main character some weird, furry pets to take care of and feed. Also, we plan on tagging this with as many "girl game" tags as we can when push it to the various app stores.

These things alone don't necessarily make it a girl game. So our plan is to test on an almost exclusively female test audience, and make changes based on their feedback. Will this create a game that's different than if we tested with a mixed audience? Guess we'll have to wait and see.

How advanced do we want to go? We figure we need to cover at least the CompSci 101 stuff: control structures, data types, functions, and some kind of structs or classes. Also, we want to raise up good coding citizens, so we’ll need to teach test-driven development, refactoring, and dialing down the madness of copy-pasta’d code. These concepts are nicely language-agnostic, so players will be well set up for JavaScript, Scratch, or even rocking an Arduino with some not-quite-C++.

Arduinos happen to be part of our last goal for the game: getting players introduced to hardware projects they can do in real life. After players are familiarized with the basics of coding, we can introduce a virtual dev-board with i/o pins. A real-life microcontroller project might seem a bit daunting for a 10 year old flying solo (every project we've don yet has required some serious forum surfing to fix weird issues), but once they practice building a plant waterer in the game, we believe they’ll have the context and confidence to try it for real. Not only that, but concepts like PWM (in an electric car’s throttle) or string truncation (in displaying a message on an 8-character display) are things that show up all over our everyday life. Relaying these concepts will hopefully spark curiosity in the players to look more deeply at the code that’s all around them.

So, in summary:

• We want to build a game for girls (boys are welcome to play too)
• That is super fun and easy to grasp, so it can be played casually, with after-school levels of focus and thought power
• That teaches really powerful coding concepts via a metaphor of virtual hardware
• That gets girls excited about doing code stuff in real life
• That sparks curiosity about how coding relates to stuff they do every day