Extra Credits: "So you want to be an Indie"

edited in General
Watch this, watch this now: So you Want to be an Indie

Comments

  • So I went into it thinking it's one of those reaction pieces to Fish's explosion - and I was completely wrong :) Even though that was touched on (Phil needed more parts to his machinery), it wasn't the point at all.

    Those 4 points at the end really sums it up really really well!
  • This is pretty much what we've been preaching from the outset.
    The Extra Credits guys really do a good job of presenting all the points/pitfalls that we talk about :)
  • I'm surprised that "early feedback" or "don't work in secret" didn't make the list.

    And I don't think that mechanics always trump content. Indie horror games don't have that focus for instance.

    I think mechanics trumping content is nearly always true, and sacrificing mechanics for content is always going to be bad, but I think there are outliers where the content is the main appeal.
  • Hm? They said to start testing as soon as you can, there was a good section dedicated to that - that's the same as "early feedback" right?
  • edited
    Oh yeah, they mentioned it at the end. But it was part of "Mechanics Trump Content". I'm saying it deserves far more prominence and explanation.

    Working in secret is an insta nail in the coffin (I think). And not just because your mechanics might turn out to be frustrating or unappealing.

    But in general I don't like "Mechanics Trump Content" as a blanket for ALL indie development. It seems a very 2011 way of looking at indie development, when the only way to be seriously successful seemed to be make a game where the mechanics were the appeal (like Braid or Super Meat Boy or Minecraft). There are other ways to be successful now.
  • The "Mechanics Trumps Content" comment means for Comp D I need to get more game states like rails and ramps in before I add more tricks! *busies himself with more work*
  • edited
    ... Well, that was terrifying. : /

    (... The video, not Andre's comment. I-I'm not scared of your game states! :P)

    In particular, the PR, marketing, taxation and legal sides are elements that I'm not at all confident about -- and I fear that I don't have much money with which to hire people to handle them for me.

    I'm hardly giving up, but that was... not encouraging. : /
  • @Thaumaturge I think all those things in the video are things to be concerned about if you are trying to development indie games professionally...

    But the first step is still making a good game. The lawyer stuff is easier than you think (Hint: LexAquillia is a damn good lawyer and human being who can help you).

    Taxation only matters once you have a good enough game to start a company and pay people, or start to turn a profit.

    PR only matters once you have a good enough game.

    So focus on that. Be open with your development and listen to input and advice. Ask questions about what people think your next move should be.

    You'll know you need to start getting the business stuff right when strangers start saying: I want to buy this thing.

    And like Extra Credits said. If you don't have a lot of experience, focus on getting that first. Make a small enough game that you can finish it, learn from the mistakes and repeat.
  • I understand what you mean, I believe -- but the thing is that I do want to sell my games, I do want to do this professionally.

    As to the lawyer stuff, I'm less worried about dealing with lawyers than about paying them -- money's pretty tight for me as it is. Once To Light a Candle is far enough along that I'm comfortable with starting a crowdfunding campaign on IndieGoGo (I primarily want to get to the point at which I can make a decent-looking video of the gameplay) then I might start getting somewhere with that, but IndieGoGo campaigns don't seem to attract as much money as Kickstarter campaigns and there are other expenses -- art and music in particular -- that are likely to drain what money I do get form that (presuming that I get anything, of course).

    You do make a good point about elements like PR and marketing only becoming relevant once one has a game to which to apply them... but looking ahead isn't entirely unwise either, it seems to me: after all, if one sees an obstacle coming, one has more time in which to so something about it.

    I do have some ideas regarding marketing, basically amounting to keeping my eyes open for relevant sites -- for example I have it in mind to send press releases and review copies to indie game sites and The Escapist, and likely others besides to be identified later, and perhaps to send a free copy off to the people behind The Yogscast (although I don't yet know whether they'd be receptive to that).

    Right now I am focussing on the game -- but as much as worrying about things while they're beyond one's reach may be unproductive, blinkering oneself to potential dangers doesn't make them go away, either. : /

    *sigh* I'm a little tense at the moment, so I'm not sure of how the above came out; for the sake of clarifying my tone and intent, I don't mean any of the above as vitriol against you or your advice. I'm grateful for your advice -- thank you. ^_^
  • @Thaumaturge Nah, you didn't come across as dismissive.

    The next bit I'm going to write might be discouraging. Possibly worse than the Extra Creditz video. But I'd feel bad not responding.

    I do worry a little bit that you're determined to spend a lot of time, right through to crowd-funding and commercial release, on what is, as far as I can tell, your first game.

    In my own experience, in my game development career, I didn't achieve anything close to that success with my first few games. It took me 4 years to turn a profit. Though of course you might be luckier, or more savvy, or more skilled than I was, or just have a much better game idea than any of my early ideas.

    What I'm trying to say is that my impression of most indie game developers journeys is that they are littered with early failures. And if that is the case, then, if you are an inexperienced indie game developer, then you want to optimize your time so that you fail quickly and learn fast. Getting to the point where you can succeed as fast as possible (instead of spending a ton of time working on doomed projects) should be your goal.

    I know this is discouraging to hear. And I don't mean to be telling you to give up on "To Light A Candle". I think there's a genuinely interesting premise for a game there.

    But if you're motivated by making money, and working on your first project, usually that's a warning sign that you need to reframe your objectives.

    I'd love to be able to tell my early self to focus less on producing a sellable product but instead to make lots of little game ideas quickly. I think I'd be better as a game designer today if I had optimized that time better. I might have gotten to the point of actually selling something a bit quicker.

    On the flip side there was at least one project that I gave up on too soon and should have released for free instead. I was focused on making money, and thought that I wouldn't make money if I released, but I didn't see the value in releasing it purely as a learning experience.

    So giving up before releasing a playable, even a free one, is also something that can be a mistake.

    The main thing I want to encourage is getting your game into the hands of players.

    You've already taken a big positive step in the direction of success by posting on forums and communicating with other game developers. The next step is following that up with communicating with players of your game.

    Make that your joy and your purpose. Money and lawyers and all that are nice to dream about, but that's a shitty goal. Get people playing your game(s). Figure out what you can improve, and take pleasure from them responding positively. Players love to see improvement in a game they've played, and it's a positive loop to get into.

    Players might also make criticisms of what you're doing. Listening to them is by far the best way to learn, and the fact that they've taken time to write anything at all to you means that they see some potential.

    And so keep improving you game(s), and get better at pleasing players, and then one day they're going to want to give you money for the experience.

    You aren't doing that with "To Light A Candle" as far as I can tell. Maybe the game is incredibly fun to play, but it might not be, and until someone plays it besides yourself you won't be able to know if there is potential there or not.

    Worrying about whether or not you're going to make money before you know whether people enjoy playing your game is very premature.

    It seems to me that you might also be falling into what is a very common pitfall. Get you game into the hands of players ASAP!

    I might be reading the situation wrong, but if I'm reading the situation right then these are probably some very tough words to hear.

    I'm sorry if this makes you more tense. But I'd be very happy if this moved you towards getting players playing "To Light A Candle" sooner, and moves you towards succeeding at all your dreams faster. (That's what I like to think MakeGamesSA is all about).

    If this hasn't been constructive criticism I'll shut up.
    Thanked by 3Tuism LexAquillia GMax
  • edited
    I think that you're probably partially correct. Don't worry about making me tense: I'd much rather have an unpleasant truth than a comforting lie, I believe, so I'm grateful to you for sharing your thoughts with me -- again, thank you.

    My current focus with To Light a Candle -- my short-term goal -- is, as suggested in its thread, to create a playable demo level to show here for feedback. There's more yet to be done for that, but it's getting there, I think. It looks as though it will be horribly, horribly buggy when that early demo is made available (I still have some annoying path-finding issues that I don't intend to look at for this demo, for example), but it should be largely playable, at least.

    I'll confess that I've been tempted to put down this project -- which I recognise as a big one -- for one or another newer, smaller project. The problem there is that I have a history of putting down personal projects when I've hit some sort of wall and then never picking them up again; the main exception perhaps being competition entries, which enforce a deadline. Sometimes elements get remixed into new games, but that doesn't break the cycle of not finishing the games themselves. So, when I started what was to become To Light a Candle, I recall that I decided that I wasn't allowing myself to put it down.

    I've relaxed that a little as time has gone by -- in fact I'll likely soon start a new thread for a little game that I recently began work on -- but all such are strictly side-projects, with To Light a Candle as my main focus.

    As to experience, for what it's worth, I did spend about three years as a programmer in a small local game development company, including titles that saw release, as I recall. I've also created a fair few small prototypes and games over the years, albeit few to any degree of polish or completeness (as mentioned above). What I'll admit that I don't think that I've done is released any games of my own to the general public.

    I realise that it may seem that it's the money that's motivating me here, but I don't think that it is. To some degree I suppose that I'm looking at having a commercial release as an achievement, but that's a goal in itself, regardless of whether it makes much actual money. Perhaps more importantly to me, I want my game development to become self-sustaining, and want to be able to hire people to handle the elements in which I feel that I'm weak (I believe that I have very little facility with music, for example). I suppose that I see money as more an obstacle than a goal.

    I'm not in this for the money, I believe.

    (For one thing, if I were motivated primarily by money I'd likely choose a genre of game with broader appeal -- a first-person shooter or RPG, perhaps.)

    (I'm not sure that those preceding three paragraphs came out terribly well -- I'll confess to being somewhat tired and drained at the moment, albeit largely for other reasons that those that we're discussing. ^^; )
    Thanked by 1GMax
  • @BlackShipsFilltheSky
    Working in secret is an insta nail in the coffin (I think). And not just because your mechanics might turn out to be frustrating or unappealing.
    A year ago I think I would have disagreed with this statement (actually I am sure I would have and I am just a sure I would have been wrong to do so). Well to be specific the distinction between working openly with a community or working in isolation with a small closed group. I am warming to the idea or to be more specific I am growing more comfortable with it. Bit of a 180 from 13 years ago, but to be fair (to myself) the internet was just a baby and online communities well there were few if any.

    There are a few things I have seen that make working openly with a community can do.

    1) Early chance to see how your game plays and how much "fun" it might be.
    2) Of course feedback about your game and how to make it nicer.
    3) A chance to spread the word earlier which if you game is good enough could lead to opportunities.

    The one thing I can also see that's a little less tangible but makes a difference to me is energy. The only thing worse then showing off your hard work and getting a negative response is getting none at all. At least a negative response can be constructive. No response just saps your will to carry on.

    We will be bringing our projects here more often because of this.
  • I'm not getting a lot of response for my game but I concede that's due to the awkward need for a controller to be involved and that I haven't got AI yet....... But yeah I totally agree that getting little to no response can be very energy sapping...

    What does that mean, don't make games that need complex AI to start with? >_<
  • @Tuism your game AI giving you hassled or am I misunderstanding? We got plenty controllers here from Toxic Bunny testing but not sure they work with Gamemakers games I saw the hassles you had getting the controller working at the community night. Will give it a spin and see if it works with them.
  • @tbulford yeah I'm having trouble with AI... It's really my first foray into AI and stuff, and to be honest I'm needin to work out a whole pile of awareness and reactions and whatever... And that's making my head explode >_< (Note that my experience with GM has only been a year in hobby time and I'm not a developer naturally XD)

    And yeah that was a bad first showing with the controllers thing, it must have turned people off from it. I have heard that some people have just plugged and played without issues so I think it might not be a big hassle. In any case I *WILL* have my own machine set up soon.

    And I did tweak the control options a bit so I'll upload a new build soon. With slightly better presentation and collectibles (but I'm not focusing on anything but AI at the moment)
  • I kinda feel like "mechanics trumps content" is really useful - often new devs get all excited to make content that doesn't interact with or inform mechanics in any way. Think of all the time you spent on backstory of game concept X when you were starting out and how little impact it actually had, despite being awesome fun to work on.

    Content that interacts with your mechanics is always better. To make that, you have to know what your mechanics are, hence mechanics needing to - at the very least - come first. Or be the primary subject of your explorations.

    @Tuism: If people aren't playing your game, ask why, then fix the bottlenecks. I think you've got a good handle on the things preventing people trying your game at the moment, you've actually worked around that really well with your videos of gameplay. Keep releasing more of those as you mess with it :) People will eventually play it - but do realise that multiplayer games do limit their audience a bit.
    Thanked by 2Tuism GMax
  • @Tuism - I am without a doubt a fan of your game. Battle Blocks is awesome!! You'll get the AI sorted soon, so don't give up.

    @BlackShipsFilltheSky - your advice above seems really valid and important. I think it is great that this community has so many heavyweight Indies that are willing to give advice to start ups. All we have to do is listen to the advice given.

    @dislekcia - can't you get (read suggest to) @nandrew to get more involved on this forum. I know he has in the past written in his NAG collumn about the importance of mechanic over content. I think he would be able to give some solid advice on this topic, which will also be valuable to the Noobs like myself.
    Thanked by 1Tuism
  • @Tuism I have been considering AI options for Battle Blocks since you showed it to us. Keen to chat/explore your current thoughts at the next MGSA JHB meet.
  • @FanieG: I'll tell him you're asking :)
  • edited
    @dislekcia @FanieG Yeah, definitely starting out Mechanics Trump Content. I'd never advise starting on a story first or something like that.

    I guess I didn't read that into the Extra Creditz advice, but it probably was there. I read it as "A rough looking/sounding game that is crafted well mechanically is always better than a beautiful looking/sounding game where the mechanics are rough". I don't think that is always true in 2013.

    I don't think Mechanics Trump Content in a game like The Light http://steamcommunity.com/sharedfiles/filedetails/?id=97293280 or Dream http://steamcommunity.com/sharedfiles/filedetails/?id=92647949 or Routine http://www.routinegame.com/

    And these sorts of games are becoming more popular and more numerous.
    Thanked by 1GMax
  • @BlackShipsFilltheSky - It could be argued that in both those games the content is the mechanic. Maybe i'm just over thinking it. For me the main reason to try harder getting the balance between mechanic and content right is simple - replayability. If story is the main focus you limit your player, because he/she might feel there is no reason to return to the game after it has been finished once. If the game feels good, i'll play again. If there is the possibility to find something new 2nd time around, i'll play again. The trick is to get that balance right I guess, but for new devs/hobbyist - go for mechanic. It makes your projects more focused, which will mean there is a better chance of actually producing a finished product.
  • edited
    FanieG said:
    It could be argued that in both those games the content is the mechanic.
    lol :) By that logic everything good in games is mechanics, so why even make the statement "Mechanics Trump Content". Why not just say: "Don't waste time on things that can't help your game right now".

    But I don't think that's what "Mechanics Trump Content" means. I don't think I'm reading it wrong in that Extra Creditz is valuing gameplay over content. Which is ideal obviously for potential indie devs that want to build gameplay driven games (like Broforce), but not ideal for indie devs who have a legitimate path to build a content driven game (like Dear Esther or even possibly Stasis).

    Limiting the scope of the game was in a previous point by Extra Creditz. I'm all for that. But I don't think that new indie devs, or devs entering the indie scene from AAA (which Extra Creditz mentions as part of the audience for the talk), necessarily need to hear "Mechanics Trumps Content". I think that was true in 2010, and still true for most cases in 2013, but not all cases in 2013.
    BlackShipsFilltheSky said:
    I think mechanics trumping content is nearly always true, and sacrificing mechanics for content is always going to be bad, but I think there are outliers where the content is the main appeal.
    Deslekcia said:
    Content that interacts with your mechanics is always better. To make that, you have to know what your mechanics are, hence mechanics needing to - at the very least - come first. Or be the primary subject of your explorations.
    This is not mutually exclusive with saying "Mechanics Don't Always Trump Content". Or are you saying that Dear Esther's creator Robert Briscoe only achieved Dear Esther because mechanics were the primary focus of his explorations.

    Let's be friendly to artists and musicians please. I feel like Mechanics Trump Content devalues their work, and that is not the culture I want for Make Games.
  • @BlackShipsFilltheSky,

    I agree with you but have come to think of it in terms of focus. You should decide early(ish) in your development what the game's focus will be and make damn sure that that thing is spectacular. It could be mechanics(Minecraft, no story(sort of)) or story(Final Fantasy 8, crap mechanics) or something like atmosphere/ambience(Proteus, no real story/mechanics(arguably)).

    The one thing that I think sort of validates the mechanics trump content is that it seems(to me at least) an easier thing to create. Especially if your scope is small. Also, I think mechanics provide more bang for your back in terms development time. So in terms of a studio that's starting out and is probably limited by budget and have a small time frame to be successful(ish) in, it seems like solid advice.

    PS. Sorry for all the brackets...()()()() :)
    Thanked by 1GMax
  • @Rigormortis - Thanks for putting so elegantly what I was trying to get across in my previous comment. Mechanic should be the focus for smaller teams, start ups or hobbyists. That focus is important to ensure you actually finish a product. Learn to do one thing at a time.

    @BlackShipsFilltheSky - my statement was in no way meant to take anything away from any artist/muso etc. I was thinking of content more in the line of "side quests", collectables, customizable character etc. Also, speaking as a 1 person hobbyist not a development team, who can more easily focus on the extras (content), wheras it would be safer for 1 person to focus on the mechanic without all the bells and whistles. Sorry if my comment came of as "Dissing" anyone. That was not the intention
  • edited
    I just want to say a really really really really heartfelt THANK YOU to you guys (@FanieG, @tbulford, @dislekcia and everyone else commenting and having played it) for supporting Battle Blocks (working title), I just realised that despite my really slow progress, I really should be sharing it more with the world... There are some stuff that I really should be updating so as to not be devving in isolation, so an update will be forthcoming :D

    Thanks so much guys :')

    (sorry for derailing the the thread...)

    And I absolutely believe in mechanic trumping content, I think even if there's amazing content without mechanic, won't you essentially end up with a huge ass slide show?
  • I think even if there's amazing content without mechanic, won't you essentially end up with a huge ass slide show?
    And if it's a damn good experience, and I enjoy myself, then I don't give a damn if it is one. :P
  • Absolutely fair enough, I guess where games and movies and music and books are bleeding into each other, there's no prescription for enjoyment. But wouldn't the way that slideshow bring you joy and an amazing experience be considered "mechanic"? Like, the mechanic of a movie to make you pay for it is... Well, those formulas. Script, effects, stars, etc etc. Right?
  • If I may chime in quickly here, I'd just like to say that my favourite, and/or most memorable, things in games have come from the content side. I'm not much of a mechanics player :) The world of Unreal 1, or simply running around the city in Assassins Creed. The sound-scape of Quake and HL or the world of STALKER. I get far more from these elements than the mechanics themselves ;)

    That said, I think that it absolutely makes sense, and will make you a better designer, if you focus on mechanics first :) A content heavy project is most definitely a very demanding beast. Also, I agree with @Rigormortis; Figure out what your games core is, and do it well!
    Thanked by 1GMax
  • edited
    lol. Not sure if I commented on Battle Blocks, I did play it a while back and we had a bit of discussion at the office about it (I think @raithza was particularly impressed). I'm not sure if I commented in the thread. At that stage it wasn't two player, I think. We'll be giving it a try again once it allows for two players on controllers.

    btw. I assume you've played this (although your game is different of course). If not it might have some interesting ideas you could use:
    BlackShipsFilltheSky said:
    I think mechanics trumping content is nearly always true, and sacrificing mechanics for content is always going to be bad, but I think there are outliers where the content is the main appeal.
    Look guys, I understand the usefulness of learning to implement mechanics. When I started I 100% focused on mechanical driven design. I wanted to be a game designer and make successful indie games, which at that stage were all mechanically driven.

    I made lots of prototypes and small games which are littered about the South African forums. I've given lectures on getting into game development that have espoused learning mechanics through prototyping and game jams.

    I'm 100% not arguing that you guys are doing it wrong.

    What I'm saying is that while focusing on mechanics before content is well suited for game designer/programmers, not every person who gets into indie game development is entering it in order to be a designer/programmer.

    In particular tools like UDK are making it possible for artists to craft almost entirely content/art focused games, and there is a rapidly growing audience for that. Look at the list of Greenlit games on Steam.

    There are a lot of ways to start game development. For most people, and certainly most people at Make Games SA, that means practicing mechanics first.

    But we aren't all destined to be designer/programmers, we don't all want to be, so lets please not tell people that that is the only way get into making games.

    Yes let's talk about limiting scope and focusing on that person's strengths, and talk about things that can be implemented immediately instead of pipe dreams that require 12 person teams. Let's talk about iterating and improving and mastering the skills we require to achieve our goals.

    But lets not deny the existence of avenues that don't suit us personally. Doing so makes it harder to help those who have different strengths and goals to us.

    We're having a hard enough time getting artists / sound designers onto this forum as it is, and the "Mechanics Trump Content" by extension suggests that game development is only available to those who work as a programmer/designer, or those who are reliant on programmer/designers. It places artists and sound designers as secondary citizens, and that's not cool, and it's unnecessary.

    There is no way of knowing how many artists and sound designers are simply not participating at all here because they see no way to give input without being at the whim of one of the existing members. It might be none, but it might be a few. Which sucks, it just isn't necessary in 2013.
    BlackShipsFilltheSky said:
    I think mechanics trumping content is nearly always true, and sacrificing mechanics for content is always going to be bad, but I think there are outliers where the content is the main appeal.
    Thanked by 2Tuism GMax
  • edited
    @blackshipsfillthesky YES INDEED I did play that, eerily enough I had been working on my game a fair bit (sketches and planning) before seeing it on steam. Then I was like... HAVE I SEEN THIS OR HAVEN'T I SEEN THIS BEFORE?!?! I can't tell anymore, and yeah it's gonna look pretty damn similar when it's done... Oh well so what :) The way I'm taking my game's in a very different direction, I can certainly tell :)

    I guess I needed to communicate it properly - it was never NOT two players - it was one on mouse another on controller, I can probably quite easily change that to two players both on controllers, but I figured it was hard enough to get one controller for most test candidates XD I'll certainly have that option available by the time next meetup rolls around and bring two controllers to see the feedback on the control scheme :)

    ---------------------

    Incidentally I utterly agree with what you're saying. A lot of the time we miss the forest for the trees, and it's absolutely better to focus on mechanics instead of getting tied up with story and art and whatever. And of course those specialists will bemoan that claim (I'm an artist myself, I'm devving only cos... I have to XD), but at the end of the day we're here to make games. And the game should come first.

    What I've learned in my own making of stuff is that while graphics make people go "oooh that's nice", without the gameplay underneath it, the interest fades pretty fast until/unless something "mechanical" grabs interest.

    But enough about that, I think :)
  • edited
    [quote=@dislekcia]Content that interacts with your mechanics is always better. To make that, you have to know what your mechanics are, hence mechanics needing to - at the very least - come first. Or be the primary subject of your explorations.
    This is not mutually exclusive with saying "Mechanics Don't Always Trump Content". Or are you saying that Dear Esther's creator Robert Briscoe only achieved Dear Esther because mechanics were the primary focus of his explorations.[/quote]

    Well, yes. Actually, very yes. The levels in Dear Esther are expressly built around gameplay elements like the player not being able to jump and how fast the player moves to create a sense of timing as story elements are revealed. The levels are all built from the perspective of the player and where that player will be, the game uses all sorts of tricks to make it feel as lush and beautiful as it does - you're not just wandering around an entire island and happening to pick good paths. Turn on noclip and you can see how all the content is built around the game's mechanics (as minimal as those are).
    Let's be friendly to artists and musicians please. I feel like Mechanics Trump Content devalues their work, and that is not the culture I want for Make Games.
    And I'm not trying to be unfriendly to artists and musicians, or whoever it is that the straw man you think I'm setting up is supposed to be aimed at. I'm just saying something that any skilled artist already knows - for a work to be coherent, it needs to be built around a focus. The core point of saying "mechanics trumps content" is to try and steer inexperienced people away from paths that are less successful: How often does a new creator in any field literally just create themselves into a position where they have a wealth of concepts/ideas/worldbuilding/backstory/musical rules/history/physics/engine code that actually ends up drowning them in fluff? I used to do that. I'd write tons of backstory and draw endless maps for every concept I came up with and none of it ever did anything but suffocate those projects.

    In part I did it because that's what I felt I could do. Everything else was hard to learn and would take more time. It's only once I got my focus zeroed in for me by someone else handing me a project to make better, that I started making progress and practicing the hard things I'd been using wild content creation to avoid learning. Nothing in what I've said is exclusive to making games - it's a process that's echoed in every creative medium and skillset.

    "Mechanics trumps content" isn't a stricture to strangle those who enjoy art, it's a guideline to help newbies find a path that's more likely to lead to learning and, maybe one day, success. I don't see it as something that needs to be told to experienced artists trying to build games around their art skills, partly because they probably understand the idea of focus already. But mostly because they're already good at their art, so if they wanted to build a game, they're probably already focusing on how to turn their art into game-like experiences anyway instead of floundering around creating noise for the sake of feeling like they're doing something.

    If anyone feels alienated by that concept or that their existing skills are being looked down on, don't worry: Do what works best for you, just make sure you keep evaluating your progress.

    -Edit-

    Oh, I see that we were posting at the same time, heh ;) Um, generally we're talking about the same stuff, I think there's a misconception that "mechanics" means programming. It doesn't, it just means interaction. That's why you're feeling that talking about mechanics is exclusionary - I don't think it is because I'm not talking about programming when I say it.

    Extra Creditz are using their previously defined MDA definitions:

    Yeah, mechanics are the "lowest" rung of the player experience, so it's usually more technical in nature, but it's where the entire MDA concept starts, which is probably why they're talking about it in those terms.
    Thanked by 1GMax
  • edited
    Dislkecia said:
    "Mechanics trumps content" isn't a stricture to strangle those who enjoy art, it's a guideline to help newbies find a path that's more likely to lead to learning and, maybe one day, success. I don't see it as something that needs to be told to experienced artists trying to build games around their art skills, partly because they probably understand the idea of focus already.
    So why when I say "Mechanics don't always trump content" you say "No" and then say "I don't see it as something that needs to be told to experienced artists trying to build games around their art skills, partly because they probably understand the idea of focus already." ?

    That's agreeing if I'm not mistaken.

    Extra Creditz mentions that indie games cannot compete on polish and scale. He is warning against putting a lot of love into the content, like that cannot work. But Dear Esther definitely competes on polish, and its scale even in its early incarnation was substantial.

    Sure it doesn't play badly, but I never said that focusing on content required the mechanics to be badly designed, or have no attention paid to them. If I'm not mistaken that is a straw man you've argued against.
    BlackShipsFilltheSky said:
    I think mechanics trumping content is nearly always true, and sacrificing mechanics for content is always going to be bad, but I think there are outliers where the content is the main appeal.
    Dislekcia said:
    And I'm not trying to be unfriendly to artists and musicians, or whoever it is that the straw man you think I'm setting up is supposed to be aimed at.
    BlackShipFilltheSky said:
    Let's be friendly to artists and musicians please. I feel like Mechanics Trump Content devalues their work, and that is not the culture I want for Make Games.
    I don't think that is a straw man. Telling people that "Mechanics Trump Content" is definitely devaluing the work of content creators. The language used states it pretty precisely.

    But I didn't say that @Dislekcia was telling people that "Mechanics Trump Content", I was referring to the video. "Mechanics Trump Content" aren't your words. I certainly didn't try to make a personal attack.
    Thanked by 1hanli
  • edited
    Sorry, but where did I ever say "No"?

    I'm simply a firm believer in not trying to undermine a helpful message. Yes, being aware of edge-cases is useful, but the important part of that, the "being aware" part applies equally to knowing who you're talking to.

    If I'm talking to young, inexperienced hopeful game developers, I'm going to try to point them at the statistically least likely to fail routes to make a game. Sure, being aware of other routes is great, but if those routes are often copied and regularly failed, they're not the best places to send young developers.

    If, however, I'm talking to people who want to build the most amazing content-based games, I'll tell them to get good at producing that content first, then come back to games once they're masters.

    If I don't know who I'm talking to, I err on the side of suggesting mechanics should be built and tested before they're covered in content - purely because having mechanics first is never a BAD thing, it doesn't discourage great content later. But having great content first actively hinders building mechanics later - either through discouraging mechanics that require content to be recreated or through precluding certain mechanics entirely due to assumptions made because they'd produce interesting content (focusing on a 3D world and shoe-horning in jumping puzzles, for instance).

    If you start with a book, you still have to build the game. If you've got a painting, you still have to figure out how it could be playable. The important point here is that what most often happens is people who are building tons of content AREN'T trying to build that content, they're trying to build a game and actively not getting there despite putting in tons of effort. They have to, at some point, focus on mechanics to do that. It's not like writing hordes of backstory is going to help me produce a book either...

    And yes, everything I said above COULD be done the other way around and result in a great game, but that's not the most likely outcome. I'm coming at this from the perspective of not doing harm first, which is why I don't understand why you think I'm saying anything that devalues content skills in any way. Where is that coming from? (If you tell me, I can see about changing how I'm saying stuff to prevent that misconception)
  • edited
    Nah, I do mean mechanics as in interactions. Derp.

    I genuinely don't believe that if you are starting indie game development you absolutely have to first focus on mechanics.

    That certainly wasn't the case in Dear Esther. He certainly got a character walking around (which is free in Source and in UDK and Unity) and got some very rudimentary interactions working and then focused for literally years on content.

    The appeal of that game would not have been apparent at the start. It could have only been apparent whether he could find success with this game once he had a whole lot of the content roughly in place.

    And if the content had been mediocre then it wouldn't have mattered how classy his walking mechanics were.

    I really don't think it needs arguing that in the case of Dear Esther (and games which have similarly low amounts of iterations or complexities of interactions) content trumps mechanics.

    Actually, now that I mention mediocre mechanics. Dear Esther had mediocre mechanics that bugged out. The drowning mechanic was confusingly implemented, it didn't always work as expected as it had poorly placed hitboxes. And I lost an half hour's playing when it bugged out.

    But that didn't really matter to the appeal of the game.
    BlackShipsFilltheSky said:
    I think mechanics trumping content is nearly always true, and sacrificing mechanics for content is always going to be bad, but I think there are outliers where the content is the main appeal.
    BlackShipsFilltheSky said:
    But in general I don't like "Mechanics Trump Content" as a blanket for ALL indie development.
    That is what I wrote at the start.
    Dislekcia said:
    And yes, everything I said above COULD be done the other way around and result in a great game, but that's not the most likely outcome.
    I certainly never said that inappropriate advice should be given. Do you really think that?

    I don't think you are actually using the same definition of "content" as extra credits. You talk about things like:
    Dislekcia said:
    I'd write tons of backstory and draw endless maps for every concept I came up with and none of it ever did anything but suffocate those projects.
    That's not the content Extra Creditz is referring to, that's pipedreaming. Extra Credits specifically mentions building lots of maps to pad a game where the mechanics are meh (which is obviously a bad idea).

    And yes, I totally agree that the bigger a game gets the larger the emotional and technical overhead in altering the design. In fact I think I gave the "start with small games and get things playable and iterate advice" yesterday to Thaumaturge in this very thread.

    I think I was pretty clear in stating different advice should be given to different people contextually.

    And in the case where the subject is being addressed to a large group, but there are outliers, my suggestions would be acknowledging the outliers (even if discussing them isn't within the scope of the present subject).

    But within this discussion on these forums it definitely is within the scope to talk about outliers, or their absence in a video. Arguing against acknowledging edge cases seems to me to be a bizarre stance to take in an argument.

  • edited
    Whoa whoa whoa! I just had a thought, I think:

    In the very beginning, it is 90% more likely that a mechanics based approach will yield a positive response to a game being built and prototyped. Can we agree with that?

    Sure the Dear Esther's of the world exist, but are they the 10% or the 90%?

    Thus it's more prudent to advise with the most likely scenario than the edge case in mind.

    Also:

    In a prototype, it should be 90% game and 10% polish, otherwise "players" hear that they're going to play a "game" but instead they see art, or words, or renders, instead of... A game.

    So... Yes the other routes to a game exist, but it does seem to me for
    1) prototyping purposes, and
    2) advising as many people while maximizing the chance as outlined by previous experience/data

    Mechanics trump content. While edge cases should still be catered for. Is that right? :)
    Thanked by 1EvanGreenwood
  • hmmm....

    Actually, I don't think @Dislekcia really took that point... Just both of us were phrasing our responses as disagreements and actually talking about different things.

    Well me certainly. I don't disagree with anything @Dislekcia wrote. I just disagree with him (in my mind) using mostly unrelated post to (in my mind) disagree with me.

    I guess we both must be stressed O_O
    Thanked by 1hanli
  • edited
    @Tuism Lol. Yes.

    I'd like to think edge cases could be mentioned, and discussed in places where there is the scope to discuss them.

    I think that we are in an excitingly evolving indie landscape right now where indie developers can feasibly produce heavy content based games. This hasn't been the case until recently, and I'd predict that their presence will be more prominent in the future.

    I still really don't like the language of "Mechanics Trump Content". It devalues the role of content producers. Can we rather rephrase that?

    Even "Mechanics Before Content" would be an improvement, and I think might be more accurate.
    Thanked by 1GMax
  • @BlackShipsFilltheSky - or "Mechanics Lead to Content"
    Thanked by 1GMax
  • edited
    I think the point of disagreement is whether anything here devalues the role of content producers or not. I really don't feel like anything said here actually has, in fact, part of what I was talking about earlier is that skilled content producers are focused enough to be able to see when their content is going to produce a game or a book/movie/comic/album and act accordingly to change that. It's only people who are new at both that need the guideline.

    That said, I kinda hate always acknowledging edge-cases when talking about advice. 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.

    So I feel that general advice specifically designed to minimise the role of luck in game development probably shouldn't be auto-harpooned by re-introducing successes that obscure the role of luck in their development. That said, forums are probably the place to be discussing HOW those edge cases managed to do well, so that at least the people who want to use them to ignore advice have other evaluation criteria to replace the ones they're dismissing. (So, let's talk about HOW Dear Esther did well and if that's something that's repeatable or luck-based)

    I also feel that dismissing the content spinning that I was talking about as pipe dreaming is a little overboard - yes, that's exactly what content without mechanics to hold it together is. We both think it's bad, but it's not immediately obvious to newbies why that's the case. So how should we discourage pipe dreaming?
  • edited
    Just a few observations from my side. I agree with most of what has been said, and think that some talking at cross purposes is taking place. I am not contradicting anyone, just trying to reiterate and expand a bit on some of the points that have already been made.

    I think that 'aesthetic', 'content', 'art' and 'polish' are being conflated at some points.

    The MDA model runs in two directions - depending on the individual case. It outlines the players experience of the game, and the developers experience of the game, and examines how these intersect.
    The development process should then be approached to maximise the impact of the intersection, and tailored towards the express intention of the game.
    Is your game about an aesthetic response you you want to raise in your players? Are you trying to evoke a specific dynamic, or explore a specific mechanic? Then the MDA process takes this element as its starting point.

    Also, as Danny highlighted, Mechanics is not programming - it is a PART of the interaction framework, and aesthetic is often misinterpreted as the 'look' of the game, or the 'story' of the game where it is in fact INEXTRICABLY linked to the mechanics and dynamics as it is actually the psychological/emotional response elicited through the experience and interaction with the art object. (there is quite a lot written about aesthetics and the process of aesthetic activation. The most interesting for our purposes is the work done by the Russian Formalists. (if anyone is interested, I could talk about this for hours) Sensory pleasure - the look of the thing - is only ONE possible aesthetic, as is narrative pleasure.

    "Interaction", or the experience of the game, would then be composed of Mechanics, Dynamics, AND Aesthetics.

    The extra credits video on Aesthetics is really great, but for the whole MDA thing, I have linked the original 2004 paper: http://www.cs.northwestern.edu/~hunicke/MDA.pdf
    It's an easy read, and really worth it.

    As already discussed, Aesthetic is not only 'content', but content comprises some elements of what can be analysed as aesthetic. And there, it should not only be about story or art or sound, but rather about the thematic underpinning of the work, which is then realised through the sensory arts. And polish isn't about any of these things, but rather just about final execution.

    An issue that confuses things is the phrase 'content producers' which artificially creates hierarchy. A situation which is not possible, or desirable, in indi dev. (The implicit hierarchy here is that the 'we' build the real thing, and 'you' just fill it with pretty stuff = content. Or even, 'we' build the real thing, 'you' just write the fluff = content. This is a symptom of the larger creative industries, and has to do with the nomenclature surrounding it. Something I feel should be actively challenged) This underplays the role of the sensory, fantasy, and narrative aesthetics in the production of meaning in the work, and overemphasises the challenge aesthetic. While this can be done, it is only desirable in very specific situations, exactly like an overemphasis of sensory or narrative aesthetic is only desirable in specific situations. In each of these cases, shifting the emphasis on the kind of aesthetic experience desired MUST be accompanied by a corresponding shift in the mechanics.

    This is not the content EC is talking about either. They are talking about adding 'moar stuff(tm)' By more content, they seem to mean expanding content by expanding range of mechanics, play time, levels, and, yes - the sensory arts. There point, as I read it, was about getting the core experience working, without expanding unnecessarily.

    The focus, in my view, (and in both Danny and Evan's if I'm reading them correctly, but phrased differently in each case) should then be on the quality and execution of the entire interaction framework (M, D and A) over the production of an unnecessarily inflated interaction framework (as a whole, or in one of the areas).

    So - I think 'mechanics over content' (EC's line) could be better framed as 'Tight interaction framework over moar stuffs' but it doesn't quite have the same ring to it.

    What this does, is enable the separation of the idea of "content = more stuff" from the idea of "content = sensory or narrative pleasure and thematic underpinnings". Which removes the hierarchical concerns from the equation.

    The 'pipe dreaming' would, in my view, not be a content issue but a scope issue. How do you distil the scope of that pipe dream (the lots of stuff) to the core content (thematic) that you need to support the interaction model you have decided on?


    Thanked by 1Bensonance
  • edited
    @hanli said:
    So - I think 'mechanics over content' (EC's line) could be better framed as 'Tight interaction framework over moar stuffs' but it doesn't quite have the same ring to it.

    What this does, is enable the separation of the idea of "content = more stuff" from the idea of "content = sensory or narrative pleasure and thematic underpinnings". Which removes the hierarchical concerns from the equation.

    The 'pipe dreaming' would, in my view, not be a content issue but a scope issue. How do you distil the scope of that pipe dream (the lots of stuff) to the core content (thematic) that you need to support the interaction model you have decided on?
    Very well put :) I think that separation is a very important concept.
  • Thanks Danny. I'm a bit preoccupied with this at the moment, my lecture next Tuesday is on MDA, can you tell? :P
    I've re-worked to include the extra credits video now :)
  • I'll confess that I've skimmed a few of the posts since my last -- quite a bit has been said! ^^;;

    That admitted, I think that I agree with Hanli's description, and suggest a slightly different "mantra": "Core over more". I don't agree with discouraging aesthetically-focussed games (or mechanically focussed games, or other sorts besides) -- and I don't think that that's what the makers of Extra Credits were likely trying to convey. I do agree with the idea of making your core game first -- whether that means getting the atmosphere right in a horror game, or the physics right in a puzzle-platformer, or whatever is appropriate -- and worrying about how many levels there are later.

    As to edge-cases, while I agree that they are dangerous to pursue, I really don't like the idea of teaching that they should never be pursued. Even if the intention is that such lessons be only for beginners, I worry about those inclined to pursue such edge-cases either being put off, or taking the lesson to heart and not returning to those edge-case designs; I worry that such a lesson might reduce the frequency of successful edge-cases, and so reduce the diversity of indie games. (For the sake of clarity, I'll note I don't think that it would likely eliminate edge-case designs altogether, but fear that it will make implementations of them -- successful or otherwise -- rarer.)

    Instead, I think that I'd rather start with Dislekcia's suggestion of discussion such cases, and then build a school of teaching that educates new developers not only on the relative success rates, but also on what those successful edge-cases did well. I'll admit that I'm not sure how that might be fitted into attention-grabbing axioms, which I suspect tend to have a significantly high rate of uptake.
    Thanked by 1hanli
Sign In or Register to comment.