Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 25, 2014
arrowPress Releases
October 25, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Bright, Slow, and Deadly
by Robert Dieterich on 09/13/12 09:21:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


This is a cross-post from my blog: Game Dev Without a Cause.

The classic SHMUP (shoot-em-up) may be one of the purest video game designs out there. Even for games like Ikaruga that implement systems that dramatically change the gameplay, the core mechanic stays essentially the same: the player must destroy enemies while dodging loads and loads of bullets.

Given the significance of the relationship between the player and enemy bullets, the design of said bullets is crucial to making a SHMUP work. The following is a series of guidelines that I use when implementing enemy projectiles in games.

Enemy projectiles should be... Bright
Because a SHMUP requires a player to be keenly aware of where enemy bullets are located, they must stand-out from the rest of the graphics in the game. As a result, such projectiles are usually brightly colored. Some games go so far as to make them flash different colors in order to make them more easily noticeable. Enemy projectiles are one of the few cases where it may be advisable to ignore the color palette of the rest of the game and purposefully render them with conflicting colors.

In terms of draw order, enemy projectiles should also occupy a rank commiserate with their importance to the player. What this works out to is that enemy projectiles should generally be rendered on top of most other objects in the game. The last thing you would want is to have bullets hiding behind power-ups leading to unfair player deaths.

Enemy projectiles should be... Slow
At first glance, it might make sense to have player and enemy projectiles travel at the same speed. While that symmetry may seem attractive, it ignores the differing purposes served by player projectiles and enemy projectiles. Mainly, player projectiles are meant to hit enemies while enemy projectiles are meant to be dodged. Player projectiles need to be fast so that they hit enemies effectively and enemy projectiles need to be slow so that the player can avoid them.

I learned this lesson the first time I tried making a SHMUP. I started out with both player and enemy projectiles having similar speeds. As a result, enemy projectiles were so fast that I rarely had a chance to avoid them once they fired. The only way to avoid damage was to destroy enemies before they fired. One day, I tried halving the speed of enemy projectiles. The game immediately changed. Instead of try to destroy enemies just as they came on the screen, I was weaving around fields of projectiles to get good shots on enemies. And it was a whole lot more fun that way.

Enemy projectiles should be... Deadly
This may seem like a no-brainer, but I can't understate how important it is for collisions between players and enemy bullets to be a significant event. In games with one-hit death, this condition is cleared because the loss of a life provides a clear enough sense of consequence.

Games where the player can take multiple hits need to provide a lot of feedback to make collision with enemy projectiles a suitably jarring experience. U.N. Squadron does a great job of this by having alarms go off when the player is hit as well as putting the player in a temporarily vulnerable state where one more hit will instantly finish them off. Sine Mora also does this well by having the player's accumulated power-ups fly out thereby forcing the player to drop what they were doing and concentrate on recollecting power-ups. Enemy bullets are key to making a SHMUP fun. If you ever find yourself building one, remember: enemy projectiles should be Bright, Slow, and Deadly.

Related Jobs

Digital Extremes
Digital Extremes — LONDON, Ontario, Canada

University of Central Florida, School of Visual Arts and Design
University of Central Florida, School of Visual Arts and Design — Orlando, Florida, United States

Assistant Professor in Digital Media (Game Design)
The College of New Jersey
The College of New Jersey — Ewing, New Jersey, United States

Assistant Professor - Interactive Multi Media - Tenure Track
Bohemia Interactive Simulations
Bohemia Interactive Simulations — Prague, Czech Republic

Game Designer


Christopher Gile
profile image
Good points. Feedback is a huge issue for a lot of game genres, I can't tell you how many times I thought I was doing well in a game only to look at my health and wonder "When did I get hit?". When significant things happen it should be significant.

Raymond Ortgiesen
profile image
I've been working on a shooter in Flash on and off, and while my bullets were clear in the environment and the feedback was responsive I felt like I wasn't getting the right feel out of the overall gameplay. I went in and slashed the speed on enemy bullets, pick ups, mines, etc. in half and it took the game one big step towards nailing the feel of the game play.

Good advice!

Robert Dieterich
profile image
I'm glad you find the advice helpful.

I was a little worried that these tips would seem too obvious. But, looking back, I realize that each tip stemmed from a time when I had implemented something and it just didn't work. It's funny how easy it is to forget the "obvious" stuff when you're eyebrows deep in implementation.