Every so often, I see discussions about how to build and maintain a design schedule as a freelance/hobby designer. A lot of that advice doesn't work for me, so I thought I would take the time to discuss a different approach. At the end of the day there is no right way; there is only what works for you.
First off, I avoid a lot of activities in the design community that don't mesh well with my creative work flow. For example, a lot of time is spent in design communities on brainstorming design ideas. I am very selective about brainstorming. I usually try to only have three designs in progress at one time. If I have three in progress, I avoid brainstorming new ideas or any other similar activity that might result in a new design. My goal is to conserve my creative energy for the games I have in progress. When I do brainstorm, I usually spend some time quietly mulling over areas of design and/or themes that interest me until something sparks an idea. My version of group brainstorming would look more like a debate about mechanisms rather than throwing out a bunch of generic categories to see what sticks. While it may seem odd, my driving goal is to not get new ideas very often.
If I do get an idea 'out of season,' I write it down, possibly even making a quick rough prototype, as soon as possible. I want any new ideas out of my head right away. I put these aside for when I have room for them. Usually I revisit promising ideas when waiting to hear back from a publisher on a design that's mostly finished. Then I shelve the new design again when I start working on revisions for the game with the publisher. The best way to stop working on an idea is to write it down.
Similarly, I don't like game jams. I have a pretty specific process for generating ideas that focuses on emotions and themes I want to explore. Game jams are largely mechanics- and components-driven. Plus if I do end up with a good idea, it takes up creative space in my brain that I may not want to give it. I like some aspects of game jams, but I don't seek them out. If you aren't interested in design on demand, it's ok to skip game jams.
Side note, along with brainstorming and game jams, I tend to avoid forum posts asking for thematic input on someone else's games. I will gladly give feedback on a game I have played. However, the brain space required to imagine the problem and then come up with a solution is not something I'm usually willing to do on social media. I don't want to deplete my creative energy, especially in a format where my feedback is less useful since I don't have all the context I need. I do respond if it's a problem I have wrestled with in my own designs, because I can respond from a shared experience perspective. I never respond to posts asking for help with names.
Some people like contests because the deadlines help guide the creation process. I only enter contests if I have something in my queue already that seems like it would be a good fit. (Sometimes, that is just an idea of a game depending on the submission rules about how long the game is allowed to have been developed.) Mostly, contests have very specific rules about what type of games they are looking for. Given that I'm only ever working on three games at a time, I'm not very likely to have something for a contest. And as previously stated, I may not have room to add another game. The other reason I don't submit to contests is that, in my observation, contest judges expect more polished looking games than publishers do. I would rather spend time perfecting the rules and experience of gameplay than the graphic design. Plus, publishing pays more. One of the reasons people suggest entering contests is to be active and visible in the design community, but in my experience you can skip contests and get involved in other ways if contests aren't your thing.
Speaking of contests, some deadlines are what I call 'good deadlines' and some are 'bad deadlines.' Good deadlines propel your design forward in a productive way. Bad deadlines result in rushed work or a creativity block or just too much stress. For me, most contests and game jams are bad deadlines; most conventions and playtest nights are good deadlines. I like the accountability of showing progress to playtesters more than the need to have a finished product by a certain time.
So far I've been outlining activities I avoid in my design cycles. My weekly schedule (as of the pandemic) is one day writing for this blog, four to five working on existing projects, and one to two days off. Time dedicated to design looks like solo playtesting, designing components in Affinity, building physical prototypes, learning TTS, researching a theme, researching games with similar themes or mechanics, researching publishers, and making sell sheets and videos. I very much consider research and learning new software parts of the design process. I generally consider non-solo playtests as taking place outside of my regular design schedule. What I do on a given day depends on where I'm at in the process. However, all of that goes out the window when I'm finishing something up for a publisher. During crunch time for a deadline, I skip the writing day and the days off and just work through until I have what I need to send to the publisher (usually this is an updated prototype).
Part of the reasoning behind my regular design schedule is avoiding creative burnout. I find that alternating language-based tasks and visuals-based tasks helps me maintain a more regular schedule. The reason this blog updates so frequently is that I need to work on something design adjacent that is purely language-based in order to not get fatigued when working on my games. Alternatively, I use rulebook writing as a break from the more visual aspects of design.
Creating time for your existing projects and working on them sustainably is the only way to finish anything. Finishing one project will teach you more than beginning a hundred projects. I manage this by avoiding spending my creativity on things that aren't my main projects and alternating my work to engage my brain in different ways.
No comments:
Post a Comment