SVG bounding boxes

I have been doing a lot of research with SVG lately and have found it to be a wonderful subsection of graphics and programming. With it's increase in popularity in the web development community, it has been touted as the solution for the huge range of screen resolutions, as well as being used for other things such as filters and effects. Today I wanted to talk specifically about it's use for creating polygonal bounding boxes.

With HTML, every element has a rectangular bounding box. This is not generally a problem, except when layering more complicated images, of which some are links.

Above is an example from a site I worked on recently, sevenpsychopaths.com. The bounding box that triggers the link is highlighted in blue, and you can see that it extends from the actual imagery itself by quite a bit.

In response to this, I wrote this quick bounding box test using SVG:

To create this, I followed this tutorial to wrap a bitmap image with a path in Illustrator. I then saved that document as an SVG and dropped the SVG into the HTML document.

Adding interactivity is very easy. SVG elements can be styled with CSS just like HTML elements, and can be bound to events (such as onclick) in javascript as well.

I don't tout this as the be all end all solution for bounding boxess in HTML, but I do think it offers an interesting solution for more dynamic interactivity!

Diglett Bop - an HTML5 mobile browser game

I recently made an HTML5 mobile game called "Diglett Bop!" which you can play here! In this post, I will be discussing some of the techniques I used to create this game.


The resolution variable

8-bit, pixel graphics, whatever you choose to call it, this style has a special place in my heart. I tend to default to this style of graphics when given the choice. What is interesting about pixel art is that you always start small and scale up, as opposed to creating HD assets and then scaling down when necessary. If you have ever worked with pixel art, you have probably noticed that you can only ever enlarge your illustrations by a factor of one (100%, 200%, ect) otherwise you get dropped pixels and things start to look broken (as demonstrated below).

I kept this in mind when programming and did all the coordinate math using the dimensions from the original, low resolution sprite sheet. For every coordinate check, I multiplied the dimensions by a "resolution" variable, where resolution was the number that the sprite sheet was multiplied by when enlarged.

The huge advantage to this is that it's no problem to scale the graphics up for different resolutions. In fact, I actually do a screen resolution check at the initialization of the game that loads in the appropriate sprite sheet and sets the resolution variable. This way I don't have to worry about creating an HD version, as the game responds to screen resolution appropriately!

Rounding coordinates

Another important aspect of the resolution variable is rounding coordinates. Even though everything is being rendered as pixel art, each pixel is still actually a 3x3 (or 4x4 on higher resolution screens) square. Without taking this into consideration, the pixel graphics would be layered on top of each other at fractions of the upscaled pixels, which looks and feels wrong

To combat this, I simply made sure to round the coordinates down to the previous "whole pixel" based on the resolution. Here's an example of setting the X value for each Diglett:

And then everything layers naturally:

Touch events

It is actually very easy to handle touch events and have them fall back to mouse events where touch is not available! Especially for this game, where the interaction was simply "on touch" or "on click." To do this, you bind your event listeners to a variable event, which is set at initialization based on whether or not touch is available. Like so!

Coming soon in part 2:
- The game object
- Webapps
- CSS3 vs Canvas (i used both!)

Tic tac toe - with a twist

This year was my first year attending IndieCade and I was fortunate enough to sit in on some wonderful panels! Among them was Jeremy Gibson's game design workshop, which he has graciously posted slides for at his site http://jrgibson.net/. As part of his workshop, we played a simple card game. The basic idea of the game is to place an allowed card from your hand on top of the center pile whenever it's your turn. If you cannot place a card, you draw a card. First to lose all their cards wins.

After getting an idea of how the game feels and plays, we were asked to change one rule of the game and analyze the results. I was actually really surprised to see how dramatically one simple rule change could affect the game's mood. Rules that affected the rotation made players feel a loss of control, while rules that allowed players to benefit from punishing other players made the game more aggressive and fast paced.

This made me wonder what some universally simple games would be like if you added one simple rule. I decided to try this with the classic, and usually quite boring, tic tac toe. In tic tac coe, the board fills up quickly and the game ends whether or not someone has won. To combat this, I added one rule: each player only gets three marks. In other words, when you place your fourth mark, your first mark is removed so that you can only have three on the board at a time.

I built a quick two-player prototype in HTML to test this out. I quickly noticed a few differences: the game is obviously longer as the board does not fill up, there is added strategy in anticipating where the spaces will clear up, and extra challenge in memorizing the order that marks were placed. Players not anticipating the need to focus and memorize the order would become frustrated when they place their connecting mark and another mark in the winning row would disappear.

The game is available to play here. I encourage you to try it out, and please let me know what your reaction was!