First Look at Yeah Jam Fury: UME!

So we’ve recently started showcasing gameplay overviews, tips, and tricks across our various social media platforms to help spread awareness about the new game.

The first question you might ask – what exactly is Yeah Jam Fury?

And this week we’re featuring tips for the first of our lovable trio named Yeah!

Be sure to follow @YeahJamFury and @McLeodGaming on Twitter to keep up to speed, and expect many more updates to come in the following weeks leading up to release in December!

New Twitter + First Commercial Game On Its Way to Steam This December!

So two things:

First, I have a new Twitter handle @RealCleod9 so please follow me! (This is different from my company Twitter @McLeodGaming since I plan to use the new one for interpersonal connections and game dev banter)

Secondly, in case you missed it from my various other news outlets, Yeah, Jam, and Fury are back in an all new game coming to Steam this December for Windows, Mac, and Linux!

I’ve teamed up with World Entertainment Studios (formerly WillyWorld Entertainment), to transform what was once a simple Flash game into a full-fledged puzzle-platform experience for the desktop!

In this new version there’s over 100 levels of puzzle-platforming fun, new game mechanics, crisp HD graphics, gamepad support, leaderboards, a custom stage builder (with sharing!), dozens of achievements, and more!

I’ll be updating this blog during my journey towards a release date. In the meantime, here’s a brief introduction video on the basics of the game:

Long Time No Updates: Here’s Some Piano Sheet Music!

So it’s been quite some time since I’ve written any posts (and even longer time since any of them were music related!) so I’ve uploaded 3 new pieces of piano sheet music to my Music page!

(Special thanks to Iker Estalayo’s YouTube channel for providing the basis of these beautiful piano renditions of music from DBZ Super’s OST!)

I’ve been wanting to get back into transcribing pieces for piano, so if you find these interesting or would like to make a request please leave a comment! I find that transcribing pieces from anime and games is pretty relaxing and helps keep my music chops fresh. I’m definitely hoping to do more of these for the days to come.

In addition, I should note that this year I plan to shift the focus of the blog towards game development. Up until now I have spent most of my time in the professional web development space, but my true passion is games. I hope to share all sorts of knowledge I’ve amassed over the past decade – hopefully something I’ve learned will be useful to you readers out there!

PostScriptum.js Deprecated (And Some Tips on JS Promises)

So today I’m officially deprecating my Promise-like JavaScript library, PostScriptum.js.

While it had a good run and indeed solved a problem I was having with a huge project, I’ve been using Promises long enough now to realize there are plenty of ways to handle my use case with Promises if implemented correctly. It really just comes down breaking down your promises into operations that are as small as possible and not being afraid to nest Promises just a little bit when control flow necessitates it.

There was also another major thing that turned me off about Promises initially, though I’ve had a change of heart recently. It was about the proper way to cancel Promise chains, since it’s very easy to get stuck in an anti-pattern if you’re not careful in how you write rejected handlers. What I found really helpful is described by the diagram in section 4.2 of this article:
(Read the rest of the article too if you have time, it’s extremely helpful)

The diagram in that section describes the control flow after a promise is rejected, and it looks very much like a literal game of catch where errors are thrown from the left-side of the diagram and caught on the right. What I didn’t quite understand before is how Promises try really hard to not to stay in a failed state, and they sort of “toss” back to the left side of the diagram unless you explicitly throw another exception. I know that might sound weird, but another way to put it is as follows:

Promise chains that land in a rejected handler will always “bounce” back to the next subsequent resolved handler (provided that no additional errors are thrown within the rejected handler, in which case it would move to the next rejected handler)

This is crucial when managing errors, since if you’re not careful you’ll end up from a rejected handler back in your resolve handlers where you really didn’t want to be. The easiest way to avoid the above problem altogether is to only ever have 1 rejected handler in any Promise chain. Remember that catch() is just syntactic sugar for then(undefined, rejectedHandler). So once you understand that much and realize how Promises flow down the resolved side VS the rejected side, things start to make a whole lot more sense.

Maybe at some point I’ll do a more in-depth post about how promises work and how to avoid certain anti-patterns that I ran into. But for now, don’t use PostScriptum.js and grab another library such as Bluebird, RSVP, or even just use straight up ES6 promises.

AS3JS 0.3.0 Released

So I thought I’d do a brief post about version 0.3.0 of AS3JS, which I released a few days ago. It comes with a bunch of various bug fixes, a few new configuration options, and an all-new live browser demo of everything in action!

The biggest change about this update however, is that I’ve separated the output “program” from the “loader” for the library. In other words, output from the AS3JS library is still “vanilla” JavaScript for the most part, but I’ve stripped out the part that actually initializes your application and placed it in a separate script. The main reason behind this is that I had always wanted to build a browser demonstration of AS3Js, but it seemed like all the extra boilerplate could be a turn-off for some people to look at. So by writing out the AS3 program as a basic JS object containing a hash of class names to modules, it allowed me to drastically reduce the amount of text in the output file and generalize the loading process into a separate function. So it’s just a matter of calling AS3.load(…) and passing in your “Program” object, and it will start up your application at the entry point that you specify.

Definitely be sure to give the demo a try! With this update I hope to more cleary demonstrate both  the similarities between AS3 and JS, as well as distinguish the load process for running a package-based app versus a traditional module-based one.