Symmetry in Games

As a part of the MochiPets project, I have been rapidly prototyping mini-games. This weeks game was Flip Puzzle, a game in which players flip a 3x3 area of tiles on a grid so that it will match the answer key. The core mechanic essentially being that the player needs to find the single (or multiple at higher levels) answer tile to flip that will cause the two grids to match.

I put together a couple different patters for grids spanning from 3x3 to 5x5, using the size of the grid and the number of clicks to determine difficulty. However, during play testing, I discovered something very interesting and unexpected. The symmetry of the puzzle was also a key factor in determining a puzzle's difficulty. Amongst the designed puzzles, there were puzzles with no symmetry, bilateral symmetry, and quadrilateral symmetry. Quadrilateral was least difficult, bilateral harder, and asymmetrical was the most difficult.

Once this realization came to light, it actually made a lot of sense. Our brains are designed to read patterns, and when something breaks that pattern a red flag goes off in our heads. By breaking the grids up into quadrants based on symmetry, we are easily able to distinguish which quadrant is the most problematic.

In the example above, you can clearly see that the bottom left quadrant is the most incorrect in comparison to the answer key. In fact, it is the exact inverse, so we can be reasonably sure that the tile we want to click is one of those four (it's the second column, third row ;) ). Because of this discovery, I divided the puzzles in each grid size into bins by symmetry and added this consideration to the puzzle generation algorithm.

This was a very useful discovery, especially for puzzle games! When making a game that involves patterns of any sort, whether it's pieces of a puzzle or ships flying at you, it's worth considering the symmetry of your design!

RequestAnimationFrame in Processing.js

In the weeks since the Github Game Off, I have been working on making my game, PolyBranch, playable in mobile browsers. A huge part of this has been optimization. PolyBranch was written using slightly non-conventional, although hugely beneficial methods in that the core game was written in Processing (Java) and then exported to JavaScript via Processing.js from the Processing 2.0 IDE. This is the standard way of exporting your Processing sketches to the web, however, in addition to this I followed Pomax's guide to bind my Processing.js code and JavaScript code to each other, thus allowing myself to make calls to Processing with the site's JavaScript. This is how the majority of the event binding in the game was done, including the entire menu and any GUI elements. The big advantage of this is being able to write your GUI in straight HTML5. Being designed for making interfaces (websites), it is much easier to write your GUI this way than directly in Processing!

Now, back to my original point, what makes this so important is optimization. When developing HTML5 canvas for mobile, it has been widely accepted that JavaScripts requestAnimationFrame() function offers huge advantages over traditional JS timing functions like setInterval() or setTimeout (see Paul Irish's post for more info as well as the polyfill). Unfortunately, because rAF wasn't around when PJS was first written, it uses setInterval() instead. The good people on the PJS team are aware of this and hard at work on a fix, but just isn't there yet. So, because of this, I found a work around! Because I had already bound PJS and JS together so I could do the interface, I also handed control of the looping to JS entirely! This way, I was able to write a rAF loop which calls pjs.draw(), as I will demonstrate below:

First, binding JavaScript and Processing.js together (see Pomax's guide for more details)
I have had better luck with renaming my .pde file to a .pjs file at this point. This is a practice I have copied from examples around the web, although I do not know why it works. If anyone has an explanation, I would love to know! :)

Now that Processing and JavaScript can communicate with each other, we can use rAF to call Processing's draw function!

This is a very bare-bones demonstration of the draw loop. Be sure to check out Kushagra Agarwal's article on time based animations for best results!

As a disclaimer, I should note that I had moved over primarily to JavaScript development at this point in the process and was using this method so I could retain the logic I had written in Processing. I was no longer working within the Processing IDE! If you are using Processing.js as a JavaScript library, you can also check out this discussion from the PJS google group.

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!

MochiPets

I've been interested in virtual pets for a very long time. This interest has inspired my research into the field of artificial intelligence and dynamic evolution, as well as mutations on a graphical level. I don't want to go into too much detail in this post, but what it more or less boils down to is that I have been trying to create what I would consider the perfect virtual pet. That doesn't necessarily mean it will suit everyone's tastes, but I have been drawing from what I consider successful implementations of virtual pets and trying to fill in the gaps where I feel other attempts have missed out.

In the process, I have drawn a lot of inspiration from Tamagotchi, Digimon, and Chao Adventure. I feel that virtual pets should be unique and represent a pet experience that can't be found outside the digital realm. Because of this, I have been sketching many ideas of how they could possibly be designed as recognizable, but unique entities. This is just a sample of a particular series called MochiPets, who's shape was inspired by the Japanese dessert "mochi." I have vectored a few of them in order to get an idea of what they would look like on screen.

In a Jam

My final animation for the UCLA film minor. I've been working on it for a long time and it was tons of fun to do. I conceived the original idea for it in the animation 181B storyboarding class, and then created the animatic for it shortly after (both can be seen below). The final product was created by tracing my storyboard in Adobe Illustrator and then creating the in-betweens both in Illustrator and After Effects. I did the action scene by creating image sequences in Photoshop, which I then brought into After Effects for the final animation.