Story sometimes helps to get a feeling for the design,setting,direction you want your game world to take. On the other hand, a game is about game mechanism, and forcing some game mechnism in a fix direction to satisfy the story can break the whole game. Therefor there's the possibility, that you adjust a story many times to introduce new or explain modified game mechanism. Even the mission/map design will get you in trouble if you have a fix story you want to follow.

Therefor, only games which core concept is to tell an interesting story, should define the story first in my opinion.

For the most part, I agree with the above: Start with the core of the game. When that's the story, start there; when it's the gameplay, start there.

I'd like to add one more thought, however: Different processes may work for different people. Some people might produce better games by playing with mechanics until they find something interesting, and then add a story later; some might work better when they have a story, or an experience, that they want to create, and around which they craft their mechanics. Others may have other approaches that produce better results for them.

(Beware, though, that your process actually does work for you, and that you're not sticking with a process because you think that it should work for you.)

On the other hand, a game is about game mechanism ...

I'm not sure that I agree with this: in some cases, I feel, the game is about the story, and the mechanics are a means of drawing the player into that story.

Some companies only make one gameplay genre of game, so for them they are by definition starting with that gameplay choice. But story should also be considered at the beginning if the game is intended to be one of the story-heavy kinds, like RPG or adventure. Even in a sandbox game where there isn't much story, the design can benefit a lot from having a clear basic story concept from the beginning.

A lot of people here at game dev aren't working in a company paradigm anyway, but instead are indie devs who are either working with a very small team or have a dingle core designer and outsource a lot of the resources or use premade resource packs. For them, story may be their main motivation, or something they aren't very interested in; people generally work on what they are excited about first.

Well, as all have said, it depends on what your core experience is.

Ideally, game play and story go hand in hand, each supporting each other in a continuous feedback loop.

Sometimes an interesting story will inform a novel mechanic and sometimes a mechanic inspires a story.

What you don't want is one to contradict each other too much, if at all.

In fact, we have an issue right now regarding an upgrade mechanic that I made into a story. A long time ago, we had an idea to use some of a mechanic inspired from another game, the discussion was rather vague, and we wanted to tailor the mechanic to our theme, so I wrote a story, featuring that mechanic, to get it into our theme.

Now, we're finally at the point of coding it in, and it makes more logical sense of just to dispense with the story, and just make the mechanic exactly as it plays out in our inspiration.

Is this a good thing? or a bad thing?

On one hand, we could make it mechanically consistent, yet that would take out the original spin we put on it.

On the other hand, we could keep the mechanic as the story has it written, keeping the theme consistent, but potentially mechanically problematic.

So what's the right answer?

IDK yet.

My point is, a story is meant to inform and engage your player, every mechanic, if done to its full potential could inform narrative and theme, without spelling everything out in a story.

writing story is a continuous process, our jobs as writers are to do our best in fleshing out the world long before anyone else gets to that point in development.

Once the development reaches that point, that is the true test of your team, and how much they respect the writers.

Do they follow your directions as to what was set down, with some or no alterations?

or

do they think writing is completely malleable, and start taking the story in new directions, without your input or even notifying you of their objections before they act?

Sometimes, you'll get those extremes, but more likely you'll get in between somewhere. How do you as the writer respond to that?

Writing is both the most powerful aspect of a game, and the weakest. 1st in, last out.

Your question is more accurately asking what the place of story is in a game, how much power do the writers have over everything else in the game. And by association, whether it's better to have a story before gameplay or have gameplay before story.

Story shouldn't be really thought of as 1st or last in a game, but all over the place, all at once.

The way I personally do it?

write the story 1st, then the gameplay, compare to maintain consistency, rinse and repeat. However, at times, I've looked at the roles needed in the mechanics, and use that to inform what direction the story goes.

What if you write a story about the player flying a helicopter into or out of a war zone, but the gameplay and design mechanics don't go in that direction?

What if you write a story about a stealth assassin, yet there are no silencer wapons in the game?

As a writer, your place is everywhere, yet nowhere, so far ahead, that your behind. So detailed in the descriptions of the scenes, yet the engine nor the artists are able to create it.

A story should both guide yet be transparent. It should both be the backbone of the game, yet also be able to be ignored, It should be so vivid that no one will see, and so clear that if missed, it can adapt.

It should provide the setting, and also provide the details.

It should be so good that 2 concept artists reading it, can provide both an identical image and a disparate version. So immersive that it is everything and nothing at the same time.

So clear that readers can have different images of the characters and settings.

So,

Q: does story come 1st or last in a game?

A: Yes.

I don't think its common practice to create the *entire* story first before writing code. There's plenty of code in all games that has nothing to do with even gameplay mechanics much less specifics of the story -- all the code that makes up the core game engine for example, including middleware like Unity or Unreal Engine. Even considering just the gameplay code (mechanics and rules, game-specific features, etc) you'll have a good idea of what features are starting to look like long before the story is fully formed. Assuming you're commited to bringing the thing to completion, there's no reason not to start coding as soon as you have a reasonably firm understanding of what will be needed.

This question is a bit like asking a musician whether they write the lyrics or compose the music first -- sometimes one, sometimes the other, to a greater or lesser degree, but they are never really 100% independent. The first gives rise to the second, but the second can't help but evolve the first.

Depends/maybe/both.

I don't have a hard rule on these, and frequently alterate between these within same project. It's a bit of a chicken-egg problem :) Story/theme can influence mechanics and if you have nice mechanic you could make a nice story out of it. Both approaches works :)

I found the best one probably is to make a bit of a story (basics, theme) then a bit of mechanics (core) then enchance the story and then add complementary mechanics that are compatible with the story.

If it's your first game I would not start with the story first (since mechanics will be your bottleneck).

Even considering just the gameplay code (mechanics and rules, game-specific features, etc) you'll have a good idea of what features are starting to look like long before the story is fully formed. Assuming you're commited to bringing the thing to completion, there's no reason not to start coding as soon as you have a reasonably firm understanding of what will be needed.

This makes a lot of sense, I think.

I suppose that I interpreted the question to be less a matter of "which do entirely complete first" than of "which do you start on first"--and I feel that this may be a distinction that's worth making, for the sake of clarity at the least.

If it's your first game I would not start with the story first (since mechanics will be your bottleneck).

To some degree I think that this depends on what you mean by one's "first game". The very first projects--the game-development equivalents of "Hello World" and so on--are arguably more about learning the tools more than creating something. Even if one is learning to create text adventures using one of the available toolkits designed for those, the first few projects are likely to focus on figuring out how to use the tools available--how to set up rooms, keys, doors, etc. However, once that point has been passed, the developer might well focus on story first, and figure out the mechanics as they go.