1. icon for News
  2. icon for TCHOW


Monday, November 17, 2014

Soon, You Will Fly: a Leap Motion 3D Jam game

Thanks to a soft deadline this morning, I've posted an alpha build (for Windows and OSX) of a weird little game I've been working on for the Leap Motion 3D Jam presented by IndieCade. It's called "Soon, You Will Fly", and -- perhaps unexpectedly -- it's about crawling.

I'm still working on a few things. Among them: tentacles, a heart/eye, the touch of darkness, and more sound design. Oh, and a way to quit without resorting to ALT-F4.

Anyway, please do check it out and let me know what you think. At present, I'm thinking that this probably doesn't extend beyond a simple jam game; but feedback can change that.

Thursday, September 4, 2014

Fragments: a Ludum Dare Jam Game

A few weeks ago, I worked with my friend Aaron Vonderhaar on a bold experiment: to develop a single-page html game framework and then build a game in it for Ludum Dare.

The result is Fragments [Ludum Dare Page] [Source Code]. It's a put-together puzzle in isometric 3d, telling a somewhat fragmented story of mangled memories.

I'm not entirely happy with how the game came out, but as my first Ludum Dare Jam (as opposed to compo) experience, it was a decent one. It was fun working with Aaron on a project, and I think we did some interesting things in the game framework -- though it wasn't nearly complete enough going into the competition.

Two interesting points of trivia about Fragments:

  • There is no lighting in the game. Everything is baked to vertex colors in Blender during export. This is a trick I also used in Rainbow for the landscape.
  • For some reason, 30% of the CPU time in the game is used by 4x4 matrix multiplies. We probably should have been looking at profiling data earlier. It appears that the construction of Mat4's is very expensive.

Thursday, February 6, 2014

Seven Skills of Highly Effective Rainbow Players

It has been a long time in coming, but I finally created a promotional video for Rainbow. Promotional and educational, I should say.

Take a gander:

Tuesday, January 14, 2014

Iterating on Promo Art for Rainbow

Rainbow for iOS (and for Android!) will be out tomorrow, and as part of the assets for the Google Play store, I needed to design a large (1024x500) promotional image for the game.

As you can see above, I arrived at an pretty good image. I think it captures the essence of Rainbow's art style and gameplay, while striking a balance between cleanliness and boredom.

Arriving at this image required a few iterations. My first mockups had a hand-drawn rainbow that just didn't seem lively enough:

I tried patching in some spirals, but they still didn't look right to me. Perhaps this is because I'm over-familiar with the way cubic splines look (and/or the way rainbows actually move in the game):

So I ended up hacking in a special game mode that uses a white background and hides the level while taking screenshots; and repeatedly played through a simple (splitter-only) level to come up with some rainbow patterns. This turns out to be somewhat difficult.

This was good as a first cut, but too busy. After trimming a few of the characters from the bottom of the image, and playing through my empty level several more times, I arrived at the final version:

I also needed a smaller version of the image with a slightly different aspect ratio (180x120). For this I re-arranged the TCHOW logo to above the word "Rainbow" and strengthened the halo to make the letters more readable:

The final promo and small promo images -- along with high-res versions of other game assets -- can be obtained from the Rainbow Press Kit.

Friday, January 10, 2014

Rainbow for iOS out on January 15th

It's been a while, but Rainbow is finally ready to go on sale in the iOS App store. The game will be out on the 15th of this month, and will sell for $2.

More information about Rainbow can be found on the game's web page and press kit.

Wednesday, November 13, 2013

Math: What is the right Aspect Ratio?

In the shower the other day, I thought up an interesting question: what is the right aspect ratio to work in? (With, of course, the immediate follow-up question: what does "right" mean in this context?) In this post, I'll attempt to answer both questions with some simple math.


I've been doing some pre-production work on a storybook game for iOS devices. The game will likely be composed of full-screen scenes with hand-drawn background plates. I don't want to have require new background plates for every resolution (much less aspect ratio), so the plan is to create one background and fit it to the screen.

So, depending on the screen aspect ratio (in this case: 4:3 on the left, 16:9 on the right), some of the image will be cropped, either off the sides or off the top and bottom.

Minimizing Waste

Since I'm not of a mind to have something drawn that isn't needed, one possible definition of "right" aspect ratio is the one that minimizes wasted area in the background image. So how much area is wasted?

Well, denoting the aspect ratio of the screen s and the aspect ratio of the background image b, and -- without loss of generality -- assuming the screen height is 1, it is easy to draw a picture of the situation:

So, if the background is wider than the screen, the percentage of the background image wasted is (b-s) / b. Similarly, when the background is narrower, the waste is (1/b-s) / (1/b).

As expected, on a 4:3 screen a background image of aspect ratio 4:3 wastes the least.

Of course, on iOS one needs to worry about three aspect ratios: 4:3 [iPad], 3:2 [iPhone <= 4], and 71:40 [iPhone >= 5]. (In case you are wondering, 71:40 is 'nearly 16:9'.):

NOTE: I'm only considering landscape aspect ratios because that's the target for this game.

Assuming one wants to give equal weight to background waste on each device, the proper aspect ratio of the background image should minimize the sum of these three curves.

This minimization happens at the 3:2 aspect ratio. Indeed, my intuition is that with equally-weighted devices the minimum-waste aspect ratio will always be the median aspect ratio.

Maximizing Excitement

In the previous section, I counted areas of the background for each time they were cropped -- that is, background that didn't show at 4:3 and at 3:2 was counted as being twice as bad as background that was only cropped at 3:2. Perhaps, instead of obsessing over these lost pixels, one should instead maximize the percentage of the background that is cropped by no device (i.e. the part of the background every screen sees).

What is this percentage? Consider a background of size bx1 to be shown on screens of aspect s1, ..., sN. The width of the visible-on-all-screens region is w = min(b, s1, ..., sN), because the background will be cropped after its aspect exceeds the smallest screen aspect. The height of the visible region is h = min(1, b / s1, ..., b / sN), because of cropping on the top and bottom of edge of the background when it is scaled to the widest aspect ratio. (More intuition: consider scaling the visible region to [horizontally] fit a screen of size sx1. The scale factor is s / b, so it must be the case that h * s / b <= 1; thus h <= b / s.)

Putting these figures together gives percentage 100 * min(b, s1, ..., sN) * min(1, b / s1, ..., b / sN) / (b * 1). Interestingly, this means that maximizing visible area only depends on the narrowest and widest aspect ratio under consideration:

The unfortunate news is that with aspect ratios of 4:3 and 71:40 in the mix there isn't any background size that doesn't end up with about 25% of its area not visible on all screens. The fortunate news is that the best aspect ratio in terms of waste (3:2) is within this 75%-used plateau.

Going Further

In this article I didn't talk at all about foreground content (which must be scaled to fit within each aspect ratio), and only explored two objective functions. Other interesting objective functions might include one weighted for all browser sizes, or one that is concerned with fairness (forcing all screens to lose about the same area of the background).

If you have other ideas, feel free to leave a comment or send an e-mail.

Wednesday, November 6, 2013

Rainbow Update: More Music

I am pleased to report that the iOS version of Rainbow is proceeding well. In fact, a 1.0 version has already been accepted for app store sale (though -- owning to some gameplay changes -- I will probably not release it).

So, what have I been working on? Well, other than finding a real job, tweaking and adjusting Rainbow to be an even better game. Part of that is doing things like adding incidental music to cutscenes -- and that's what this post is about.

The Music

The most recent two tracks I added to Rainbow were an opening and closing theme for the villain (and player's persona), who I will simply call "D.D." herein.

The opening theme is meant to be sinister but energetic, as befits a villain whose goal is to bring color and happiness into the lives of a drab people:

The closing theme is meant to be similar to the opening theme but more mellow, because D.D. is now tired from the effort of playing through the game:

One of the things that I think works really well in both of these tracks is the drums. The main drums are from Reason's factory sound library, but are bit-crushed via a Scream4's "digital" method:

I also automate the 'Rate' parameter of the Scream4 in one of the tracks to get some interesting variation into the drums. It's certainly a rough sound, but it's one that I quite enjoyed using in an earlier track.

The parallel channel through the reverb and compressor is generally mixed very low, but it does provide some interesting texture. (The LFO is being used to sweep the resolution on the Scream4 in this channel, which adds more rhythm to the texture.)

In addition to the main drums, I use a lone synth kick, without any fancy effects, in parts of the track. This kick is used as an sidechain input on the lower pad, in order to make the pad duck the kick (and thus make the kick seem to hit harder):

I doubt Rainbow will be winning any awards for cutscene music design, but these snippets certainly seem better than letting the menu theme continue to play.