Always Carry a Safety Net

Because I’ve just accepted a part-time position, I wanted to talk about a common misconception people have: that indie developers trade stability for freedom.  I’ve found less literature about this online than I would have hoped.

Repeated sensible advice I’ve heard from many other indies is “always have a safety net” so that when you fail, you can recuperate rather than rot.

Last year, my safety net was my full-time job.  That meant that if a game I made did financially poorly (or couldn’t do financially well… because it was free, for example), I was still okay; I could make another and learn from the experience.  The downside was that much of my game development energy was expended on the full-time game development I was doing at work.

When I left my full-time job so that I could use that energy on my independent games, I set a deadline for myself, and this deadline was my safety net until recently; I’d math-ed out savings so that I would know by what date I would apply to jobs again.

This week, I began a part-time position that I’m extremely excited about!  This is another safety net YAY!  (Also, like, I’m really really excited about it about what I’m doing :))

Other indies I know have other types of safety nets, which include:

  • on/off contract work between cycles of game dev
  • a family member who’s willing to bail that person if everything crashes and burns
  • contract-for-hire-type game dev, where you sometimes are making someone else’s game, but as an independent studio (this is basically on/off contract work)
  • other things I can’t think of just now

I think the term “safety net” is maybe not the best for these.  Better is actually maybe “safety gear” is better, because it conveys that you’re adding limitations in addition to safety.  You have to maintain your gear if you want it to last, some safety gear inhibits movement in certain ways or is heavy.  Also, not all safety gear is appropriate for all things.  A helmet won’t do as good a job at keeping you safe from a fire as a fire blanket will (and, in fact, if it’s a synthetic helmet, which the helmet probably is, it could melt, and then you’d be very very sad).

I’m quibbling about semantics only partly because I’m being picky.  The other part is because I want to better convey how I feel about the topic without saying something totally generic/likely obvious like “every safety net has an associated cost.”

But yes, “every safety net has an associated cost.”

The cost of committing to a part-time position is that it will, in fact, take time.  This means that I’ll have to reorganize my schedule a little bit so that by the end of each week I’ll still have accomplished nearly as much as or exactly as much as before.

So what did I do this week?


My focus of this week was conveying instructions on the selection screens, which is pretty closely tied to how multiplayer works in the game.

I would like Floral Kombat to at least support local multiplayer for up to 4 players on controllers.  Ideally, it will also support networked play.

The biggest reason why I think networked play is important is that I have no guarantee on the number of USB ports a computer will have.  It seems like the new big thing is to get rid of as many ports as possible, because usability and choices are just the worst and we should all do what we’re told and never ask questions.  Or something.

As an unknown developer, I can’t expect strangers to invest enough in my game to buy additional hardware to play it, so I’d like to allow them to play without requiring extra ports or even a controller.

The current model I’m using is set up just for local multiplayer; right now it’s set up to accept two players on the same keyboard and two USB controllers.

I’m unsure what the best way is to allow a keyboard player to play in local multiplayer, without require an additional USB keyboard.  It’s possible that multiplayer be exclusively networked for keyboard-only players.

Without further ado… here are some screenshots for the week:

Screen Shot 2016-04-16 at 10.43.10 AMScreen Shot 2016-04-16 at 10.43.23 AMScreen Shot 2016-04-16 at 10.43.50 AM

Until next time,


Floral Kombat – Cleaning and Refactoring

Those are two tasks I’ve been told should never appear on a todo list, since they’re so nebulous, i.e. they don’t have defined end goals associated with them, and could go on approximately forever without completion.

Personally (and I’m fairly certain I’m far from alone here), I’ve found that having a code base that’s clean enough reduces the activation energy required to continue building it to the point where it’s easy again.

[Generally my code eventually reaches a point where the activation energy it requires to continue working on it is so high that it reduces my productivity significantly.  Previously, I used to resolve this issue by starting from scratch, i.e. just rewriting the code to be cleaner so I would never get stuck in the endless loop of cleaning it until it’s clean; however, I wanted to avoid rewriting the project, given the compelling argument I’d heard against it.]

I’d like to talk about some strategies I found helpful to refactor my code without getting caught (I hope) in a riptide of gotta-clean-it-all.  What helped me most was to start with the messy stuff, prioritize readability over efficiencyadd commentsreevaluate, and break to add new features.

Start with the Messy Stuff

I found I was most effective at reducing the overall stress the codebase’s messiness was causing me by starting with the messiest stuff first, and working my way towards other things, where “messiness” was measured by:

  • How little I wanted to add features to something because that part of the code was involved and adding would just make it messier
  • How long it took me to figure out what that section of code was actually doing
  • How awkwardly/confusingly something was named
  • How much stuff relied on it that it was holding up

Note that this way of defining messiness also gives a little more weight to things that are important to other parts of the game.  It’s possible there’s a lot in there that really is terrible and horrible and messy that I just don’t care is terrible and horrible, because it’s used once, and I never have to look at again; it works, or at least does a really really good job at pretending to do so.


What was nice about starting with one messy thing was that I had a clear start point and that I could effectively treat the messiness like a stain I could remove bit by bit.  Once something was clean, it was clean, and I wouldn’t need to think about it any more, which is good, because of how connected things are.

Readability > Efficiency

Recently, a friend mentioned that a good coding rule-of-thumb is “readability over efficiency” and using that as a guiding principle helped me not get caught-up trying to get something to be perfect (since the code’s never gonna be perfect by all standards).

Honestly, getting it “perfect” wouldn’t have been that much better anyway.  Because I’m coding a game and not, like, analyzing CCD data, I don’t need to worry about picking the most efficient sorting algorithm: N is small.  Because Unity’s generally good at things, redundant code in the Update method isn’t a huge problem.


I found commenting my code helpful in keeping track of what was clean and what was not.  If I was sure to write meaningful comments throughout a class I’d just cleaned, I could look at it again and know “oh, it’s clean, no need to clean it more.”

This also helped me sanity-check my logic.  Sometimes I caught bugs this way.

Comments were sort of like the shine on a clean surface after a kitchen clean.


After finishing cleaning a section, I took a little time to gauge how the code made me feel stress-wise.  Admittedly, this was something I should have done more, since this is what determines “clean enough.”

The cleaning process can go on forever if unchecked, and I think the thing that it needs to be checked against is the reason for cleaning in the first place (in my case, being stressed by how messy/confusing everything was).


Breaking to add new features along the way helped me not get overwhelmed with mess-cleanup and helped keep my feeling of productivity high.  I knew I wouldn’t get as many things done this week if I wanted to take time to clean, but I was able to get a few new features in.

(I added a powerup system and began refining the flow involved with players joining the game, but I’d like to wrap up now, so won’t go into those).

This was a short post and a I don’t have any pictures to share because I’m horrible.


well, there is no but.

Until next time,


Fixing Floral Kombat — pt 2

It occurs to me that it should really be Floral Kombat, with a “K” rather than a “C” if I want to do it right.  Silly me.

The build I sent out to playtesters last week included what I thought were the bare minimum instructions to play the game, in hopes that that might expose conveyance issues of which I was unaware.

The instructions I gave were:

  • You and your opponent are flowers
  • The yellow ellipses are bees
  • The green circles along the edge are NPC flowers.
  • The GOAL is to fill up your pollen meter before your opponent
  • WASD or Arrows to move (depending on the player)

I never mentioned how attracting works in the instructions, to see if the UI hint was sufficient.  I got varying feedback on that control.

Most players understood that the key attracted the bees, but some didn’t understand that they key needed to be held down in order to bring the bees in close enough for pollination.  I’ve update the UI for this next build to see if adding more explicit UI there helps.  I’m also curious how the new art I’ve added will affect players’ perception.  I hoped that the male flowers† on the edge would clue the players that interactions only occur when the bees physically come in contact with the flowers, given how similar the NPCs are to you.  Without art, though, it’s hard to say if this was conveyed at all.

†Yes, there are plants that produce flowers with just male or just female reproductive organs.  They’re classified dioecious, and are, in fact, the flowers this game uses.  All players are explicitly female flowers, and the bees go to male flowers to get pollen.  I may or may not use real flower types (of which there are several pretty ones that are dioecious), but I do want to stick to the facts as much as possible.  I may not make the male flowers into flower clusters, which they technically should be, so that bees appear to be gathering pollen that would work on all player flowers, since that would be pretty visually busy… other than that though, I’m pretty proud of the fact that this is a pretty darn good representation of how cross pollination works!††

††excepting the fact that, yeah, flowers don’t normally chase down bees.  I guess it sort of works the other way or something.  Psh.  Details.

Most players did eventually figure everything out on their own, but I do want to make everything I think is crucial to play the game as apparent as possible.  Eventually, I may put in a tutorial, but I can’t expect players to go through that, and I don’t want to force them to.  As a relatively-unknown game developer, I don’t have the luxury of being sloppy or unclear.  Sort of odd when you think about it, how level of perceived professionalism and required conveyance skills are somewhat inversely proportional.  Obviously people won’t play games they don’t find fun, but players will forgive more from a triple A title if it’s unclear about controls than an Indie one.  Maybe part of that is that many triple A titles use fairly conventional controls or feature their unique controls in the press heavily, so avid players can have done their research and jump right in.

I spent a significant amount of time this week looking at UI from other games, to see how control explanations are done.

Though I don’t think it’s appropriate for Floral Kombat, I like the simplicity and clarity of The Binding of Isaac‘s (original) controls panel, which I noticed does what was suggested to me at GDC.  Title, image, caption.  I remember finding that image quite effective when I was new to the game†††.   Also worth noting is how easy everything is to read.  The image isn’t strictly necessary, but it breaks up the text and draws your eye (or mine, anyway).

†††slightly interesting academic point: Afterbirth omits the key controls from the image.  I remember finding that odd when I first noticed, because the key controls were the most helpful part of the image when I was new; however, the decision makes sense, given that Afterbirth can safely expect players to be familiar with the controls from the previous game.

I decided to stick with a popup hint like I have.  I remember finding the popup hint that Shadow Puppeteer used to indicate intractable objects effective.  Just a “Y” button that appeared when in range, but it stood out due to the contrast.  The main difference between the Shadow Puppeteer indicator and mine, however, are that I need to indicate that the button need not just be pressed, but held, like the A button in Ocarina of Time when pushing blocks around (sadly, the UI for this doesn’t seem a great fit; it’s designed for a 1-player experience).

I added “hold” to the text and added an animation to show the button being held down.  I wonder if this will help any.

I also wanted to work a little on player registration and player differentiation this week, so I put together a registration screen.  I’m not sure if I’d like to allow the two keyboard controls I have (WASD and Arrows) to stay in the final version of the game.  Ultimately, I think the game works best with gamepads/Xbox Controllers/etc, but I don’t want to prevent people from being able to play with a keyboard if they want.  There is the space restriction, though; four around a keyboard could get a bit cramped††††.

††††could be a design feature, but… I don’t really want that for this game

Screen Shot 2016-04-01 at 2.10.31 PM

My aim here, by the way, was to only use the controls the game itself uses (if possible), and to use a similar mechanism to what the game uses (if possible).  This hasn’t gone into the playtest build yet; I’d like to make the color selection be character selection instead (or its own option) first.

As for how the game itself looks now, here’s a shot of it:

Screen Shot 2016-04-01 at 2.09.31 PM

I hope that the new player HUD at the bottom are clear enough and that the new control indicator isn’t too obnoxious — I’ve actually made it go away after players have filled past a certain point.  I’m not sure that’s the right solution, or if the image itself needs to be toned down.  Right now, I think it’s too large and may occlude bits of the play-field.

And to end with a few fund things…

With the addition of art, I gave the male flowers mustaches.

Screen Shot 2016-04-01 at 2.10.05 PM

Also, now when you win, your head explodes!  Just like real life†††††.



††††† Okay so this is more or less true for some plants, but generally not so for any dioecious plants, as far as I’m aware.

Until next time,



Fixing Floral Combat

My goal this week was to create a good demo of Floral Combat, based on last week’s assessment of what one is.  I focused on visually clarifying what’s going on and on attempting to eliminate the dominant strategy of grab everything and run away.

Because I wanted to make significant changes to the way the game worked, I started a new project file.  Admittedly, it also helped me mentally to have a clean slate for the game.

Side note: many would say starting a new project is always the correct approach, but I’ve come to see the value in revision.

Dominant Strategy:

Based on playtest feedback at GDC playtest night, I eliminated the second kind of pollinator to reduce confusion.  This did seem to, but it also accentuated that the dominant strategy is to grab everything and then run away from your opponent†.

†Many players did find this mode fun; a very strategic way to “run away” turned out to be staying as close to your opponent as possible, since your bees would orbit pretty far away from you, so, as long as your opponent was inside the circle of bees, you could keep the bees safe.  Still, I’d like to allow for more dynamic gameplay.

I realized something Floral Combat doesn’t have that a lot of competitive games have is a strong tradeoff mechanic; doing action A prevents action B, and vice versa, where both actions A and B help you win.

Take Nidhogg, for example.  You win by reaching the other side, but just by running, you’re bound to leave yourself open.  When faced with an opponent (and certain geometries of the stages), you’re forced to face your foe.  You have two basic choices: fight or run.  When you’re fighting, you can choose to be near your opponent or far away.  The closer you are, the easier it is to hit, but also the easier it is to be hit, so you have to choose between being more offensive or more defensive.  When you make an attack, you also have to wait a certain cool-down time before you can attack again, so you can either choose to attack or wait.  You make meaningful choices: Run or Fight?  Near or far?  Attack or wait?  These tradeoffs make the gameplay dynamic and fun.

Floral Combat‘s two main verbs are “Run” and “Collect,” so I decided to make them mutually exclusive.  Now, if you want to steal bees from your opponent, grab a bee, or gain pollen from the bees you have, you have to plant yourself and Attract.  If you want to get away from your opponent, you can Move instead.  Move or Attract.

I hope this also eliminates some confusion players were having previously; many players felt like bee-stealing was very random.  I hope that making this a distinct choice rather than a passive action (bumping into the bees as you move) clarifies what’s going on when bees get stolen.


In clarifying what’s going on, I attempted to be as redundant as possible.

Bee Ownership:

Perhaps the biggest issue players had with the previous version of the game was identifying bee ownership.  The only ways the game indicated ownership were proximity and a faint halo.  The proximity clue was rather useless, because, when both players were very close, as happened quite frequently, the circles meshed together.  The faint halo was not only too faint, but also not extremely color-blind friendly.

Because bee ownership is so important, I’ve attempted to show it in as many ways I can:


Bees now have a darker halo of your color, a trail of particles with your color, and a tag that matches yours.  The orbital radius is also a little smaller than it was before.

Something that isn’t showing up in this image for some reason (maybe I introduced something that broke this part before I took the screen cap) is a set of lines that go from you to the bees you own.

Because many of my indicators do rely on color, I ran them through a few color-blindness filters.

Also, by happenstance, a friend who came by happened to be colorblind, and was able to verify that he could distinguish between players.

Though the colors may change in the future, the act of running the colors through filters helps me get a sense of some colors that might be problematic for certain vision types and gets me thinking about this now.

Colors that tend to work best, by the way, are ones that differ the most in contrast from one another.  It’s easy to forget this when opposite colors tend to look distinct, even at high contrast.  If those opposite colors are red and green though, it’s likely to be a problem for lots of people.


Another frequent issue players were having was determining when pollination was occurring.  I don’t think I’m quite there yet with my solution, because people who have played this version have had some difficulty determining meter levels and when they’re gaining pollen.

I think I’m getting there though.


I’ve attempted to show pollination in a few ways.  Both the player and bees are now meters that both fill with a bar and change in size based on pollen level.  I’ve also added a partcile effect that pulls inward only when pollen is being transferred, as well as an absorb effect.

In the corner, you can also see the bees gaining pollen from a flower.  I hoped that adding this would not only allow more strategy (bees lose pollen eventually), but would also let the players see a pollen transfer being done by some AI to help teach what’s going on.

I think the particle cloud is too faint and that the absorb effect could use a little work.  It might also be helpful to add some sort of shimmer or glow immediately after a pollen gain, and some other effect on pollen loss.


That’s where the game is right now.

In terms of meeting my goal for this week, I think I’ve come close, but still have some work to do before the game is as clear as I would like it to be.  For one thing, I do think adding some art will help clarify states of the bees and the players.


A few final notes:

I’m perhaps more proud than I should be of the Attract shader I made.  I wanted it to both connote pulling inward and to look pretty.

Also, fun fact, when you go into attract mode, in order for the bees to come in contact with you they used to go into the Flower Equation.  It turned out this didn’t work as well as making the radius oscillate, which still creates a flower pattern, but isn’t truly a flower… BUT you CAN create some fun patterns by oscillating the bees.  Five turned out to be the magic number that stays in one configuration when making a flower:


Above all, it’s important to me that this game stays pretty.

(also, I fixed the line-connector issue here, that’s what they look like)

That’s all for now.

Until next time,



How to Make a Good Demo

This week I was at GDC; I learned a heck of a lot, and I’m still processing much of the stimuli I received.  Instead of giving a shallow over-view, I’d like to go in-depth in one particular area: demoing.

For context, I thought about this topic quite a bit during GDC, because, shortly after I landed in SF, I demoed Floral Combat at a play-test night.  The responses I got were brutally honest, in the best way.  In addition to getting good feedback about the game, though, I also gained insight into what I need to improve when I create a demo in general.

Based on examples I liked and disliked, here are qualities I think make a good demo:

  • a short time span
  • something for people to do while they wait
  • the important things are conveyed redundantly
  • instructions don’t clutter the HUD if the developer is present

Short Time Span:

The most effective demos I tried only lasted a short, set amount of time, just enough to entice me and let me get a sense of what the game or technology was attempting to demonstrate, and without the danger of allowing a large queue to build up behind me of an unpredictable size.

This reminds me of an old adage from theatre class: “Always leave them wanting more.”

I found I enjoyed demos that were just a little too short than ones that could go on indefinitely for a few reasons:

  1. Theatrics: If my last impression of a demo was desire rather than boredom, if I wished it had lasted just a little longer, I was more likely to think about it later.
  2. “The Awkwardness Effect”:  I wanted to be a polite player/user, and didn’t want to prevent anyone else from trying a demo.  Whenever I was trying a demo that didn’t have a definite end, part of me wasn’t paying attention to the demo, but instead to any potential queue forming behind me.  That’s not great if the demo is meant to be immersive (as many VR demos were).  Every VR demo I tried, of course, did have a finite time because…
  3. Reducing Queue Length: Queues happen, and, if a queue is too long, a lot of people who would want to try your demo might not get in line.  More than once, I chose not to try a demo because I knew I could spend my time better by checking out something with a shorter wait, no matter how cool the demo was supposed to be.  Of course, a shorter demo time means a shorter queue line on average.
  4. Making Queues More Predictable: Having a set demo time allowed some booths to predict how long a wait it would be for people in line.  I saw a lot of people join long lines, with the reassurance that, actually, it would only be a 10-minute-or-so wait.
  5. Reducing Commitment: this is actually a big one; it’s a lot easier to get someone to play your demo when you can say “it’ll only take you N minutes” than when you can’t.  Before I try a demo, I’m never sure if I’m going to enjoy it enough to invest a large amount of time in it, and I don’t want to be impolite.  There’s a lot of stuff to check out in a demo hall, and time is a valuable resource.

I’d like to talk a bit about some of the strategies I saw for managing demo time, and how I thought they could be effective/ineffective in certain cases.

  • An on-screen timer: One demo I tried included a timer, displayed on-screen in an in-obtrusive spot, which, when timed-down, would end the demo by resetting the game.  The demo could also end by the player reaching a certain checkpoint.  I thought this was great for the demo, as it was a single-player exploration-based game with a few puzzles.  As a player, I knew just how long I had, and so wasn’t worried about holding up people behind me or being impolite by leaving early.  This also meant that the experience was rather controlled — each player got to experience some fraction of the same part of the game I did.  It felt very teaser-y.  The only downsides I can see to this method are that (a) it’s not very flexible (unless you can recompile on-the-spot, if you notice the demo time you chose is non-ideal), and (b) it doesn’t provide any reason for a player to come back and play again.  (b) is probably less of a concern, though, because, if you’re demo-ing a large game at a large event, you’ll want lots of people to get a chance to play a little, rather than a few people a chance to play a lot.
  • Rounds: the multi-player games I played had natural demo times built in: the length of a round.  I did not notice many games with timed rounds, but the games I did play all had short enough rounds that I could get a good enough sense of the game in one round and could leave after if I wanted.  Rounds do have a bit of added flexibility, in that players can play multiple times if they want, and have a different experience each time.  The only downside is that, as an exhibitor, you may have to step in to say “hey, it’s time to give someone else a chance to play,” if a queue forms.
  • An unseen timer: A few of the VR demos I tried were timed, but didn’t make that timer visible.  I did start to wonder in at least one of these demos if I was doing something wrong or holding up the line, and so, it would have been nice to see the timer; however, this did allow the exhibitors flexibility.  One of the demos that did this (the Gear VR) didn’t auto-reset, which made me think that the demo length might vary, based on how many people were queued behind me.  One of the others (Lumberyard) was streaming to Twitch, and, I was told could vary based on viewer comments, so perhaps a timer was not possible here.
  • No timer, no demo length: There were, of course, lots of demos without method of setting demo time.  Though I think this can work in some cases, it seemed a bit more work on the devs than it needed to be; it’s a lot easier to have a timer that says “your time is up” than to have the dev make that call, since the dev making the call feels more personal.  I also got a sense of disappointment at being “kicked-off,” in some cases.

In general, I think having some flexibility in the time of a demo can be good, but the benefits of limiting the time outweigh those of not.


Waiting Activity:

For demos I did have to wait to try, I appreciated being engaged in the technology/game while I waited.  The simplest ways I saw this being done were:

  1. Allowing me to watch the current players’ experiences
  2. Talking with a representative/getting my questions answered

VR and haptics were big at GDC, and these are two types of technologies that have a pretty big danger of being demoed in an insular way; they’re both very personal and immersive.

I did appreciate, however, whenever VR or haptics demos included a video display of what the current player/user was seeing.  It made me feel included in the demo, even though I wasn’t (yet), and gave me something to do.  It was even better if the screen was fully visible from a distance, and even helped draw me to the booth in some cases. The only (and slight) disadvantage I can see is that players (like me in some cases) may choose not to demo, because experiencing what they see on-screen is good enough for them.

One set-up I quite liked for a tech that didn’t have much to show visually was a two-part queue, that worked well, but only for small groups.  The first part included a representative who talked to me about the technology, and, right when he finished, another representative was ready with the demo for me to try.  I was also able to see the current demo, as it was a haptics demo that involved physical feedback.

For most games, I think, the ideal is projecting the gameplay experience of the current players in a way that’s visible to everyone in line is ideal.  This could mean a large screen, a raised screen, a mirrored screen at a different angle — however it’s done, I think this is often a better use of a screen than to display a trailer, unless the demo isn’t very visual or cannot be projected for some reason.



This is something I noticed my demo lacked than something I noticed in other demos.

Important information should be conveyed redundantly in a demo, I believe, based on a frequent play-test comment I received: “I’m confused.”  This is probably the most disheartening thing to hear from play-testers.  I think it can mean at most two things:

  1. The basic information necessary to play the game is not conveyed clearly
  2. Too much information is included at one time

In my case, both were true.  The first play-tester to try Floral Combat did not understand the basic information because it was not clearly dictated by the game, and because it was obfuscated by unimportant complications.

A demo should show the basic information clearly enough that it cannot be missed or confused.  In the case of Floral Combat, that basic information includes the following:

  • You win by filling your pollen meter
  • Your pollen meter fills when you have pollinators

Even after I stripped out many of the more complicated mechanics (based on the first play-tester), and even for players who understood that much information, most were confused, because there are some metadata in there that are unclear:

  • Which are my pollinators?
  • How do I get pollinators?
  • How did you take those pollinators from me?
  • How quickly/slowly am I filling up?

I have specific notes on paper for ways to make these more clear, but, more importantly, I know what a demo, in general, should convey, and to what clarity.  That is: the basic information should be conveyed redundantly, unambiguously, and cleanly.  Visual effects and animations are important in a demo if they draw the players’ eyes or alert them to otherwise-invisible cause-effect chains.  Labels can be overwhelming and slow-to-read; any other unambiguous quick-to-glance-at representation should be considered when possible and appropriate.

Related good advice I received about how to design a multiplayer game that has some complicated mechanics is to build those mechanics up in rounds (i.e., each round can add more complication, but only one bit at a time).

Related good advice about designing graphics I received: if unsure about clarity, include an image, title, and caption — the three should draw the players’ eyes in that order.


To HUD Controls or Not to HUD Controls

I was surprised to see how few games and demos included controls in-game, but realized this was because nearly every demo was augmented by the dev(s).

HUD controls are extra clutter, and, as I noticed in play-testing, no one read them anyway.

When I was present, people would ask me “how do I play?” rather than reading anything on the screen, and I would do the same, as a player, even if I was playing through a tutorial.

Only in the cases where the dev(s) was(/were) not present did I appreciate on-screen or in-options-menu controls, but, then again, demos without any devs present left a less-significant impression on me than did demos without devs present.

Freeing up HUD space by excluding controls has the benefit of allowing other, more-important information to take its place, without making the screen overwhelming.

I did appreciate when games clued controls that were event-specific (like an interaction button appearing above an intractable object when I came within interaction radius), but it was simple enough to remember most demo controls by being told once that I never missed having a constant on-screen reminder for (often-situational) controls.




What I’ve learned most is that an effective demo has both an enjoyable waiting and playing experience, and that the simpler and shorter the demo is (within reason), the stronger an impression it can leave; the demo must be long enough for me to get a good sense of what the demo is demo-ing, and but should also be short enough that I leave wanting more.


Until next time,


On Beyond Pollen

This coming week I’ll be at GDC helping Affectiva demo Bee Happy!  In prep, this week I wanted to also get a version of the other flower game (once Gobbler, once Pollen Snatch, now maybe† Floral Combat) to a more user-friendly state.

† I can take no credit for this name, it was a wonderful suggestion from a play-tester 😉

My end goal was to bring Floral Combat to a point at which I could hand it to someone and say “play” without having to explain anything at all.  I think I would like to take more time this coming week before GDC to finish what I didn’t this week.

When I demoed at Mass Digi, I cheated, but knowingly so.  I knew that the game was not self-explanatory, so I explained it to players before/during play.  I knew this meant I wouldn’t get any good feedback about how intuitive the game was, but then I was focused for on finding the fun.  Now I want to see if I can actually convey the important things to players.

Meetups this week: WIG Boston and BUG (I believe Post Mortem was the same night as BUG this week, but I opted for BUG; it was a playtest night).


It was actually a good Monday.  It might have had to do with the fact that I did more work on-paper this week than last, but I think what made this Monday better were these things in particular:

  1. Earlier morning meeting: I wake up early, so I’ve pushed my morning meetings earlier to prevent an undirected pre-meeting section of my Monday.  I think that was negatively contributing to productivity.
  2. A simpler goal: I set myself a simple goal for the week and broke down each day into a planned smaller task††

†† I deviated of course, because the point of making a plan is so that you can deviate from it

I did stick to the plan on Monday anyway, which was attempting to present controls and instructions to the player in a meaningful way.

I attempted the following:

  • Added two-word goal text at the beginning of the game: “Get Pollen”
  • I added some visual effects to the pollen-o-meters to make it clear when they were being filled up
  • I zoomed-out the camera and made the arena bigger
  • I made bee-butterfly explosions bigger, so they wouldn’t be missed

More on that later though.  See… WEDNESDAY

I also attempted to address an issue that was brought up at Mass Digi, which was that the lack of ranged interference meaning that it was very easy to run away.  Also, a few people had requested the ability to launch the pollinators, and, I’ll admit, something about throwing bees at your opponent sounds very fun, so…

…I tried implementing launching.  It made sense to use the right control stick to aim.  I’d thought about this before, actually, and thought it would make sense for the reticle to highlight any bee/butterfly in its path; those bees/butterflies would then be launched on a fire.

With this model, I ended up trying a few different ways of launching, but wasn’t able to get it to feel right.  A fun accident was boomeranging, which, of the launching options was my favorite.

I ended up scrapping launching, however, in favor of shell expansion.  At least that’s what I THOUGHT would make more sense, but… more on that WEDNESDAY.

Actually, let’s just do Wednesday now, because Tuesday I mostly played with powerups, but I find that less-interesting than Wednesday play-testincg.


I brought a play-test build with me to BUG, and, this time, decided not to tell anyone anything about the game other than a short pitch (“It’s a competitive pollination game”), and sometimes would tell players to “Get Pollen” if they entered the game after that text had appeared.  (Come to think of it… maybe the fact that this is missable means it shouldn’t be if I think it’s important… though I discovered more useful things.)

Oh, I should mention; I’ve cut the timer, since rounds go quickly, and players couldn’t (in this version) lose pollen.

What did I discovered from play-testing:

  • the meters were unclear; many people never looked at them or even noticed them
  • people weren’t sure how to get pollen and/or that they were controlling any bees/butterflies
  • a lot of people think bees and butterflies do different things
  • because of how chaotic it is generally (collisions of bees and butterflies everywhere), players had difficulty figuring out what was going on or how they were  winning/losing and/or that bees/butterflies were orbiting them at all
  • some people saw bees and butterflies and thought that one must be bad and one must be good
  • the dual pollen-o-meter was tricky to explain still
  • people like to mob each other
  • despite spinning faster meaning less control, most players just held down that button, because of the increasing pollen perk, and this was a pretty dominant strategy
  • the prevailing strategy in this version was still: (1) get as many things a you can, (2) run away
  • colliding wasn’t clearly useful, though it was fun


I also got lots of great suggestions, especially from the play-tester who suggested Floral Combat!  I still need to address all of them, but most prominently on the list were:

  • make the flowers physically change as it gets more pollen.  They’re flower, after all <— how did I not think of this one??
  • add specials that cost pollen, using the other buttons (a vine grab, a burst, a root, bud turrets that drain enemy pollen, etc etc)
  • add the ability to launch bees
  • create a distinction between bees and butterflies; maybe bees are more plentiful, but produce less pollen and so are better for launching
  • add launching (I think I’ve definitely gotta do this, it’s gotten lots of requests)
  • reduce the pollen-o-meter to 1 type
  • add different types of insects that don’t give pollen
  • consider a different goal than “fill up pollen”
  • consider putting in spawners for the bees/butterflies, and making them exit sometimes (bees go to hives, etc etc)
  • try filling the background with flowers that change to your color the more pollen you have (to indicate the current winner)

One suggestion was to give the players health (represented by number of petals) and to have the winner be the last flower standing, but in thinking on it more, I would like to keep the game non-violent as much as I can.  I like the zany fun of throwing bees and butterflies, but I want it to distinctly not be a bullet-hell-combat game.

After Wednesday, I also got thinking more about flowers in general.  I think I’ve been pushing back at theme a bit too much, and now it’s time to embrace it.  Like, the fact that I missed one of the most obvious ways to represent change in a flower (budding†††), is a sign it’s time to investigate my subject more.

†††actually, I may go with ripening rather than budding, since buds woudn’t be able to make use of pollen/be pollinated

I watched lots of time-lapses of flowers growing, read about pollination, remembered bio things.

I started to consider other directions the game could go as well.  Some of my favorites were:

  • What if it encapsulated the full flower life-cycle, and involved water and sunlight too?
  • What if the flowers actually couldn’t move at all, and the entire game played like a time-lapse, where you could do thinks like grow roots and leaves in directions/open or close petals?


For GDC, anyway, I do plan to stick to the current game direction I have.

With all this in mind, I began on Thursday starting fixing the game.

The two things I wanted to fix the most first were: (1) conveyance of the goal, and (2) the dominant chaos-rush strategy.

To better convey the the goal and pollen transfer in general, I went back down to 1 type of pollen, and just set the pollen-o-meter as a bar above the players’ head.  I also added a less-subtle “I’m being filled” effect to show the rate of filling.  Additionally, I added a particle effect to show the physical transfer of pollen to the player from the insects.  I actually like how it turned out, it creates a pretty vortex 😉

Screen Shot 2016-03-11 at 2.44.55 PM

Another fairly significant change I made (and this one, I’m not yet sure how best to convey to the player), is that your pollen-o-meter fills more quickly the slower you move.  This means that running away means you’re not filling as quickly.  This, of course, needs testing to see if it actually does what I want it to do.  My hope is that it encourages more tactical play and stealing, rather than brute-force.  I also slowed down the players’ overall movement speed and added a damping proportional to the amount of pollen the player has.  I’m considering making the player grow, too, like I did with the coffee cups.  That would make it pretty clear who has a lot of pollen AND make that player a bigger target.

Oh yeah, and those button indicators (X,Y,A,B) appear now when you have enough pollen to use one of your four (two for now) specials.  The current specials I’ve added are: (1) a grab (planned to be a vine) to pull in the nearest thing you don’t already have, and (2) a nectar trap that you can spill to slow down anyone (including you) who get stuck in it†††††.

†††††Right now, it’s got the issue that it sticks you when you lay it down.  That’s a thing I should fix.  Also, yeah, I’ve lost track of footnote numbers.  Whatever.

Remember that time I said I would take more screenshots?  Well… didn’t happen this week.  Eh.

Here are some other screen shots.

Screen Shot 2016-03-11 at 2.46.03 PMScreen Shot 2016-03-11 at 2.47.15 PM

And with that, I think that wraps up most things.  This may not feel like much resolve for the week.  That’s because this coming week I’d like to continue unfinished work from this week.

I’m excited for GDC!

Until next time,


So Many Bees, Like, So Many Bees

Okay I think the best place to start is Mass Digi (so… Saturday), and then I can wrap around until Friday or something.

Last week on “this blog”…

Mass Digi day one happened.  I demoed the orbital version of Gobbler, people seemed to enjoy it so YAY!  I wrote last week’s post, then day two happened.

Day 2:

I demoed what was V 4.0 of Gobbler, a version closer to the initial pitch my brother had initially given.  Rundown: collect orbs or anti-orbs, win by having the biggest difference at the end of the round (so think of them as + and – charges, and only the magnitude of your charge matters in the end to score the round).

I had difficulty thinking of something that would read as opposites and would make sense, so I decided the players were bowls of soup, though, really, they looked a bit more like coffee cups.  Admittedly, I also animated them the way I think coffee cups would be animated.  So I guess they were coffee-cup-like bowls.  Actually, the file name had the word “cup” so maybe they were “cups” of soup (?) .  Anyway…

Screen Shot 2016-02-27 at 12.00.33 PMScreen Shot 2016-02-27 at 1.11.42 PM

There were several things that were nice about showcasing at Mass Digi:

  1. atmosphere: the crowd is very forgiving.  They know and understand games, a lot of folks interested in game dev, of course, given the nature of the event (i.e. participants are pitching games), and so, yeah, that was excellent
  2. downtime: because the main event WASN’T the showcase, I had plenty of downtime when participants were doing what they were there to do, and so I could implement fixes that people suggested.
  3. support: the crowd was also supportive
  4. free food!  I totally wasn’t expecting this the first day, but, hey!  I’ll do it!  Never turn it down.  It was great.

The biggest point was the downtime thing, because I was able to make changes to the game and see “oh hey, did that actually work”?  It was probably also pretty cool for the people who played, because they got to see their suggestions implemented the next time they got back to play.

This probably should have gone in with the atmosphere note, but something that came from the atmosphere was how wiling people were to play and give candid feedback.  I even got some testers who helped me catch bugs!  Since I did the no-pause-on-game-over thing, we were able to (and did) keep playing for, like, 15 minutes at least, trying to break the game.  It kind of reminded me of how my brother and I used to do that with games (favorite, by far, was Mario Kart 64, Toad shot-put on Block Fortress: Toad on top, Bowser with a star, see if you can get Toad over the wall).  You can see some of the exploits we managed in the shots up above actually.  Notice how sometimes there’s at least one player missing from the arena?

Oh yeah, I never explained why I thought soup made sense.  I went with “spicy” and “cool” flavors, and the soups were composing themselves out of cucumbers and peppers to be spicy or cool anti-respectively.

One of the player suggestions was for the soup bowls to get bigger, so I did that.Screen Shot 2016-02-27 at 1.00.15 PM

Oh, and initially I had just a label up top that changed colors to say who was leading, but… it was too subtle.  Something I’ve noticed about this version of Gobbler is that it’s got a lot to keep track of, and the more that can be represented entirely at-a-glance-parseable, the better, like, more than in the other version (even though, yeah yeah, that’s, like, always important, right?).

I knew when adding art, by the way, that this wasn’t a really color-blind friendly demo, since the sprites were just tinted, and at the same contrast.  I planned to fix that and was okay with that for this, because it was a demo.  What I didn’t know was that it also not very friendly to people susceptible to seizures.  One of the people who played told me that she had to stop because she is susceptible to absence seizures from certain visual stimuli, and, she was kind enough to explain what measures I could take to remedy this for her and/or others who might be triggered.  She suggested I mute the colors of the players and the walls, since, what was likely to trigger a seizure was the flashing that occurred when who’s-in-the-lead swaps really really quickly.  It was a quick thing to change, and she offered to look at the new palette, and confirmed that it was better.  I felt extremely lucky that she was so understanding, informative, and understanding about it.  It’s something I’ll keep in mind for future games too.


The biggest takeaway about Gobbler itself that I got from Mass Digi was that, in their present states, players found 1.0 more fun than 4.0; HOWEVER, I didn’t want to jump to conclusions.

I decided to consider it more on Monday.

Monday was a day of a lot of indecision and a lesson in JUST MAKE A CHOICE.  Probably this was also coupled with DO JUST ONE THING AND DO IT WELL.

I waffled a lot on Monday.

By the way, I want to be sure to talk about low points in development.  If I don’t, there’s this danger that these posts won’t be an honest reflection of my development, and, thus, won’t serve any real purpose.  I always feel this extra incentive to make progress each week because I know that I’ll have to write about it at the end, and if I’ve done nothing, well, that’s pretty sad.  I think it’s tempting to skirt around the low stuff and just focus on the positive, but I’ll try not to do that.  Not that I’m lingering, but just that I want to remind myself of the times I stumble so that I can prevent stumbling in the future.

I spent much of Monday bouncing between the two versions of Gobbler and the two versions I had of the game I was developing for Affectiva.  In my Monday meeting, I decided that I would end the week with a more-polished build of Gobbler and the game for Affectiva.

This turned out not to be a super-useful goal, but what led me there?  Well, I think I was worried that I wasn’t making progress quickly enough on Gobbler, and that I could urge myself to move more quickly to make a decision by setting a goal.

This didn’t entirely work, and so I scheduled another meeting with me on Tuesday (luckily, I was free then, even with this last-minute notice).

Why it didn’t work was because I spent Monday trying to split my time when it would have been spent better focused on one thing.  I was also being indecisive, and so I spent a significant amount of time sending out playtest builds to friends to get opinions on the two versions of Gobbler I think have the most promise.

Meanwhile, I did have a hard deadline for Affectiva, and I was waffling on the theme, starting to second-guess whether or not flowers made sense, if the game was fun, etc etc.

I did briefly demo the Affectiva game at Mass Digi for a co-exhibitor, but I had it set to some settings that made that a non-ideal playtest.

I’m going to give names to the Affectiva demos, by the way: Bee Hunter, and Bee Afraid.  I think the names make sense wit the games (shown in some previous post, last week I think?)

I’m going to fast-forward to Wednesday, because that was the most important day for me.

A friend and I co-worked and played Bee Hunter, because that was the one on which I’d received the most positive feedback.  I’d previously tried playing it Tuesday night with another friend.  Actually, maybe that was important too.  I think they’re both important.

Anyway, what I learned was that the game was more gimmicky than fun.  Something my friend pointed out was that by making one of the mechanics be to emote, I was sort of circumventing the whole point of emotional detection — then it’s a game about gaming the system or being “robot sneaky” as she put it.  Also, as for the emotional control, that felt like it was just slapped on; the sneak may as well have been a button on the keyboard in the way it worked.  Also, my face hurt.

What emotions ARE good for is making the world respond to you.

Based on these suggestions/this feedback/a lot of my waffle-thinking/etc/etc/other stuff/etc, I decided to:

  • Combine Bee Afraid, with Bee Hunter to make the game about collaboratively collecting (something my friend on Wed pointed out was that emotions are also more fun when they’re collaborative — she’s totally right)
  • Scrap the emotional controls in favor of emotional “mood-setting”
  • Set a new goal: make the game laugh with you

This meant a lot of changes, but nothing too crazy, and everything felt really worth-it.

Things started small, of course:

Screen Shot 2016-03-02 at 5.47.00 PM

I tried seeing how it felt for the bees to stay in the arena with you

Screen Shot 2016-03-02 at 5.45.12 PM

but then decided it was more fun if they fly in and can exit

Screen Shot 2016-03-04 at 10.04.16 AM

I turned down the bee’s freak-out speed, turned up your speed.  And…


Screen Shot 2016-03-04 at 10.04.28 AMScreen Shot 2016-03-04 at 11.21.33 AMScreen Shot 2016-03-04 at 11.21.23 AM

As of now, I’ve left the option to sneak via very barely using the joystick, like, just barely pressing it.  The sneak is just less effective.  Actually, something I noticed was that when I saw the expression on my player going into sneak, I started to make the face automatically, so… it’s sort of like the opposite of what I initially intended, but I guess that’s more natural.  It was subconscious.  Maybe I’m just emotive.  Anyway, I may cut sneak entirely (after all this, I know), because the game now becomes more lively the happier you emote, and sneak-face is kind of the opposite.

It’s pretty rewarding seeing everything come to life with a smile, which made me smile more.  THAT is what I wanted from this version, and so I’m quite happy with it.

Your animation changes, magic rises more fervently from the grass, the bees have more panic around them when they panic and the pitch of their terror scream goes up —

Oh yeah, also, the bees now scream in terror when you approach.  (I was really going for that good ‘ol Ren and Stimpy scream, but… couldn’t quite get it.  Eh, I’ve got a bit more time to polish it up.  Music would also be nice.)  I had fun.

The end of this week made up for the beginning of it.  I’m quite satisfied.  Maybe I even learned something.  Or something(s).

That’s all I’ve got right now, so I’ll depart.

Until next time,


Faces & Mass Digi

I was demoing at the Mass Digi Indie Showcase, which was a great opportunity to get lots of play on Gobbler (and I’ll be back tomorrow to get more feedback).

As for what I did this week, it was, again, a week split in two.

The first half was spent developing a game for Affectiva, that showcased their emotion recognition software.

The second half was spent preparing Gobbler for Mass Digi; it didn’t have to be polished, but I wanted it to be more than placeholders.

On my Monday meeting with myself, I broke down my tasks by day, since I knew where I wanted to be at the end of the week.

Monday: make something simple with Affectiva’s SDK.

Tuesday: develop a prototype of the game for Affectiva (with additional work to-be-done over the weekend)

Wednesday: prepare Gobbler for Mass Digi

Thurs: any last prep I need to do before Mass Digi

Fri: Mass Digi.

The biggest challenge for me was to determine what constituted “enough” work to be done to a game to make it presentable to players.  My metric for determining what to do/prioritize was to ask “what would I need to see in order to get what the game’s about without being distracted by what’s not there?”

I’ve noticed a trend that a lot of developers present their games at events like this with a lot of disclaimers like “alpha,” “pre-alpha,” “demo,” “prototype” — take your pick.  It’s a trend I want to avoid†, since I think that screams out “don’t judge me,” in sort of an ashamed way, and so my goal was to get Gobbler to a point where that sort of labeling wouldn’t be relevant.  Anyway, I sort of do want people to judge me.  I want feedback, and, the protection of a word like “pre-alpha” I feel like can be sort of a crutch; it’s a fallback that could allow me to leave it in pretty much whatever state I got to rather than whatever state I think is most useful.

†I’m not against telling people after they play that it’s a prototype; in fact, I told almost every person it was after they played, since I felt that was a good way to open up to critical feedback, and would make people feel less mean/able to be more harsh without inhibitions.

With all that in mind, my metric for what would make Gobbler complete was, that it had to:

  • be playable by the number of people I intend, and in roughly the way I intend them to control (Xbox Controllers)
  • have a definite end and be reset-able by the players
  • have some kind of art so that players have something to hold on to and can relate to it, even if it’s art for a different theme than what I decide ultimately

Actually, these were sort of my goals for the game I developed for Affectiva as well, since I’ll be sending them a version at the end of this weekend, so I can get feedback if they would like to provide any.

But I’m getting ahead of myself (perhaps because I’ve just come from Mass Digi) by starting at the END of the week with Gobbler rather than the BEGINNING of the week with Pounce, what I’m currently calling the game I’m making for Affectiva.

Affectiva, by the way, makes emotion-recognition software that is handy in that it doesn’t require any awkward sensors — it just reads from the camera.  Since this is the Internet, I want to make a habit of not passing judgement on stuff in text; I will at least say though that the emotion recognition was more accurate than I thought it possible to be, just be reading from a camera, so I was impressed!

I had a few game ideas to make use of the SDK, and they were:

  • a cat-catching-mouse pouncing simulator where you have to be sneaky (what eventually became “Pounce”)
  • a key-and-lock style navigation game with enemies that become more difficult towards both ends of the player’s valence spectrum, in different ways
  • a multi-player Rubik’s-cube-scrambling game played with your face
  • something more gimmicky, Face Face Revolution

I began with Face Face Revolution as my “I’m learning” game, where I could familiarize myself with the flow of using the SDK from the doc, and learn what it does best.

I actually started on Pounce earlier than Tuesday.  Learning the SDK was easier than I thought it would be!

I also changed Pounce a little.  I thought one player catching things was less interesting than two — also, I had just acquired a second controller to use for Gobbler on Friday at Mass Digi, and wanted to toy around with multiplayer stuff a bit.

I decided that Pounce would involve both players stalking the same thing, their ability to catch it based on sneakiness, as detected by various measures of the face/head.

Here was how it looked before some art was added:

Screen Shot 2016-02-23 at 2.52.56 PMScreen Shot 2016-02-23 at 2.53.15 PM

The white circle is the thing you want to catch.  The players are the bule and red circles.  Everything has a detection radius.  When one of the players’ detection radii falls into the white thing’s, the white thing goes into freak-out mode, and runs away in an (in theory) un-catchable way.  The yellow things are just obstacles to the players, but not the white thing.

The white dot on the players in one screenshot represents “I’m so sly you can’t see me!” which means you’re both sneaky enough to safely approach the white thing.

Oh, the goal, by the way, is to be the first player to catch the thing.

Also worth noting; the way I have it set up, both players SHARE sneakiness with each other AND up to 7 people watching them in the audience.  If your opponent is about to make a catch, you can try to scare the white thing away.

I did end up adding a little bit of art this week, by the way.  I actually strayed away from the original cat-mouse thing, towards something more logical.  You’re flowers trying to catch a bee.

Screen Shot 2016-02-24 at 10.50.28 AMScreen Shot 2016-02-24 at 12.11.09 PMScreen Shot 2016-02-24 at 12.10.44 PMScreen Shot 2016-02-24 at 12.10.27 PMScreen Shot 2016-02-24 at 12.10.49 PMScreen Shot 2016-02-24 at 12.10.35 PM

When I added art, I thought what was most important was to show a distinct difference in sneakiness of the player, so I made 3 sneak levels, which you can (sort of) see here (there’s a gauge in the top right) — there are both idle and moving animations, so individual frames might not make a LOT of sense as depicted above in still form.

I’d like to add a bit more dynamism to the movement of the player, since, right now, you there aren’t too many choices; I’d also like your sneakiness to have an affect on the level of freak-out the bee has.

Oh yeah, also, I wanted to make it iso rather than purely top-down.  Not necessary, but it was simple enough, and fun to do.

With Gobbler, I struggled quite a bit to get the art to a place I liked for Mass Digi.  I tried a few things.

First I thought, why not just do flowers for this too?  I made some art for that that was okay.

Screen Shot 2016-02-24 at 3.04.25 PM

Something felt off though, so I drew up a few different ideas.Photo on 2-26-16 at 6.51 PM

Eventually I went with Wizards who stressed about the arrival of their overseer, and wanted to be the one with the most stuff when he or she arrived.

Screen Shot 2016-02-25 at 1.51.49 PM

Probably the most useful thing I did for Gobbler though, and I haven’t mentioned this yet, but I sent the various versions of the game to my brother, who playtested with a friend.  They gave great feedback that led me to want to develop 4 (the one where you can launch both types of amo) and 1 more (the orbital one I’ve shown here with the art).

The feedback I got back indicated that a lot of the things I thought were fun in the abstract (a lot of the chaos) was actually just confusing, so I toned down some of the bounciness and speeds in some places.

I’m kind of going out-of-order here in explaining, oh Imaginary Reader, so forgive me, but, at Mass Digi, today I just demoed Gobbler 4; tomorrow, I plan to demo Gobbler 1.  They’ve kind of developed into different games entirely, and, well, you’ll see why.

The next most useful thing I did was playtest with a friend.  I can make excuse after excuse for not doing this sooner, but I won’t.  Yes, I had NEVER playtested this TWO-PLAYER GAME with a real OTHER person until this week.  Shame me shame me shame me!

Now that that’s over…

From a quick round of 1 and a round of 4, I was able to see a lot of things that needed fixing.  First off, 1 was boring.  Having the most things at the end of a time limit meant we didn’t really interact meaningfully until the end of the round, so, like, the last few seconds.  4 was definitely more fun, but it was also more confusing.  It needed something to indicate “who is in the lead?” “by what” “with what” etc etc.  I have to make some fixes to 4 before Mass Digi tomorrow if I want the playtesting of it to be meaningful.  In order to resolve the issue with 1, I changed the goal.  The wizards don’t need to impress their boss; they need to summon the fastest by maintaining the most power over either water or fire.  I added meters that fill up depending on how many things a player has.

Screen Shot 2016-02-26 at 6.35.17 PM

Also, I had way too much fun with particle effects (as you saw from the previous screenshot, but there’s at least one more in this one, plus the explosion, which isn’t pictured here.  Also, check out that grass!  (I… spent more time on the grass than I really should have, actually)

Then I prepared for Mass Digi.

Then I arrived at Mass Digi.

Then I decided fuck Wizards, everything should be flowers, so I swapped out the art before the showcase began (I had a few hours before it began anyway).

Screen Shot 2016-02-26 at 6.36.37 PM

It made everything much better.  The most consistent comment I got was that people thought the flower walk cycle was hilarious†† (someone referred it as “muppet-ing” and said that that’s the most important feature in the game and that I simply must keep it in.  I’m not one to argue.  I simply must!).

††side note: I have a going trend of not really ever making walk cycles for human characters.  When I think on what I’ve done walk cycles for, I’ve got: a sneaky robotic hand; a jack-o-lantern; a derpy chocolate cake; a cloud (no legs); a two-headed dinosaur made from the front halves of two regular dinosaurs stitched together.  It’s just better this way.

I was also really pleased that a lot of people came back to play a second time!  Best of all, I got great feedback for what/how to improve the game and make it more fun.

Tomorrow, I hope to get feedback on Gobbler 4.

Some other things I learned at the showcase: having multiple games out isn’t necessary.  I brought Screw Sorter and Pffffft with me (the batteries on both devices went near the middle, and I couldn’t charge off my computer because Macs only have 2 USB ports (!!!), which were occupied by controllers).  Anyway, the biggest draw was Gobbler, because it was on the biggest screen.  That just makes sense.  Also, Pffffft always worries me in crowds because it can easily panic and start detecting the ambi in the room if it’s not at a constant level, you know, like EVERY room.  Actually though, I was pretty impressed that I was able to get Pffffft to a sensitivity setting that made it pretty darn playable in the space.  It wasn’t super loud, which helped.

Tomorrow, I may just bring Gobbler 4 and call that good.  I brought a bucket of screws to go with Screw Sorter, but I think I brought too many.

Maybe if the mobile games were on tablets they’d be easier draws.

OH!  Speaking of draws.  Another thing I’m glad I did was disabling the pause that I had added when a player wins in Gobbler 1.  It meant that players could keep playing around in the space, watching the walk animation they loved so much, and watching the bees and butterflies bump around and orbit, even after the time was done.  It also made for a nice arcade-style attract mode.  There’s something to be said about the demo being different than how you intend the actual game to work.  I had some great conversations with playes where we were both just sitting in front of the screen doofing around with our flowers — and I WAS HAVING FUN TOO!  That’s always a good sign.

Well, this was a rambly one.  I’ll aim to fix Gobbler 4 before the showcase tomorrow.  Even if I don’t, just showcasing today has been an excellent experience.

Until next time,


Some Prototypes & First Android Submission :)

I split this week in two for myself (roughly anyway).

I spent the first half prototyping the game I’d like to work on next (right now I’m calling it Gobbler, but I think the name will change), and I set aside the second half for submitting Pffffft to the App Store and Google Play Store (it’s submitted yay!)

I’m going to explain my week a bit backwards with the tail-end of Pffffft, since my process starting the new game is pretty strongly influenced by how the dev of Pfffffft went, and talking about all the Pffffft stuff at once makes sense to me.

This was my first time submitting anything to the Google Play Store and the process is muuuuch more painless than– and as I’m writing this OH HEY the status JUST changed from “pending” to “published.”  Dang.  That was… really simple.  I submitted it, like, 2 hours ago.  This is … wow… I’m so used to the iOS process which…

Okay, let me back up.

In order to submit to Apple, you have to Archive a build (a few minutes), attempt to upload the build (a few more minutes), wait for the build to process (a few more minutes more), and if you’re like “oh shoot, that slider should really be inverted”† you have to do it aaall over again.  If you’re working from Unity, by the way, before you do any of that, you have to build a new Xcode project, which, depending on what your previous build platform was, may or may not write over some of the settings you had to set in Xcode to prevent some of the errors appearing.

†totally and absolutely fake example unrelated to anything here whatsoever at all

Oh yeah, and if there are complications along the way, after any of the steps… you’ve gotta start at the beginning.

Forget to increment your build number?  Well, it’ll tell you at the end of the upload step that it failed… Gotta change that and re-archive before you can start the upload process again.

Apple got sad at one of your archive settings?  Whelp, gotta re-archive again.

Apple Worldwide Developer Relations Intermediate Certificate expired a few days ago?  That’ll cause you all sorts of problems…

Screen Shot 2016-02-18 at 1.33.26 PMScreen Shot 2016-02-18 at 1.30.54 PM


(Somewhat related to stuff that takes a long time, I highly recommend, oh Imaginary Reader, either using code to take screenshots in Unity of the proper dimensions for the upload page, preferably via a Plugin — but more on Unity Plugins later!  I happened to find a very helpful post online with some sample code for how to do this that I used.  By the way, I’m pretty strongly against blindly pasting forum code to solve a problem.  Whenever I find sample code, I follow a strong rule that I never copy it.  I like to write out my own version of it so that I can learn the process, using the other code as reference.  I will admit that in this case I did paste in code from the forum to see if it did what I needed, i.e. take a screenshot, because it didn’t affect game code, and I felt okay doing that.  I’d like to find the post so I can give proper credit to the forum poster.  It was super helpful and did mostly what I wanted with just a little modification on my end.)

All this in mind, I was very happy to see the Android upload process was this:

  1. upload the apk file.

(The only hitch I ran into with Android was code signing, but I was able to find out how to do that pretty quickly, thanks to teh Interwebz)

Now Pffffft is uploaded and submitted (and live in one place!)!

I wanted to take some time to review some of the lessons I learned from Pffffft (other than how much easier it is to build to Android than iOS and how it’s somewhat remarkable I thought it would be the other way around).

I’ve touched before on how I sort of began dev for Pffffft in a backwards way; I had a heavy focus on the overall experience rather than the moment-to-moment gameplay until the last few weeks, when it makes more sense to do that the other way around.

I also let a lot of the theme dictate decisions I made instead of the other way around.

Some advice I remember getting in a game dev class when I was an undergrad that I didn’t quite understand but thought about a lot was that sometimes starting with a theme can be dangerous.

In the case in which I received the feedback, I was working on the art and some of the code for this game.  Our group made very fast progress in that class and had (I thought) a pretty well-polished piece by the end.  I was very proud of it.  In the beginning, during an in-person meeting with our instructors, one mentioned that it’s sometimes dangerous to have art so soon (I think we had art in our first or second prototype — partly because I was eager to integrate it; partly because my role was to (a) make art/animations and(b) integrate the art and animations; partly because I was scared that if I did it all at the end, I wouldn’t be able to figure out how to put it all into code — I’ve gotten a loooot better at decoupling since then).  The reason given was this: it can tie you down to a theme that doesn’t best showcase your mechanic and/or the fun of your game.  We brushed aside the suggestion to change tac and play around with other themes.  We had a positive feeling in the end, and, because of that, I never strongly considered how the game might have been different with a different theme.

Now that I’m done with Pffffft, I look at it and think about the fun of the game.  In my opinion, the fun of the game isn’t so much the blowing as the bouncing around and generally looking silly.  Perhaps I would have done better to pick a theme after ensuring the game was really truly fun and zany in the way I wanted.  That’s not to say I’m disappointed with Pffffft, but I do realize that decisions I made early on made me feel boxed in to continue along a trajectory that may or may not have been optimal.  Of course, I don’t want to wind up with the opposite problem of having too many options, I like having bounds.

What I want to try for this next game, however, is to make the bounds be the mechanics and the moment-to-moment play — this is pretty new to me.

I have faith that I can develop a theme that I like while also letting the mechanics dictate that theme, rather than working more off the theme.  Anyway, it’ll be an experiment!

What DID I make though?

I started with a concept pitched to me by my brother: a timed multiplayer game in which players compete to collect objects that have canceling interactive properties when combined.  You can use the things you collect as amo to cause opponents collecting the opposite thing to lose points, or you can horde them and play more defensive to try and not lose what you have.

For me-being-able-to-give-it-a-name-for-now purposes, I’ll call it Gobbler.  As stated above, that’ll probably change.

I made 4.5 prototypes (one was just an alteration/fix of the other, and I prefer it to the previous one).  Here they are††:

†† none of them are very color-blind-friendly prototypes by the way… I picked green and red, because they remind me of protons and electrons.  Then I realized, oh yeah, those colors often do that genetic thing in some people.

1.0 Orbits

Screen Shot 2016-02-19 at 1.09.37 PM

In this version, the players (pink square and blue square) have a finite number of orbs (green and red circles) they can collect on contact.  When you collect an orb, it gets placed in orbit around you, sort of like Bohr’s electrons (I’ve represented this by putting a colored border matching the player color around the orb).  Opposite orbs orbit in opposite directions.  When an electron green orb and an anti-electron a red orb come in contact, they annihilate in burst of energy.  It wasn’t fun to have them die though, so I had them produce a burst of energy, but not get destroyed.  Also, I thought it might be cool if your shell got bigger the more electrons orbs were in it, and this led to something kind of fun; you can have both types of orbs… as long as you don’t have a matching number of them.  Also, the nearer the number, the more likely they are to collide, since I made it take a bit of time for orbs to settle into orbit.

The win condition is to have the most orbs total.  In one version of this (the 0.5 version that I’m not counting), I made the goal optionally be to be the first to collect all of 1 kind, to incentivize players not to wait until the last minute, but I think I was thinking too hard about specifics then.  I cut that.  There are other things I could do to incentivize different types of play, like awarding an extra orb for holding a certain number for a certain amount of time, etc etc.

This version was originally going to involve some method of launching the orbs, but… I realized there really wasn’t a need.  You can steal orbs on contact and/or interfere with them by bringing opposite kinds in contact to create an energy burst and knock the orb away from your opponent.

The last thing I added was the ability to change your orbital speed, just so players aren’t always in-sync.

I think this version’s got some pretty cool potential.

2.0 Shooter

Screen Shot 2016-02-19 at 1.10.43 PM

I had a lot of difficulty developing this one.  It’s a side-view, with gravity facing downward.

The players are the pink and blue turret-like things that can collect different colored and valued orbs (the circles with numbers in them) on contact, but if you collect the opposite kind, it’ll decrement your count by that value.  The red squares you see, by the way, just spawn more orbs, since in this version, you can lose orbs.

I had a lot of difficulty figuring out what could be fun about this version.  I wasn’t too tied to the side-on thing, as you’ll see from none of the other prototypes attempting that.

The way you move in this one, by the way, is by firing charge blasts of orbs.  If you’re empty, you’ll dry-fire, which will still move you, but if you have orbs, you’ll fire orbs of that kind.

In this version, the thing that I think made it most unique actually wasn’t the side-on thing or the movement mechanic, but the orb quantity information.  Though this prototype’s a bit broken as a game (i.e. it’s not very incentivized to fire at your opponent, since hitting will just even your scores at best, lose you something at worst, and so sitting still is probably the best strategy once you have anything at all), I did like seeing the orbs combine.  Oh yeah, the orbs themselves combine too.  Opposites subtract, likes add (e.g. Red 2 + Green 3 = Green 1; Red 2 + Red 3 = Red 5).

This is something I may try to take away from this model.

3.0 Classic

Screen Shot 2016-02-19 at 1.11.28 PM

I realized I should probably try something more standard/closer to the pitch.  In this version player blue square and player green square can collect and fire twin-stick style (I also took this model as an opportunity to learn how to set up Xbox Controls in Unity on a Mac running 10.10!  These are the drivers I was looking for, by the way — took me longer than it should have to find them… but they just worked!).

Player blue square and player pink square compete to collect orbs (little green and red squares) on contact, and they somewhat annihilate inside you EXCEPT, I wanted to resolve part of the problem prototype 3.0 had; i.e. if you each have the same count of opposite orbs, it’s never advantageous to fire.  In fact, it’s NEVER advantageous to fire, because don’t need to fire to move, and you’ll always lose 1, and your opponent MIGHT lose 1 if you miss.  You’ll always be the one to want the rebound, by the way, because your opponent would lose 1 by picking it up.  In fact, the winner is pretty much always determined by the fortune of choosing the type of orb that the spawners (those red and green squares) spawn most.

To try and balance/fix this, I changed how annihilation works.  No orbs annihilate unless they’re inside a player, and when they do, they spawn an orb of the color that was fired at that player.  The net result of this sort of confusing-ly explained set of rules: firing at your opponent:

  • always reduces your count by 1
  • MIGHT reduce your opponents count by 1
  • MIGHT allow you bring your count back up to 1 again, making your net 0 or -1
  • MIGHT reduce your opponent’s count even more if you don’t pick up the rebound and hope it bounces at your opponent.

It’s a risk, but your opponent probably wont want to collect the shot you fired unless it reduces that opponent’s count to (otherwise it would cause more loss).

4.0 Heat

Screen Shot 2016-02-19 at 1.13.00 PM

After making what I called “classic” I realized that it lost something kind of key that was in the pitch but that I’d only tried in the orbitals prototype, i.e. the ability to have multiple kinds of orbs.

In this version, orbs don’t get destroyed, and, in fact, players (blue and pink duo-circles) can pick up as many of both types of orbs (green and red circles) as they’d like.  Only when an orb is FIRED does it pose a threat.  An orb fired by an opponent (or a spawner — those red and green squares with time-til-next-fire counters on them) gets HOT (as indicated by the yellow outer circles around some.  If you fire an orb, you can collect it while it’s still hot (blue’s fired orbs would have a blue outer circle in this prototype, pink’s would be pink), but if the spawners launch them, they’re dangerous to both players.

When hit by a hot orb, you’ll gain the orb, but you’ll also be forced to expel an orb of the opposite type, if you have any.

A sort of happy accident from this logic is that players with 0 orbs don’t need to dodge the spawners, and players never need to dodge hot orbs if they don’t care about the consequences.

In general, I like when being in last allows an easier jump to first (so long as I could add some mechanic to make being in first for a long time advantageous).


In looking at these prototypes and in evaluating which I want to pursue, what’s most important to me are these:

  • Is the main thing players do fun?
  • Is it easy to understand what to do moment-to-moment?
  • Can this be expanded to more than 2 players?
  • Do I want to play it?


Two tricky things about playtesting this are that (1) it requires at least 2 people to get a good sense of it (2) if I want to go with Xbox Controller controls, this will require both playtesters who are co-locus to also have 2 Xbox controllers on-hand.  This is something that I can help by being present for all playtests (i.e. providing half the equipment, and hoping that people are willing to play in pairs).


There is a chance, by the way, that this coming week will be an interlude from Gobbler (a name I mentioned more in this post with-respect-to-it-being-temporary than otherwise come to think of it) in order to develop a game to showcase Affectiva‘s software at GDC ;), so do not be alarmed, oh Imaginary Reader, if you don’t hear about Gobbler for a little bit.


Oh!  Plugins!  Something else I wanted to mention (man this is running long) was that this was (somehow) my first week attending Boston Unity Group.  The event was a panel, and, in addition to lots of in-general-good-advice given, there was a quite long discussion about how amazing Unity Plugins are.  It made me realized that I’m not very knowledgeable about what Plugins are out there, like, I don’t generally look for them.  Maybe I should start.  I often find answers to questions I have on fora, and people make suggestions that can often be followed without using specific Plugins.  Perhaps it also helps that a lot of the most popular Plugins have become, like, part of Unity.


All right.  That sums up most of it.  Oh, and I did miss Boston Post Mortem on Thursday.  It snuck up on me, I’ll admit.  I’ll also admit that it was nice to have a night off this week.  I had to person a little bit.


Until next time,


Embrace the BUMP

This was my last full week developing Pffffft; it’s definitely time to bring it to a close.

The most common playtest feedback I’ve received is that Pffffft is a “cool concept.”  This isn’t a bad thing, but a cool concept isn’t necessarily a fun game.  In the case of Pffffft, I must admit, I… think I’ve created something no one will play: a single-player mobile game that makes you look silly while you play.  Games that make you look silly are most fun when played in groups, and mobile games are often thought of as a commuter thing.  As the Boston Indie Games Collective folks pointed out during our meeting, it’s unlikely someone would want to play this during a morning bus ride, unless he/she/other doesn’t mind lots of stares (“Why’s that executive blowing all over his/her/other phone??”).

I hoped that I’d be able to overcome this somehow, but there’s only so hard a game can fight against what it is.

There’s also the issue that playing excessively, you might get pretty winded, and there’s… little incentive to keep doing that…

I do still plan to publish the game, however, since I’ve never published to Android before, and I’d like to gain some experience with the process.

All that in mind, knowing I’d be in my polish phase, the theme of this week was “Fuck it!” Yes, there’s only so hard a game can fight against what it is, so why fight it?  Why not embrace it?


My goal on Monday, in rough, was to get the game to a publish-ready state by Friday, create a build, let it sit for a week, and the publish a week later.  My goal, in particular, was composed of:

  • Add 2 very very short audio loops (menu, level)
  • Balance levels
  • Art Polish
  • Add a warning screen

(I made a conscious effort not to add any new features† this week, by the way, other than the warning screen.

†Okay, I added a “restart” button to the pause menu, and I did add a time display to the win animation… but, other than that, I didn’t really do much feature-wise.)


I decided on Monday not to add sound effects to my list of goals, since, if I was going to have any audio, I’d prefer music.  Also, audio + Pffffft doesn’t always = benign, since music is just another thing that the mic could pick up (and I didn’t want to do any fancy processing to cancel out the music etc etc, this isn’t that kind of game).

Also, I decided that, if music did cause problems, I could always just cut it, so it wasn’t worth spending a bunch of time getting right.


As it was the last week, I also wanted to make sure the game was, well, fun.

Many playtesters were getting stuck on early levels or dying frequently on the spikes, and so, in the name of fun, and the theme of the week, I decided, fuck the spikes!  They never did me any good anyway.

See, dying in Pffffft isn’t a very fun thing to do.  You have to restart the level… and try not to die… and then you get out-of-breath… and you don’t want to play any more… But what IS fun, is bouncing around, so I replaced all the spikes with Balloon Bumpers and redesigned the levels!

Screen Shot 2016-02-12 at 3.04.48 PM

Since I cut spikes, by the way, I also could safely cut the health bar, since… nothing could hurt Cloudy any more 😉

When I’d implemented bump and knockboxes, something I’d done was make the bump detector a component that anything could have, so I decided, just for fun, to add it to the goal too… and the other bumpers… and the sad clouds (they used to just fall, and would only move if you blew on them).

Pretty much, everything is a bumper.  It’s just better that way.

Some other feedback I’d received was that players were still sometimes getting out-of-breath.  A lot of this has to do with the fact that, in order progress through a largely-vertical level, you spend a lot of time fighting gravity.  So… fuck gravity!  Cloudy Cloud Cloud’s no longer affected by it!

Screen Shot 2016-02-12 at 3.03.25 PM

(That image doesn’t really show that there’s no gravity on Cloudy, but… eh, close enough, right?)

I don’t know why it’s always an epiphany, but going with worst idea possible is always so rewarding.

To be fair, I guess they’re not the worst ideas possible, like, they embrace what Pffffft is: it’s wacky and zany, not challenging and precise.  The spikes and gravity were hold-overs from when I imagined it more as a tactical platformer, and less of a fun toy.

In redesigning levels, my goal was no longer to present the players with challenges to overcome, but only to present the player with rewarding moments and/or opportunities to create fun visuals.

Because players can no longer die, every level can be brute-forced into completion, and I’m fine with that.  The levels near the end involve more bumping around and chaos.  The ones near the beginning are simpler and more open.

I fixed various other things, the most crucial, I think, being fixing tilt control.  Some players were still having issues with the tilt controls, so I tried making those more sensitive.  I know now that it feels much better for me, but I’m, of course, the worst barometer for that sort of thing.  I’ll see what people think in this final week, if it’s better, worse, and/or good enough.

I’m excited to start on something new this coming week.  I have lots of other ideas, so I have the weekend to think about it.  I can even take some of this coming week to experiment a little and find the fun.  Taking time to do that is definitely worth-it, and rushing into an idea, just because it grabs me at the moment doesn’t ensure that the game will be fun.

Before I go, here are some other screen shots, just because I want to put them here:

Screen Shot 2016-02-12 at 3.03.15 PM Screen Shot 2016-02-12 at 3.03.00 PM

Until next time,