Game Design (or related) Articles

Discussion in 'Game Design' started by keithburgun, Mar 20, 2014.

  1. keithburgun

    keithburgun Administrator, Lead Designer Staff Member

    Thought I'd make a thread just for posting articles we find on the internet. I found this one.

    http://gamasutra.com/view/news/213612/What_makes_Gone_Home_a_game.php

    Why do people argue about whether something is a INSERT_WORD_HERE but avoid providing a definition for that word? I see a lot of debates like this... and it's like, OBVIOUSLY the answer is contingent on how you are defining the word "game". The whole reason there's disagreement is because people are defining the word differently.

    So how about this: let's propose nice clear definitions for the words we use, eh? Crazy talk, I know.
     
  2. keithburgun

    keithburgun Administrator, Lead Designer Staff Member

    Another article which was linked to me by some FS people the other day: http://www.sirlin.net/blog/2010/6/2/on-subsystems-and-selves.html

    Picking on it is a little unfair because it's from 2010, but Evizaer seems to think it's super valuable.

    Firstly I think there is some probably unintentional comedy in the "disclaimer":



    The reason this is funny to me is that it's entirely the writer's entire job to make thoughts non-labyrinthine (clear). Anyone can just spit out thoughts into a list of words; that's not really engaging in the craft of writing, though. So it's kinda like "hey, this article isn't TRYING to be good, okay?" kind of preemptive defense.

    The second reason it's funny is that he says "that's how thinking about things works", which suggests a few things. It suggests that... other articles don't involve thinking about things? Also if that is indeed how "thinking about things" works, shouldn't everyone kind of know that and not need to be told?

    Anyway, as far as I can tell the article comes closest to making an actual point somewhere in the middle, where it says something along the lines of, "it's much easier to make repairs and changes if all your systems are not tightly woven together". I agree with that, but also I think it's like the least controversial thing anyone ever said.
     
  3. Erenan

    Erenan Well-Known Member

    The reason that article was funny to me was that at the beginning he says the ideas are labyrinthine, but they weren't, and at the end he says, "you're confused now," but I wasn't (at all).

    By the way, a quote from this follow-up article about the interconnected subsystems of Puzzle Strike:

    This sounds a lot like what you're saying over at FS right now. I haven't read that whole article yet (and I probably won't unless I actually start playing Puzzle Strike regularly), so maybe at the end he goes, "nope, it's best to avoid interwoven systems after all." But glancing at it, the article doesn't seem to be evaluating the "complexly interwoven megasystem" vs. "well separated subsystems" question but just specifically talking about the systems of PS and certain practical issues that came up during development.
     
    keithburgun likes this.
  4. keithburgun

    keithburgun Administrator, Lead Designer Staff Member

    Yeah that's EXACTLY what I said at FS, haha. Evizaer brought that article up to me and I replied with almost exactly that bit of quoted text (except that I am more certain that "interwoven systems" are better).
     
  5. Nachtfischer

    Nachtfischer Well-Known Member

    Wtf? Is Sirlin really saying something along the lines of "Hey, designers, you better take the easy route, because going the other one is just so damn hard"?

    I mean, the fact that you can break a lot by changing one small thing, when your system IS tightly interwoven, is not at all an argument not to make such a game. It's an argument to "game design is hard if you don't take shortcuts". Similarly, balancing a tightly interwoven system is hard, yeah. But that, again, doesn't mean a balanced tight system is undesirable. Is there actually a part in these articles that talks about why a tightly interwoven system is BAD (and not just in that it's hard to make)?
     
  6. Leartes

    Leartes Well-Known Member

    For the type of games he is interest in balance is impossible if you do it tightly interwoven. He tends to go the customization route and here it easily gets too much to handle. Keep in mind that what he is doing is insanely hard. He is not taking shortcuts but making the impossible possible already.
     
  7. Nachtfischer

    Nachtfischer Well-Known Member

    How is he making the impossible possible if he's taking a non-impossible fork in the road?

    (Also, if you make something impossible possible, then it obviously wasn't impossible to begin with.)
     
  8. Erenan

    Erenan Well-Known Member

    Well, the thing is that that Sirlin article is a little confused. It starts off by saying that "systems designed this way are problematic" but then he's saying something more like "for understanding a system and how its components function together, a well separated set of subsystems is best."

    For instance, the whole thing about carving up a building according to a set of functional subsystems (e.g. plumbing, electrical, load-bearing materials, etc.) vs. according to high-level user level functionality (e.g. bathroom, kitchen, storage closet, etc.). This is like, two different ways of understanding a system after it exists. But when designing a building, you want to carve it up in both of those ways. You have to design the functionality of the plumbing and electrical subsystems in such a way that also allows for a good design in the user-level functionality (e.g. how traversing the house will flow, proximity of bathrooms and bedrooms, make sure the plumbing is connected such that bathroom and kitchen faucets don't cause conflicts, etc.). It is true that in either case you want systems that are relatively well separated (I mean, you don't want the kitchen and the bathroom to blend together in the middle or something, you want to have walls between bedrooms and other rooms, maybe with the kitchen and the living room not having walls is more acceptable, but mostly no, you want separation), and that makes sense.

    But then Sirlin never really explicitly applies this idea to game design in the first article. Instead, he starts talking about the self and how consciousness emerges from the interwoven system that is the brain. But then, he just, kinda, never makes a point about it? There's no thesis, just... Here's an example of an interwoven system (one that works, at that).

    And then there's the Puzzle Strike follow-up article, where he says that it maybe works well if it's well balanced, but balancing it is hard.

    So no, I don't think he's ever really explained in depth why interwoven systems are bad, but he's also kinda not really completely just saying that they're bad either.
     
  9. keithburgun

    keithburgun Administrator, Lead Designer Staff Member

    Yeah structurally it's a really annoying article to read, because as far as I can tell, the "thesis statement" is buried somewhere in the middle(if it is a thesis statement at all). The end feels like a "wait, what? Where were you taking me?"

    But hey, there's me and my crazy core-mechanism philosophy coming out again, wanting silly stuff like a clear "thesis statement" in an essay that "everything in the essay supports".
     
  10. Erenan

    Erenan Well-Known Member

    Come to think of it, I don't think this is exactly the same thing, and I think it's because there's a difference between what you mean when you say "clockwork system" and what Sirlin means when he says "interwoven system." As far as I can tell, he means that it doesn't use a modular design structure and instead all the various components are well connected in a variety of ways. You are pushing for a system like that, but with additional characteristics: It should have a single core mechanism that all the other mechanisms support. Sirlin's article really had nothing to do with that idea at all.

    To put some specificity on that, the diagram in his article is a good illustration. He would call that an interwoven system, but a system with a messy structure like that isn't what you're pushing for, since it doesn't appear to have anything remotely like the core mechanism you're suggesting.
     
  11. evizaer

    evizaer Well-Known Member

    I think the "is [thing I'm invested in] good/bad according to this article?" perspective may be clouding people's readings of this article.

    (The following is what I get out of the article when reading it in good faith, combined with my own interpretation of its implications--I try to mention how what Sirlin has to say is directly contextualized in my experiences.)

    So one thing you fight against when designing a game is the very complexity that makes the game such a compelling thing to play. If the game has enough emergent complexity to stay fresh to the designer as a player, it certainly has more than enough such complexity to stump the designer in his efforts to improve the design. Sirlin is saying that a common way of managing this complexity in systems-as-solutions (though he doesn't have this construct in his writing, it fits with my conception) is to break the complexity into subsystems that themselves may have intricate tightly-tuned mechanisms, then to have a few of these subsystems with well-defined, manipulable links. This isolates the impacts of changes, and has worked pretty well for basically the whole history of software development. There are a number of programming paradigms based around this, including all of the major ones current in use, such as Object Oriented Programming, Functional Programming, and Structured Programming. You can trace the general subsystem decomposition pattern further back to the necessary structural changes to the workplace that allow for mass manufacturing to take place.

    Sirlin's further point about subsystems is that there's no canonical, correct way to do it in most cases a game designer or architect or consciousness-studying scientist will face. Often, the subsystemic decomposition you'd do in your process of design is influenced strongly by your culture. The way a Pequot family builds its dwelling and conceptualizes its construction and maintenance is notably different from how a family that lives in the suburbs of New York City would conceptualize those "same" processes. So not only is design based on myriad cultural factors, but our analysis of existing designs (designer-absent) is biased in similar ways. The real challenging part is that there is not one true subsystemic decomposition--there are only more or less useful ones according to the criteria of certain purposes. I'm not sure if Sirlin mentions this specifically, but I think it's an important, fairly direct implication of the article.

    The article is not ground-breaking work. It's not some critical point about game design that will change the way you design games. It's an exploration of the challenge of game design, written by a game designer who, himself, is very much still learning every day both by growing his intuition and improving his conscious understanding. Sirlin is not passing down commandments. He is not the object of divine revelation. He's a game designer, working in the field and making notes. I think in that context the article makes more sense, and doesn't at all need to be seen as "Oh, is Sirlin saying the X is bad and Y is good!? Well, if he isn't this is useless." I contend it's way more useful if you don't think of it that way.
     
  12. Leartes

    Leartes Well-Known Member

    Just for the record, this statement is wrong in the same way the "every problem is solvable" statement is wrong.

    The halting problem is unsolvable or - in other words - impossible to solve. If you restrict the input language enough, e.g. from a while to loop language, the problem becomes solvable.
     
  13. evizaer

    evizaer Well-Known Member

    It's a failure of abstract reasoning in that he's saying "If there are specific cases that are possible, the general case can't be impossible." It mistakes (and this not something I expect non-CS people to know) "solving a problem for a specific input's implications for the problem as a whole" for "solving a problem for arbitrary inputs." This distinction is useful to use when your doing more fine-grained analysis of the problems that games present to players. Coming up with an interesting problem for players to solve means not only creating a class of problem, but also setting the parameters for the problem such that the problem will be sufficiently difficult. This is usually an intuitive process for a game designer--it involves some sophisticated intuitions with regard to level design and content placement (or the automation thereof) in most games, but specifically in decision-contests it involves analysis of the complexity load when the player has to make each kind of decision he's asked to make.
     
    Last edited: Mar 21, 2014
    vivafringe and Leartes like this.
  14. Nachtfischer

    Nachtfischer Well-Known Member

    Well "making the impossible possible" can actually mean two things, either of which don't make sense when you taker a closer look:
    • Problem X is impossible to solve. Someone manages solve X with solution Y. So he "made the impossible possible." In that case X obviously wasn't impossible to solve begin with.
    • Problem X is impossible to solve. Someone changes X to X* so that it becomes possible to solve. Again, he "made the impossible possible". In that case though, X is actually still impossible to solve (without the transformation to X*).
     
  15. evizaer

    evizaer Well-Known Member

    That's not a correct way of analyzing the situation.

    "Problem" can either mean "instance of a problem" or "(class of) problem." I'll refer to them respectively as "instance" and "class" so it's totally unambiguous.

    An instance would look like "10 + 6."
    The class of "10 + 6" would be "binary addition", meaning an addition problem with two operands, more specifically in this case integers.

    In the class "binary addition", you have a description of an infinite number of instances. Depending on which instance you select, it could be very time-consuming to solve, or trivial to solve. "1 + 1" is trivial. I could write out some 1,000,000 digit numbers and add them together and that'd take a while. I could start writing out a pair of numbers so big that literally they could not fit in the universe and we'd never even finish seeing the problem before eternity is over. (This last sentence is not relevant in math, but it's very relevant in game design.)

    So an unsolvable problem (read: class) is a problem where, for arbitrary inputs, you can't derive a solution. There may be instances within the class where you can derive a solution, but they are generally considered "trivial" cases. You could construct a solvable class out of a unsolvable class by adding a constraint on inputs. Laertes mentions this in his halting problem example.
     
  16. Nachtfischer

    Nachtfischer Well-Known Member

    What "situation" are we even talking about here? I just analyzed the string of words that is "making the impossible possible".

    Also, I didn't make any assumptions regarding X. So X could either be a class or an instance, it doesn't matter for the rest of my post.

    Which was my second point.
     
  17. evizaer

    evizaer Well-Known Member

    Sorry, I misinterpreted what you said. Now that I re-examine it, I know what you mean and it agrees with my description. I hope my description helped someone... I mean, it's a description of something useful to the discussion, at least.

    Here's the original content:

    "Impossible possible" here is a rhetorical device and doesn't justify your somewhat pedantic approach. He's just saying that "his doing something that is insanely hard" and that "he's doing what he can to make it not turn out to be a mess/waste of time to play."
     
    Leartes and Nachtfischer like this.
  18. Erenan

    Erenan Well-Known Member

    I agree with all of this in principle, but not in the specific case of Sirlin. His standard operating procedure, especially in the context of talking with Keith, actually does seem to be saying, explicitly, "X is bad and Y is good." When Keith submits an idea for discussion, Sirlin's response is to say "No, that's obviously a bad idea, so we shouldn't talk about it" and then close the thread. So the proposition of not thinking about Sirlin's thoughts in terms of good and bad is a hard pill to swallow for me.
     
    deluks917 and Nachtfischer like this.
  19. evizaer

    evizaer Well-Known Member

    I'm reading an article and attempting to extract useful information from it. If interpreting it the way you specified were actually useful to me, maybe I'd do it. Doesn't seem like it is. He's definitely not talking about Keith's ideas as outlined on fs.com in that article, anyway--he's talking about a concept that is much broader superset that may include Keith's clockwork design idea.
     
    Erenan likes this.
  20. Erenan

    Erenan Well-Known Member

    Yes, and I don't disagree at all that some measure of value can be derived from it if you just focus on the ideas and not on the author.

    If we are thinking about how this article fits into Sirlin's views on game design, it's a different question. Perhaps not an interesting one, especially since it's an article from four years ago. I don't want to dip into making ad hom attacks on an idea, so I guess I will let it go.
     

Share This Page