anyway.

Here.

I'm not sure that's what I was saying?

Oh no, it's what I'm saying.

Isn't this true for, oh, any non-trivial system design?

This seems really non-provocative to me.

- Alex

Most fundamental truths are!

So, in literature studies and textual criticism, there's this thing called the hermeneutic circle. To understand a text, you need to understand how the parts of it, the basic terms and claims, fit together to make up a whole. But to understand any of the parts, you need to understand how they relate to each other as mutually conditioning context. In other words, to know the whole you must know the parts, and to know the parts you must know the whole. This paradox is what makes basic acts of reading and communicating so rich and so challenging. It's a fruitful tension that requires us to find interpretive equilibria, most-plausible-so-far kinds of understanding which adapt as our familiarity with a text deepens.

The hermeneutic circle exists for the author of a text, too, since the author is the text's first and original reader. The whole of what you want to say is what you get when you put all the sentences in order, but the sentences you write are the ones that work together to bring about that whole. To write a sentence you need to know the whole story or the whole argument, but to know the whole story you must already have an idea of how it's told in the sentences.

The situation with game design, I think you're saying, is similar. The designer has to develop moves that reflect the idea of the whole game. But you can't have a clear enough idea of what moves do or don't reflect that idea unless you already have insight into how the game will be structured, ie. what it's moves should look like.

Yeah? Right track?

You could probably turn it around and get something like the hermeneutic circle we started with. A player can only use a move correctly if it's clear how that move relates to the rest of play. But the player's sense of gameplay is something that has to emerge from correct use of the moves at hand.

I wonder if any particular sort of knowledge or feel is required.  I always have a vision of "what the experience of playing should be like" in mind, but that hasn't helped me answer "so how do I produce that?"

In practice for me usually what happens is that a game starts with just one insight, like "Oh, if players were trying to do this, you could make a subsystem where they'd have to say things like this!"

Then the rest of the game kind of flows from there.

Well, to design any part of a game and know with any certainty you're doing it "right", it surely helps to know, or at least feel, the whole game.  It may even be that the better you understand the whole, or the more deeply you feel it, the easier it is to design the part.  Possibly still soul-wrenchingly difficult to get right, but at least easier to know if the part is working or not.

But it's also true that you'll only come to understand the whole through working with its parts, so - how does having arrived at this particular destination change how we go about designing a game?  I mean, we were probably already paying attention to both the parts and the whole as best we could ...

?to design any part of a game, you have to know, or at least feel, the entire game.?

It's possible to design a thing if you know something about other things that will interact with it.  What you know influences how well the thing you design later fulfils your intentions for that thing.

If the thing is part of a larger system, the way the thing is made influences how the larger system behaves. 

Hopefully your design influences the way the thing is made. 

Knowledge of the larger system is needed. 

Maybe you could start at the boundaries of the larger system and work inwards, designing subsystems as you go?  That way you would always be working from known constraints. 

@Simon C - so you're working outwards from a randomly generated (but carefully selected) starting point?

Well, once you've got one subsystem in place, usually you can kind of sense the shape of the whole game from that.

Like, right now the the thing I'm working on started with one character, and then to make the things that character's player could say make sense, I had to write the rest of the game.

I said something mild about this in the other thread, but seen as we're going zen:

And there lies the difference between design and creation. Creating a game only requires linear causality.

I dunno about zen. If you've just come up with an axe head, it doesn't take much esoteric meditation to realise you need a haft.

I wasn't talking about you being zen as much as Vincent and zen's not even the right word!

(Also, I'm not trying to correct you or anything, just jumping off what you've said.)

It's more that this concept of design assumes profound overlapping coherence to the point to which designing the axe handle means you'll have to go back some point to tweak the head, in order to make sure that both head and handle are being as good as they can be, and also supporting each other.

Resolving this idea in general is like trying to solve the halting problem in distributed computing; how do you make sure that the process of design actually comes to a stop?

Practically, one way we solve this is by iteration, going backwards and forwards making tweaks, trying to make less and less dramatic changes, another is by finding things to fit into place, another way is by juggling things in your head until it somehow coalesces into something, which feels a bit like magic.

Expanding on that a bit, I find even when you're working "side to side", from one little bit of a game out to others, there'll still come points where you are designing from the outside in, where you now know you need a specific thing, maybe the last puzzle piece of your game, and now you have to start creating something specifically to fit.

Up until that point you can go a long way by saying "what does this imply", and creating something that fits it according to those aspects, but there comes a point where you find that you have a lot of leftover or overlapping constraints, a lot of loose ends, and you're now wanting to do a lot with this last piece.

At that point you can go back and make your job easier by getting some of the other mechanics to take part of that role, or you can look around for mechanics in other places that fit, or you can sort of dream about it, try little fragments and put it together.

I suppose another way to say this is, you can go a long way without "intuiting the whole", but it's actually enormously satisfying to do so. Is it possible to do so waterfall style before you've even settled anything? Probably, although it's equally possible to do so by starting with a few idea fragments and asking "what is this game about?" "what kind of feel does this give me?" "who can I imagine playing this?" "what things do I imagine happening?" etc. or other more schematic and less verbal questions, and sometimes not going for explicit answers to those questions immediately, just enough to get you forming some kind of picture in your head of what it will look like, where you're going.

@Simon C

So I guess its a more intuitive process for you, than the way I described it?

@Josh W

I don't know anything about the halting problem.  Most everything else you said fitted with my experience, though. 

Wasn't quite sure what 'overlapping constraints' meant.  Can you explain further?

Oh, you probably know what I'm calling overlapping constraints by another name, it's just about how you can specify something more than once, so it has to be like this and also like that at the same time. They'll often come from different bits of your design:

"I need this mechanic to encourage low level jovial backstabbing between players, not require or encourage long term planning, act as a kind of freebee resource that will be wasted if people don't use it, but also encourage imagination of the background social environment. It's also got to be cute or physical enough that people don't forget about it, and tied lightly into some existing day to day mechanic."

The constraints just sort of stack up on each other, and you have to find ways to accommodate them all.