Recently I built a game for my friend Amanda’s baby shower. (By the way…congrats again, Amanda!!) Everyone laughed at the jokes in the game, so it seemed like an all-around success. You can play the game here.

The game was built in Phaser. Phaser uses JavaScript, which I love and it has loads of built-in functions which made building the game a breeze.

In all, I’d say I worked on the game for about 20-25 hours, and a lot of that was looking things up, with a little bit of debugging misplaced parenthesis. Phaser makes getting started really simple, which is always a plus.

So starting from the beginning, I got the art for the game from Open Game Art, and Ofi helped edit it. The idea actually came from Ofi and Jessica. They wanted to do something different and fun for Amanda’s baby shower.

The game: User (playing as Amanda) will dodge people who are trying to touch her belly.

Since I was on a tight deadline, I didn’t have enough time to make the game work on a mobile phone, as well. That is probably the only thing about this game that I would change. To save myself some time, I used the game from TwisterJS as a foundation. Once Ofi and I figured out the mechanics of the game (left-to-right, across the screen), I was able to get started.

Since Phaser has a lot of stuff built-in, like running and jumping, it was easy to get version 1 out. I had a lot of help testing, and with feedback, I added the awkward things that the strangers say to Amanda. Those are just stored in an array and chosen randomly.

With more testing and feedback, I added comebacks for Amanda to say to the strangers. These are also stored in an array and selected randomly. (If you download the repo on GitHub, you can see these comebacks. Download the repo here.)

I wanted there to be an end to the game, so I gave Amanda limited ‘patience.’ Similar to lives, but when Amanda runs out of patience, the game ends, and she starts swearing in a thought bubble.

To make sure the game would eventually end, I increased the amount of strangers being generated in conjunction with the amount of points the player has. Every 500 or so points, the number of strangers being generated doubles. Phaser has a very handy built-in loop, which made generating the strangers very easy.

The points were just a small function adding the new points to the current points with +=. Because I was trying to discourage people from just standing there hitting the strangers (the goal was to jump on them), I set the hits equal to two points, and the jumps equal to 10.

I wish I had had a little bit more time to build a top-score list, as that could’ve been very fun. All-in-all, this game was very fun to build, and I was so happy to be able to give Amanda and Jesse such a cool gift for their baby shower. I learned a lot, and now I am plotting my next game.

Questions? Tweet me!

I was fortunate enough to speak at OKCjs this afternoon. OKCjs is our local usergroup, and I can say the best bunch of nerds I’ve ever met. I could write an entire post on how sweet, welcoming, and helpful these people are to beginners. In large part because of the people I’ve met at OKCjs, I am further in nine months than I could’ve hoped to be in years of self-learning.

Seriously, if you are in Oklahoma City, definitely check out OKCjs, and Techlahoma and see all the cool stuff that is going on around here. It might surprise you!

Today I spoke at Lightning Talks, which is essentially a mish-mash of short, very insightful talks. Other people who spoke included Nicholas Lindley, Jonathan Yarbor, Raymond Lewallen, and Adam Rackis. All of their talks were fantastic! It’s really great that we have so many knowledgeable speakers willing to share what they know in the Oklahoma City area.

In my short five-minute talk, I went over JavaScript libraries.

Basically, a library is a collection of JavaScript functions that you can include in your project. Someone has gone in and written out these nitty-gritty functions so you can have the benefit without the nitty-gritty. I am deeply appreciative of anyone who writes libraries.

A framework is also a collection of JavaScript functions. Essentially ‘library’ and ‘framework’ can be used interchangeably. However I did find an explanation of the differences between the two that I really like. (Note: I will say library throughout this post, but I am referring to both libraries and frameworks.)

A library will allow you to pick and choose which functions you would like to use. Much like a physical library doesn’t require you to read every book in a specific order, and you can check out whichever books you want.

A framework will provide a very specific way to write your code. And much like the frame of a physical structure, if you don’t follow the framework layout specifically, things can begin falling apart.

There are loads of different libraries out there, and I’m not in the business of telling people that one tool is superior to another. I will tell you to research a library before you start using it, and really consider whether or not you need it. A library is adding complexity to your project. If you project doubles in size from your library, consider if you can do complete the project without the library.

I said this several times during the talk, but I really believe it can’t be said enough.

If you can’t write the code without the library, please don’t use the library.

It may seem nice in the short term to just get your work done and out the door, but you will do far better in the long run if you can write the code without the library. Don’t take shortcuts in your learning, you’ll end up shortchanging yourself.

Also beware of using multiple libraries together, as this can cause compatibility problems. Using more than one library isn’t bad, you just need to research and make sure you can use them together.

And whatever you do, make sure the version of the library you are using has the word ‘stable’ in there somewhere. You don’t want to use a version that is still in development!

You can see the slides from my talk here.

Questions? Tweet me!

You can’t handle the truth!

JavaScript can’t either, which is why it uses type coercion to convert most values to a ‘truthy’ value. What does this mean?

Well, the true boolean value is just ‘true’, right? That is accurate, but it’s good to know that JavaScript also interprets the majority of other values to be true as well. Meaning, if they are place in an if statement, JavaScript will go ahead and run the if statement because the statement isn’t false.

Obviously JavaScript interprets the boolean value ‘false’ to be false. But there are a few values in JavaScript that are interpreted to be falsy, and as such, JavaScript will not run an if statement that is dependent upon these values. The values are:

• 0
• ””
• null
• undefined
• NaN

Other than being a handy little bit of trivia, what is this useful for? Well it’s not something that will always be useful, but it’s definitely worth filing away for future reference. Here’s an example of a use-case I ran into lately.

Recently I wrote a game for a friend’s baby shower. (You can play it here, if you’re interested. Or you can check out the code here.)

One version of the game included pausing when the player jumped on the bad guy. I wanted the bad guy to be destroyed on unpause. But the problem I was running into was that Phaser, the platform I used to build the game, runs the update function pretty much constantly, and I have to destroy the villager in the update function (because it’s called immediately after the game is unpaused).

But here’s the rub: there wasn’t always a villager that needed destroying. Since that was coming back undefined, my whole game was breaking.

Having the falsy value trivia tucked away, I was able to work around this relatively easily.

if(currentVillager) {
	currentVillager.destroy();
}

In the function where the player jumps on the villager, I pass that specific villager to a variable called ‘currentVillager’. Then in the update function, I have an if statement checking for ‘currentVillager’. Lucky for me, JavaScript interprets undefined as a falsy value, and skips my code if there isn’t a villager in the ‘currentVillager’ variable.

Pretty handy!

TL;DR

If you have some code that only needs to be executed if a variable has a value (or isn’t undefined), you can wrap this code in an if statement and take advantage of truthy and falsy values!

Questions? Tweet me!

Have you read or seen Shakespeare’s ‘Much Ado About Nothing’? It’s a pretty funny play. The short story is that two characters have a thing and want to get hitched, except a rumor gets out that the girl has been hooking up with this other dude (not her boyfriend). Chaos ensues because it was back in the day and that sort of behavior was unseemly. But in the end it’s all ok because it was just a rumor, and didn’t really happen.

Much Ado About Nothing.

That pretty much describes my relationship with callbacks up until recently. I was really intimidated by the idea of them, and if I saw them I tried to find some other way of accomplishing my goal without using callbacks. However this mentality – appealing as it may be in the moment – is not conducive to growing and learning.

Recently I was working on a game in Phaser. (I’ll post more about it soon.) I wanted to call certain functions upon specific key presses. For instance, when the user pressed the spacebar, I wanted their character to jump. I tried really hard to find a way to do this without using a callback, and I came up empty. So it was time to me to face my fear and figure out how to work with a callback.

Turns out in looking at them more and really focusing, I was really getting intimidated and worked up over nothing.

So what is a callback exactly? Well, a callback is a function that is passed in as a parameter. It might look this:

spaceKey.onDown.add(jumpUp, this);

You can see more code here.

So basically what this is saying is “when the user presses spaceKey, call the jumpUp function.” In this case, the jumpOn function is only called when the player presses the spacebar.

Here’s another example.

module.exports = function getExtName(dirName, ext, callback) {
  var result = [];
  fs.readdir(dirName, function(err, files) {
    if(err) {
      console.log(err);
      return callback(err);
    } else {
      for(i = 0; i < files.length; i++) {
        if(path.extname(files[i]) == '.' + ext) {
          result.push(files[i]);
        }
      }
      return callback(null, result);
    }
  });
};

And here’s the function being passed in…

function outputToConsole(err, data) {
  if(err) {
    console.log(err);
  } else {
    console.log(data.join('\n'));
  }
}

mod(filePath, extName, outputToConsole);

You can see more of this code here.

As you can see above the callback function is returning data, whether it be the error, or the data that the function is manipulating and then returning. This is done as a callback to the fs.readdir function because we need the data to be read in before we do any manipulation on it. Otherwise the outputToConsole function would likely run before the data was even read in. That would in turn mean that data would be undefined and the function wouldn’t work.

Notice that in these functions when I pass in callback, I do not pass it in with parenthesis. This allows the function to be passed in, but not called until I choose for it to be called.

The nature of JavaScript is that it reads your code from left to right, top to bottom. It runs any functions in the order they are called. But there are cases (like the examples above) where you don’t want the function to be called when it is read. You’ll only want it to be called when something else happens…like when you get the correct user input, or you want it to wait until after your data has been read in.

This is why callbacks are so handy!

Think also about if you are waiting on the user to give your program data. Any manipulation of that data would have to wait until the data has been typed in. (Otherwise the variable holding your data would be undefined, right?) This is another good example of when you might want to use a callback.

TL;DR

Callbacks aren’t as scary as they seem. Write up your function and pass it in as a parameter (without parenthesis) and then you can call it only when you actually want it to be used. This allows your other functions to continue running while you wait for user feedback, or to access the information you need for your callback.

Questions? Tweet me!

So I just gave my first talk at Tulsa Tech Fest last Friday. I’ve spoken at OKCjs (my local usergroup) before, but those were short 5-10 minute lightning talks. This was a full length presentation. And it was about Star Wars. (You can check that out here.)

Regarding the talk itself, I decided to give a beginner talk. Why is that? Well, I don’t feel very qualified to give any other type of talk! Beyond that, I am all about beginner talks. Why is that?

When I attended my first conference (which was not that long ago, if I’m being honest) I was a total newb and I didn’t get much out of it. Through no fault of any person, it’s just the talks were at a higher technical level than I was actually at. I did learn one thing about Node servers, and that was really it. I remember being so bummed, because I thought I was going to learn a bunch and I didn’t.

Not to say I regret going. It was a really fabulous networking opportunity, and I did meet some really cool people. Also I’m able to go watch the videos of the conference and understand far more than I did then.

But suffice to say, I wanted to give a beginner talk because I wanted to attend beginner talks. Be the change you want to see, right?

I did learn a lot from speaking, and I wanted to share some of the things I learned.

Start on time

My talk was scheduled for 75 minutes, or 60 minutes for the presentation and 15 minutes for Q&A. But my room filled up really quickly, and before 3pm, my scheduled time, we had already run out of seats. I didn’t think anyone else would come in, so I started my talk more nearly 10 minutes early.

Learn from my mistake and wait until your scheduled start time, or even two or three minutes after. I had people continue wandering in after 3pm, and they missed the first 10 minutes of my talk, which was a bummer because I’m hilarious. ;)

Engage your audience

I thought I did enough with choosing a unique and funny topic. But the truth is I ended up just sitting in a chair talking to my audience for close to an hour. This is pretty tough for me because I can get really nervous, but I should have been up and moving around, and trying to engage the audience more.

Ask the audience questions

Don’t expect your audience to have questions immediately. They might think of questions later on, or (and this is especially the case in beginner talks) they might be too nervous to ask whatever question they have in mind. Go into the talk planning to ask questions to the audience to get a conversation going. To give you an idea, I came with an example of a project they could create a program for. I asked them how they would handle this program, and then moved on to the plan I created.

But I missed an opportunity to engage my audience further by working with them to make a full plan for their program – entirely their own. Listen for when your audience starts talking, and focus on that, even if it means deviating from your notes.

Come in with code

I didn’t do any live coding, nor did I give any code examples. My talk was about using your skills to better your community, and while I gave examples of projects, I didn’t give any code examples. If I have the opportunity to give this talk again, I will do more of a workshop, and actually use the tools I’ve mentioned, instead of just talking about them.

Just start talking!

Even though I had several spots where I could have done better, I am still really proud of myself that I did it! It was really nerve-wracking to get up in front of people and talk. There’s a fear of rejection – and that’s really tough to overcome.

What is your first talk going to be about?