MelonJS Space Invaders

MelonJS is one of several HTML5/Javascript game engines available, and it’s actually not too difficult to work with. There’s some really good documentation at http://melonjs.org as well as two very good game tutorials. There’s a platformer tutorial here, but the retro gamer in me was really drawn to the space invaders tutorial. I was worked through the space invaders tutorial as part of a “coding carnival” at work – basically a coding challenge that had the goal to implement one of three classic video games. I wanted to do the space invaders type game, so I selected that option.

When you finish the MelonJs space invaders tutorial, you have barely playable game. The player can shoot at the ever-encroaching invaders, and rack up points for enemy kills, but there’s not much more than that. Obviously this is the point of the tutorial – get the game developer to a point where they have created a really basic game, and provide them with the basic building blocks to be able to take their game to the next level.

After completing the space invaders tutorial, the first thing I wanted to add was enemy fire. In the basic tutorial, invaders moved as an implacable force down the screen toward the player, but they didn’t actually shoot at the player. Before I could do that, I found that I needed to alter the player object so that it extended the me.Entity object rather than the me.Sprite object that’s provided in the tutorial. This would allow my new Enemy_Laser objects to be able to collide with the player.

In addition, I wanted to use some of the original imagery and sounds from the classic Taito Space Invaders game, so I Googled until I found the resources I wanted. Afterwards, I used Photoshop to create sprite images for the invaders as well as the player. I was able to add sound effects that were sampled from the original game, and I found that this was definitely taking me in the right direction.

Once I had the enemies shooting back at the player, I needed a way to throttle the enemy fire. While working through this, I introduced something that I’ll call the alien rain of death by virtue of using one equal sign in a conditional test rather than two. Remember kids, when you say something like this:

if (myVariable = someValue)

in Javascript, you’re doing an assignment of someValue to myVariable, and the return value is ALWAYS TRUE. So, if you do that in a while loop, it will never end. And if that loop is spawning enemy fire, well … you are completely screwed.

One of the things I found was that MelonJS provides audio features, but you have to be careful where/when you play a looping track.

For example, when I added the mothership, I wanted the audio file “ufo_highpitch” to play while the ship was on-screen. It turns out that you need to place the looping audio track following your animated sprite. For example:

Another thing I realized was that I would be easier to accumulate player shots and use this counter to trigger the spawning of the Mothership rather than using a timer. I created a MotherShipContainer class to manage spawning and reaping mothership instances, and I initially thought I could use a me.timer method to control when to spawn the Motherships. This approach was really wonky, and led to fantastically weird results. So instead, I decided to accumulate player shots, and use this as a way to spawn Mothership inastances.

The code for the accumulator and how it was used is below:

Here, notice the accumulate functuion. This is simply incrementing a counter every time the player shots. Then, in the update() method, the shotCount is compared to the randomly-selected threshold value. If we hit that value, then we spawn a MotherShip. Notice in the spawnMotherShip method, I reset the shot counter as well as the threshold value.

There’s plenty more to discuss about this game, so I’ll tackle these additional findings in future posts. For example, I had fun trying to figure out collision detection, and I’m sure there are things I can do to improve the HUD and UI.

Oh yeah, you can play my version of Space Invaders here. If you’re interested in the source code, you can find it here on GitHub.

Image Matters for Remote Workers

It’s becoming increasingly common for software developers and other IT professionals to work remotely. While the amount of remote work required may vary among different companies and across the field, I think it’s likely that the trend will continue. As enabling technologies improve, web-based video calling and shared-desktop applications will be ubiquitous, and both employers and remote workers will see increasing value and share positive experiences with remote work arrangements.

Technology alone, however, cannot take the place of our social skills – you know – those abilities we’re supposed to develop that help us get along with others. In this post, I’m going to focus on video conferencing technology, or rather, on how we use it. I’ll focus on some simple things you, as a remote worker, can do to improve how your audience views you. This can be critical, since your audience is often comprised of your coworkers, managers, or most importantly, your customers.

In my work group, software developers regularly communicate with customers using video conferencing software. We all know how to use the technology, but after just a few months of meeting with developers and customers on these conference calls, it’s clear that there are individual differences in how we use the technology. I felt that someone needed to broach the topic of being aware of your on-camera self. Yes, self-awareness is a thing, Google it.

If you’re the consultant, or a remote worker trying to impress a manager skeptical of the benefits of remote work arrangements, you need to know how extremely easy it is to set the wrong expectation or make a bad impression. Below are some things to think about – preferably before you get on one of those really long video conference calls.

Continue reading “Image Matters for Remote Workers”

Struts 2 Dynamic Method Invocation

java1I’ve been doing plenty of Sruts2 work lately, and have used wildcard method mapping quite a bit. Wildcard method mapping is one way Struts2 allows a developer to flexibly call methods other than execute() on your action classes. Recently, however, I had reason to check out another flexible method calling feature in Struts – Dynamic Method Invocation.

The struts documentation says this about Dynamic Method Invocation:

Dynamic Method Invocation (DMI) will use the string following a “!” character in an action name as the name of a method to invoke (instead of execute). A reference to “Category!create.action”, says to use the “Category” action mapping, but call the create method instead.

So basically, instead of changing your struts.xml file to support flexible method calling on your actions, you could simply target specific action methods my using the actionname!methodname.action format supported by DMI.

Of course, there are potential security risks with this, and Struts 2.3 adds the ability to restrict the methods that you can use DMI upon. Also, the Apache docs state clearly that wildcard method mapping is preferred over DMI.

If you have a Struts2 application that faces the internet, please consider disabling DMI, or at least providing a set of allowable DMI methods. Be aware that you have to explicitly disable by setting a constant in your struts.xml (or struts.properties) file. Since DMI enabled by default, your application could be at risk if you don’t manage how users access your action methods.  

For example, adding this line to your struts.xml will completely disable DMI:

Given that our usage involved an internal application, we found that DMI helped us solve a problem quickly and cleanly, and its use in our application outweighed the potential for abuse.