Support NeoGAF

[deadhorse32]

Finishing a Full Game

Michael Labbe
July 31st, 2004

Games can be big business, but they can also be a hobby. Quite a few people build games on their own time. And why not? Making games can be fun.

Sadly, the majority of hobbyist games never reach a completed state. Some may be playable, but most are not. Even if the author had the best intentions going in, the games never even reach beta status most of the time.

This article takes a look at how to choose an achievable scope and examines the hobbyist game developer's most common pitfalls.
The Steps

Technically speaking, creating a game can be summarized by a three step process.

First, you must adopt or create supporting routines to take care of mundane tasks such as image loading, memory management and joystick initialization.

Second, you build art assets for your game. You need at least placeholders before you proceed.

Finally, you have the sound basis required to develop your game. This is the time to write your gameplay code and build your levels, generally speaking.

The funny thing is, the majority of games never get past the first stage.
....

http://frogtoss.com/index.php?content=finishingafullgame&dir=journal

 

[deadhorse32]

and a nice reply at slashdot from someone who has the great idea but couldn't pull it off

http://developers.slashdot.org/comments.pl?sid=116533&cid=9867679

 

[LakeEarth]

Yeah, most people who make games for fun just get it to a decent state, make one stage, and stop working on it entirely. See all the flash games at Newgrounds that say "stay tuned for part 2" or something and it never comes.

 

[Lathentar]

The majority of hobbyist developers imitate big budget development houses. This is an insane undertaking. Independent movies don't have big explosions and million dollar effects; they focus on strength areas like plot and storyline.

I've fallen into this trap many times. Not such much any more though. I'm usually content if I get something playable I'm happy with.

I can't count the times I've walked in the door at 8 in the morning, to find a bleary eyed programmer leaning back in his chair, with a satisfied look on his face. "No component depends directly on any other component." He then fires up his build of the game, and I watch a 60% complete implementation of the feature whiz by.

He tries to tackle a serious question with a really short, direct answer. One-time-Write Programs vs. Write-and-Expand Programs. I'd love to say that its always great to write well design code, but its difficult especially if you really don't have much of a direction. However, writing too many poorly designed/coded projects will eventually make you forgot how to write good code. Its necessary to look at what you're writing and go over your mistakes and how you would do things differently. I'd say start with a simple design, get to a playable point that you are satisfied with then start from scratch with a completely different design using the previous project as only a reference.