On game design goals
I was having a conversation with @Elyaradine tonight where the topic of game design goals came up.
I found myself mirroring this advice Hunter S. Thompson gave about finding purpose in life: http://yourfriendshouse.com/uncategorised/hunter-s-thompson-on-finding-your-purpose/
In that I think that goals are best shaped to your game, rather than the game being shaped to your goals. I think knowing your game, like how Hunter advocates knowing yourself, is the basis for good decision making about the avenues that should be explored. I think it's very easy to assume planning ahead will allow you to discover the best path, but I think this often results in us trying to imitate the successes of others rather than finding the unique opportunities before us.
Apologies if this is a bit philosophical and not especially practical. I intended to share the link with @Elyaradine, but then thought one or two others might be curious.
I found myself mirroring this advice Hunter S. Thompson gave about finding purpose in life: http://yourfriendshouse.com/uncategorised/hunter-s-thompson-on-finding-your-purpose/
In that I think that goals are best shaped to your game, rather than the game being shaped to your goals. I think knowing your game, like how Hunter advocates knowing yourself, is the basis for good decision making about the avenues that should be explored. I think it's very easy to assume planning ahead will allow you to discover the best path, but I think this often results in us trying to imitate the successes of others rather than finding the unique opportunities before us.
Apologies if this is a bit philosophical and not especially practical. I intended to share the link with @Elyaradine, but then thought one or two others might be curious.
Thanked by 9bischonator Sash NickCuthbert Elyaradine Kobusvdwalt9 pieter francoisvn Squidcor Boysano
Comments
I think you need some goals in mind and a solid sense of the core experience you're trying to convey, but those need to be flexible enough to adjust as you explore the design space, to the point of being willing to completely change course or scrap the game idea if necessary.
I also think that without some solid goals in mind up front, you can potentially dither about a lot. Or arrive at a sub-optimal local minima on the design space.
To explain that last sentence for folks who aren't familiar with the jargon - think of the design space as a landscape. You can arrive at the top of a small hill, decide that this the highest point/best design in the area and plant your flag there, but a better design/higher hill may be achievable by going back down the hill and further on a bit. You may need to go back down the hill/make the game worse/tear out things in order to make it much better in the long run, but it can be hard to make that decision/see the need for that without a decently strong sense of what you think the game should be/goals.
The tricky part, of course, is deciding whether the idea is dud or whether you just need to roll back a bit. And whether rolling back/changing direction is sensible vs when it's just endless puttering.
I think the badness of goals only really comes about when you stick to something that is suboptimal because it fulfills the goal you had previously, or carry on too long along a path because there's a social punishment for changing goals, or demoralize yourself because of becoming emotionally attached to a previous vision of the outcomes.
Having a "Non-Stick Plan" like Tom Francis outlines solves this in the context of designing games. In reality the way I plan works almost exactly like this, but it takes a lot of self-discipline on my part to stop myself from becoming invested in plans (so I'm far more concerned with resisting planning than planning itself). I think planning is the easy part, sometimes it's really hard to avoid planning, sometimes impossible, and so making the plan(s) less sticky is the part that I need to work at.
I think the non-stick plan is quite compatible with what Hunter was talking about (when translated into game design planning). Not aimlessness, but goals that are useful and always based on the best information available rather than being defined by external ambitions or absent information.
To be fair though, Tom Francis is speaking from a different position to me. He is the sole designer on his games, his goals don't come with the weight of coordinating other people who are also setting up their own goals. There are a lot of extra difficulties with goals that happen in team situations, so in this regard my situation is somewhat different to Tom's (and yours for that matter @garethf). I think that I probably should be more wary of goals than Tom Francis, or at least have to do more work to keep them flexible, as there is more pressure on me to form goals and stick to them because of working in a team.
I do worry that developers might think that they're following a non-stick plan, when in fact they've become stuck on a suboptimal plan (I guess I'm talking inclusively of slightly more generalized development goals again here). A plan offers certainty, and deciding something is a bad path is often based on a lot of uncertainty (like you say, that's the hard part).
How do we put checks in place to avoid getting stuck?
Like I said, I don't have much experience, so I can't offer much in the way of suggestions, there. I'd imagine starting with rapidly prototyping a variety of ideas and then pursuing the ones the entire team feels excited about, as you've talked about, is likely the best way to go about it. Only do some non-stick planning once you have a decent feel for what's exciting about the core game, and even then follow the rapid prototype/willing to drop it if it doesn't work approach with the things you plan.
This is a very personal or subjective process, understanding yourself and how you (and the team you influence) deliver results most optimally. What I have learnt from managing people in the past years, is that each one is motivated differently and has their own personal views and goals, which make this all the more challenging and interesting. Then what is even more surprising is that it many times is more difficult to see (or admit) our own strengths / weaknesses or know what we are really passionate about. I blame this mostly on "not giving ourselves the time to really get invested, while also being able to throw away what we did invest in, as long as we keep the learning of the process".
I find in life and especially anything that can be classified as a project (after the idea phase), has 3 sticky points which can be difficult to overcome.
1. Ideas are easy, but taking ACTION is not. Probably due to known future commitment required.
2. Level of COMPLEXITY POINT. There is a point (usually at end of prototype) where adding another feature make the effort and risk much larger, due to interlinked or integration complexity.
3. MOTIVATION until you go past your CEILING (or burst the BUBBLE) of your definition of success. These days that means social popularity. The point where you feel you forgot why you where so passionate about this, people are starting to be critical, or you do not have enough traction for your idea. Many times people give up here on their vision, when they are so close to the feedback they need.
Then even if you manage all these 3, many times just as things start to SCALE,
there are unforeseen setback which few people seem to recover from, since they are already stretched thin.
Would be interesting to hear of you agree or disagree, and feel there are other important sticky points when if comes to successful game development, and project phases of game development?
But I think there is at least one other sticky point I'd add to @Boysano's list of attributes of any project that makes choosing the right path difficult. That of the sunken cost. Kind of a point of no return (to frame it like @Boysano's points).
In that changing course often requires discarding work. No-one likes discarding work, and it's especially painful discarding other peoples' work. It's EVEN MORE difficult when it's difficult to judge whether the new path is better, which is nearly always the case.
I think this can apply to life as well. It's hard to change careers for instance. Sometimes it might be best to reskill as a different role or even into a completely different field, but devaluing the past investment in skills, and possibly starting again a lot more junior, is incredibly daunting.
I'm still curious about having checks in place to avoid getting stuck on poor paths, in projects, and where it applies, in life.
One obvious way is avoiding the traditional design document. We do have a "design doc" for Broforce. It is still called "RAMBROS! Design Doc" and is 154 pages long with mostly outdated information about ideas that will never make it into the game (and many that weren't any good to begin with). The game is our design doc, but we do record ideas when we have them and stick them in a place that nobody ever refers to. Also we apparently never delete anything from the document.
I know Adriaan de Jongh spoke out at the closing of his studio about how the Dutch game development community didn't give them the feedback they needed to avoid failure on a couple of Game Oven's projects:
http://gamasutra.com/blogs/AdriaanDeJongh/20150527/244437/Closing_Game_Oven_numbers_and_struggles.php
(The bit I'm referring to is half way down under "A critical note on the Dutch game industry". A bit after that he also writes about reconciling differing goals of team members, which is another goal related challenge).
So much of the difficulty in games is evaluating your choices, as the big ones are very complicated and counter-intuitive. Having a community to help provide perspective is important in my opinion and Adriaan's.
But is our community, which is comparable to the Dutch one in scale, any better at providing insight on which to base our expectations?