Project Logs

Collapse

• Cinch for Unity

  Kyall • 10/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

  Kyall • 10/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

  Kyall • 10/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

  Kyall • 09/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

  Kyall • 09/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

  
  

  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