Wednesday, February 15, 2012

The Setting of Dead Gear, Part 1

When I was thinking about a possible location for a Metroidvania-type game, I had to give it some thought.

Very often, platformer/metroidvania games in general have a few archetypal settings. A lava area, a snowy area, a forest area, a desert area, and so on. Using archetypes like these in a game should never really be considered bad by themselves; after all, they are archetypes for a reason. Players expect and know what the dangers and gimmicks will be in a lava area. (Rising lava, fireballs, deadly heat, fire enemies that are weak to ice, etc) Using the archetypal areas ensure that your game will have a variety of areas that take advantage of familiar gimmicks that do not need to be explained. The Mario games in particular play well with these archetypes, drawing and playing off of player expectations in their designs.

Players enjoy a degree of familiarity, as long as it is not so familiar that it feels canned. The Castlevania games are a good example. In each game of the series, the player traverses through Dracula's castle. In each of the games, there is a significantly different rendition of the same familiar locations (such as Dracula's throne room, and the Clocktower area), but the developers are consistently adding completely new areas in each game as well. A mix of old and new, a blend of familiar and unexpected is ideal.

The Dead City area, in Dead Gear

Icy Forest area, in Dead Gear
I wanted to be sure that in each of the 'zones' that I designed, that they would all have a distinct feel, way of playing, and color scheme to them. As I designed mobs (enemies) for each of the zones, I made a conscious decision to not reuse mobs outside of their native area, to insure that each area feels unique. I decided to make snow a common element for all of the outside areas to remind the player that these are actual linked locations, and you're not going to find a random desert out in the middle of a mountain range. More on this later.

-Kirb

The Joys of Design Docs

When first designing a game (or any large scale project really), what Designers need to do is create a Design Document.

A design document is essentially just that: documentation of every mechanic, every idea, every small tidbit of information that you can think of that is relevant to the game you want to make. Think of it as a movie script that has all of the camera direction and scenery included in the text.

Why do this? For a few key reasons:

-To lay everything out in an organized fashion to make sure your designs work well together.
-To show other people for feedback on ideas.

-To document everything. Nothing is useful if it's only in your own head. Programmers, artists and musicians need direction, and it's much easier to point to an already written set of criteria as a guideline  than to make it up on the spot.


When I first decided to start work on Dead Gear, I quickly wrote up a 40+ page document detailing game synopsis, weapon mechanics, locations, etc. I then went and bugged all of my friends to read it.

In a way, the document was sort of a game pitch more than anything. Of the few willing to read the monstrosity, I was able to take some feedback and further polish the document.

Ideally, one should have a completely finished design document before programming even begins. Of course, in larger scale projects, this may prove unfeasible and extremely time-consuming. What designers should try to do is write a skeleton of a design document; write the beginning, middle and end. Know exactly what your goals for the project are, so you don't fall into the trap of not knowing when to stop adding to the document, and risk bloating the project with tons of cool, but unnecessary features or ideas. A designer needs to set a reasonable limit for the project.

Lots of amateur developers often disregard the design document, and jump straight into developing a game. While you could design that way, it's a pretty sloppy and difficult way to get everyone on the same page. Documentation is key!

-Kirb

Saturday, February 11, 2012


An Introduction to Dead Gear and Daedalus Games

Welcome to my design blog. Well, I'm guessing you'd like to know what Dead Gear even is.

 It is a 2D platformer/shooter homage to the Metroidvania genre, and the golden era of SNES platformers, RPGs, and shooters.

It follows a young, magic-wielding girl who's crashed her airship into a strange place, and becomes determined to find her missing friends and find a way out. In true Metroidvania fashion, it is very exploratory-based, but unlike most in the genre, there is dialogue and an engaging story with multiple endings.








Growing up in the late 80s and 90s, I have fond memories of every platformer game I've ever played, and I want to recreate that feeling in Dead Gear. In an industry increasingly putting emphasis on graphics (and dumbing down for maximum accessibility), over gameplay, complexity, creativity and content; I think indie games are an extremely important factor in gaming's future.

It's my first foray into the dog-eat-dog indie gaming world, with most of my older game work being dedicated to modding. But one day I slapped my head and went 'why am I redesigning games with mods when I could make my own game?'

And so, in January of 2012, I created a small team as Daedalus Games and began work in my spare time. If you'd like to follow me in my journey of game design, then hop aboard, you're free to come along.