Developer Diary #16 — New Game! New Game!


A few days ago I started work on a new game. This is always an exciting time, so I am capitalizing on the creative high by doing as much pre-planning and asset creation as possible before piecing things together in Construct 2. I am usually so eager to see things moving on the screen that I can skip important steps. Then I waste time and focus correcting them later. Right now I am streamlining the gameplay and organizing the flow so that the resulting game is cohesive and simple.

Photo Mar 21, 3 47 33 PM As an artist, one of the best ways for me to plan a game is dive right into asset creation. As I create elements, I think to myself, “what purpose does this serve the gameplay?” and, “what is the simplest way to include this?” That way, as I am creating art, I am solving key problems before being faced with less important but more distracting problems. With this game, I am telling myself that I should be able to play and enjoy myself in my mind before writing any code. It’s tough but so far has been absolutely worth it.

I hope to catalog development on this game better than I have in the past, so more posts/screenshots/gifs should be on their way shortly. Feedback is very appreciated. Drop me a line on Twitter or leave a comment below.


Thanks for reading!


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!


Anyone Can Make Beautiful Games

People Don’t Play Ugly Games

There are a thousand reasons to make beautiful games. The most noble reasons could be about creating meaningful experiences, developing atmosphere, or making the world a more beautiful place—but let’s face it: people don’t play ugly games. If art isn’t your thing, aspirations of beauty are the least of your concerns.

Anyone can make beautiful games.

I’m talking to you, programmers. You can pay an artist as much as you want, but if you do not understand beauty your game will be ugly. Fortunately, there’s no magic talent or personality required to make beautiful games—just skills. Anyone can learn them.

Beautiful Banner

Continue reading

Limits are Valuable

Lately I have been wrestling with a problem. If you are a game designer, you probably wrestle with this problem, too.

I have limits.

This shouldn’t shock too many people. Everybody is limited in some way. But my current limits reside in my developer tools. As a programmer, this can be cause for panic. We want freedom to do whatever comes to mind in our projects. Choosing an environment that limits is often seen as a bad design choice.

I certainly didn’t start here. I learned to make games in an environment that allowed me to create my own architecture from scratch. I had nearly complete freedom. But what did I do with that freedom? I made physics engines that never got used, powerful map generators that mapped nothing playable, and generally wasted my time. Lately I have begun using Construct 2, a third party environment for creating html5 games. Making the transition from writing code to clicking on predesigned behaviors was like putting down my carpentry tools and picking up Duplos. It was humiliating. However, what I discovered over time was that by limiting myself in this area, I began making leaps and bounds in my design decisions. I started making more games in shorter amounts of time than I ever had, and they were better than when I had had more freedom.

Continue reading