Game over, man, game over

 I was recently replaying SOTN, one of my favorite games of all time. As I died the umpteenth time to a particularly mean boss in the inverted castle, I realized something.

Game over screens suck!

Game over screens were a staple of games even as early as the 1950s, with pinball machines lighting up the phrase with lightbulbs.

 Naturally, they became a staple of the arcade scene as well, often followed by a CONTINUE? screen with a countdown, challenging arcade-goers to empty their pockets of sweaty quarters.

 So in reflection, I guess game over screens have always sucked for people experiencing them. But when did they begin to become obsolete?


In an arcade, getting a game over literally meant your game was over. There were no save points and you had a finite amount of lives.

 When the home consoles came out, many of the games available were formatted the same way. They were essentially arcade games for home.

You just didn't have to pony up the cash to continue. Heck, in most early console games, you didn't even get continues.At best, you might get a terrible password combination to get back to roughly the same place you were when you died.

But even when savepoints and checkpoints were being introduced late in the famicom's life cycle, the game over screens persisted, even though the game was never over! 

I suppose the main point of this rambling early-morning post is that Game Over screens are largely obsolete, and usually irritate a player if he has to sit through the same game over screen, press start, wait a few seconds for the main menu to appear, and THEN reload his save.

If you're designing a menu screen flowchart for a game, allow the player to instantly reload their latest save directly the game over screen. This way, instead of a game over screen, it becomes a permanent Continue screen, without the question mark, and you don't grind a player's nerves.

I've noticed that personally, if I am able to instantly reload my save when I die, I'm not nearly as irritated than having to wait 10~ seconds and go through a few screens before reloading my game.

Just something to think about.

-Alex

BHOLDR Mockup

Quick little update, I was fond of this mockup I just did, so I decided I should post it. Click on it for full, animated size.

The room houses a neurotic Artificial Intelligence named BHOLDR, and his little pet.

This room serves as the shop in the game, the AI sells you the junk his pet scavenges from the Dead City. In typical Metroidvania fashion though, it is possible to beat the game without ever finding him.


Once I get the assets in-game, I'll have to take advantage of some particle effects, maybe add some dripping water and steam; should look pretty nice.

Update-wise, we inch closer and closer to a workable prototype. We've completed a great deal of the movement-based code, which is, for obvious reason, the bread and butter of a platform game. I've even gotten my little idle animations in there too, which is nice.

-Alex

A small look at my level design process in Dead Gear

While a significantly large portion of the design work is done primarily in word documents; I still have to design the actual world prototype. Here's a very small , shrunken cropping of an enormous 1:1 scale game world map that I build in photoshop. (The actual 1:1 image is somewhere around 60000x18000 pixels; it's pretty huge.)

It's an evolution of the original layout I had created using Visio, which is pretty invaluable for layouts and flowcharts.

As you can see, the majority of it is simple gray and black; with only a few colors to discern special platforms, enemy placement, or objects affected by gravity. It's very difficult to not get caught in the trap of making everything beautiful from the get-go, like IceForest1 up there in the corner. But it is essential to get your level flowing and working well as a prototype before adding all of the flair, because, after all, what if the level you designed turned out to be crappy and unfun?

With prototypes like these, I can write in a document about what the room is going to be like, design the room design visually, insert them into the game, use them for playtesting, and then once we're satisfied, I can begin the task of making it pretty. (Although I do like to create a small, pretty mockup of each area before I begin. It helps me feel out the atmosphere of the area, as well as block out the colors I'll need later.)

The purple boxes are rooms that are documented, but yet to be designed visually. I typically try to judge their sizes with the purple box, but on occasion the final design is often larger or smaller than anticipated.

Each 'room' has its own PSD file and Text file; I add relevant gameplay notes everywhere I can. Then I flatten the room and paste it to this large map. The giant map is somewhat unwieldy, but it's important to examine the game world as a whole, and to make sure areas are connected appropriately and logically, game-wise.


-Alex