Gaming & Design Theory

Sunday, August 21, 2011

A Lot of people seem to be wondering what happened to Projekt H (Even though i posted it was on hiatus)

Here's an explanation: It's on hiatus.

Long one: It's on hiatus with tech problems.

Allow me to explain, using one of the bosses attacks.

Boss 3 (Level 3 boss) has an attack ("Implosion field") which traps the player in a shape (Square, circle, or triangle, depending on difficulty) before a series of shots come from the sides, after which, the shape turns into a set of bullets and collapses, forcing the player to move before another spawns (The shape is a solid instant-kill until morphed)

However, this pattern causes an amazing amount of lag at higher difficulties, due to the number of bullets and loops required to get the patterns to work, which my current setup isn't supporting well, this caused me to be faced with a choice:

Either A. Nerf the crap out of my later cards, staying around a 200 object total (Not counting player shots) or B. Re-design the engine a bit to allow me to go as high as 300-900 objects at a time (Not counting the player)

So, i chose B, this means there will be a longer delay before i can get the demo out, BUT means the finished product will be much more impressive (And as difficult as initially planned - Stock up on advil and find a good psychiatrist)

Tuesday, September 7, 2010

A Lot of people ask me, "Just what does it take to make a game" or "How long does it take?"

Well, i seek to answer these questions

First: "What does it take?"

This boils down to what you're trying to do, a simple 2d game focusing purely on the gameplay over flash can be made fairly easily and rapidly, though it has drawbacks, this is mainly used to test concepts

A Game combining a bit of polish with solid or unique gameplay can be done fairly fast, with a bit of testing afterward, a good example of this is Audiosurf, it has VERY simple 3d graphics, Simple, easy to learn gameplay and controls, but is very unique and challenging, with a large variety of game modes. Games in this category are the common "Cheap" retail games - focusing on uniqueness and wide popularity to be successful, the low cost also means it's easier for someone to splurge on them, as it's easier to set aside the 5-15$ for one of these massive-replay titles, than the 60$ or so too many modern games cost

In a similar vein, we have the MMO Category, these games are purely multiplayer, rarely with singleplayer options, ranging from free games supported by micro-transactions, the best of these not allowing players to buy power, relying on great gameplay to not need it (League of Legends) or requiring a monthly fee to play, but offering constant content updates to keep players interested (World of Warcraft and Champions Online being prime examples) they can be quickly made (to an extent) because you can release content to them over time, the whole game world can be planned out in advance, the game can release with a portion of it, and you add the rest as you progress the games storyline over the course of it's life (In the case of major MMO's, this can be upwards of 5 years)

And finally, the Pure retail games, these are the 20$+ Titles that typically feature short singleplayer gameplay, backed up by multiplay options to justify their high cost (Halo) - Or, they are games purely singleplayer, but with hundreds of options in play to give them massive replay value (Mass Effect, I'm looking at you). These games have hundreds if not thousands of hours of development, and hundreds upon hundreds of hours of testing before release, usually featuring dev teams of ten or more people

As a solo developer, you have a ton of responsibility, you have to do everything yourself, for some people this works out very well, for others it's endless stress

For me, it's a hobby, which brings me to the next point:

"How long does it take?"

For my current Project, without a dev team to help me currently, it looks like this:

Beta testing follows, with final tweaking and bugfixing during, Before the final release or Retail Availability

Which brings me to "Why haven't you updated, then?"

Because, for the 5-end period i wont be doing pure-text updates

Why? Because typing these out, editing all the images for a post and going from there after uploading everything is a chore, instead, once i find a good desktop capture program i'm going to be recording these into video form for Youtube, i can cram a lot of info into 15 minutes of video and audio

Yes, I'll still be doing these in text form, I'll just also be doing video-form ones and releasing them with each post, this makes it easier to go into detail and really show what i mean, and what i achieve in short bursts of time

Wednesday, September 1, 2010

This day will involve your first delving into Drag&Drop programming in GMaker, to assemble the menus, and fill out some basic game information
First, a Screenshot with everything marked out:

Explanations:

Rooms (#1, in black outline) - This is the area, by right clicking on it, you can make and name empty rooms, based on the rooms required by your game (Menus, Levels, Etc.)

Game information (#2, red outline) - This brings up the "F1 screen" which is an area you can type in to explain things about your game (Default keys, what powerups do, enemy types, etc.)

Global Game Settings (#3, teal outline) - Here is where you choose things like game resolution, fullscreen, fill out overall game info (Game version, etc.) and more, be careful with some of these settings, they can cause problems on some machines (Like forcing Vsync or Refresh rate changes)

The Process Begins

First things first, Create a series of empty rooms in the Rooms folder by right-clicking on it and choosing create room, name them to correspond to the needed rooms for your game, it'll look something like my rooms folder for projekt H when you finish:

You may have noticed i'm "Missing" a room, fear not, i'm saving it's creation for this next part

Making the magic - The game maker way

So, now you have a lot of blank rooms, a bunch of game-sized paint images showing button placement and layout, and a few questionsWell, time for me to answer them, here's how a room generally works:

1. The game loads the room
2. All objects in the room at creation become active
3. Any "Run on object creation" codes run
4. If no other actions, room goes into a "Paused" state

Now, for that missing "rm_player_select"

First, it needs a background, so i'm going to import it into GM8, by right clicking on the "Backgrounds" folder, clicking create background, then hitting "Load background" and navigating to it in my Projekt H Placeholders folder, when i'm done, i get this:

Upon hitting "OK" i've just made bg_playerselect with the placeholder image of img_placeholder_playerselect

Now, to make the room use it, and to make the "Abort" button, i make the room, go to its settings tab, and set the room name to "rm_playerselect" and it's size to 800x600 from the default of 640x480, The room "Caption" is what the game displays at the top bar if it's visible, like how your browser shows it's name at the end of the website title, so all of them should be the same, in my case, just "Projekt: H" without quotes

Now, under the "Backgrounds" tab, there is an option that will say <no background> with a box next to it, click on the box, and select your background, in my case, bg_playerselect, when you're done, the room will look something like this:

The grid just shows you the snap to grid if enabled, for now, mines at 16x16 snap, but more on this later

Part 4 - Sprites, Objects, and a bit of D&D

Now, as you can tell from that screen, eventually the 3 boxes are going to show the 3 different ships, and their weapons + Stats, the abort key will go back to the previous menu (Game type selection)

Now, to do this, we need to make a sprite for the abort button, like so:

but you say "It doesn't say anything!" - Thats because this is a base for all of my large-type buttons

So, under sprites, i right-click -> Create sprite, name it spr_return, and load this image, like so:

Now, rather than hit OK, i hit "Edit sprite" bringing up the game maker sprite editor, i then click on the little pencil at the end of the tray to bring up the graphic editor, and use it's text tool to finish my button, like so:

After which, i click the green checkmark in both windows to accept my edits, and then accept the sprite, and then click OK To save the sprite to my file

At this point, i also save my .gmk file, since i've done a lot of editing

Part 4 - Redux

Now, Sprites are little more than fancily-named images, you have to make them into Objects for you to be able to code anything with them, so now we right-click on the objects folder, select "Create object" and then set it to use my newly-made return button sprite
Now, since it's going to be a basic return key (Like hitting escape) i'm also going to add a clicked event using D&D that makes it so clicking on it will return to the previous room, which in my order, is the gametype select, so it looks like:

In short, the object will ignore everything, but if you click on it with the left mouse button, it will trigger the event, making the game go to the previous room, now, i place it in my room by selecting the object and then left-clicking on my background where i have my "Abort" button lined out:

Note: All my button sprites have transparent edges

Now, another thing to note is that this button is UNIVERSAL, meaning any room i put it in it will work, the event doesn't jump to a specific room, just whatever room you were in before the room you clicked it in

This differs it from my "Return to main menu" button, which SPECIFICALLY jumps the game back to the main menu room

So now, by the end of Day 3, you should have the following done:

1. The game design text document outlining the game
2. The placeholder graphics for the game (Buttons, backgrounds, Player ships, etc)
3. The game partially built with navigable menus and placeholders
4. The game information all filled out

If you have all 4 done, congratulations! you're ready to begin the hard part - Coding it all

That will be covered in a future post though, that's a lot of typing for me to do and images to make, so it could take another couple days before you see it

Tuesday, August 31, 2010

No, just kidding, here, at this point, is where the most of your actual layout work is done

For me, using game maker, the game will have a number of rooms, each room pertaining to a different section of the game, for projekt h, the rooms look like this (Name, Simple name)

rm_menu_main = The main game menu, from here, the player can start a game, Change the game options, or exit the game

rm_menu_options = The options room, here the player can turn the music on or off, the sound effects on or off, or return to the main menu (Since Projekt H is scaled for 800x600 res, changing the window size could cause graphic issues, and is disabled as such)

rm_gametype = Where the player chooses between Arcade or story mode for projekt H, has a main menu button to return

rm_difficulty = where the player chooses the difficulty level of the game

rm_player_select = Where the player chooses the ship (Character) they wish to use

rm_game_ingame = Where the actual game is played, Projekt: H uses a timeline system and global variables to imitate having multiple different levels, in reality, the entire game is played in this room, and the "Room change" is faked by using graphics that cover the screen to show a breakdown of the level, these are then deleted and the "Next level" (timeline) starts

Pressing escape in any room other than the main menu or the main game room causes you to go to the previous screen, in the main menu it has no effect, in the game window, it pauses the game and brings up a pause menu

Once you've figured out how many rooms you need, next, you need to fire up paint again, and design the layouts for your menus, button locations, etc. similar to how we previously designed the layout for the playfield of the game. I Won't lie, this is a lot of work, even before you start coding, Projekt: H alone has over 50 design sheets covering all the game menus and layouts, plus effects that keys have (Such as escape and screenshot keys)

Congratulations, if you're not beating your head off your keyboard by now, you may be cut out for a future in indie game design

Saturday, August 28, 2010

For my first theory post, i thought i'd go over an element of design a lot of people and companies seem to skip: Properly starting a project

First things first, you should ALWAYS create a design document for the game, consisting of several parts, as if you were pitching the idea to a team of people, this gives you a reference, and a place to outline mechanics the game will use

As usual, i'll be using my Projekt: H for this

Part 1: Creating your concept and Picking a genre and theme

Here is a Surprisingly hard one, most of your design basis will be made from this

For instance, the Concept of Projekt: H is a unique bullet-hell type shooter, but with player-specified dynamic elements beyond difficulty, unlike most bullet hell shooters, where the patterns are predetermined entirely based on difficulty and time

For my Genre, i'm going with top-down 2D, but using Celshading and lighting to create a 3D Look. it's a vertically scrolling shooter of the Danmaku type

As a general rule, you should also be thinking about your final graphical look while doing this, but i'll touch more on how to properly do this later

For my theme, i'm going with a space/future theme, Heavily influenced by games i've played like Tyrian and Deimos Rising

Part 2: Mechanics & Preplanning

This part will deal with how your games mechanics work, what the game will feature for them, and simple code as to how basic mechanics work, which makes coding them later easier - you've already designed how they should work

for instance, in my game, there is a touhou-style collection boundary at the top of the screen, as well as an autocollect circle around the player that pulls powerups to you from a small radius, so my example for it looks like:

Autocollect zone (Screen top): This zone is a player-ship height area (Invisible) at the top of the screen, when the players ship touches or enters this zone, all powerups will become homing, and gain a speed boost, causing them to fly towards the players ship faster than normal, and to home perfectly in on it, powerups spawned after the player leaves the area will be unaffected unless they reenter it

Autocollection zone (Player) Around the player ship is a collision zone circle, any powerups that touch this circle are redirected in the same manner as the zone at the top of the screen, all other collisions are ignored

There are similar descriptions for each Ship type and it's weapon, it's countermeasure, and various mechanics in the game (such as the health system, extra lives, weapon power bar, etc.)

Part 3: Designing the Playfield

This is one people tend to overcomplicate a LOT

In this phase of design, people always seem to make the mistake of attempting to make the final graphics for the game as they code it, even in game maker

The easier way to do it, is to make simple graphics using MS Paint or The included sprite editor, or a combination of them, for instance, this is the "Alpha" Appearance of Projekt: H for the ingame room, as one would see in the playtest distribution before i add final graphics

However, as you can see, the darkened areas where things go are sometimes hard to see for the purposes of lining up ingame objects that use them

As such, when first starting, it's best to make a simple background with labels showing where each thing is supposed to go, like this:

As you can see, this shows me right where everything is supposed to be, the maximum size they should take up, as well as the furthest the player and enemies should be able to move, while this may look stupid while you're making the game, you can later remove the text easily, and create the background in photoshop or Paint.net in a new layer ABOVE this, using it as a template, before deleting this layer, leaving just your alpha or final background, and since you've already lined everything up using it, when you replace this with the much more game-looking background, you need to do no resizing - just maybe some recoloring to go with the new, proper look

In closing

At this point, you've come up with your theme, your genre, your games mechanics, Possibly a name for your game, and you've designed the playfield or main play enviroment.

In short, you're ready to start making the game, in my next post, i'll show you what i call the "Day one" phase of making a game, consisting of menu design, and Aesthetic theory

Welcome to my dark, dusty corner of the internet, Don't worry though, we ARE up to code here now!

Joking aside, welcome to my blog, i decided to finally get into this after a couple years, since i'm intrested in seeing what people think of my methods for gaming design

A Bit about me and my madness: Currently, i'm working on a few retail gaming projects using a cheaply-available game design program known as "Game Maker" the unrestricted "Pro" version will run you about 25$ USD, and allows full retail game creation and sales with no restrictions (No splash screens, required logos, etc.) as well has having far more available for you to use

As far as it goes, it's actually pretty powerful, allowing both 2d and 3d game creation, features a very Basic/C++-esque coding language, called "GML" and with enough work and knowledge of it, it can be more powerful, as it's more simple

This first series of posts will take you through the day-by-day creation of a game i'm calling internally "Projekt: H" it's a top-down 2D Shooter of the "Danmaku" or "Bullet hell" Variety, the screenshots i'll post are all using placeholder graphics made completely in Game maker 8 with the sprite editor, and backgrounds made with Apophysis or Paint.net, Retail will have a different name and much better graphics

Down the line, i'll eventually cover using other programs, Such as Multimedia Fusion by clickteam, Coding in things like Unrealscript (For modding games like Killing floor, or using the Unreal Development Kit) and general theory on what makes a Great game

Followers

Blog Archive

About Me

"Zerethon" Is the online alias of myself, i'm a self-employed Game designer and IT Tech, doing contract work for several companies. On this blog, so non-snappily titled, i'll explain principles of game design, and how to do it in numerous freely or cheaply available programs, along with examples from my own works in progress