Developer Diary #17 — Gifs Ahoy

Work on Treasure Chasm has finally begun. Boy has it been fast. I’ve never had a project take off so quickly. The last few weeks have been very interrupted by travel and grad school finals, so the rapid reentry has been very refreshing. I was pleasantly surprised to find that my pre-drawn artwork served as a to-do list once development began. With so much time to consider how the game should go, I found the gameplay was solidified and focused before I even began to program. There really is very little complexity, and I want to keep it that way. Projects tend to spiral out of control with too many ideas. So far, I have been avoiding that by sticking to a simple core. We’ll see how that plays out in the end game.

I’ve included some gifs to show off some of the game. The main idea is simple: dive below the surface to collect treasure, but don’t run out of fuel. Players can refuel at the surface as well as upgrade their submarine. As the players upgrade their vehicle they will be able to go further and further below the surface, where greater rewards are found. Along the way they run into many different kinds of obstacles. The goal of the game is to reach the bottom of the ocean to collect the greatest treasure. What players doesn’t know is that a secret buzzes in the deep. I am currently wrestling with the ending, giving it a satisfying bigness without bloating the project unnecessarily.






I can’t properly describe how much fun I’m having with this. Here’s to hoping it’s just as fun for everyone else. More to come soon!



Developer Diary #13 — “Done” and “Released”

About a week ago I started saying that I am done with Precarious Potions. It’s a great feeling, being “done.” It’s really too bad that “done” and “released” are not the same thing. Now that I am no longer adding content, I am rounding up edge cases, squishing bugs, and arguing with nonsensical web standards. In some ways I want the release to be as perfect as possible, and in other ways I know that I can never make it 100% functional for every browser on every device in all weather and astrological conditions. The consensus at the moment is that HTML5 is still flaky, at best. I’m starting to learn tolerance for odd bugs that don’t actually break the game. It’s the ones that do that are currently driving my up the walls.

One important thing I do in the time between “done” and “released” is lots of random testing. I usually stick my iPad under someone’s nose and ask them to check out a game I made. If they look interested (which they usually do) I ask them for critique—mean critique. I want them to rip it apart. This serves two purposes: The first is to take their socially acceptable nothing-but-vague-praise response and push it into a more realistic realm. The second is to help find the things that solicit 1-star reviews before they have the potential to scar my game’s reputation. You can hear it before or after, but I find it much easier to manage before. If the tester truly likes your game, they won’t be able to help including praise along with the critique. Either way, it’s a win-win.

I can’t wait to kick this game out the door. I’ve got a lot of great plans for it—which I will be writing about quite soon. I really believe in where this game has gone. With the right exposure it will do well in the wild. Once it releases I will share more details about the transformation it went through in the past year-and-a-half, as well as overall success or failure in the marketplace.


Until next time, here is a preview image of the intro sequence. All elements were hand-drawn on a very large sheet of paper and then captured via my iPad camera. I vectored over them, but the hand-drawn nature remains. I am psyched to use the process again—it made such a difference.


Anyone Can Make Beautiful Games: Tweening

I’ve said it before, and I’ll say it again. Anyone can make beautiful games. Last time I wrote about this I made a list of things you can use to make your games beautiful, but this time I’ll go into bit more detail about just one concept so we can drill down a bit further.

For those who are not yet aware, tweening is an animator’s term for the process of drawing frames between two distinct and separate images. In traditional animation, the lead animators usually create the rough outline for a scene and pass on their work to a team of animators who fill in the gaps. Good animation has excellent use of tweening. You should not be able to tell where each key frame is.

Game developers also benefit from tweening. If you would like to read more about why we tween, you can look at some of my previous posts. For this post, however, I will be talking more specifically about how to tween. Let’s start with an example.

Below we have a fairly typical title screen. It’s got a title, a play button, and a help button. It looks ok, but really isn’t all that eye-catching. Clicking the play button moves to the first room of the game, but in a jarring, static sort of way. Though it isn’t the best, most indie games look like this. In fact, nearly all HTML5 games work this way.


Here’s how to stand out: tween everything. In the example below, I have taken all four menu elements and added a tween to them. The title image uses a tween called Ease Out Elastic. I have applied it to the width and height of the image. Both the play and the help buttons also use the Ease Out Elastic function, but what is affected instead is the y position. The black bars on the side use a simple tween which subtracts 10% of the distance per loop cycle. The function is very easy: x = x + (targetx – x)/10. You can play around with the number on the end to change the speed of the transition. Lastly, when the player presses the play button, rather then immediately jumping to the next room/layout/canvas, using some sort of transition can make everything look better. I generally use a fade, though there are many other options.


One last note on tweens. Because tweening inherently delays the game (however briefly), it can leave “beautiful” and enter “frustrating” if it is too slow. Human reaction time is about 0.3 seconds after the initial stimulus. In that time, our eyes can see almost 20 separate frames (assuming 60 frames per second). This means that game designers have about 20 frames to flash a transition without worrying about holding the player up. Sometimes even two or three frames are enough to satisfy the player. This is very important for tweening elements that might hang up the game (between-room fades, buttons, etc.). For this reason I never let a fade between rooms last longer than 0.2 seconds.


Below I have included some resources for javascript, GameMaker: Studio, and Construct 2 users. You can write your own functions, but in the end it’s the same math. I have found them extremely helpful.

GameMaker: Studio:
Construct 2:

Happy Tweening!