Battlezone Forums

I've always wondered, how are video games conceived, and how are they developed? What's the first thing that the developers start coding, usually? Ever since I've gotten into DarkBASIC Pro, I've always thought it went something like this:

MY THEORY of Game Development:

1) Inception: The game is planned out, given a storyline, characters, worlds, and settings.
2) Actualization: The rudimentary parts of the game are developed, including AI, environments, and designing and animating the characters.
3) Expansion: More details are added to the game, including cutscenes, usable pick-ups, environmental details, and loading screens.
4) Playtesting: The game is given a "dry run" to ensure playability, and bugs and other undesirables are reported.
5) Optimization: Bugs, glitches, and plot holes are all corrected.
6) Publishing: The game is packaged into an installer.
7) Marketing: The game is placed into shiny boxes and shipped.

Am I almost accurate?

Game development usually follows either a waterfall or rapid development plan, as far as I'm aware.

The waterfall model flows like this:
Requirements analysis and specification (what are we making, what does it have to do, what do we need)
Design (How are we going to do it)
Implementation (Making it)
Testing (Make sure it works, re-implement if it doesn't)
Maintenance (Patches)

Rapid cycles have design, implementation and testing running cyclically through prototypes until a build is reached that's ready for release. It's faster and more efficient, but doesn't work as well on larger projects like games. If I had to guess, I'd say Ken and Nathan are doing 1.5 and 1.3 through rapid development, whereas the games themselves most likely used a slower model like waterfall there.

Ahh the waterfail method...

The steps are more like this:

Concept - Broad idea of what sort of game you want
Prototype - Quickly whip up a working prototype showing off the basic gameplay elements. This usually happens quite a few times to find what's fun and what isn't. This will help immensely in pitching the game to a publisher.
Development - Fill out the game, add content, start developing a story if needed. Basic artwork at this point.
Polish - Final artwork comes in, sounds are added, any performance issues that haven't been fixed yet get worked out.
Release - Chuck the game out there, get it noticed, etc.
Maintenance - Patch major issues that come up which haven't been caught in testing. 1000 people will break your game much faster than having 30 people playtest it, no matter how much you've done it.

Testing should be done pretty much throughout the project to squash bugs when they appear so nothing ends up relying on them to break when you fix it at a later date.

Bugs need to be addressed BEFORE the game is released. Battlezone 2 and Mercs. 2 could both have lived if they were better tested.

forgottengames wrote:Bugs need to be addressed BEFORE the game is released. Battlezone 2 and Mercs. 2 could both have lived if they were better tested.

They would have been better tested had Activision not wanted the games released "last week, goddamnit".

forgottengames wrote:Bugs need to be addressed BEFORE the game is released. Battlezone 2 and Mercs. 2 could both have lived if they were better tested.

Its the company paying for development that dictates when you are far enough to deliver, not the producer/developer, and definitly not the final customer.

Yes... But what is the first thing that people code, usually?

Depends on where you start.

forgottengames wrote:Yes... But what is the first thing that people code, usually?

The Beginning?

AHadley wrote:Depends on where you start.

Let's say from scratch.

The best method is to first, design the game correctly, that being, start with your core mechanic and go from there. Write up a good requirements document, you can use that to figure out your testing requirements and figure out all your technological risks and functional vs non-functional requirements. To cover the tech risks, start with prototypes of only those areas to ascertain you can in fact do what you want to, how you want to. It might be a good idea to mix some market research in here early to figure out if people would like these mechanics but you really have until the first testing phase until you really get into that. Of course, you don't want to make a game everyone will hate no matter what you change.

forgottengames wrote:Yes... But what is the first thing that people code, usually?

I've made a couple small games so far. Assuming all the back end code is done, the first thing is to get the camera and player control up and running in some shape or form. I'm not sure what your point in asking this was, so I'll leave it at that.

I feel like I just read a text version of this. . .

To simplify, make sure you can even do what you want to do with prototypes.

And for god sakes, do it on the side, its not worth the stress of a mainstream career in it.