next »

[Dissident Dan]

What are the phases you go through to take a game from prototype to finished game? Or do you not really have phases and sort of jump back and forth between different things? What do you focus on early, and what are you working on right up until ship?

I've always focused on mechanics and game feel first, with art and sound coming later. This has its pros and cons. I think it's the right way to make a game that's the most fun. However, it hurts you in marketing as you don't have the pretty pictures to show until a much later point in time. In the future, I will probably pretty early on at least have mock-ups of what the game will look like, but I can't see myself breaking away from the mechanics-first approach. Firstly, that's honestly what I care about. Secondly, I think so much of the content (especially level design, but also art and sound) are dependent on what the gameplay is that you would do more throw-away work if you were to start creating content before the core of what makes the game fun is nailed down. This is similar to what I've heard of the approach that Nintendo took with Mario 64, where they had these small "gardens" where they nailed the feeling of controlling Mario and determined proper sizing of environment elements before they started building full levels.

But perhaps "fun" in the traditional sense isn't what you're after. Whether or not that's the case, I'm curious what your thoughts and experiences are.

[Muz]

I run through so many game ideas that I've actually got a process for filtering and sorting them out.

1. Sales pitch
Describe the idea of the game in 1-3 paragraphs. Preferably 1. If it doesn't 'sell' the game by now, it's probably a weak idea.

2. Game philosophy
What makes the game stand out? What values are you not going to compromise on? For example, one of my casual games has "5 minutes a day to hit high score", because I don't want people to quit the game out of time concerns. Another has "macromanaged, not micromanaged" or "emphasis on risk and reward".

Later on, you'll come back to this whenever adding new features. So if a feature would add more grind to a campaign and remove the emphasis on the player taking risks, I'd reject it easily.

3. Core mechanics
This is the most important parts which the game needs to be fun. Something like X-Com would have its core mechanics in base building, r&d, tactical interface... not the ufopedia, world map, or body part damage system.

4. Simplest implementation
This is what I need to build a prototype. It's similar to the core mechanics, but often takes only one or two of them and strips that down. So an X-Com prototype would focus on implementing bare bones tactical world, without line of sight or destructible environment.

Add features only when you realize that features are helpful. Something like art and sound are not even considered -- unless you have something like a horror game which relies on sound or a more artistic game.

5. Sample of what gameplay looks like
This is kind of like my "appendix". Here I rant about what's so cool about the game so that I can recapture the energy when I get back to the idea.

[SimplyRivet]

So, I've asked several several people to weigh in their options with this, but the most memorable was one of my old teachers, Holcomb.

He said that generally when he'll come up with an idea, it'll either be a game mechanic he wants to play with or a story he wants to tell. From there, he'll work it into a full game concept.

Afterwards, you make some sort of prototype. Even if you think you have the best idea in the world, it's worthless until it's tested. It can be on paper, or an electronic version it doesn't terribly matter. All that matters is that you need to make sure the game works on a basic level.

If the game works, then you start development. Set some milestones, and try to have a "Vertical Slice" of your game at each one. A vertical slice is a taste of what the game will be like. It should give a complete sample of what the finished product will be like. This is what some games use as their demo.

These vertical slices serve two purposes. First, this is a good way of showing your progress to the public. More importantly though, it serves as a good motivator. There is no better feeling than actually having something working that resembles the game you want to make.

From there, it's just a push to the end.

So long story short, I would focus on the parts that will keep you motivated, and leave the polish for later.

[oodavid]

All the software clichés I'm afraid.

Minimum Viable Product
Release ASAP to get feedback - no fear!
Iterate, have patience

[Richard Kain]

1. Basic idea
2. Boil down basic idea as much as possible.
3. Create working model of boiled down basic idea.
4. Filler art.
5. Flesh out idea slightly and repeat steps 3 and 4.
6. Repeat steps 3 through 5 until a testable prototype is ready.
7. Test the crap out of that prototype, ideally with other people playing.
8. Polish and redesign based on feedback from testing.
9. Repeat steps 7 and 8 until ready for release.
10. Marketing and promotion. (this step can begin earlier, and technically begins as soon as anything about the game is shown)
11. Release.
12. Repeat steps 8 and 10, with the customers as the test base.

[Interface]

I run through so many game ideas that I've actually got a process for filtering and sorting them out.

1. Sales pitch
2. Game philosophy
3. Core mechanics
4. Simplest implementation
5. Sample of what gameplay looks like

Following this thread. And liking Muz's approach (which I butchered in the quote, thank you very much).

[ActiveUnique]

You need to choose and utilize available game mechanics to get anything done, so that's always coming up first.

When transitioning between mechanics becomes viable, remember that without a seamless transition, there's bound to be negative feedback.

Case Study: Metal Gear - the recent stuff
You begin and get cutscenes, endless cutscenes. The viewing, anticipation, moviegoer feeling becomes mechanic #1.
You might haev listened to 2 hours of bonus tape logs before or after playing the game. This uses the same mechanic #1.
You begin playing after that first cutscene and discover the game's a stealth shooter, which is actually #2 on the list now, because until now, you thought it was a movie.
You get a call on your radio every few minutes, you stop to listen. This causes a repeated transition between #1 and #2, meaning you'll be hard pressed to forget there's another cutscene on its way.

Overall, the Metal Gear games become memorable because of their cutscene transitions. What might Metal Gear - the recent stuff have done differently to make it feel more action packed?


There's clearly a heavy focus on the core game mechanic in any successful franchise. Or in a more sane development environment, the only game mechanic.

[dog199200]

I think I may do things a little backwards from most people. I always start with a story. I always have a general storyline concept in mind before I will move on. Once I have a story line concept in mind, I think about what type of game would work best to match a story I want to work with. Is it a horror story? Ok, maybe a first person style game. It it a cartoony game? Maybe a platformer. Once I have established a general game style, I start documenting the game mechanics that would correspond to that style of game, and the storyline itself. Once I have some of the core mechanics established, I start working on cannon character concepts, and concept work for the first few levels in the game. Once the concept work is assembled, it's time for actually assembling the concepts, and programming in the core mechanics for the first few levels. In most games, the core mechanics just need to me established and then refreshed as needed, so that just leaves programming in any "custom" scripts needed for that section. Once the several sections are finished, it provides a stable structure for demos, cutscene testing, etc. At that point, it all goes back to picking the next few sections, and starting again at the drawing board. I found that breaking development into chunks helps a LOT with debugging because you can fine tune everything before you move on. The last thing you need is a lot of mixed bugs at the end of a project and not knowing where to start.

[Muffinhat]

I play with the engine until I find something interesting, take a few steps towards working on that, then look back to see what I created. From there I'll make small design improvements on it until I feel I'm ready to move on to the next random idea. Basically, I create before I design, as counterintuitive as that sounds.