Stuff you should just read.

edited in Tutorials


  • And then click on the links in the article too.
  • Thanks for the reminder - been meaning to follow him on Twitter for ages. Love that blog.
  • edited
    It's a good article.

    But there was a bit at the start that bugged me.
    We often know what we need to do next. Instead of just doing it, we get into a long-winded philosophical argument, tangential discussions about directions that we definitely are not going to go in, or bury our faces in Google trying to find everything that there is to know about this particular decision before we just, 99% of the time, finally get around to doing what we were going to do in the first place, in the same way that we were going to do it in the first place.
    This could also be an argument to make snap decisions, which is a sure way to guarantee less creativity.

    Obviously in the context he's talking about developers doing make-work and procrastinating. But I think a long-winded philosophical discussion is a great way to give the brain time to search for more innovative ideas. But that discussion should have a defined end, when implementation begins. Discussions are also important to make sure other team-mates didn't already have a better solution than you.

    Procrastinating is bad though, and I do do too much of it. But occasionally that procrastination comes from genuine discomfort that the work being done isn't understood and better options haven't been sought. And occasionally produces a better outcome (when performed under the right circumstances).

    Though most often procrastination is just procrastination. I'd have to concede.

    [Edit] I can't really identify with the "bury our faces in Google trying to find everything that there is to know about this particular decision" but I can identify with erroneously trying to use my brain as an emulator.
  • Cool read...inspired me to hack something together instead of over thinking it shortly after I read it. :)

    @BlackShipsFilltheSky, I usually start procrastinating when I'm stumped...when I don't know how to do something and I don't even know where to begin on how to implement a solution. I've found that discussions are a great way to stop procrastinating. Most of the time just talking about the problem makes me think of another "solution" I can try. Basically...I need a rubber ducky to do things properly. :P
  • edited
    @Rigormortis Yeah, I find a bit of empathy from others often helps me just doing the thing I fear and seeing how it turns out. Often I feel like other people are relying on me (for the piece of work I'm doing), and so I need to know they essentially agree with me on whatever the decision is.
  • The forum helps, but nothing is better than having someone to actually talk to when you're stuck. That's why teams are needed... man, which is a tough one for some of us :P
    Thanked by 1TheFuntastic
  • Out of interest, in my experience, the best sources of creativity have come through just making something, and then showing someone. When there's nothing, it's difficult to talk about, and difficult to be inspired, kind of like how a blank canvas can be so terrifying. But once you have something down, anything, a sketch, a page of thumbnails, even some abstract shapes, then there's something to talk about, and there's a spark for creative discussion; and then if we involve other people we may be taken down routes we didn't expect.

    And really -- and I'm super guilty of this -- I think we're just generally all too familiar with talking about how cool it'd be to make some game, or what a great idea something might be, and not sit down and just make the damn thing and test it. I think, if anything, it's more likely that people think too long about an abstract thing that hasn't been proven through doing, than that they make snap decisions...

    @Rigormortis: Heh. I've had that pretty often. I don't know how to do something, and ask @MattBenic or @Chippit, and at the end of asking the question I know what to do before they've said anything. :D But had I not asked, it may have taken me way longer to figure out.
    Thanked by 1hanli
  • @Elyaradine, it's interesting. I've heard people talk about the blank page before and understood what they meant, but because I don't really have a writing/art(ing?) background I've never really tried to see where it might apply to me.

    When I read your comment it clicked that sitting down to build something(in code) that I haven't done before evokes the same emotions. Hopefully being more aware of it will help not falling prey to it so often. :)
    Thanked by 1hanli
  • edited
    @Elyaradine Oh! I certainly wasn't talking about discussions about pipe dreams. I meant discussions about what should be done next in the project, how something should be implemented, or how does the team feel about certain symbolism. And carrying certain questions around with you, instead of immediately trying to solve them.

    e.g. Do we make alien eggs terrain (so that they can be rolled around and manipulated to spew facehuggers directly at unsuspecting terrorists/friends) ... Or do we make them decorations (so that you can walk past them but cannot roll them). Originally I hadn't even contemplated making alien eggs terrain (because Ripley always walks amongst them), but then I talked to @Merrik about it and the much cooler emergent possibilities of having them as terrain emerged out of that conversation... so I'm going to try that approach first and see how it feels.

    But yes... in this example the real decision is going to happen AFTER the alien eggs have been implemented one way. We'll have some evidence of the experience the idea actually produced, and we'll have some idea of the gamut of possibilities the idea could have resulted in and we'll be able to compare the results against that (and maybe experiment with it the other way if it doesn't feel good).

    [Edit] In all honesty I really do agree with the spirit of that article. I think I was being disagreeable because I'm busy thinking of ways to post-pone decision making (and post-pone implementation) to maximize creativity in long-term projects without negatively affecting productivity or communication to end-users. It's actually a different subject.
  • [quote = BlackShipsFilltheSky]But yes... the real discussion is going to happen AFTER the alien eggs have been implemented one way.[/quote]

    Such a crucial thing. It's really hard to carry a conversation about how to implement stuff without having at least one possibility already done(even if it's hacked together). If there is nothing to point at and say why it does or doesn't work the best conclusion you can come up with is usually "I don't know". Which is a terrible feeling if you've spent an hour or two discussing something.

    Which is kind off what the author of the articles is talking about I guess. Talking for hours/reading stuff for hours and then going and implementing something the way you would have implemented it in any case is sort off pointless. It's better to implement something shoddy/quickly, then use that as a focal point for discussion or analysis and decide on a course of action for the next iteration.
  • I have actually read somewhere that there is a psychological reward for talking about something cool that gives you (on a much lower scale, obviously) a similar feeling to actually making the something-cool. That little bit of reward is often enough to kill further motivation to actually do the thing.

    I don't know if it is the particular work I normally do, but I often feel there just is not enough time to investigate things properly... you _have_ to just get going. And therefor I miss being able to do that very much (university was a good place for this to happen)...
  • edited
    I have actually read somewhere that there is a psychological reward for talking about something cool that gives you (on a much lower scale, obviously) a similar feeling to actually making the something-cool. That little bit of reward is often enough to kill further motivation to actually do the thing.
    That makes sense. But that's a pretty darn hard thing to optimize around. I'm going to have to think about that some more.

    Also, probably another reason why writing design docs is a terrible idea.
  • Also, a reason why playing Game Dev Story is satisfying. At all :)
  • I touched on that in my talk about failure. The study was about jogging, how people who thought about the end goal (getting fit) were far more likely to quit than the people who were told to focus on the empowering feeling of jogging (the activity itself).

    A perhaps even more amazing experiment is one where they had children drawing. The ones drawing for reward stopped pretty soon, whereas the ones who were drawing for fun had to be stopped. I think the same applies to Game Dev. If you take a gleeful enjoyment out of it the act of genesis it's going to be impossible to not make a large volume of work along the way and get good at it in the process.

    Myself personally I often find working on my own games an anxious and nerve wracking process. I put it down to the fact I'm seeking reward - in this case personal validation that I am talented and a creative person. How to disable that inhibition is something I'm still very much trying to figure out. I do think I'm starting to win ( my own internal ) war but its a very incremental process.
  • edited
    @TheFuntastic Chris Hecker did a rather great talk at GDC a few years back, though I think the difference between endogenous and exogenous rewards is somewhat different from the psychology of talking about a process fulfilling a partial role of the endogenous reward.
  • edited
    @Kariju... how about internal and external :P (Edit:
  • I've just realized this is why I think debates about are games art are tosh: games being art serves as validation for the artists ( in this case the developer ). Same goes for the is it a game debate. None of those criteria have any business messing with your right to create something people can engage with.

    @karuji thanks will check it out.
  • @TheFuntastic I suppose it would be a bit easier if I just gave you a link

    @hermantulleken I like 'big' words; I think more people should use more 'big' words! How else are we supposed to learn words. Going through life using only the same words is boring!
  • (Sorry for temporary derailment @Karuji Maybe... I floccinaucinihilipilificate big words.)
    Thanked by 1Karuji
  • Soooo many i's :D
  • "endogenous" is a silly word.

  • This article pretty much triggered an epiphany (sorry Herman :P) on my side.

    Y'see, I'm a self-taught coder with no formal comp-sci education, and I'm generally far more conscious of what I don't know than what I do. I'm also moving over to Unity from GM, which is quite the paradigm shift. As a result, lately I've spent ungodly amounts of time working out HOW to do things instead of just knuckling down and doing them. Somewhere along the line I decided that I needed to know ALL THE THINGS before I could make a game effectively. I was going to be a Real Programmer (without using butterflies).

    Boy do I know some neat functions now, but I still haven't released a game prototype built in Unity.

    This is hilarious, because when I first started out with GM I pretty much hacked things out until they did what I wanted, learning along the way. I can't even look at my first GM game's code (remember Overseer Assault?) without cringing, but man, it worked. Barely. Somehow. Even came second in a competition, to my tremendous surprise. Point is, I learned by making the game and referring to documentation on demand instead of poring through tutorials and manuals for weeks to determine the super best optimal solutions available to me. Those came as I built more games. A lot more games. More than I have lately.

    I'm not advocating a total lack of planning or research, obviously. Pulling a Leeroy Jenkins and rushing in blindly is just as much a recipe for frustration and quick project death. But hopelessly overcomplicating things and getting stuck in analysis paralysis? Yeah. Guilty as charged.

    Time to fix that.
    Thanked by 1EvanGreenwood
  • edited
    I think a lot of game developers go through a dip in productivity (hopefully it's a dip, not a downward slope) after the point where they sort of know how to do things and then sort of expect the next things they do to be much better than the previous things they did...

    And they get stuck for a while, thinking they can really do things now, but being too afraid to do things (because actually what they are doing doesn't easily match up to their expectations).

    Which is a problem that article mentioned...

    And it's hard.

    Some of the wonder of just getting things working is lost... and then just getting things working isn't motivating... and then just getting things working just doesn't happen as often as it should.

    And recapturing that wonder is hard.

    Or so I've found.
  • That dip hits me pretty hard. Usually because I come into something with too many expectations of how awesome the resulting game is going to be, instead of just playing and seeing where it goes.

    Happens at game jams all the time. Felt like it ruined the 2011 GGJ in many ways.
    Thanked by 1EvanGreenwood
  • edited
    @Herman I was looking up that concept you mentioned... about the psychological reward of discussing something with others and how that can harm motivation.

    It looks like it is a fairly substantial effect. It's probably an even worse effect when the product you are making doesn't live up to the discussion you had (that must feel something like embarrassment, like promising someone a ride in your Ferrari and then discovering you drive a Fiesta).

    That produces an interesting problem to try solve in teams.
Sign In or Register to comment.