Close
0%
0%

Fruit Coder: a game to get girls coding

Fruit Coder is a mobile game that will get girls hooked on programming, and start changing the gender imbalance in the software industry.

Similar projects worth following
With women outnumbered 4 to 1 in the software industry, we need to get more girls programming. Unfortunately, the current crop of tools that teach programming to kids feels much to “educationy” to capture the imaginations of the general public. Fruit Coder is a game, first and foremost, that teaches coding skills through the metaphor of Rube Goldberg-esque machines, and introduces virtual hardware projects that can be replicated in real life.

We have a playable demo here: pixelheavyindustries.com/fruitcoder

We're crowdfunding the project here: https://www.indiegogo.com/projects/fruit-coder#/

Currently, the project is built in Flash, but that's just for prototyping. Production version will almost certainly be realized in Unity3D. We'll be using a plugin we built that emulates the AS3 display tree model, making UI development way easier.

We plan on open-sourcing the core code, and possibly the game itself. This will allow other teams to build their own games using the language we develop.

We're keeping the demo code closed source for the sole purpose of hiding our shame. It's worse than bad, and we can't wait to replace it with the real code.

The production game, if at all possible, will be entirely free-to-play, with no in-app purchases. If we do have to add in IAP's, we'll limit it to auxiliary items, like decorative items or wearables for the pets, because we want to open this up to as wide an audience as possible. We'll pursue Spanish translations after the production version stabilizes.

  • Cinch for Unity

    Kyall10/07/2016 at 19:28 0 comments

    Despite all the flak it gets (some of it very well deserved), Flash is still really great at a few things. One of the truly great things about it is the display tree.

    As the name implies, it's like a tree, or better yet, a bunch of folders on your desktop. Here's what the display tree might look like for a simplified version of a fruit coder level:

    root

    - UI buttons

    - - Menu button

    - - Pause button

    - - Toolbox button

    - Countertop

    - - Puck

    - - If statement

    - - return bracket

    - - Pet

    - Background holder

    - - Background image

    While unity does this, sorta, it's just not quite like Flash. In Flash, we can dispatch a button click event from the Toolbox Button element, and listen for it at the UI Buttons and root levels. We can squash and rotate the Countertop clip and everything under it will squash and rotate. Best part is that we can put a big, screen-covering movieclip above UI buttons and lock everything down (if we need really truly absolutely modal dialog box for some reason).

    To emulate this in Unity, I built Cinch 2D. It was last tested with Unity 4.3, so it needs a bit of updating to compile with the latest Unity. If anyone wants to contribute, or code review it, please do.

    Here 'tis: https://github.com/kyallbarrows/Cinch_4-3

  • Paraphrasing, or, in other words, saying it differently

    Kyall10/03/2016 at 02:23 0 comments

    About 1/3 of our testers totally didn't understand the difference between If-statements and their Boolean values, but whose fault is that, really?

    It’s always surprising what you find in testing. Things that made such perfect sense in development often end up a complete mystery to your users. Case in point: Half Life 2 ep. 2’s final level took a whopping six months of play testing to get right. Players were completely confused as to how to solve the level.

    It’s not that being clear is difficult. It’s easy to write a tutorial that everyone can understand. But being clear AND concise seemingly requires a magic potion made from unicorn tears and one of Morgan Freeman’s eyelashes.

    It shouldn’t be all that surprising. We all come preloaded with experiences and assumptions that color our view of what we are learning. It’s what makes traffic circles so darn confusing to American drivers. It also means we had a to spend a lot of time in play testing to get tutorial text correct, and it could still be improved.

    All this adds up to a lot of uncertainty in the development cycle. It’s going to be extremely difficult to ship this reliably using a waterfall model, or even plan out what levels will go where, without incorporating feedback loops. An agile development process will be required, which is good, because agile rocks the most.

    Even with the most perfectly crafted text, we will still have players getting lost. After about 15 revisions, and introducing Booleans as “things that are true or false”, and properly introducing if-statements, about ⅓ of players still said “a Boolean is something that makes it go one way or the other” (referring to if statements). We were concise, but still not clear enough.

    But what to do? We can’t assail the player with 3 pages of text. They’ll just hit skip, start hacking at the level, get confused, and drop off. The solution is to repeat concepts, saying the same thing in different ways.

    The demo (totally play it here) doesn’t do a very good job of repeating concepts, but it’s just a demo. Its goal is to introduce the game in 3 minutes or less. For the production version, we’ll need to introduce and reinforce every concept in at least 2 different ways, if not more. And we’re going to need to take things piece by piece. Will players respond well to building a vending machine, or is that “so 2015”? It makes it hard to plan the entire game out in one shot, but it does make for a better adventure in the process.

    We won’t lose track of who this is for: the players. As much as we may think they should understand our verbiage, or engage well with a certain level, the players have the final call.

  • Surprises

    Kyall10/02/2016 at 23:49 0 comments

      A great idea is awesome, but one is never enough. A great game is usually one great idea evolving into another. Half-Life starts as a shooter, but then throws in the-floor-is-made-of-lava (the first antlions level) and eventually adds elements of capture the flag. Angry birds starts as knocking things down, and doesn’t really change, but does add a bunch of cool characters that massively change the dynamics. Even the first Mario Bros., a platformer, had swimming levels.

      Likewise, dropping a puck from top to bottom probably won’t be enough to carry players through 20 hours of gameplay. We’ll need surprises and new gameplay elements about every 10% of the way through.

      In keeping with this goal, we’ll break the game up into 3 main sections:

      1. Feed the pets by dropping fruit top to bottom (the initial idea). We’ll try to keep this short, maybe 20% of the game, since it blurs the line between flow control and program state (a melon getting sliced is a state change, but the melon also represents flow control). Surprises come in the form of new keywords and new tasks (rescue the pet rather than just feeding them, refactor verbose code, optimize code speed)
      2. Move the entire concept of physical machines into virtual machines inside a dev-board. Once players are associating an if-statement with physical switches, and Boolean values with light switches, we can make the machines virtual, inside an Arduino-style dev-board inside the game. This allows a lot more cool tasks within the game as we’re no longer limited to just feeding or rescuing the pets. We can expand into pinball tables, plant waterers, K-Mart electric pony rides, electric cars, drones, vending machines, autoturrets, and robots. We’ll start with a simple pinball machine, wiring up push buttons to solenoids that drive the flippers. Tasks and projects will be overlapping: we’ll keep coming back to it throughout the game to keep score, launch multiball-mode, and do cool text animations on the score display.
      3. Collaborative play. If it tests out well, it would be cool to let players collaborate. While not super well planned out yet, this would probably be some kind of RTS style gameplay overlayed on the programming gameplay. Think Farmville, but with programming tasks involved. And friends. And trading parts you earn from each level.

      Virtual devlopment board mode

  • It's never quite that simple

    Kyall09/07/2016 at 00:07 0 comments

    After the excitement wears off of any good idea, you’re usually left with a giant pile of “oh crap, how will the xyz part work?” Like when you get your shop entirely organized into totes only to find that tent that's 15 inches too long. Such it is with Fruit Coder.

    To see what we have planned out and what we don’t, let’s make a list of everything we want to do:


    Flow control

    This part is easy. The puck (marble, or another object) moves down the screen, activating any component it lands on. Single threading is modeled by one puck at a time. Multithreading, when we get there, by multiple pucks.


    if, else, and else-if

    This part also seems easy. The puck hits the if statement, activating it. The boolean expression in the if statement executes, and the puck either skips the attached block, or gets indented and works its way through. The expression may be as simple as a Boolean literal, or as complex as a triple nested and/or/not combo.

    Herein lies our first headscratcher: one frustration with stepping through code is that you generally don't get to see the parts of a Boolean expression executing. The debugger just keeps sitting on the same line while you punch F7 repeatedly. Because we want to make this obnoxiously simple, it would be great if the puck activated each part of the expression. However, this probably isn't practical, as it would look like an out-of-control sing-along, with the puck hopping left and right (the execution order being b -> c -> a -> d).

    A good compromise is to have each part of the Boolean expression light up as it's being evaluated, and play a nice loud boxing bell if it evaluates to true, or a buzzer if false. The background of each sub-expression turns green or red depending on the result.

    This compromise should mostly work, but it leaves one big gotcha: calling functions from within the if statement. The puck needs to enter each function, but we don't want the puck hopping around. We could just make it impossible to nest a function in there, but that would be a huge disservice to the players. Learning that the return value of a function gets evaluated just like a variable is an important concept. But, since we don't really have functions all that well defined, we'll leave a mental note here and hope for a eureka moment.

    Since each if block gets indented, a slide or conveyer belt to outdent seems pretty natural. This also makes else's easy: it can just be a slide to outdent.

    switch/case

    For now, we're going to skip switch/case, since it's just a cleaner way of writing if/else-if. We may add it later, but it seems like the sort of thing young developers can easily learn when pursuing their next language.

    Next post: for loops and functions.

  • Planning out our great idea

    Kyall09/06/2016 at 21:49 0 comments

    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

    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.

    Sidekicks, the "Bytes"


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

    Read more »

View all 5 project logs

Enjoy this project?

Share

Discussions

Kyall wrote 09/19/2016 at 19:03 point

1) Agreed, there are gender imbalances all over the place.  2) I'm a dev.  I can do something about the imbalance in the software industry.  It's near and dear to my heart.  I can't readily do much about gender imbalance in, say, the automotive industry, so I won't try.  I'm going to do what I can to help make my own neighborhood better.

My daughter doesn't have to become a dev like me.  I'm going to encourage her that she can, not that she has to.  I'll also encourage her that she can become a teacher, ballerina, CEO, rock star, construction worker, or anything else she wants to be.  But until we stop mentally stunting the engineering side of our girls' brains by giving them the wrong toys to play with (go ahead, walk the pink aisle and tell me how it compares to the blue aisle for engineering and other living-wage career choices) I'm not quitting.

  Are you sure? yes | no

Gravis wrote 09/19/2016 at 18:33 point

"With women outnumbered 4 to 1 in the software industry, we need to get more girls programming."

Actual question: why?

There is a massive gender imbalance in the education system and construction work but nobody is addressing that imbalance.  What makes the software industry so important that we "need" to get more female workers involved?

<b>Children should be encourage to into fields they are interested in</b> rather than what other people think they should be interested in.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates