Floral Kombat: Tabled Until Further Notice

Hey Imaginary Readers,

I’ve decided to table development on Floral Kombat until further notice.  These past few weeks, I’ve found it increasingly difficult to motivate myself to work solo. I would like to be a part of a team again, and, once I am, I would like to finish development of Floral Kombat, but not before. The game is very close to complete, but I would rather bring it to full completion when I’m full of energy than when I want to get it done.

This past almost-year of solo development has been very educational for me; not only have I learned about independent game development through trial and error, but also I’ve learned about my preferred work style and what sorts of things I’m most passionate about making.

I knew that I was more passionate about making niche things — “I’d rather make something someone loves than stuff everyone likes” — but there are other aspects that I’ve realized are very important to me too.  For instance, I care a lot that whatever I make encourages some form of engagement with friends, be that sharing the game to joke about it or simply playing together.

I also miss working on a team.  While working solo gives me full freedom, that doesn’t outweigh the benefits of feeling like I’m part of a community working towards a group effort.  I anticipated that working solo I would need to provide my own accountability, and I think I’ve done a pretty good job doing that, but I did not account for how much I would miss the social and community aspect.  The project I’m most proud of working on, Hack Punt Tool, a musical about the MIT student experience I collaboratively wrote with other MIT alums and students, felt so good to write because of how much we all cared about the project and all were able to motivate each other.  We shared so many late-nights-that-turned-into-sunrises together, and that’s not something I ever want to do when working solo.

I hope that I’ll be joining a team soon, and will then be able to continue development and this blog. I’m not sure how long that will take though, so I’ll make no promises.

It could be in a few days, weeks, or maybe some time next year.

If you would like a build of the most current version of Floral Kombat, I’d be happy to send it to you; just shoot me an email (zbarryte@alum.mit.edu), but I think it’ll be better to wait for the full release.

I guess this is it for now.

Until next time,


Floral Kombat: Tutorial

Probably the thing I like least about writing tutorials is knowing that most of what I put in will be ignored entirely or misinterpreted.

It’s much easier to choose to get caught up in making the menu very very very pretty than it is to invest in writing the tutorial…


And why not right?  I care a lot about aesthetics and making things pretty… and… and… I think it’s pretty…

I mean, I HAVE a tutorial button, so I’ll definitely do it… And yes, I have actually been working on the Tutorial, but… the menu is so much shinier.


Look at that bloom!  Look at that blur!

If I want people to read any text I have in the tutorial, I need to make it more than just instructional text. It’s got to text people will WANT to read and NOT want to miss.

It’s got to have the sense of humor appropriate to the game.

I do think Wand Wars does a pretty okay job with this by making the text all flavored dialogue and giving it sound that matches the mood.

What I want to do differently is use fewer steps.  I feel like I only need to explain 5 things:

  1. You are a flower and your goal is be the first to reproduce!
  2. You suck pollen out of bees (by holding down A, you move with L stick)
  3. You refill empty bees by launching them at refillers (using X and aiming with L stick)
  4. You knock pollen out of opponents by launching bees at them
  5. You can suck up pollen opponents drop when hit

I do want to use text to explain objectives, and I want to use images/animations to explain controls.  There’s a lot I’ve seen from testing that I don’t need to explain.  Something not yet in that category, but that I think should be, is that progress is displayed on the racetrack.

I’ve already started doing most of this.  Now I’ve just got DO the rest of it.

It’s less technically challenging and more mentally draining.

I guess it is worth sharing the progress I have made though.

Sep-23-2016 19-11-00.gif

Oh yeah, the refillers now act that new way where they only refill when targetted with a launch. They now also hold beggar-esque signs to explain the conversion they do.

Also, something something pretty water?  I got pretty into Caustics last week.

Anyway, that’s pretty much it.

Until next time,


Floral Kombat: FIG complete

This past weekend was Boston FIG, and so I got some excellent feedback on Floral Kombat — both during the event and leading up to it.

I unfortunately did not get a chance to explore the rest of the show floor to see other games friends were working on, since I did have a fairly regular flow of people coming to my booth — probably because of the title and very flash attract screen I used as the win screen:

Sep-16-2016 04-32-00.gif

I’m very glad I set up the game to be playable by 2, 3, or 4 people via a debug key rather than the character selection screen, since it was one fewer thing for players to have to do, and was literally as simple as asking “for N?” and pressing the debug keys.

The booth set-up involved a large monitor, 4 colored controllers (they roughly matched the character colors and were further marked with tape), and a vine-y plant (alas, of which I have no pictures).  I was able to fit everything more-or-less comfortably/uncomfortably on my bike, with its newly added milk crate.

FIG provided 2 chairs, and somewhere during the showcase, a third appeared.

Overall, I think I did a pretty effective job at making an attractive demo?  People who understood the game seemed to enjoy it, and I received NO comments that player interaction was meaningless.  This is really big for Floral Kombat, as that’s been a pretty consistent critique in the past.  In fact, I may have made attacking too advantageous, as it causes the hit player to reset entirely.  A lot of people thought that was unfair, and it did feel really upsetting to get hit when at ~99%, only to have the opponent win at the last minute.  I do like the ability for the match to totally change pace near the end, but I think players were right to suggest that attacking be nurfed from losing all pollen to losing at most 2/3 pollen.  Players also suggested making the total amount of pollen in a round never decrease, i.e. making pollen pickups not have a lifetime and making sure that no pollen pickup winds up out-of-bounds.  Also, pretty much every player tried to suck up the pickups rather than touching them, which is natural, as that’s the method of interaction that they’re taught to use by the game earlier.

The biggest points of confusion were:

  • What the goal is/where progress was displayed
  • What the rainbow trail means (some people thought it was a homing attack and was to be avoided)
  • What the point of the recharge flowers is – a common misconception was that they were the goals, or the things that give YOU pollen. A lot of people would put bees there and just wait.
  • Holding down A vs pressing A
  • What the arrows pointing to the recharge flowers meant – a lot of people also thought that there was some button they needed to press in order to give the bees, but more on that later
  • That the logs didn’t block bees — probably water would have made more sense for what those barriers were, but also adding blocking barriers inside the level is a thing players seemed to want/expect, which makes sense, given how important taking cover/creating bounces is when it comes to avoiding/aiming bee launches.

About Recharging Bees

Or… Bee-charging… in this world of portmanteaus.

I think the recharging mechanic needs to be redesigned for a few reasons:

  1. People find it unintuitive to donate bees; it’s a passive action and an odd one at that
  2. It’s easy to accidentally donate bees, they can get sucked into the vortex just by coming in contact with it. If this happens, it’s possible to win the game without ever actually understanding how recharging works.
  3. The stations were not very clearly intended for recharge, and so were often interpreted as other things
  4. The pollen level on the recharge flowers is technically readable in 2 places, but apparently unintuitive in both. Also, with how busy everything is, it’s really difficult to pay attention to minutia like the size of the recharge flower’s head and/or its heart fill amount

The current system has a few good things going for it mechanically though, and these should be preserved:

  1. Recharging takes time and is fairly camp-proof; unless you’re sneakily sitting in a corner, you can’t safely camp on a recharger.
  2. The act of recharging requires bringing the bees to a specific place and allows some bees to be more or less valuable than others.
  3. It’s easier to take bees from rechargers than to give them – well… arguably anyway, due to radius differences in orbits of players and rechargers.

What I’d like to propose is a system that’s activated by launching bees, not only for the reasons listed above, but also to include a prompt to teach the launch mechanic.

I would impose the design constraint that rechargers would only be allowed in places that can only be reached via launching (so not within orbit or the walking path).

To recharge a bee, a player would need to use X to launch the bee into the recharge area (which should be fairly forgiving, and should have some fall-back, in case of a miss). The bee would take some time to recharge, and then be launched out in some direction –not necessarily the direction from which it came, to discourage camping.

These new recharge stations should be labeled, and may even have a 1-bee capacity, though that may really slow down recharge, so maybe not.

I’ll try this and see how it feels.

Release Date and Future Plans

Going to FIG also gave me a clearer picture about what the ultimate fate of Floral Kombat will/should be.

In its current state, it is playable, and people do seem to like it. I don’t think the game will be very big, nor should it, but I would like to finish it and submit it to Steam with at least 3 unique stages, the fixes to the mechanics (and a few more) I’ve mentioned, and MAYBE customizable flower heads (beyond the ability to pick a pre-built head).

When will the release date be?

When it’s ready.

But! I’d like to aim for the end of September. Floral Kombat has reached a state where I’d like to finish it sooner than later.

This means that I likely won’t add any AI or Networked play, but I think that’s okay.  I like the idea that this game can only be played by friends who are in the same space.  It’s a smaller, cozier game, and I like the idea that it breeds gatherings rather than isolationism.

Ideally, I can get the conveyance upped to a pick-up-and-play level, because, right now, conveyance is the single biggest issue with the game. It can’t be easily described as “It’s just like [popular title] but with [tweak],” at least as far as I know†, and so players need to learn something totally new in order to play it.

†The closest I can come up with is “It’s like Sweet Day meets Wand Wars.” A lot of people also have likened it to Tower Fall, and I suppose it does have the amo-reuse mechanic in common, though it doesn’t have the elimination component — in fact, with the current version, catch-up is so easy, it practically doesn’t have places until the end (which, yes, I would like to fix via the 1 -> 2/3 pollen loss change).

The end of September is 2 weeks away, which should be feasible for the changes I want, and, if not, I can give myself extensions if need be.  I do want to be sure not to allow too much feature creep, and, instead, focus on getting the Minimum Viable Game published.  I can always extend it later if I’m feeling motivated and if players want that to happen.

Until next time,


Floral Kombat: 2 Days Until FIG!

(i.e. time to not add any more features, and make sure what features I do have work)

There’s not much more to say than the title, so let’s go on a toooour!

Starting Pan


Given that I’d already done a bunch of camera work, this took an embarrassingly long time to get right.

I thought this was worth the time though, because it gives the players a sense of where they are. On a map that can get so visually busy, I think it’s important for players to know pretty quickly which things are the ones they control. I hope the flowers stand out, but I don’t want to leave that up to chance, like player color choice (which will likely not be available in the FIG demo).

Probably what took me the longest was settling on the function to use for the panning.  I think I’m happy with what I chose ((-Cos(t * PI) + 1) * 0.5 I think or something equivalent?).



Play testing revealed that one of the most confusing things to players was that the pollen-giving flowers don’t always give pollen (because they run out of pollen themselves, until they recharge). I thought adding a counter might help, and…

…I’m happy to say that adding the timer made a new play tester say “Oh, they refill!” I’d call that a success.

Clarified Launching


Play testers were also not getting launching as quickly as I wanted them to understand it.

To remedy this, I’ve made the arrow appear immediately upon pressing X, and to have some default direction, based on the last direction you’ve tried to move. I decided to take a note from Wand Wars‘ book (again!) and make the arrow fill in rather than stretch up.

This means that players can very quickly see that pressing X does… something… and that that something can be charged by holding longer.

I’m happy to also report that this appeared to be successful with the next play tester!

I’ve also added an (obnoxious perhaps, but effective) indicator to tell players when they’re attempting to dry-fire.  I know that I used to dry fire, and seeing the red warning is enough to let me know “oh, I need to get bees” so that I’m not confused why I’m not launching any.

Refill Warning


On the topic of warnings, I also implemented (before the other one), a warning to let players know when their bees are all depleted and need to be refilled.  I do have those lines, directing players to the pollen-giving flowers (which have seemed to work well, even for players who didn’t understand the mechanics entirely), but I saw too often that players would sit and dry-suck bees, which is a move that’s only disadvantageous.

This does seem to be something that could prove annoying to players, but it’s also something an experienced player will never see (because it only happens on dry-suck), and it’s a good reminder to new players.

I just hope the scale function doesn’t make it too difficult to read. One version I made of it flattened the Cos at the top, so that the indicator was at a uniform max scale for longer, but it looked more rigid than I liked it to look. I know I shouldn’t be picky about cosmetics for something that’s there to inform, but I do think it matters. Maybe I’m just being too picky though… I still have a day to change my mind…

Head Shrink


There’s a pun in there somewhere that I’ve sadly neglected.

I’ve made the pollen-giving flowers’ heads shrink the less pollen they have and regrow the more pollen they get.  This is an attempt to make it really clear that the flowers are in some sort of dormant state when they’re empty and to also be an indicator that’s easier to read from a distance than the heart (which I may strip from them, but more on hearts later).

Passing the Crown


At least that’s how I’ve been referring to leadership.

The crown (i.e. rainbow trail) now no longer repositions to the center when there’s a tie.  This makes stealing look much less awkward. Last week I said that stealing looked okay, but… it didn’t quite.

This is much smoother.

In order to resolve the tie issue I had before, I decided that the crown should remain on the player who got the lead first, but should become inactive. This means that, in the case of a tie, no one has a rainbow trail until the tie is broken, and that, when the tie is broken, the crown travels (visually) from the player who was just usurped to the usurper.

This is an effect few new players seem to notice, but I do think it will help more advanced players. Maybe I’m wrong? I have gotten positive feedback on it though, which does make me happy.

Even if it’s not really a helpful or important thing… who could argue with rainbows. Right?

A Very Black-Knight Ending


I decided the ending needs more rainbows.

I also for some reason (because I’m horrible and lazy) decided that this gif should get cropped in a dumb way. It says “You Are Champion” — there’s not much more than that to say about this.

Pollen Bars


Ah, those fucking pollen bars. Those stupid. Fucking. Pollen bars. It was way more effort than it was probably worth to get the bars to move in a way that looks good, rather than snapping to fill levels or moving in an awkward way to them. I’m still not convinced this looks all that great, but… … I’ll admit, it’s not a thing I’d like to spend significantly more hours tweaking. I spent… maybe a whole day on it? I can’t remember.

Seeds of Glory


I suppose I’ve constructed this tour out of sequence. For some reason, I thought this was in here last week.

It. All. Blends. Together. T_T


When you win, your head bursts with a nice drum roll and… you get showered with seeds!

Yes. Those are intended to be seeds. I KNOW they don’t look a whole like them now, especially all mostly-monochromatic as they are generally. I’m not sure I’ll be able to make them look much more seed-like by FIG? Either way, they’re smiling, and that’s what matters.



Go ahead. Call me lazy. It works.

This much of an instruction set seems to have been effective enough for the people who play tested a version with it.

I was able to give someone the game, say absolutely nothing, and the person was able to successfully figure out everything I thought was necessary (except the value of launching and that pollen pellets could be collected).

Speaking of pollen pellets…

Sexy Pollen Pellets


They just got sexier.

A play tester noted that the pellets really didn’t look all that enticing. He suggested adding the God Rays to them (which is great, because I totally didn’t know whether or not the God Rays on the bees were working or not! I guess they are!)

I also made ’em daaance! Or… at least pulse. Like a lot of stuff in this game. Probably my second most-used effect. Maybe first?

Adding the Whole Gang


Finally the whole gang is here! Your favorite 4 anonymous flowers!

The FIG demo will be up to 4 players, and so I needed desperately to test that.

Thankfully… it looks like I did a maybe okay job in building this game to be scalable, because getting 4 player support up-and-running was as easy as plugging in 4 controllers and uncommenting some debug code!

It… may also help that I added the key mappings from when I did 3-player testing before…

Anyway, I’ve tested everything as best I can. It all seems to be working? I’m sure I forgot something… It scares me that it was this easy…

It should never be this easy…

Heartless Flowers

No images for this one, because… it’s been in all the previous ones.

Play testers were getting confused about wether or not they had bees because of how eye-catching the player hearts were, and so I ultimately scrapped them. They weren’t great indicators in terms of completion AND that information is conveyed in a pretty okay way via the race track at the bottom, and so play testers never looked at the player hearts. Well… except accidentally, and then they thought they had extra bees and would get confused why sucking/launching did nothing.

The warning indicators should help, yes, but I think the suggestion the testers gave of removing the player hearts was a very good one. It feels so much less cluttered on the screen.

I’m considering removing the pollen-giving flowers’ hearts as well, though I do think that those convey information that is more quantitative than the heads are able to give.


That’s all!

Well, almost.

There is one more thing to say, which I meant to say last week.  I mentioned I’ve gotten more and more into Shaders, and just wanted to give shout-out to my favorite function, Sign. It’s like the “You-Don’t-Need-Conditionals-Anymore” function. It’s such a smart function, one might say it’s… piece-wise ;p

Also, I found this thing, which confirms my delight.

Until next time,


Floral Kombat: 1 Week until FIG!

And so…

Time to get a everything sharp and ready.

Let’s take a tour, shall we?

The Fate of Gurding

After much experimentation, I really wasn’t feeling it. Though it was fun to play around with, when I actually wanted to move anywhere targeted or do anything precise, it just didn’t beat the previous movement controls — which people had commented in the past did feel very tight (a comment I wasn’t expecting to hear, I guess that’s a good thing though?). Gurding was also pretty dang tedious.

I tried alternates: Gurding alone, Gurding + movement, the ability to coil up for a Gurd while moving — nothing felt right.

Aug-29-2016 10-37-40

RIP Gurding… though it’s not entirely dead, because Gurding turned into:

Launching Bees!

Aug-29-2016 10-21-33

You can now launch bees at your opponents in place of the burst attack! Because it’s more difficult to land than the burst was, I decided to up the reward to the highest one possible: when you hit an opponent with a launched bee, ALL of that player’s pollen will drop out onto the floor in collectable pellets. The player could scramble to pick it up, try to launch a bee at you, steal your bees, or run away to get more bees. You can pick up the pollen or threaten another attack (if you have more bees) to prevent the opponent from collecting the dropped pollen.

Aug-29-2016 12-40-24

Bees come out fast, so the attack is pretty difficult to avoid I think.

Something I learned from Gurding that I applied to the Bee launch mechanic is that it really didn’t feel good to launch on release of the directional button when using a controller.  It felt okay on a keyboard, but that’s not my primary control target.

What felt better was Gurding/launching on the release of a button you have to hold down to coil, so now you hold down X and aim to coil up, and release X to launch.  You can cancel a launch by releasing the direction, but keeping X held.

Oh, and of course you have to plant yourself in order to launch.  This is actually very similar to how Wand Wars handles shooting Hexes (you slow down and use the same stick you do to move to launch, meaning you don’t need dual stick coordination, which a lot of people find difficult to master, AND it means that you need to make yourself vulnerable in order to launch an attack).

Cleaning up the Chaos

Man I love chaos, but it IS very difficult to tell what’s going on in a busy, chaotic scene, so I decided to pair down on particle effects and make every visual display as clean and focused as possible.

I started with Pollen-o-meters, which started the trend of the week, which was (unsurprisingly):


Aug-29-2016 13-53-52

Look at that pretty shader, all gradiented† and stuff :3

†I realized later that the gradient didn’t really read from a distance, so that got cut, but it was good while it lasted. RIP gradient…

I decided to put the pollen-o-meters on the HEARTS of the players/bees/etc, so that it would feel more included in the silhouette to not take up extra space or distract, while at the same time be very visible.

The first iteration was a bit too small, but I didn’t realize that before implementing…


Aug-30-2016 12-42-15

(to replace those sorta ugly Mandorlas I had around the bees when they were full)

I also paired down on the effects that go onto the player who’s in the lead. The bubbly flower particles were nixed in favor of some rainbow God Rays and I added some footstep-like hearts to extend the sense of motion/chase.

[I’ve been making a lot of clean shapes to use for particles, which I have in a separate folder ready to use, by the way, because I’ve been experimenting more with Particle Systems, possibly to put out a package with them on the Asset Store.  Maybe soon?  Maybe not.]

In implementing the God Rays, I came across a bug that I quite liked.  In previous versions, where i had the crown to indicate the leader, when two players were tied, there was no visual indication of which players were tied.  When I did the switch-over to the rays, I didn’t quite get the logic right to turn off the old one, and so the rainbow trail zips away, but the rays remain!

Aug-30-2016 13-04-58

It gives stealing the lead an extra bit of flash.

Aug-30-2016 13-06-03

You can also see, by the way, that the pollen-meters changed to li’l beating hearts 😉

Aaaand… A Few More Things

Sep-01-2016 15-18-34I…

  • changed out the tile sprites for more fitting ones
  • added some non-tile barriers (this game isn’t entirely suited to being on a grid, so why force it?)
  • changed the reticle on the currently selected bee to be a crosshair
  • added the ability to switch which bee you’re going to launch and made the bees launch from your center rather than just from where they happen to be(e) in orbit
  • changed the score display to one that better conveys the idea of RACING (i.e. a race track), complete with a flowin’ pollen-juice shader that trails behind your icon and a checkerboard shader for the finish line 😉 It even fits 4 players!
  • made the bee fire look… better?


I’ve got a lot of work still left to do.

For FIG, I think my demo will consist of 1 map, no character selection, and I may write the instructions nearby.

I’ve attempted to design the level to teach you how to suck bees, but I currently have nothing in place to teach the Kombat mechanics (i.e. launching bees).

That’s about it I think?

Until next time,



GoGoGadget Gurdy & A Battle with The Trait’rous GetComponent()

Boston FIG is in 3 Weeks!

Er… it was 3 at the beginning of this week, so… now it’s 2… but I like to think of weeks as discrete objects sometimes.


I’ve returned from teaching and so am back onto full-time development!

The course I was teaching, by the way, was a lot of fun! I’ve enjoyed teaching with MakeSchool before, but this time was even more fun — I enjoyed getting an opportunity to develop original curriculum, especially in such an open field, and, in general, find VR sooooo much more exciting than iOS.  Also, the students really blew me away with their final projects.  I can’t wait for the ones that aren’t yet up to hit steam so that I can show them to friends at home!

Now that I’m back, getting Floral Kombat ready for Boston FIG is my current priority.

If you’ll recall, oh Imaginary Reader, I received some great feedback from curators, which has given me good direction for which fixes to prioritize above others.

On the top of the list is making interactions meaningful.

A game I played while in SF that was very inspirational to me was a small-team-made local multiplayer game called Wand Wars.

It’s a lot like a game I’d seen earlier at a game night (but can’t remember the name of, so that’s not extremely helpful…) in which you hit a ball around, making it faster and faster, and try not to get hit if someone else hit it.

Wand Wars was more nuanced than the other game, however, with more varied courts, a top-down giving players more positioning options, and (most importantly) the ability to turn your opponents into chickens thus disabling them temporarily.

Wand Wars felt clean, polished, and well-balanced in terms of interactions. Everything I did to my opponents felt strategic. Even doing nothing and just moving felt strategic.

Inspired by this, I started this week by reevaluating the interaction options I’ve given the players in Floral Kombat.

I decided to try what I implement something a lot of people had been asking for — a dash, which I dubbed “Gurdy Movement” because it helped me to look to Gurdy Jr. or Lil’ Gurdy for inspiration.

I worked primarily in a sandbox scene and got something that felt pretty good.

Aug-25-2016 21-54-09

The idea is that this will replace the burst or movement altogether. Rather than walking up and bursting an opponent, you need to aim yourself, similar to the hexes in Wand Wars.

If you attract while you are jetting past someone, you can steal bees, and if you hit an opponent directly with a fully charged gurd, you’ll create a burst.

Aug-25-2016 21-57-39

Something that really bothered me about the way stealing bees was working in previous versions was how it forced players to be stationary for the most part.  Stealing involved walking up to a player, getting bees in-range of your area of influence, attracting, and then running away, BUT because you couldn’t move while attracting, the other player could just walk up and re-attract the bees.  The player could do the same back, and then you would both end up pretty much stuck in the same spot or in a slow chase.

Bursts had a similar problem. Bursting was too easy. You could walk up to a player and burst ad infinitum. I tried implementing burst juice, but even I couldn’t keep track of my juice level. Perhaps a conveyance thing, but I really wanted a way to get players to have to very visibly strategically time bursts.

I like the potential of Gurdy Movement to get players moving and to make 1 v 1 more strategic.

I’ve also reduced the size of attraction radii and decided to reduce the number of Bugs in each stage.  Resources should be limited to encourage competition, and radii should be small enough that Bugs can be owned, but outside the attraction radius.

The other big change this week is still underway: a battle against the once-friend GetComponent<T>().

But first…


Or at least backstory.

Whenever I learn a new engine, I like finding ways to optimize flow.

A way of doing this I was really proud of in Unity was via a Utility function I wrote called Utilities.GetComponent.  It looks a little like this:

public delegate void GetComponentCallback<T>(T component) where T : Component;

public static void GetComponent<T>(GameObject go, bool doForceToExist, GetComponentCallback<T> callback) where T: Component {

    if (!go || callback == null) {return;}

T component = go.GetComponent<T>();
if (!component) {
if (!doForceToExist) {return;}
component = go.GetComponent<T>();

Aside from the fact that I could really just say component = go.AddComponent<T>() this method’s not great…

See, what I was trying to do was save myself the time of aaaaalways having to call GetComponent and then check whether or not that component even exists, which means checking whether the object is non-null in some cases… but I starting using this everywhere.

I mean, like, EVERYWHERE.

Rather than passing specific components into slots of my other components, I started getting in the habit of passing in GameObjects and then using my handy Utilities.GetComponent method.

This was great, because my code didn’t rely at all on the GameObject existing at all.  Like, if I wanted to unhook something, I just needed to empty a slot and my code didn’t really care about that.

The problem was that framerate wasn’t so happy…

GetComponent isn’t constant time, it’s O(N).

As mentioned in a previous post, teaching made me reconsider a lot of the ways I normally do things, especially things that help with frame rate (because that’s so important in VR, to prevent nausea/eye strain among other reasons).

Utilities.GetComponent was pretty much EVERYWHERE in my code, but I decided it was time to bite the non-violent projectile and do it.

Needless to say, there was a lot of this:

Aug-25-2016 21-59-29

And, well… there still is…

But… working in a sandbox scene, I can see that the work/tedium paid off!


Screen Shot 2016-08-25 at 10.08.15 PM


❀✿** *✿:・゚✧*:・゚✧❀


❀✿** *✿:・゚✧*:・゚✧❀

Screen Shot 2016-08-25 at 10.10.11 PM

W0000! Look at that FPS.


(I just noticed there’s one more batch in the older version than the newer version… I’m not sure what that is, but I doubt it’s eating, like 100 FPS).

Until next time,


3x News!

This was an exciting week in terms of notifications!


Z Smart Tiles is now available on the Unity Asset Store!  It felt good to finally put that up there, and even get some downloads!  I put it up for free, since I just wanted to share it, and figured it’d be easier that way.


Floral Kombat was accepted into the Boston FIG showcase, so I’ll be showcasing it on September 10th!  😀

I received great feedback from the curators of Boston FIG.  Some overarching comments I’d especially like to address are:

  • The game is fairly stagnant with 2 players, and interactions aren’t meaningful
  • The high number of resources makes interactions generally unnecessary
  • Interactions, in general, aren’t very deep, and so the game has very low replay value
  • Winning doesn’t feel victorious enough

I have a fair amount of polish/refining I’d like to do between now and then, not the least of which involves smoothing the tutorial process such that anyone can pick-up-and-play with little-to-no instruction.  Though the curators mentioned they were able to pick up the controls, I’m unsure whether or not they were able to out of a sense of duty and whether or not they gave my game more patience than they otherwise would have.

Ideally I’ll also have it submitted to Steam Greenlight before FIG begins.


Er… oh wait… this one’s not a notification, and not really that great.

I incorporated Z Smart Tile into Floral Kombat (I’ve got to change from my default tiles, since they don’t really look right), and then, being bold and stupid, I decided to pack the sprites I was using before to reduce batches, and… it kinda messed up, like, all the shaders.

Aug-14-2016 23-09-16.gif

Eh, I guess that’s why I’m using git.

That’s all for this week.

Something I think will help with on-boarding in Floral Kombat is making the first stage more linear in nature, so that players can learn both the controls and the flow before being faced with another player.

Until next time,


Z Smart Tiles!

Remember that thing I said about the 2×2 sprite implementation being less efficient than the shader implementation… well…

Turns out that’s not actually true.  I did a comparison, and, as it turns out, the 2×2 sprite implementation is better, even though it uses more tris because the 2×2 sprite implementation allows using a sprite sheet (via the Sprite Packer), which means all the sprites actually use the same draw call 😉

(And just to make sure, I made, like 1024 of each type and checked the frame rate.  Honestly, I hope no one makes a tile map with that many tiles…)


Based on a suggestion from a friend, I also made a “how to” video:

I guess now I just wait for the approval process.  In any case, it feels real real good to have submitted, and I’d like to make a habit of this.

Something that this process reminded me was that publishing is more important than making something perfect (and also I was perhaps because I’ve been giving this same advice in the class I’m teaching ;p  I should take my own advice).

I spent a lot of time stressing over doing things “the optimal way” when really I should have just been pragmatic about it.  Stressing about doing stuff right can lead to that whole development-in-a-vacuum thing, and I’m always allowed to update.

Of course I don’t want to put out something that is low quality, but I also don’t want my projects to die in that bin of “I never got it good enough.”

That’s pretty much all for this week.

Next up, fixing Floral Kombat.

Until next time,


2×2 & Shaders

I’ve realized I’ve been really into ampersands recently.  For titles anyway.  I dunno, they just look efficient.

What did I do this week though?


I knock optimization a lot, and, like, for the most part, I think I’m pretty right to do it.  Like, premature optimization is the root of all evil and all that, though it’s important when the code’s causing actual problems.

I got to have fun with efficiency this week, YAY!

Well, okay, not entirely.

The idea for the Smart Tile package I’m building is to allow people to create Tile prefabs that they can drag into any scene, and that will respond accordingly to have their sprites match up, given a few input sprites.

The flow I want for people building tile maps is kinda like this:

  1. Create a tile prefab.
  2. Copy that tile prefab or drag out a new one.
  3. Magic.

That works for the most part:

Jul-31-2016 18-57-49

It even works with the 2×2 implementation I changed it to to allow concave corners!

Screen Shot 2016-07-31 at 6.59.39 PM

(trust me, that there is a concave corner sprite…)

However… the way I implemented it at first didn’t scale well with lots of tiles.  There was… pretty significant lag, and this was exaggerated when I changed to the 2×2 implementation.

Each tile is (at least) one Game Object (I this is the root of another problem, which I’ll describe at the bottom), and I was calling probably the worst function I possible could to get all the tiles: GameObject.FindObjectsOfType<>()… which is O(N x M), where N is the number of Game Objects in the Scene, and M is the number of components on a given Game Object… like, real real bad.

Also, I was kinda calling the map update once for every tile I was moving, so it worked fine while dragging one tile around, but got real real sluggish when dragging lots of tiles.

SO!  I changed the implementation to store each new ZAT_SmartTile (the name of the tile component) each time I add a new one to the Scene, and to remove it when it’s destroyed!  I also fixed that issue with multi-updating, so now there’s only one update called per group! 😀
Jul-31-2016 19-09-09.gif

Still though… because there are so many Game Objects…

Screen Shot 2016-07-31 at 7.11.35 PM.png

There are a lot of triangles… To give a comparison, a blank Scene would get me, like, 300 FPS…

This is sorta a problem I should solve, because tile maps should be allowed to be big.

In order to solve this, I may go back to some stuff I did this week that I thought was kind of a waste of time, even though it was a lot of fun…


Man, I could spend hours on these.  I did, in fact.

I spent a lot of time adjusting stuff, but mostly, being bad at math.

Jul-31-2016 18-57-04

I spent the middle of the week trying out a shader implementation that would allow me to draw the sliced sprite based on some settings for rotation and sprite of each quadrant!

Screen Shot 2016-07-31 at 6.50.31 PM

I scrapped this approach initially, because it seemed like it required a lot of set-up for the user, at least as I had it, but it’s looking like I’ll have to go back to something like this if I want to not slow things down horribly.

In any case, I am happy with the changes I did make this week, and they are definitely changes that I should have made regardless.  Like, faster = better generally with this kind of stuff, and now it’s written to be faster.

I’d like to put this thing up on the store by this coming weekend, so that I can call it done and funnel my energy back into Floral Kombat.

Until next time,


Reengagement via Smart Tiles

Probably the highest priority fix in Floral Kombat is getting those first moments of gameplay right.

My most recent attempt at conveying how pollen works is this:

Jul-22-2016 22-04-49.gif

I’ve added little globules that head over to your icon to attempt to direct your eye there when you get pollen.  I’ve also just written “pollen” under the percentage, and nixed the burst meter, since I really didn’t even notice it (I also got rid of the idea of burst juice, it didn’t feel good to press the button and have nothing happen (I’ll need to rebalance bursting some other way).

Is this clear enough? I think not.


I don’t want to talk about that.

Instead, I want to talk about this:

Screen Shot 2016-07-22 at 10.05.53 PM

Just a boring ol’ tile map, right?


Jul-22-2016 22-07-02

It’s made of Smart Tiles!  This is me adjusting the IN THE EDITOR!

I’ve decided to extend and polish that auto-tiling code I’ve been using into something I can put on the Asset Store 😉

I’m doing this for a number of reasons.

  1. Once this is done, I can use it in Floral Kombat (and any other tile-based games I make)
  2. It’s been on the tip of my mind for a while
  3. Doing something personal that seems like relatively low time-commitment has been helping me get back in the groove of doing personal work after jobly work.

As you may have guessed, the big reason here is 3.

Often when I can calculate how long a task will take me, if that time is large, I become rather afraid of the task and it’s very easy to work on something smaller instead.  I think that was happening to Floral Kombat — not in small part because it’s at a fairly feature-complete stage, but now is faced with a lot of tough questions like… so how do I make it intuitive?

Working on Z-Auto-Tiler (or ZAT, as I’ve been calling it, but probably, it’ll be really called Smart Tiler on the Asset Store, since that’s a more descriptive name?) has been good to get me back into the groove of my own stuff after hours.

Right now, ZAT is nearly ready for the Asset Store.  Like, I could probably put it up tonight if I wanted, but I do want to change on feature of it that affects structure, so that if I update it later, people who have chosen to use it can more seamlessly update it.

[That feature, by the way, is the way I’m spriting tiles; right now, I’m doing 1 sprite / tile, where a tile can have 0, 1, 2 adjacent, 2 opposite, 3, or 4 sides.  This doesn’t allow for as aesthetically pleasing concave corners though.  I’m going to switch instead to an implementation that uses 4 sprites / tile where there will only be 4 sprite types: side, center, corner convex, corner concave.  Here’s the problem I’m trying to resolve basically:


Oh! And one more thing.  Because having only one sprite per option could get kinda boring… I’ve added a “Reroll” button to each tile, so you can select as many tiles as you want and roll new sprites (assuming you have multiple for a type).  The result looks like this (the grass, not the rock, I’ve only made one of each rock sprite so far):

Jul-22-2016 22-22-09

Oh yeah, and these sprites… entirely drawn with just a trackpad!  Because… I didn’t bring my drawing thing with me.

And I’m so proud of how they turned out with just the trackpad!

More than I should be.

Anyway, that’s pretty much all for this week.

Until next time,