Happy Easter!

Happy Easter, everybody!

I took a few hours and wrote a little something for my kiddos for Easter and I thought I’d share it with the rest of the world as well.

So if you have an extra minute and want to see some funky eggs get tossed into a few baskets with a creepy chocolate bunny staring you down mockingly, check out my Easter 2011 egg toss.

Easter 2011’s Egg Toss has…

  • a score system in place, but not visible at the moment (working on it)
  • no end (as eggs will continue to spawn forever muhahahaha!)
  • 26 different eggs to chuck (and growing; more added by the hour)

Game-play is simple: when the egg pops up in front of you, [LMB] (click) to send it flying; [Space] gives you a new egg if you miss (or if you just want to see them).


Click here for Easter 2011!

Hierchical thinking with PlayMaker…

I’ve noticed something in this short time that I’ve been working with PlayMaker that I wanted to share. I’m sure the Hutong videos probably go over this much better than I will, but in my experience, there’s nothing quite the same as hearing about a product from a real user.

One thing that I’ve found over time with using someone else’s work is that when a refactor or reorganization is needed, third-party products typically leave you dreading the rework so much that you continue to pile more spaghetti on top of what you already know to be faulty.

Well, I am pleased to announce that with PlayMaker, this couldn’t be farther from the truth. It’s actually quite delightful to graph pretty state machines.

While the idea of an object’s FSM may be simple to start, it doesn’t always end up that way. For example, I started Zombs off with a character that could move. Simple enough. Then I added a state to let him fire. Again, simple enough. The next thing you know, the “simplicity” of it all had me taking damage, switching between weapons, controlling firing rates, handling movement, etc… all in one FSM. At this point the instinctive “clean-this-koi-up”-gremlin came knocking at my screen.

So the first thought was “well, I have a Gun object under my Player object… maybe if I move some of this FSM it will read a little more clearly.” Sure enough, that was exactly what was needed. In seconds, a new FSM was created on the Gun object, and after copying the Player‘s FSM onto the Gun (to bring events and variables over) I removed the states of the Player‘s FSM that related to firing, deleted the non-weapon states, and viola!

Now it seems to play the Player/Gun states even smoother… and I can find my logic!

Things were literally a copy/paste/delete away from being cleaner, more functional, simpler to expand upon, easier and debug and maintain than they had previously.

In the 15+ years that I’ve been coding, I can honestly say that this kind of foresight isn’t even one that developers usually take into account when writing their own code, let alone an expectation that they can put on a third-party tool.