next »

[TacoBell_Lord]

As you near closer & closer to a concrete design, how do you save time by cutting unnecessary mechanics that bog down the game? What's your method of choosing the right ones & prototyping? How do you go about basing which mechanic is necessary; by Profit Potential? or by Fun Factor?

[starsrift]

What's your method of choosing the right ones & prototyping?

While I suppose some mechanic ideas can be cut before prototyping, prototype them all. Something you might not even think would be fun, could be, and you won't know until you try it.

[s0]

what i do is basically just weigh the potential costs and benefits against each (not just for mechanics but for p much any feature). basically

1. how hard/time consuming is this feature to implement?
2. how much additional "workload" does it create or remove for the player?
3. how much does it actually add to the game in terms of fun/interest/watever

[rek]

How frequently will it be used? Does it allow for anything that can't be done with existing/simpler/similar mechanics?

[battlerager]

Make it, then make others play it and watch them and hear what they have to say. 

[Graham-]

How many times do you guys "change" a boring/bland feature until you give up on it? How do you know that is time to cut the cable on it? (And give up on it).

[rocketh]

Well, I guess it comes without saying that iterations through various prototype versions helps A LOT. Plenty of ideas work on paper, but will underperform once implemented.

But should you have issues with creating multiple versions ( cost-wise, usually ), I'd suggest writing down an overall decision tree, checking if said feature or mechanic has any major impact on it.

[Moth]

How many times do you guys "change" a boring/bland feature until you give up on it? How do you know that is time to cut the cable on it? (And give up on it).

In the case where you don't want to cut a feature outright but you're still struggling with trying to make it "work": if it's going to kill your productivity trying to perfect it before moving on, and there are areas you could be making rapid progress in elsewhere, then go do that instead. You might get an good idea for the feature you're having trouble with.

[Snail_Man]

I always look and see whether the mechanic is ever used in a variety of ways. If something is only ever used in one capacity, I cut it.

[Preece]

Early in the design of a mechanic, I don't look for it being fun or not fun. Rather, I look for how much potential the mechanic has. If the mechanic seems to naturally imply better versions of itself, then I can follow those and see where it goes. With care it could end up somewhere engaging. A mechanic with low potential just sits there and there is not really anywhere you can go with it.

[Lycaon]

Every time I come up with a game idea, I sit down and write it all out on a piece of paper (or a google doc), with no regards for coherency. Then, I go through it, and try and pick out what I was trying to get at with the idea. What's the reason this idea seems so compelling? That idea, the core of why the game concept seems compelling, is the foundation upon which you must build your mechanics.

Any mechanics that don't serve the core of the game must be cut, no matter how much you like it. Put it in a box for use on a future project.

Then, I try (if possible) to throw together a pen and paper mockup of the game mechanics. This can be anything - sticking together pieces from random board games, drawing things on paper, having people stand around a room, whatever. The point of this is to see if your mechanics make sense to people that aren't you in a way that's cheap and doesn't waste tons of development time making a prototype.

After development begins, I just playtest a lot. That's super important. Playtest with programmer art. Playtest when you just have squares moving around on a screen. Playtest every step of the way so that you know what works and what doesn't.

[SimplyRivet]

I agree with Lycaon.

Personally, I run with the ideology that as game designers, we can never know would be "fun" in our game. We just have spent too much time around it. As a result, I try to have my playtesters tell me which mechanics are good, and which just aren't that interesting.

The problem with this strategy is that playtesters don't know as much about design as you (generally), so you have to know what to listen for. I generally would listen to what they think the problem is (xyz is confusing), but ignore how they want to fix it. Obviously, if you are talking to an experienced game dev, this doesn't apply.

At the end of the day, if the playtesters consistently don't like something, it's time to throw that out the door. As a corollary to this, get a prototype up as quickly as possible. Even if the design isn't perfect, playtesting is going to be the only way that you will learn what works.

[Graham-]

Good ideas.

I like "moving to something you do care about," when something isn't working. Then you return to the original thing if you have new inspiration.

One of the things we hit in business a lot is a boredom wall. Sometimes something doesn't "work" because it isn't completed. Once you force yourself through, you realize it does work. Sometimes you have to trust in how much you originally believed in an idea, more than your current feelings towards it. Telling the difference, between when you should move on, or stick with it, is hard.

[CursedSmilodon]

A simple thought process is what I use

1. Does it play to the core theme of the game?
2. If yes, then does it add to the experience of said theme?
3. Will it be used often?
4. Is it fun when in action?
5. Is there a mechanic similar enough, that they can be merged in some capacity?

[Zanenga]

One of the things we hit in business a lot is a boredom wall. Sometimes something doesn't "work" because it isn't completed. Once you force yourself through, you realize it does work. Sometimes you have to trust in how much you originally believed in an idea, more than your current feelings towards it.

That's great advice! Game development truly does have it's highs and lows and sometimes it's easy to doubt yourself or your original vision.

[Graham-]

Thank you.

[rj]

something i read long ago that tim rogers wrote in an essay he did about gears of war has stuck with me a lot

the basic thing he said was, and i'm paraphrasing, but: if your game mechanic can't comfortably have an endless mode, it's not worth making a game around.

obviously this isn't a hard and fast rule. but if it's purely mechanics-based, and it's a good mechanic, you could make an endless high-scorer out of it, more than likely, in some way.

anyway. it's something to think about.

[Sik]

I was going to say that it probably wouldn't work well with story-centric genres, but if you could have a infinite storyline somehow, the rule could still apply theoretically.

[baconman]

You can endless a story; just change every "conclusion" to some kind of cliffhanger. Like in all of the kids shows where the bad guy "got away again!" Even those tend to be the same story every episode after a very short while, just changing a couple of details; and occasionally hammering home a really good concept that sticks. (Compare Ninja Turtles "Eye of Sarnoth" episodes or guest star ones to the other copypasters; or the Sailor Moon/Weird Sisters showdown vs. Monster-goon-transformed-friend-of-the-day.)

[valrus]

Or with puzzles.  I wouldn't really want infinite Braid -- I want Braid until it runs out of clever puzzles and then it should end.  The time-reversing was still a good mechanic, though.  Portals were still a good mechanic.  It's that puzzle games often don't have the kind of goals that can stretch to infinity -- you could create ever-more-complicated procedural puzzles but more complicated puzzles aren't better puzzles.  For many games there's a natural point at which the player has figured out everything that's going to surprise and delight them, and puzzles beyond that are just traversing a decision tree.

(This doesn't go for "puzzle games" of the Tetris or Bejeweled ilk -- they're games with mechanics similar to puzzles, but they're not themselves "puzzles".  Of course those can have endless modes.)