Four pillars of games / entertainment

edited in General
So I've been pondering what makes a game, or any entertainment for that matter. I don't know if there are other discourse on this, but here's what I've come up with:

Mechanic
Art
Story/theme
Content

Resulting in something like ths:

image

What do you think? Can games/entertainment be broken down into such simplistic elements? Does it make sense? Do you agree?

Comments

  • I like looking at games that way too, mainly because I find that games can be wildly successful for different reasons. They don't all need to look amazing, or have a story to tell -- they don't necessarily even have to have a strong game mechanic (I'm thinking about To the Moon and the Mass Effect series), as long as there's a great experience (beautiful soundtrack and story, beautiful and super engrossing world, respectively) that it can offer.

    I think it's useful to use as a check: Can my game be improved by strengthening one of these pillars? Is it worth the time investment? (Because it's probably better to have, say, no story, or a story that the player can create for themselves, like Tetris or the Sims, than to have a story that's written by someone who thinks he can write.)

    --
    I'm not sure that "content" is big enough to be a pillar. To me, content is just "more". More art, or more story, or more levels, etc. I don't see how it adds anything really, other than a lengthier game or more re-playability. Perhaps you mean something else?
  • Well actually, that's exactly what I meant by "content". There are games that are successful exactly due to the length of the experience, and there are plenty of games where if it were significantly shorter it wouldn't be successful. In fact there are games that are too long/much.

    MMOs are successful due to content, for example.

    Come to think of it, To The Moon lacks in the Content department and probably shouldn't be there.

    Are there other things/games that you can think of that fit into these intersections?

    And I just realised that there's no space for Mechanic + content and art + story... A 2D venn doesn't seem to cut it for this :P
  • A 2D venn diagram can totally do it -- just use a shape that isn't pure convex! :P

    I suppose I see pillars as being similar to mathematical axioms or something, where they're irreducible, and are able to stand quite confidently on their own. A "content" pillar seems secondary to me because of its reliance on one of the other three pillars. An MMO isn't successful "exactly due to the length of the experience", I think. It's (financially?) successful because it does great things in one or more of the other pillars, and its success is extended by having more of that "stuff".

    Out of interest, Schell referred to "technology" as one of the pillars he writes about. The medium in which the game is delivered might be very interesting, original, novel. Perhaps things like the Kinect, or Occulus Rift, etc. I imagine the EyeToy was able to sell games purely because they were EyeToy games. I really don't understand the popularity of (at least the first iteration of) Angry Birds, but I imagine it was largely due to its being one of the first games to make use of a touch device...?
  • Not pure convex shapes... How...!? Squares? Stars?

    Would technology not be able to be grouped under mechanics? Yes I understand that novelty can be good, but pure technology without the right mechanics (playing space invader on occulus, for example) would never be able to be "good", right?

    Though I do kinda agree with content. It's not necessarily something that can stand on its own. I wonder... I think a good way to see whether any of this is valid is to put known titles into these categorisation, and what would a pure content "game" or entertainment thing be - devoid of mechanic, narrative or art?

    ... Can't think of any really XD Maybe yeah, time to drop the content pillar :P
  • edited
    Would you describe Asura's Wrath as an almost pure content game? (It does have bits of mediocre combat in it... but it's mostly one long quick time event)

    Content is critical in the AAA space, but we do kind of view it as less necessary in independent development.

    Though Super Crate Box with one weapon would be lame, and Proteas on a 3 X 3 island would be pointless. For argument's sake, I'm not sure if mechanics or art can stand on their own either.

    Though I do think there are problems with this Venn diagram. And I wouldn't include "content" this way myself.

    It's vaguely unsettling how content is overlapping mechanics.

    image
  • edited
    The content tentacle?! :P

    I think that's actually a good way of describing the content/mechanic... Diametric? If it were possible to completely argue the one over the other, then that's basically a Y axis of (theoretically and arguable) Indie to the top and AAA to the bottom of the Y axis...

    The the X axis would be something like... Writer <===> Artist?

    Although this argument is a bit flimsy when things like Dwarf Fortress, which is arguably the game with the MOST CONTENT EVER. And Minecraft? Maybe it doesn't work quite that way.

    Well I was gonna drop content anyway :P

    Though, then, would we be able to say that there are three ingredients to games, mechanic, art and story/theme? Does/should technology feature, really? It's really a product of its time, I think?
  • edited
    In any case, if it's down to fundamental building blocks of games... then surely it should be:

    Mechanics + Art + Sound + Story / Theme

    But those building blocks don't really describe the experience the player has. And I'm not sure what use such a diagram has....

    Being excellent in mechanics and art (like you suggest Braid is) is of course great for Braid... but aiming for excellence in art and mechanics isn't really what Jonathan Blow did to get to that point.

    I mean to say... no-one intentionally makes mediocre games, it just kind of happens when developers don't have the right skills or methodology or have crippling constraints.

    I guess such a diagram could be a tool in game appreciation (but I don't find game appreciation discourse, without development understanding, to yield usefulness very often).

  • On what is perhaps a side-note, given the discussion of the validity and utility of the graph, I think that I'd be inclined to place both Braid and graphic novels one step to their respective lefts: the former into the bright green area (since I think that Braid was quite strong on theme, perhaps strong on story too) and the latter into the pale pink area (since I think that graphic novels are likely to be strong in story or theme). I might place (at least some) paintings in the intersection of content and art (little story, likely at least some theme, but largely content and art). While I'm stumped for a game to put in the intersection of art and mechanics, I imagine that such a thing exists.

    As to the validity of content, I think that I'm inclined to agree with its removal: one could easily, I think, define "content" as simply "more art, mechanics or story/theme" (and perhaps sound, if that's included); if it's not one of the other pillars, then one might argue that "content" becomes padding.

    As to the utility of such a chart, it may well not have much utility to developers, but it may well have utility to critics and analysts, just as one (generally) doesn't build a story out of tropes, but tropes provide a way of understanding and dissecting stories.
  • I do agree that noone sets out to make something with mediocre games - but one sets out to focus more on one area over the other - The best metaphor I can come up with is that the diagram is a roulette betting table, and every developer has a limited number of chips to dole out (kinda like game dev story has it XD) - and you bet your time on areas that you wan to focus on. Some devs have special chips that can only be placed at art or mechanics or whatever because that's what they're experienced and is good at, because they've built skill towards that direction.

    Sound is a very valid addition. Although I wonder if sound/art couldn't be grouped together? Or am I gonna draw some ire of artists/musicians? To me they perform a similar function, but of course they're created by different people with very different masteries. Perhaps I'm over-simplifying and over-generalising (as I tend to do)?

    Yeah content is more like the height of the pillars? More content could be more mechanic, more story, or more art, more sound, etc. I like that.

    This line of thought came from the prototyping discussion - that it's important to start with mechanics, but it's just as valid to focus on areas other than mechanics, but it should be done with the awareness a "successful" non mechanically-focussed game tend to sway towards other forms of entertainment, like books and movies, etc, Which is great if that's what you're going for. For example Dear Esther veered very close to having very no mechanic, and was all art... And Whether there was story is debatable XD
  • @Tuism said:
    Yeah content is more like the height of the pillars? More content could be more mechanic, more story, or more art, more sound, etc. I like that.
    That's a really good idea! If you make it depth, then it would translate to mechanic really well too.
  • @Tuism, I wouldn't group sound and art either, not because they are created by different people but because they are interpreted differently by the players.

    I'm not exactly sure how I mean that...but take something like Deep Sea, no visual art but still an awesome game because of the sound. Or rather it couldn't even exist without the sound.

    Also, most games can be played without sound/music, but it completely changes the experience.
  • edited
    If you want to group art and sound together then maybe call it "aesthetics" ?

    Although "aesthetics" has been appropriated by the MDA framework to mean something more specious. So it's kind of a not-useful word in game theory right now. Though I don't know how other designers regard the MDA framework (I find it clumsy and vestigial).
    Thanked by 1Tuism
  • MDA = ?

    Aesthetics - that's closer to what I was referring to when I said that art/sound kinda felt like they belong to the same thing to me. Though I know that to some "aesthetics" were more of an overall thing, like the Aesthetic of Diablo games vs the aesthetic of MOBA games. Maybe to some it feels more like a little more specific than genre and broader than particular titles. It's like describing the experience of the game...

    @Rigormortis I understand that a game can stand without sound or without art - but in any case the sound and/or the art fits the same "function" in the framework I'm describing... They're the things that conveys the mechanic and the things that convey the story. And they do things that neither the mechanic nor story can do, but sometimes - sound can do what art can do and vice versa, and they usually do it in tandem (or exclusive of each other, but that's a very specific decision by the creators, probably based on mechanics).

    It's like... The wrapping?
    Thanked by 1EvanGreenwood
  • edited
    MDA = http://www.cs.northwestern.edu/~hunicke/MDA.pdf

    As I've said, I feel like it vacillates between common sense and theory for theory's sake. There are some good insights in it (it is written by some smart people), but I don't like the methodology it espouses.

    I think it is thought to be useful by the same people who think game design documents are useful... I mean it treats game development as if a game designer can have a goal and achieve that goal and that having a goal and then achieving it is even a good thing (as a methodology).

    Whereas game development in real life (in my experience) is always an exploration. And the best results come more in the form of happy accidents and listening to players rather than perfect executions of ideas based on theories.

    Although, I'd concede that the MDA framework, or frameworks like it, would be useful in the same sort of circumstances where game design documents are useful (like client work and maybe AAA).

    But for the most part I don't like these frameworks (for game development) because I feel they present an appealingly simple view of game development rather than the messy reality. And they seem (to me) to make the assumption that if you know the theory you can make a good game (or at least, the theory assumes that implementation is a predictable/trivial thing).

    They're fine of course for game appreciation and game criticism, but the MDA in particular does propose to be employed as game development methodology.

    (Sorry for going on a tangent / rant about my dissatisfaction with the MDA framework)
    Thanked by 1Tuism
  • edited
    Just noticed that the tentacle came alive @_@ Is it mechanics powering content... or content draining the life out of mechanics? Both actually have a reasonable chance of being true :P

    Guess I should again go back to why I thought of making this diagram - I agree that game dev is a messy affair in reality, and that projects shouldn't be boxed into holes at the beginning, but I was trying to make a point that mechanics should be the starting point of any project prototyping.

    Then the point came up that it's just as valid to start with other things, like art and story.

    Then I thought - sure, of course you can, but that focus would probably tilt your eventual outcome towards one type of outcome or another.

    Therefore, I thought it would be good for people to see that focussing on areas other than mechanics eventually lead to a outcomes that are stronger on somethings at the expense of other things (again, because we all have limited resources and a craps table full of betting options).

    It's kinda like we all say that we shouldn't focus on building an engine, because the outcome of that engine-building obsession is an engine and not a game. If that's what you want, then go for it, build your engine, but don't mistake building an engine for building a game.

    And I feel that the same can be said if the focus started from story or art - then you'll build something like a game, but closer to something else. And if you're cool with that, then go for it.

    And that's where I started to try filling in those gaps with examples of things that fit in those overlaps, so that people can see "ah, is that where I'm headed if I focus on this or that?"
  • I think that there are a fair few viable ways of starting the development of a game, only one of which is mechanics.

    For myself, I think that I've found exploration of mechanics to be a less-than-ideal starting point, but more useful later in development. Instead, I think that I prefer to start with an experience, something that I want to convey or produce for the player; this can be mechanical ("I want to make a stealth game"), aesthetic ("I want to make a game that's like wandering through a series of paintings, changing them as the player goes"), narrative ("I want to make a game about <insert name>; he hunts monsters, but doesn't know... etc.") or something else besides.

    That said, that is, again, for myself: what works for one person may not work for another.

    Starting from a point other that mechanics may very well skew the final result on the graph that you produced -- and I don't think that this is a bad thing. Indeed, I think that there's plenty of space for a wide variety of games, be they story-heavy (think of games like the Gabriel Knight series, or Planescape: Torment), aesthetics-heavy (I'm a little stuck for examples here, I'll confess), mechanics-heavy (think of games like Tetris, or Rogue) or otherwise. And, to me, those are all games.

    The lines of classification between games and other media might blur in places, true -- but that seems natural to me: I argue that the categories that we create, our labels of genre, medium and so on, are artificial, and don't see much significant benefit to using them to constrain new games (or books, movies, etc.).
  • edited
    Thaumaturge said:
    For myself, I think that I've found exploration of mechanics to be a less-than-ideal starting point, but more useful later in development. Instead, I think that I prefer to start with an experience, something that I want to convey or produce for the player; this can be mechanical ("I want to make a stealth game"), aesthetic ("I want to make a game that's like wandering through a series of paintings, changing them as the player goes"), narrative ("I want to make a game about <insert name>; he hunts monsters, but doesn't know... etc.") or something else besides.
    @Thaumaturge I think what you outline is exactly what I'd warn against. Everyone has different experiences with game development certainly... but this is the warning I'd give:

    Starting from the end point and working towards that might work if you're lucky (or very experienced in the thing you're trying to do), but just as likely you might end up trying to force an experience into a preconceived shape and arrive at something that feels not great. Implementation always produces problems and opportunities along the way (for art, for mechanics, for sound etc).

    Of course in exploring mechanics (or exploring art, sound, story etc) you've got to have some kind of direction in mind. I'm not advocating aimlessness. Just as if you've decided on an experience already you're not going to follow that blindly.

    I think planning/visualizing the end point, just in itself, has a negative emotional effect on development as the actual result is never going to be quite the same as you imagine. In game development we're always under a ton of constraints, but in our armchairs we are not, and becoming emotionally attached to your preconceived ideas is a real thing. This can make you cling to bad ideas, long past the point they've proven unsuitable, or push for them when you don't have the resources. It can be demoralizing and, in my experience, that can make you a lousy person to work with (and that feeds back into your ability to come up with new inspired ideas and be productive).

    Well for me certainly. The more a project I've worked on has been armchair designed the more conventional (as apposed to innovative) it has turned out. All the best features in any game I've been involved in have come out of playfulness, and the most embarrassing mistakes were all planned.

    Also, regarding exploring mechanics later in development, this has been pretty exhaustively argued elsewhere (with a fairly unanimous conclusion I thought): http://www.makegamessa.com/discussion/823 (@Dislekcia argued that one of the things about mechanics is that they are less efficient to explore the more content your project has. This isn't as much the case with art and sound and writing, and so starting with a lot of art and sound and writing in the project kind of guarantees meh mechanics, which is a problem if your game relies on good mechanics).

    (Though I'm not saying that games shouldn't be aesthetically focused. I'm saying that implementing/testing interactions later in development is a strictly worse approach than implementing/testing interactions at the start)
    Thanked by 1hermantulleken
  • @BlackShipsFilltheSky

    I agree almost 100% with you, especially how implementation presents new opportunities, and so starting from the end point lead not-so-great feeling games. I do mostly contract games, so I have walked that path many times. And I have worked on many projects where we (me and the rest of the team and even the client) looked with sadness at the looming deadline and realised what is not going to be...

    That said, I think starting from the end point from time to time has one great benefit: not for the game, but for the people making it. Because trying to emulate some preconceived idea forces you to think of how to do it: it makes you a stronger implementer. And I do believe that type of skill makes exploration-driven design (on future projects) better. [It's a little bit like how drawing from your imagination, instead of life, leads to more interesting art... but drawing from life is necessary to learn how to draw what you want and not just what you can].

    ----
    (And on the separate point of experimenting late with mechanics I agree that this is a huge huge huge huge expensive and demoralising mistake...)
  • edited
    @hermantulleken True.

    I totally don't mean to say focusing on the end is valueless. And I do advocate starting game development by trying to copy small games and figure out the basics.

    But a little further along in a game developer's career, I think focusing on the end can be sub-optimal and problematic, but it is certainly necessary in many circumstances.

    I started game development on my own, and then once I had some skills I started doing client work (which obviously necessitated visualizing-the-end-point).

    I was pretty unhappy, and catering to the client's visualized-end was a big constraint. I made better games before and after having to work with clients.

    So for me personally, I think I would have learned faster if I'd continued doing the exploration approach on my own. I was in the position to be able to make testable prototypes by myself or in teams of two (which isn't a unique position).

    But I needed money, so doing client work was necessary, and working with larger teams gave me other kinds of valuable opportunities/skills.

    Also I think working in teams, especially with other members who aren't as experienced, requires a certain amount of visualizing-the-end-point. There isn't really any way around that, and there are skills to learn that you need to be in that kind of situation to acquire.

    I'd argue that while always-exploring might be the fastest path to making great games, the biggest problem with an always-exploring approach is that it is high-risk-high-reward. Not everyone has the resources to take those risks. And there are less expensive paths. We've got to work with what we've got, and learn as much as we can along the way.

    Recently I feel like I need to unlearn some of the visualize-the-end methodology that I've picked up... or at least, figure out how to keep that playfulness and experimentation while managing a team of 6. It is something I am actively worried about. (Hence the soliloquizing on the subject)

    (I'd like for there to be a unified game design methodology, like the MDA, that tackles this last issue (not my soliloquizing but the issue of playfulness in teams). I've come across some informal approaches, but I'd like something that can be taught in Universities.
  • edited
    @BlackShipsFilltheSky: I think that you may be misunderstanding me.

    I'm not suggesting that one have a concrete, unchangeable and complete design right from the start. I'm also not saying that the experience aimed for can never change. An "experience" can be something fairly nebulous: wanting to make a game about loss, or a detective story, or a first-person shooter that avoids some standard mechanic, or a horror game that plays with the player's mind, etc. It's what the developer wants to convey to the player, not the final design of the game intended to do that.

    When you sit down to create a game, and do so starting from mechanics, how do you decide which mechanics to try first? Do you not have some idea of what you want to make, even if it's as vague as "I want to make a platformer", or "what if we tried making a stealth game in which the player was blind"? Those goals may change during development, but do you not start with some idea to head for? That's more or less what I'm talking about, except that I'm also suggesting that the idea that one starts with need not be mechanical in nature.

    As to exploring mechanics later in development, I perhaps misworded my intention there: I don't think that I was at all suggesting that one should only experiment with mechanics once there's a significant amount of content in place. Instead, the idea is that mechanics can follow another "pillar", be intended to serve that pillar, rather than being first of all.
    This can make you cling to bad ideas, long past the point they've proven unsuitable, or push for them when you don't have the resources.
    I don't think that this is unique to starting from some point other than mechanics, or even unique to game development: getting used to "murdering one's darlings/children" is one of the pieces of advice that I think that I've seen in advice to writers, for example. For that matter, surely one can become attached to a beloved mechanic (I think that I recall that happening to me).

    In the end, I'm not arguing against starting from mechanics; I'm arguing against teaching that starting from mechanics is the only reasonable way to make games (or at least to make them outside of contract or AAA work), as seems to be being argued here.

    For one thing, I don't think that the "mechanics first" approach leaves much space for games that aren't built on new mechanics. A new point-and-click adventure game might introduce no new mechanics at all, and still be an excellent game, because mechanics are not its focus.

    Finally, perhaps it would help if I gave an example of what I have in mind:

    Let's say that I had a story in mind for a game -- specifically, I wanted a detective story involving a genius detective who discovers himself dealing with werewolves -- and started from there. I might then think about what mechanics might support such a story -- perhaps a point-and-click adventure would be a good start. Since the main character is a detective, some sort of deduction mechanic might be interesting, and I could start experimenting with those.

    A little further in, I might find that the deduction mechanic isn't working, so I might change some of the focus of my writing to no longer emphasise the detective's genius; this needn't change the overall story, just an element of its focus.

    Overall I would be looking for mechanics that support the story that I want to tell: since it's a detective story, I might decide to avoid a linear, scripted approach and instead allow players to find clues at their own pace, for example. Neither the linear, scripted approach nor the more open-ended approach is, I argue, inherently better in and of itself, but the latter might serve this particular story better.

    Of course, that's just one potential approach, for one potential game. Different games are served by different approaches, I feel, and "mechanics first" is just one approach, serving just one subset of games, I believe.
    Thanked by 1hanli
  • @BlackShipsFilltheSky Yes, I think I get what you are saying. I think my focus on getting things done also warps my perspective a bit (for after all, I'm not a designer). I tried thinking of some examples, and they were all relevant to programming; not design 0.o...
  • @Thaumaturge I think the method you've outlined it an appealing trap.
  • edited
    @Thaumaturge what you described is exactly what I was talking about - if you focus on that story, you'll end up with a game that is focused on the story that you've set out to tell - and you'd have naturally spent less time on the mechanics.

    Whether you might happen on an awesome new and innovative mechanic or not is besides the point - one could argue that concentrating on mechanics first might make you happen on an awesome new and innovative story. That's counting on being lucky, and I'm not a fan of that. The model I'm talking about is directly assigning time as advancement tokens to various items of importance - the thing you spend more time on/was already really good at is more likely to be stronger. The thing that you're already good at is probably the thing you've already spent tons of time on.

    So, what I'm saying is not "DON'T FOCUS ON STORY! DON'T FOCUS ON ART!" - it's if you focus on anything, know that you're focusing on it, and understand that the outcome is less likely to be "that awesome game" but "that awesome story" or "that awesome art". And accept it :D
  • edited
    @BlackShipsFilltheSky: How so?

    @Tuism:
    Why need a new game have an awesome new mechanic? Is there no worth in, for example, a new point-and-click adventure game that tells a new and interesting story, despite using one of the standard sets of point-and-click mechanics?
    ... understand that the outcome is less likely to be "that awesome game" but "that awesome story" or "that awesome art"
    I disagree with the implication that an end result that's well-described as "that awesome story" is necessarily not also "that awesome game" -- or rather, that a story-focussed game is somehow not a game.

    Gabriel Knight 2, for example, is perhaps best remembered for its story and characters -- does that make it any less an "awesome game"? You might argue that such a game might then be just as good or better if rendered as a novel, stripping it down to what it does best -- and yet, having both the game and the novelisation, as I recall I've played the former multiple times and read the latter only once. Planescape: Torment has a wonderful story, one that I've played through twice, as I recall -- despite having gameplay that I honestly don't have a terribly high opinion of (for one thing I really, really don't like D&D's Vancian spell system, which is a problem given my preference for playing as a mage). I've thought a few times, as I recall, that as wonderful as Planescape: Torment is, I don't think that it would be well-served as a movie: it's an experience that derives a lot of its power from the sense of the player being the one making the choices, of experiencing the Nameless One's journey oneself.

    For me, mechanics are not all that there is to a game, and nor need they be the most important element. To me, the defining and distinguishing feature of games is interaction, and it's true that interaction is produced by mechanics -- but one doesn't need new or prominent mechanics to produce that feeling of interaction, of taking part.

    I haven't yet played Dear Esther or Gone Home, but from what I've read they're good examples:

    To call such a game -- and yes, I classify them as such -- "an awesome story", but not "an awesome game" does them a disservice, I feel, because it implies that they would be just as good in non-interactive form, which I doubt. I think that you might find -- and this seems borne up by some reactions to them that I've read -- that having control of the player character's movements and what that character does changes the experience from one of observing, as one does in a novel, to one of taking part, which can be a dramatic difference.

    Note that I'm not saying that there's anything wrong with mechanically-focussed games; I'm saying that they're not the only "real" games that exist.
  • I must be really really not presenting myself clearly, I didn't say that a game focussed not on mechanics not a game - I say that it will be known as that thing with that art, rather than that thing with that mechanic.

    I don't think every new game needs new mechanics, but if you want cool mechanics, you work hard on it, and first, before you dive into story and art.

    If you want awesome art, you do that first, then you attach mechanic and story to it.

    In the perfect world, all of us would be able to get perfect art, perfect mechanic and perfect story.

    But given that we are indies we most likely have 10 chips to spread out on 3 stats with 10 as each's max.

    That is all :) Not saying that games that don't focus on mechanics as not "real" games, I'm saying that they're not games with awesome mechanics, because the creator didn't focus on them.

    If we really wanna go to the example of dear esther, I played it. It was interesting. But not fun. I didn't like the mechanics, I didn't like how it was more like a slide-show or a guided tour. But some people loved it. I didn't say it wasn't pretty, or that it wasn't an interesting way of expositioning a story (is that even a real word?), I just didn't like it mechanically, and I wouldn't play it again.

    Now that's probably exactly what the creator was going for, so that's fine.

    The only real thing I was warning against are people who focus on art and story and expect a mechanically strong game to come out in the end.
  • Ah, fair enough -- and in all fairness, it's quite possible that I misread you. ^^;

    In that case, I think that I more or less agree with you, if I now understand you correctly: the advice, then, would be "start with the focus of your game", or something to that effect. If your game is intended to be mechanically focussed -- the "next Portal", for example -- then start with the mechanics. If your game is narratively focussed, then start with the narrative -- and so on.

    As I think that I've said, all that I'm arguing against is the advice that one should always start with mechanics; all that I'm arguing is that the other "pillars" are similarly valid as starting points for game development.
  • I think the major thing to avoid here is lack of evaluation and synthesis. The reason people are talking about the dangers of focusing too much on art or story is because those are pretty easy to focus on too much to the detriment of the rest of the system that becomes a game eventually.

    A game needs to be constantly evaluated as it's taking shape in order to make sure that your goals with it are being met, whatever those goals are. Yes, picking good goals is a huge part of that, but if you're not viewing your game as a whole, if you're not synthesising the disparate lumps you have early on into an actual, playable, testable single experience, you're going dangerously astray.

    If your goal is to tell a story, test everything you're working on against that goal - including the story itself. That's how Journey could be focused on specific emotional progressions they wanted players to experience, they synthesised continuously and threw away all the parts that weren't working towards creating that coherent experience - you should see how many different mechanics and movement prototypes they went through before they felt comfortable going ahead with anything.

    It's just that sitting down and getting lost in writing a story or making some neat concept art is far too easy to do, that's all... That said, I'm pretty sure that having solid mechanics before you start content production means that you'll not only have an easier time producing content and getting it into your game, but you'll also be able to have more content that ties in with the game experience better too.
    Thanked by 1EvanGreenwood
  • edited
    That I'd agree with, I believe; specifically, that it can be very important to keep an eye on the project as a whole, and how the various elements are interacting.

    Again, I'm not arguing in favour of getting heavily into content creation at the start.

    Finally, I do agree that one can get caught up in story or art at the expense of gameplay -- but also that one can get caught up in designing gameplay at the expense of art or story. If the resultant game is still good, then well and fine -- but that holds too for a game that has a wonderful story and poor gameplay, I think (again, I suggest Planescape: Torment).

    Funnily enough, I think that I'm currently re-playing a decent example: Sherlock Holmes: The Awakened (a crossover of Sherlock Holmes and the Cthulhu Mythos).

    The story is good, but there are a number of gameplay issues, in particular what seems to me to be poor communication with the player, some cases in which it looks as though one can miss discoveries by doing things in the wrong order, not allowing interaction before the game activates a hot-spot (and thus making new hot-spots inobvious) and a paucity of hot-spots.

    Little of this refers to new mechanics; most of these are well-established adventure game mechanics, and I think that at least some of them have accompanying adventure-design truisms.

    I do think that these problems might have benefited from considering the game as a whole -- in particular how problems in the mechanics might be letting the story down.
  • edited
    Dislekcia said:
    A game needs to be constantly evaluated as it's taking shape in order to make sure that your goals with it are being met, whatever those goals are.
    @dislekcia I agree with what you're saying... but I'd go a step further (and phrase it a bit differently).

    To be clear: I am trying to speak to the developers on this forum. And I am speaking about starting original self-owned projects (as apposed to client work which is a bit different, or finishing projects which is also different).

    None of the developers on this forum have the experience of a team like Journey. While I agree that ThatGameCompany did a brilliant job following a methodology for Journey that ensured the best results, and I'd point to them as an example of excellent production I'd like to emulate, I think we have to work even more flexibly than that.

    Basically, evaluating everything against the goals you set still has the problem that you may not be able to achieve those goals at all. Deciding on detailed goals (like a point and click adventure about a detective hunting werewolves) before you begin your project means you're doing so with minimal information. Even goals that seem modest and flexible (like telling a story about a detective hunting werewolves) can be well beyond your team's skills and resources.

    And that's a trap. As you can't know what you can and cannot do before you've tried it. And goals are very difficult to give up.

    Also, evaluating the work you do against those goals is non-trivial and irrational. Unless you have a ton of experience there's no guarantee that you will evaluate them reasonably (because we are emotional beings). And even if we can find methods to evaluate goals well (like user testing and open development) there's no guarantee we'll make useful decisions with that evaluation (because everyone on this forum is fairly inexperienced). It's far easier to try keep something that isn't working than it is to discard it (for instance).

    And that's another trap.

    Though I totally agree about synthesis (as I think you mean it). But I'd emphasize the prototyping and creative experimentation with the medium (be it gameplay, or in-game story telling, or game sound etc) and de-emphasize the goals. Yes, it must be possible to evaluate things, but working towards a preconceived goal (like a point and click werewolf detective) can be a massive creativity constraint (and you are likely going to produce a conventional solution if you are focused on that rather than explore the space).

    @dislekcia Though to be fair you did outline that ThatGameCompany were constantly prototyping and throwing things away and synthesizing in the bits that were good. I'm not debating that part, I'm debating the wisdom for a solution (be it story or sound or gameplay) to be the product of solving a problem that is framed by a goal that was made without little or no knowledge of the form the experience is taking.

    ThatGameCompany were a team of experienced developers on their third iteration of similarly engaging games... they were the masters of meditative beautiful journeys before they began Journey. (Their early games, like Flow, are far more experimental)

    If Free Lives were to try Journey then far far more would go wrong along the way, and some things would be actually impossible. To arrive at a pleasing result we'd have to have even more robust methodology than they did, and have to change our goals many times along the way in order to better reflect the actualities of what we're developing. The best experiences wouldn't come from trying to be something, but rather from seizing on opportunities that arise and following them to their conclusions (which may happen when we evaluate them to be unsalvageable, or perhaps find a way to synthesize them and build on top of them)

    I know that's basically what you're saying. Changing ones goals is of course a part of any perfect evaluation.

    I am saying though that, in the case of an inexperienced team working on an original project, setting goals (for story or gameplay or art etc) at all at the outset of a project is most probably a mistake.

    I would say it would always (in the circumstances I mentioned at the start) be better to find appealing experiences that you actually can deliver to player (by prototyping them and testing them) and then finding a way to produce something cohesive only after you have something that has value.

    As a project progresses of course more goals are necessary. I'm certainly not advocating aimlessness. But I am advocating more experimentation at the start.
    Dislekcia said:
    It always seems to happen that the people who really need to hear the advice being given, instead end up justifying ignoring that advice based on edge-cases that they don't understand. The whole problem with game development is that we don't see the failures (you have to be old and cynical to start noticing those patterns), so everyone keeps assuming they're going to be successful because case A did X, meanwhile thousands of others that tried X failed horribly and A only succeeded due to what eventually comes down to sheer luck.
    I'd say something like this is likely to happen. Inexperienced developers can hear "evaluation and synthesis" and think they'll set goals and evaluate against them and synthesize their prototypes.

    But it won't work out like that because a) They don't have enough information to set good goals b) They don't have the skills or resources to meet those goals c) They won't seriously prototype anything d) They won't throw experiences away that undermine their goals away e) They don't have the skills to evaluate their own production yet f) They will choose goals that limit creativity and force conventional solutions.

    Sure, everything might just work out fine, but that's an edge case at MakeGamesSA.

    Of course: In a situation where you have to set goals (like client work) then experimentation is much trickier and you will have less control over setting goals.

    And of course: in a situation where the developer has experience in the thing they're trying to achieve, then implementation is going to be predictable, so working towards a goal is fine.

    The core of what I'm saying is that humans are unpredictable, irrational and stubborn, and game development is complicated, and we need to optimize for that. Goal orientated methodology and arm chair design can produce unwinnable situations for inexperienced developers and at best encourages conventional solutions.

    Because goals themselves can be crap (unless they're inversely nebulous to the developer's experience or budget).

    image
  • edited
    Another subtle reason why you don't want to set goals at the start, is that you are front-loading your creative decisions.

    Making creative decisions is fun, it's fun and inspiring to imagine what might be. But if you do this at the start of the project you are robbing your future-self of that fun/inspiration, and at the same time you are making the decisions when you have the least information.

    Here are some handy graphs:

    image

    VS

    image

    Maintaining inspiration over the course of a long project is a real problem. And it's a feedback loop. Feeling inspired means you can function better and make better decisions (which in turn helps you stay inspired) whereas feeling demotivated because of working according to your past self's decisions (which were made when you had less information and are more likely to be bad/impractical) means you are less able to come up with good ideas or inspired implementation and so fall more into emotional debt.

    (The graphs don't attempt to account for the feedback loops, but I'd wager the team that worked on the second graph made a better game and came out feeling far happier about the experience)
  • edited
    Phew, that's a lot to respond to! Please forgive me if I miss any points that I should address, or if my response wanders a little. ^^;;

    I agree that a goal that is beyond the team's reach is likely to result in a failed project. On the other hand, even failing is not necessarily a bad thing, especially if there's a supportive community available to provide advice and critique: sometimes failing is a part of learning.

    Additionally, how do you intend that new developers learn the amount of work involved in a game, and how to evaluate a projects, if they don't try it?

    You say that evaluating against a goal doesn't necessarily imply that the goal is attainable, and I agree -- but I also think that experimenting with mechanics doesn't imply that the resultant mechanics will be enjoyable. Just as experience helps one to learn how much work a given goal might call for, experience helps one to learn what gameplay elements work together, and how to implement them well.

    As to becoming attached to goals, I think that one can become attached to mechanics, too; I recall being loth to remove a "Time Stop" mechanic from a game at one point, but, as much as I liked the mechanic, it wasn't serving the game.

    I disagree that as nebulous a story as I laid out there ("a detective hunting werewolves") is necessarily out of reach to even a beginner, simply because it says nothing of the scope of the project. It could be a one-room adventure game with only "look" and "use" as available verbs, made entirely in Adventure Game Studio using clipart, or a forty-hour mystery RPG with deep mechanics and professional art, or any of a variety of results in-between.

    In short, I think that, as a goal, it's rather more nebulous than you seem to hold it to be.

    As to constraints, I very much disagree with the assertion that constraints necessarily restrict creativity: I think I've found -- and been advised -- that constraints can actually enable creativity, giving one a problem to solve, an obstacle to work around. Conversely, attempting to be creative with no restraints at all can be paralysing: with no theme to chase, no obstacle to work around and no given to manipulate, all directions are available -- and thus none stand out.

    As to fun in development, I'm not sure that all people find the same things to be fun. For example, for me one of the major rewards in game development is seeing my vision take shape, come out into this world -- it may be greatly changed since its first conception, but that sense of accomplishment is a significant draw for me, I think.

    For me, then, there might be some spiking in experimentation with mechanics -- because concepting and implementing gameplay can be fun -- but I think that the major spikes would come both early on, as I make the first steps to creating the work, and then further through development as it starts to more visibly become what I have in mind -- even if that has changed somewhat over the course of development.

    I think that I have, a few times, tried making a game with no vision to chase -- just started making a game. And, as I recall, it's resulted either in a poor, unfocussed game, or one that others seem to like but that bores me (and the one example that I have in mind of the latter -- ArcanoTrack -- was inspired by the constraints of the competition for which it was created).

    I'm not saying that your method and preferences don't work for you, or that they aren't better for some; rather I'm saying that not everyone works the same way, and what worries me is that advising "mechanics first" or "start by experimenting with mechanics" as the only valid way for a new game developer to begin might be deleterious to some.

    What if someone were to sign up here, having just gotten their hands on a copy of Adventure Game Studio and with a desire to make an adventure game? Should we say "no, make Tetris first", or "no, you should be experimenting with mechanics"?

    For people just starting out with game development, I think that I'm inclined to two pieces of advice: first, start small -- whether it be a one-room Adventure Game Studio game or a remake of Tetris -- and second, figure out what you enjoy in game development, and what works for you. I don't claim to know the best way to figure out that latter, but I do think that a good idea might be in listening to and reading the postings of others who have already gone that way, and so expose oneself to experiences potential paths that one might have missed.
  • *decloaks*

    I've been lurking in this thread with great interest, but I'd like to hop in to say that Thaum's comment on inspiration by constraints is highly pertinent from my perspective. What I'd consider my best work has been made for competitions with very clear constraints and themes. Whether it's the deadline (I'm only a hobbyist after all - I can still eat if I fail), or the sheer problem-solving challenge of working around the set constraints, I couldn't tell you. Something about them makes my creativity and design engines go into overdrive, whereas everything I've made from general dicking around has been somewhat lacklustre and pathetic. I'm not sure if anyone else (particularly the Real Developers™) has had this experience, but I'd say beginning with a set objective/scope/constraint in mind, however loose, definitely has its place.

    *recloaks*
  • edited
    I'd just like to point out that the design/inspiration impact of specifically chosen constraints, while probably not what @BlackShipsFilltheSky was actually talking about when the term was used, are also subject to the same issues that goals are: Not all constraints are helpful, in fact, as the person who has probably set the most development constraints for the largest number of developers on this forum, I know that I'm actively picking the constraints that are most likely to inspire interesting ideas. It takes days of thinking to figure out what each competition will be.

    If you're talking about the positive impact of constraints because of the Game.Dev and MGSA competitions, realise that you're talking about constraints chosen with the benefit of lots of experience of poor constraints in the past... All you have to do is look back at the early Game.Dev comps to see what I'm talking about. There's a definite pattern of luck to how well those worked.

    I think that talking about how people get experience with which to make better choices is a great question, I just don't understand why so many people keep trying to find ways that the similar and extremely relevant experience of others can be ignored.
  • edited
    @Thaumaturge

    As to fun in development, I'm not sure that all people find the same things to be fun. For example, for me one of the major rewards in game development is seeing my vision take shape, come out into this world -- it may be greatly changed since its first conception, but that sense of accomplishment is a significant draw for me, I think.
    This is indeed one of the most rewarding aspects of game development. Seeing a world being build and narrative arcs and connections being drawn is awesome. But I would add two thoughts. Game development is not about having fun. It's about letting players have fun, and constructing those experiences for them. That may or may not fall within your vision, and I have worked on many projects were someone's grand vision stood in the way of players having fun. (And of course making games is fun [for me]; I'm just saying you should not choose a viable strategy for making fun games based on how much fun you are having). Secondly, the experience of realizing a vision is rewarding, but watching people having fun with your creation trumps that a thousand, a million times over. And the opposite (with which I have way more experience) of people getting frustrated and bored is a dagger in your heart that paints your vision over with a layer of acid.

    ----

    On a separate note. I agree with you @dislekcia and @BlackShipsFilltheSky that wrong constraints can debilitating in principle, but I am wondering how you start off in some direction, and what advice you can offer for those without that experience when just starting on a game (I mean, I want to know too!). Obviously taking part in competitions etc. where constraints have been chosen carefully is one way, but are there others?
  • @dislekcia: Point well taken, although I've found generalised constraints work just as well for me. I'm also not saying all this in a misguided effort to debunk those with more experience though. No idea where that came from. O_o If anything, I was curious as to whether those with experience could relate. We're all trying to nut out how not to waste time to make rad games, no?
  • edited
    @dislekcia:
    Regarding constraints, I do realise that not all constraints are necessarily beneficial, but -- for me, at least -- having nothing at all to start with seems to generally not work well.

    The competition constraints were amongst those that I had in mind, I think, but I don't believe that they were the only ones that inspired the thought, by a long shot.
    ... I just don't understand why so many people keep trying to find ways that the similar and extremely relevant experience of others can be ignored.
    I'm not sure of which of us you're referring to in that, I'll confess; for my own part, I don't feel that that's what I'm arguing for at all. (Quite the opposite, in fact.)

    @hermantulleken:
    Regarding the rewarding aspects of game development, I do agree with you, I believe; the point that I was making was against an earlier claim regarding keeping up the passion for a given project. In short, I was pointing out, I think, that different people may derive the satisfaction of game development from different aspects of the process, or derive different degrees of satisfaction from various elements.

    In other words, I'm not arguing that one should only make games based on what elements are fun to make; indeed, sometimes the game calls for something boring or unpleasant (save-game functionality is a dislike of mine, for example).

    That said -- although I'll admit that this is somewhat of a tangent -- that I do very much believe in "making the game that one wants to play"; to me that helps to keep up passion, because it's a game that's more enjoyable to test, more exciting to see coming to fruition and something that one is likely to be more invested in, as well as something that one is likely to understand rather better than a project that one has little interest in. (Of course, one could argue for contract work as an exception to that; I'm referring to one's own projects.)

    @Gazza_N:
    Whether it's the deadline (I'm only a hobbyist after all - I can still eat if I fail), or the sheer problem-solving challenge of working around the set constraints, I couldn't tell you.
    I don't know about you, but I think that for me it's both: the deadline helps to motivate one, and the constraints encourage creativity.

    (Indeed, a little exercise that I indulge in from time to time is to set myself a small conceptual challenge: how might I implement an RPG on a small-screen touch device, for example.)
  • @hermantulleken: You start out realising you're going to make mistakes, instead of assuming that your first game is going to be some sort of amazing, life-altering money fountain. In fact, you kinda have to aim for a more scientific mindset - don't approach your designs/story/art for a game from the angle of "This is brilliant, I'll be a hailed as a genius" - rather figure out how to break it all and discover where you're personally weak as a creator. That's why I kinda advocate against doing only the development that you consider fun: Start out with the stuff that you hate doing, the stuff you can't figure out without smacking yourself around, otherwise you won't ever stretch yourself. There's always time to do the fun stuff later, once the shitty parts are out of the way.

    I also very strongly think that open development and making regular and easy feedback a possibility is a huge help. Maximise the experience you're exposed to, even if it isn't your own. Sure, other people can totally be wrong about your game, but they're usually not. At the very least they'll force you out of your comfort zone, which is a great help.

    @Gazza_N: Yes, this is all about time and learning efficiency. Before Game.Dev I didn't understand how insanely effective community-enabled open development is, it's not a multiplication factor on your ability to learn, it's an exponent. That's why I'm constantly arguing for more and faster prototype revelation. From everyone.

    @Thaumaturge: Take your focus on story, for instance. Why are you talking to people who don't focus on storytelling about your own storytelling? I think about game design, so does @BlackShipsFilltheSky, so that's what we're useful to talk about. Our advice is going to aim for the best game we can envisage, I really don't see how NOT starting with mechanics is supposed to help in any way: You can say "Standard adventure game mechanics" as much as you want, but you still need to define what those mean for YOUR game and then implement those well in advance of writing your actual game story or building a world. Otherwise, all you're building is general setting that can be applied to any game mechanics at all, from an adventure game to a board game to an RTS for Wiimotes. As soon as you think of a game, you're talking about mechanics. Not owning those mechanics, not implementing them the sweetest, best way you can, seems like a complete waste of time to me.

    But yes, you like story writing. Awesome. I really hope you're talking to professional writers about your stories then. This may not be the board to do it at, is all I'm saying. But when you've gleaned the wisdom of awesome writers and stolen their experience, be sure to share it here ;)
    Thanked by 1hermantulleken
  • edited
    I fear that I'm perhaps not expressing myself sufficiently clearly. :/

    Perhaps for the sake of clarity it would be a good idea for me to iterate, without supporting arguments, what I'm attempting to argue:

    First, these are the claims that I'm arguing against, as I understand them:
    * The initial claim was that it was always (for people starting out, at least) a bad idea to start with something other than mechanics.

    * Later, another claim was added (in support of the above) that (again, for people starting out, at least) one should never have any sort of "vision" or "goal" to aim for when developing a game.

    My claims, then are that:
    * It's perfectly valid to start out with a story, or an artistic goal.

    * It's also valid to have something to aim for when developing a game, be it a story to be told, or an artistic desire, or a type of mechanic that you want to try.

    Note that I'm not saying that mechanics are unimportant, or that they should be held back until halfway through development, or that one should have a full story treatment and concept art before one considers what mechanics one is going to use.
    Why are you talking to people who don't focus on storytelling about your own storytelling?
    I'm not, as far as I'm aware. o_0

    I take it that you're referring to my mention of the "detective investigating werewolves" story, and pointing out that the description could apply to stories from flash-fiction upwards?

    That was, as I recall, intended to be in answer to the claim that a story involving "a detective investigating werewolves" was necessarily too large a goal for someone inexperienced to try. I was pointing out that it needn't be a big story at all; it could be a one-room first non-tutorial Adventure Game Studio game, for example.
    You can say "Standard adventure game mechanics" as much as you want, but you still need to define what those mean for YOUR game and then implement those well in advance of writing your actual game story or building a world.
    But how do you know what mechanics to start with if you don't have so much as a concept to start from? If you have a concept, then presumably mechanics are the second element of the game that you've looked at, since the concept came first.

    Again, I'm not talking about writing out the full story, and every scrap of dialogue. I'm talking about having a concept or experience that you want to deliver, or some vision to aim for. That can be very vague, and can very much change during development.
  • edited
    @Thaumaturge: I don't care much about "valid". I think validity is an extremely poor selector for potential success, it's a trap that plays towards confirmation bias. Building a game entirely in C++ is "valid" because at least 1 person in the history of the planet has managed to do that. I care about "useful" and it's even more tricky cousin "helpful". Building a game from the ground up in C++ has a horrendous failure rate, it's actually less successful as a strategy than wishing your game would be magically built by someone else.

    How is it useful or helpful to start with a story and not a mechanic? How useful has that proven in terms of producing games locally? How helpful have developers who are currently producing games found that approach in the past, compared to other approaches?

    I think there might be confusion around terms here. Everyone has to start with an idea for a game: "Main character is actually 3 sentient artichokes!" or "Portals whose exit point depended on when you fired them!", etc. But from that idea you have to move directly to answering "What is this like to play, how do players interact with this idea?" - if you don't think about interaction, you don't have a game.

    What I'm saying is that the idea<->interaction mechanics<->test mechanics sequence is a very, VERY useful loop state to be in. And one that many hopeful developers don't seem to start in at all, preferring the much less helpful (and much, much lower success rate of) idea->fleshing out idea setting->producing idea graphics->crap now I need interaction somehow, I'll just copy how Game X did it. Note how that second progression doesn't really go backwards either, that's because that it seems like whatever mental biases lead to that sort of approach also tend to shun feedback for some reason. I don't know why that is... I'm totally okay with you going "Oh, right, well your 'idea' and my use of 'story' are the same thing" that would actually be pretty awesome :)

    Asking if you're talking to people that write awesome stories was to suggest that as a good idea. I wouldn't trust what I say about story all that much, I've only really written interest, investigation and opinion pieces professionally before - I'm not great at narrative.
  • Ah, fair enough -- I think that I agree with you on what you've outlined there; it just doesn't seem to be what was being suggested.

    I do very much agree that the second sequence that you lay out (as you point out, it isn't much of a loop) looks like a poor idea in general; what you describe first is pretty much what I was suggesting, I think.

    As to the term "valid", I think that I was using it in the sense of "sound; just; well-founded" or "producing the desired result; effective" (to quote dictionary.com), meaning something a little more than just "works, every so often". In other words, I think that it is reasonable to start that way.

    As to my talking to people who write, my mistake! I misread you there, I fear. ^^;

    I'm not sure of whether it counts, but I do post on the TV Tropes fora, including their writing sub-fora; while I don't think that there are more than a few published authors there, it does seem to be a good place to discuss writing and get feedback -- it's actually somewhat similar to this forum, at that.

    ... I'll confess that I'm still working on getting up the courage to post much about my own work there... ^^;;;
  • Thaumaturge said:
    First, these are the claims that I'm arguing against, as I understand them:
    * The initial claim was that it was always (for people starting out, at least) a bad idea to start with something other than mechanics.
    I've been pretty clear about this not being about mechanics VS story. A mechanic can be a bad goal as well. This is about armchair designing a game VS experimentation and synthesizing player feedback.
    Thaumaturge said:
    I agree that a goal that is beyond the team's reach is likely to result in a failed project. On the other hand, even failing is not necessarily a bad thing, especially if there's a supportive community available to provide advice and critique: sometimes failing is a part of learning.
    Obviously. And in fact failure is guaranteed for most developers' first few projects. Which is why testing development quickly is important. Which is exactly why not working on anything that delays testing the idea is of critical importance.

    image

    And the problem comes when effort has already been put into the story/art/gamedesign/music. It's much harder to let that go even if it's not working, which leads to polishing a turd.
    Thaumaturge said:
    As to constraints, I very much disagree with the assertion that constraints necessarily restrict creativity:
    Are you referring to something I said? I claimed that "goals" constrict creativity, not constraints. Here's the quote I think you are referring to:
    BlackShipsFilltheSky said:
    Yes, it must be possible to evaluate things, but working towards a preconceived goal (like a point and click werewolf detective) can be a massive creativity constraint
    "Constraint" here is used qualified by "creativity constraint". I never said constraints are bad, I said that preconceived goals are bad.
    Thaumaturge said:
    Additionally, how do you intend that new developers learn the amount of work involved in a game, and how to evaluate a projects, if they don't try it?
    I think I am advocating that inexperienced developers try make a game. I'm advocating experimentation first, which in practice always only makes it quicker to get to the point of trying something (rather than planning the game first and working on a lot of unplayable content before testing).

    I can't see how you got out of that that developers should not try make a game.
    Thaumaturge said:
    * It's perfectly valid to start out with a story, or an artistic goal.
    Thaumaturge said:
    As to the term "valid", I think that I was using it in the sense of "sound; just; well-founded" or "producing the desired result; effective" (to quote dictionary.com), meaning something a little more than just "works, every so often". In other words, I think that it is reasonable to start that way.
    It really depends on what you mean by "start out with a story, or an artistic goal".

    Very few games come out of pure tinkering, most games have some sort of goal. Goals aren't the problematic part anyway... it's all down to what you do with them.

    Obviously working on a game requires having some idea. But working towards that idea , instead of exploring the space and basing your production on the experience the player is having, is where things go awry.

    And that's not "valid" by your definition. That approach has a horrendous failure rate. And I've already outlined the problems this causes for inexperienced developers, which should go some distance towards explaining why the failure rate is so high, and the time it takes to fail is also so prolonged.

    This isn't about about mechanics VS story. For me this is about armchair designing a game VS experimentation and synthesizing player feedback.

    I think @Dislekcia and myself are talking about player experience. Games don't flow like books or movies, we don't have nearly as much control over how players experience our games, and treating game creation like story writing (which as far as I can tell is what you are advocating) is a bad idea.

    And it's never worse to be flexible. It's never worse to have much less loosely defined goals and to fill out the story as you discover how the player experiences your game.

    And it is only ever worse to first fill in the gamedesign/story/art and then hope the player experience reflects that.

    @hermantulleken Totally agree.


    Thanked by 1Karuji
  • I guess one thing could be argued - that Dev 1 will level up in his storywriting and plot development, setting, etc, but at the expense of not levelling up on GAME DEV and GAME MECHANICS.

    It simply isn't possible to level up in game mechanics when you're not iterating and testing them, or doing it less than doing story. Again, we have time constraints.

    I think there's a disconnect here between parties speaking past each other on this point. Of course it's ok to concentrate on story and plot - if that's the thing you really want to be awesome. But it'll be at the expense of other things, given the same restricted time you have to spend on something.
  • edited
    Tuism said:
    I guess one thing could be argued - that Dev 1 will level up in his storywriting and plot development, setting, etc, but at the expense of not levelling up on GAME DEV and GAME MECHANICS.
    I'm not sure that Dev 1 would necessarily get much better at the story writing and plot development (or game design or graphics). Because Dev 1 won't get to the point where he/she can test and evaluate most of those things.

    Dev 1 will only improve in the areas that he/she gets meaningful feedback in, and unless the player can play through all those planned elements the player cannot give feedback on them.

    Dev 1 wouldn't get zero experience in "storywriting and plot development, setting, etc" but it won't be substantive experience unless the player can play those elements.

    To get experience with story and plot Dev 1 could make a game where implementing the story is really easy, like in Dear Esther, but without the graphics. But for the purposes of that particular thought experiment I am assuming that there are some non-trivial mechanics involved in relating the story. (I guess that should have been in the diagram)

    And the same would be true of game design and art etc, if it isn't being actually tested (ideally player tested) then the experience gained is minimal.
    Tuism said:
    Of course it's ok to concentrate on story and plot - if that's the thing you really want to be awesome. But it'll be at the expense of other things, given the same restricted time you have to spend on something.
    I don't think it'll just be at the expense of other things, I think (quite often) it'll be much more wasteful than that. It has to be tested, and it's really really really hard to test a deep game story when there is no game.

    I think that's what idea<->interaction mechanics<->test mechanics really means. The value you get out of that process is directly proportional to the granularity of of the testing and your ability to incorporate the new information back into the idea. Optimizing for more testing, and trying out more ideas, and being flexible about the core idea, is going to result in the maximum benefit. (As well as it being critical that the "idea" part of that diagram is not immutable).

    I'd personally rather phrase it: idea<->implement interactive experience<->test experience because I think the term "mechanics" is being used to defeat the meaning of the diagram. (I mean "experience" here as in "player experience")

    image

  • edited
    lol... I just found on my website a graph I made in 2011.

    image

    Clearly I've been arguing this point for some time.
  • @BlackShipsFilltheSky: And I think the results of your approach speak for themselves ;)
    Dev 1 will only improve in the areas that he/she gets meaningful feedback in, and unless the player can play through all those planned elements the player cannot give feedback on them.
    This is exactly the real issue: Maximising feedback is super important, you need to have something for people to provide feedback ON.
    Thanked by 1EvanGreenwood
  • @BlackShipsFilltheSky:

    I think that Tuism is correct: we've been talking past each other, each debating points that the other isn't making. If I'm correct, then for my part in that I apologise -- I would seem to have misread your earlier points then.

    With regards to my points, I don't think that I've at all argued that one should have an immutable, fully-defined "final product" in mind to work towards. A goal can change, and needn't be something fully-formed or terribly detailed. It could be no more than "I want to make a story-based game involving mermaids", with nothing beyond that filled in. I also don't think that I've argued for starting with a significant amount of concept-work (creating concept art, a full story, etc.).

    I think that the impression that I had was that the claim was that one (or beginners, at least) should always start -- before any sort of idea or artistic inspiration, however inchoate or mutable -- with some form of mechanic.
    idea<->implement interactive experience<->test experience
    To some degree my response to this depends on what you mean here by "idea" -- do you feel that it's reasonable, as a first two iterations of a hypothetical development under that cycle, to have the following?

    Iteration 1:
    "I want to make a game that involves werewolves!" -> "what sort of game?" -> "well, I like action games -- top down werewolf hunting?" -> *implement a prototype* -> test.

    *feedback happens here. Perhaps the werewolves are too powerful, or the camera too close, and so on*

    Iteration 2:
    "Right, werewolf hunting, top down* -> *implement changes based on feedback* -> *test again*

    etc...
  • edited
    @Thaumaturge I think the process you're employing in developing To Light a Candle is naive and wasteful.

    Even without all the backstory you've planned (we all love to dream about backstory, even when we know it won't make it into the game), you've decided that the game will entail a whole bunch of mechanics that will build up a certain kind of experience, and you've been working to implement that in the hope that after implementation the experience will feel the way you intend (or at least feel good). You're going to take the feedback you receive and try use it to adjust the design to match the experience you're hoping to achieve.

    As apposed to finding an simple experience that through testing shows merit, and then experimenting to find something that adds to and improves that experience, and repeating this process until the game is a complex and rich experience (and one that you could not have predicted when the project began).

    I'd say that you are working from a position of instability that relies on god-like foresight to pull off.

    Whereas if the game's design is informed by and built upon proven enjoyable experiences, the designer would be working from a position of stability and certainty.

    So I think when you write:
    idea<->implement interactive experience<->test experience
    You imagine that process differently to me.

    I think you're still picturing it as a top-down process where the idea informs the design, whereas I'm describing a bottom up process where the existing experience informs the design.
  • edited
    [edit 1] Ugh, that ended up rather longer than I'd hoped; bear with me please, editing for length... [/edit 1]

    [edit 2] Okay, it's shorter. Sorry about that; I tend to be somewhat verbose, and I suspect that -- somewhat ironically -- my rather small screen and my not paying enough attention led to the post seeming to be shorter than it was. [/edit 2]

    [edit 3] Yes, it was longer than what's below, I believe; I have a number of points that I want to make in response. Sorry again. [/edit 3]

    To start with, there are perhaps a few things worth noting with regards to To Light a Candle specifically:

    The main point, I suppose, is that it was under development well before I signed up here, and that the design changed several times during development before my first post. For example, at one point I wanted to use a spell system in the style of Ultima Underworld, with a set of semantic atoms that one used to compose a "sentence": a fireball might be cast by using the runes for "project" and "fire", while a poison dart might be "project" plus "poison". It's a system that I really like, and hope to include in a game at some stage.

    However, I ended up concluding that To Light a Candle wasn't the game for it; it didn't fit there, and so was removed.

    You say that I've decided to include certain mechanics; that's true of a few, largely vague mechanical desires (I want it to be a game centred around exploration, somewhat metroidvania-ish, I want something more in the style of an adventure game than an action game and I want to include magic; given where I am now, I want to stick with the 2D side-scrolling perspective), but I'm very much open to new ideas regarding the actual mechanics. For example, I'm very much open to reconsidering the spell system.

    With regards to backstory: what I've outlined is very brief and bare-bones by my standards of story. (Not to mention that at least some of it was drawn from a previous game, as I recall.)

    On your approach in general, I think that the problem that I have with it is that I sincerely doubt that it would likely work with the way that my mind and creativity work. I strongly suspect -- based on experience -- that attempting to build a game that way would result in lots of prototypes being made and never finished.

    For me, mechanics are a means to an end; they are to my games as, perhaps, elements like lighting, perspective and so on are to my visual arts, or writing style is to a story: the tools with which I create what I'm trying to create.

    I suppose that settings, stories and "experiences" are what excite me in a game; consider that my first love in genres to play is adventure (such as Gabriel Knight, or The Longest Journey), followed by RPG (story-heavy for preference, rather than action-RPG). Just having a bare mechanic in front of me might be fun for a short while, but seems likely to become boring rather quickly.

    In short, I don't believe that your system would likely work for me. I do believe that it works for you, but I strongly suspect that our minds simply don't work in the same manner; what works for you won't necessarily work for me.

    Going back to "mechanics as means to an end", I'm having trouble seeing how your approach might fit with the development of games that don't have gameplay as their focus. May a developer not want to create a game that conveys something -- an element of human experience, or a vision of the future, or whatever -- and then look for a game to support that? How does one apply your system to making adventure games? Is one required to introduce some new mechanic to each and every adventure game, and then build around that? Or should one pick a set of extant adventure mechanics and then only look for games that fit into those?
  • edited
    To be clear when I say:
    finding an simple experience that through testing shows merit, and then experimenting to find something that adds to and improves that experience, and repeating this process until the game is a complex and rich experience
    I don't mean a mechanic necessarily. I literally mean an experience. That could be a story, or a setting, or a visual that is conveyed to the player. The point is that it is conveyed and testable.

    (I've stressed this several times in this thread already. Tuism was talking about mechanics specifically. I never was).

    A story can be conveyed and tested. Visuals and animations can be conveyed and tested. And so can mechanics. The critical thing is that in our heads these things result in an imagined experience for the player, and, if we don't have a ton of development experience, odds are that the players' actual experience is quite different.

    So if we design games based on our assumptions we're going to end up delivering shitty experiences (unless we are omniscient).
    - that attempting to build a game that way would result in lots of prototypes being made and never finished.
    Yes! That's exactly the point. Bad ideas get thrown away much much faster, instead of being invested into far past the point that they're already unworkable, due to the creator believing that the idea of the game has value (despite the game and the idea of the game being irreconcilable).

    People are naturally averse to throwing stuff away... and this goes for bad ideas as well.

    That's exactly what I meant when I said that a top down approach is "wasteful". That prototypes don't get thrown away enough in top down approaches. Whereas bottom up approaches find flaws in the experience (be it in the story or the mechanics) much faster, and the creator is not as attached to a imaginary idea of the game, because they are concentrating on what the game actually is, so they are able to throw it away.

    Everyone loves cooking up game designs in their armchairs. Of course it is fun writing backstories and imagining experiences deep into the game. You're not alone in that. That's perfectly normal.

    But that's designing games based on assumptions. Implementation of any idea, be it art or story or a piece of gameplay, always turns out to be different in reality to the way we imagine it (unless you've implemented it before). And that's because games are incredibly complex, and if you're making a new game then the experience you've imagined will be affected by countless interactions you cannot predict.

    I've been doing this long enough, and have come up short enough times, to know just how wrong my assumptions usually are. And I don't think I'm special in that regard.

    And so a bottom up approach, where story/art/gameplay decisions are made based on the existing game and its feedback, instead of on assumptions of what the final product will be, is far better at achieving innovative/interesting results and consistently enjoyable experiences.







  • edited
    I strongly suspect -- based on experience -- that attempting to build a game that way would result in lots of prototypes being made and never finished.
    Yes. That's exactly the point. Eventually you'll find one prototype that simply has to be finished, something that, if you're not working on it, leaves your soul burning and empty. And that's a good thing too: Rather than being a waste, those prototypes allow you to stretch yourself as a creator (how would you practice writing, other than writing short stories - not novels) AND give you inspiration and possibly gameplay tools for other projects in the future. The larger your unfinished prototype pool, the more likely you are to reimagine a concept in one of them in a new setting and it'll just fit this time around, when maybe it didn't before.

    Look, I get what you're saying and I was wondering if the disconnect might not be based on the type of games you two feel you want to make, but then I realised that even a modern adventure game needs to have some sort of mechanical difference to it. How else will it succeed when the genre is having problems otherwise, if it doesn't have some neat mechanic that drives the entire game at a molecular level? That innovation could be around AI, it might be making an interface that allows 2D adventure games to work on console controllers (I'm looking at you, Ultimate Quest), it might be something to do with sound processing or even a graphical technique that allows a different kind of expression visually. But building a full game will always need a mechanical hook. Otherwise why are you building the thing instead of doing the unique element you're looking to create, the story, via some existing system through modding?
Sign In or Register to comment.