Favorite Story Features

For this month’s story craft post, I’m going to go highly subjective. Out of curiosity, I spent a couple of hours last week breaking down my own favorite stories (my favorite books, games, movies, etc) and looking for the common threads that ran through all of them. I certainly found a few consistent factors, including several which I didn’t necessarily expect. Your mileage may vary, but here’s what makes me personally fall in love with a story:

  1. An accessible surface; a deep, complex, nuanced core.
    1. Most of my favorite stories have made themselves appear accessible on the surface – a standard sci-fi game, a standard shounen anime, a standard small-town murder mystery, etc – but with a deeper, and usually darker, core. They intentionally foster approachable first impressions to draw people in. They don’t necessarily lie about what they are, but they keep their secrets close until you get to know them better. This gradual unfolding is immersive, surprising, and ends up becoming addictive – what will happen next? As expectations fall away, so do “rules” and predictability.
    2. This deeper core usually revolves around themes that comprise the soul of the work.
  2. Memorable, “rule of cool” characters with realistic psychology.
    1. My favorite characters bring in elements from the most exaggerated genre fiction – unique vibes, tragic backstories, odd features, immense talents, unusual names, exaggerated speaking styles, amazing powers, etc – alongside grounded psychological elements from literary fiction – motives, needs, wants, fears, hopes, complex relationships, inner conflicts, strengths, flaws, contradictions, etc. Combining the fantastical and realistic creates characters who transcend mundane humanity – becoming memorable and iconic – while remaining so achingly human.
    2. These characters have psychologically realistic growth arcs that tie into the story’s themes. Each character often has their own sub-theme, as well.
  3. A distaste for expectation.
    1. This doesn’t mean being satire (far from it), but it does mean flipping tropes around to different angles, combining or using them in unconventional ways, or eschewing common genre tropes entirely.
    2. My favorite stories have some element of surprise – twists, gimmicks, “gasp” moments. Many of them end with a “clincher” – a final twist or shocking moment – instead of a clean resolution arc.
    3. This also applies to concepts like, and especially of, gender. None of my favorite stories have ever entirely accepted gender as a flat, unexplored binary. Some have actually veered into borderline problematic territory, while others handled these themes deftly, but none have blindly accepted the notion of the binary and its roles. When the binary is questioned, even a little, characters instantly become more free and alive.
  4. Sweet, soft moments contrasted by wrenching disasters.
    1. My favorite stories aren’t afraid to toe the line of melodrama, without ever quite crossing over it. Stories should be cathartic – felt in the body, mind, and soul – and they embrace this. In doing so, they include unflinchingly sweet moments between characters and showcase the beauty of their people and worlds. They invite readers (and players, viewers, etc) to sink in and fall in love. They also include moments of brutality, sorrow, shock. They aren’t afraid of diving into the strange and horrific. They are less concerned with being realistic than they are with evoking an emotional reaction. The contrast between joy and horror creates “flashbulb memories” that stick with audiences and keep them coming back for closure.
    2. These stories aim for satisfaction. They don’t time-skip over the most dramatic or impactful moments, even if they take place in resolutions.
    3. “Flashbulb” moments should incorporate – and tie together – the plot, characters, world, and themes. The best of them even take advantage of language in a literary sense.
    4. My favorite stories tend to use tenderness and introspection during “relief” moments, rather than humor.
    5. Often, their endings are bittersweet.
  5. Moments of wonder.
    1. My favorite stories, if even for a moment, invoke wonder. This can be done through character, setting, plot, or even literary language, but most often, comes when one or more of these elements combine with theme. If they all combine with theme, the resonance is stronger still.
    2. To evoke wonder, the story must not be afraid to address the unknown – and often, to leave aspects of the unknown just as unknown at the end of the story. They embrace curiosity, uncertainty, awe, fear, joy, sorrow, life, death, the human, and the divine. They seek to transcend the story world’s own mundanity.
    3. Such stories reach for the sublime. Even if they can’t quite stare it down, they glimpse it. Even if they can’t quite hold on to it, they touch it. They find the magic in the mundane – either literally or metaphorically.
    4. There is often a haunting tone to these stories at their core, both during and after their ending. They carry a certain bittersweet taste. However, that doesn’t mean they don’t also show the simple joy of existence.
  6. Mixed genre classifications.
    1. Most of my favorite stories don’t fit entirely into just one genre – after all, neither does life. My favorites use genres as tools, not limitations.
    2. These stories also often mix elements from the genre fiction and literary fiction umbrellas (as seen in the contrasts present in the other points).

What common threads have you caught running through your own favorite stories? Do any of my factors resonate with you?

Clocked In

Hey all, I’m going to start off this year’s tip posts with a simple technique that’s so far helped me keep my own writing habit resolutions.

For 2019, I resolved to work (as in write, edit, outline, or market) for at least two, two-hour-long sessions each weekday. This way, I’m putting proper part-time work hours into my writing. The hardest part of this has been making the mindset shift. The best way to make that shift? Actually treating my writing career like any other job.

In order to keep myself accountable and get myself into the head space for work, I’ve been using a clock in app whenever I sit down at my desk. A quick search on any app store will lead to many apps to choose from, but I personally like Clock Punch, as it works well for just one person and lets me track what I’m focusing on for each shift. This way, I can set individual hourly goals for certain tasks when the need arises.

When I report to work, I act just as I would if I were at a salaried position. While clocked in, I don’t allow myself to check social media, play games, or do anything else I wouldn’t do if I had a manager to report to. I still do have one, in fact – my manager is myself. Anything outside of writing can wait.

After all, I’m on the clock.

If you give this technique a try yourself, let me know how it goes! What are your writing resolutions this year? Have you found any tools that help you make them happen?

Glass’ First Demo is Live!

GlassThumbIt’s been a long time coming, and this post is super late, but the first demo for Glass, my full-length RPG in progress, has been out in the world for the last couple of months!

There have been some frustrations, such as a stubborn occasional crashing bug that I haven’t yet been able to fix, and a lack of time to iterate as often as I’d like to, but it’s been a rewarding process so far. Glass is a story I’ve been working on in various forms for quite a while – it’s great to actually be able to share at least the first few hours of it. As much as I love traditional storytelling, and all of its unique strengths, there is something special about inviting players to explore an interactive world of your creation.

Glass (Demo 1.1) is available now and I’d love to hear what you think about the game so far!



One topic that comes up a lot during discussions of game design is the value, or potential lack thereof, of the Game Design Document. This living document, which can be used to guide and define the design of a game during both its planning and production phases, is a tool used by most major game studios, but it’s usefulness to a solo developer or small indie or academic team is more debatable. What exactly this document should contain is another point for debate.

So, what exactly is found in the usual GDD? That varies. This document, essentially an outline of a game project, is often tailored to fit the project and studio using it, but for those unfamiliar with the concept, some common examples of content might include:

  • Basic technical information about the project:
    • What engine will be used for development?
    • What platforms will it be released on?
    • What is the latest stable version of the game?
    • When is the projected release date?
  • Project goals and general design notes:
    • How could the game be described in one paragraph?
    • What are the game’s major gameplay and narrative genres?
    • What target audience is this game designed for?
    • What is the target gameplay length of the final game?
    • What are the game’s major selling points – why would players choose this game over the countless others they could be playing?
  • A mechanical overview:
    • What are the game’s major mechanics?
    • How will these mechanics be implemented?
    • How will players learn these mechanics?
    • Are there multiplayer modes or other optional gameplay modes?
  • A level/world/environment design overview:
    • How many levels/dungeons/towns/etc will there be?
    • What locations can the player visit?
    • Does the game feature shops or currency?
    • What are the designs of these levels or other locations?
  • A narrative overview:
    • Who is the character that players control?
    • What NPC characters are present in the game?
    • What is the game’s central premise or theme?
    • In what narrative setting does the game take place?
    • How does the player advance the story?
    • Does the game feature dialogue?
    • How does the story relate to the mechanics?
  • An overview of the User Interface:
    • How will the controls and camera work?
    • What menus can they player navigate?
    • What controls will they use to access and navigate these menus?
    • How do players save and resume progress?
  • An art design overview:
    • What is the overall atmosphere of the game?
    • What style should be used for the character designs?
    • How should the menus look and feel?
  • A sound design overview:
    • What atmosphere should the audio portray?
    • What style of music should be used?
    • What player actions will require sound effects?

Of course, this is only an example of a few game design basics that may, or may not be, present in any given GDD. Another thing that varies is the level of detail provided on any given subject. For instance, many game design documents also serve as technical documents, with specifications about how the mechanics, menus, and modes will be implemented in terms of programming and scripting, but others focus primarily on the design aspects themselves, without getting too deep into how these aspects will actually be implemented into the game. The genre of the game also naturally changes what should be present in the GDD. A highly story driven game, for example, might feature a full narrative outline or game script, whereas a more arcade style game may forgo the narrative design section nearly all together. Actual sketches, demos, or screenshots of level designs and other game environments may also be present or not in the GDD – it all depends on the amount of detail a developer desires to have in this single document, or in the case of some major companies, the amount of detail publishers require.

As with nearly anything, there are pros and cons to creating and maintaining a GDD for your game project. The discussion actually reminds me quite a bit of the classic ‘pantsing’ versus ‘planning’ debate for traditional writers – that is, whether or not to outline a novel or other writing project before actually writing it. As with a GDD, a ‘planner’ often writes the outline before beginning the novel and tweaks their notes as they go along and progress with their project. However, where game design documents differ from novel outlines is that a game has many more aspects to take into account, aside from narrative alone. A game design document can be very useful for combining the gameplay, narrative, audio, and artistic ideas a designer might have into one cohesive vision of a game. It can also help a designer remember some of the aspects of the design that might perhaps be slightly less exciting, such as the User Inferface and some of the technical details. After all, a game isn’t made from any one aspect – not the gameplay, the story, the art, nor the music. Instead, it’s the sum of its parts.

Personally, I tend to believe that game design documents are a very useful tool in the design process, even for a solo developer or small team, because they help the designers and the developers ascertain that all of their disjointed ideas really come together to form a complete and satisfying product in the end. However, there does come a point where the simple chore of recording and updating every detail of the game becomes a bit excessive or just another distraction from actually getting the development done.

Here is my personal take on the pros on the cons of the GDD:


  • They are definitely useful for teams, and they help make sure that every team member is united in their vision and knows what they need to be working on.
  • They help a designer work through the small details of the game, from saving and loading to the gameplay camera.
  • They help designers ascertain that all of their disjointed concepts for the various components of game design – the gameplay, the narrative, the art, the audio, etc – all really do come together to form a cohesive whole.
  • The road map they provide, and their encouragement to plan out contingencies and details in advance, help designers attempt a project they might be more likely to actually finish.


  • Game design documents must be constantly updated throughout the design and development process to remain useful, as the design of the game is always shifting as features are actually implemented, stories are edited, and resources are composed.
  • They take time away from actual implementation, and can lead to a slower start for a project. This is especially true for solo developers, who don’t have team members also working on and relying on the GDD.
  • They sometimes have a tendency to lead to either overscoping or underscoping. That is, they can encourage either feature creep or over simplification. After all, it’s easy to add a new feature to the design when all you have to do is write it down, and it’s also easy to be so intimidated by the road map that the nerves can cause a designer to play it safe.
  • They can turn into a distraction in and of themselves, if a designer becomes too focused on the accuracy and detail of the GDD.

For these reasons, when it comes to solo projects or small teams, I would tend to recommend GDDs more to those designers who might also outline a novel before writing one. For those who would simply sit down and start writing, forcing themselves to plan out and update a GDD might only hinder their progress on the project, itself, and they may find it easier to simply take less formal notes as they carve out their progress from nothing but the ideas in their head. I also find that game design documents tend to be more important for mechanical or gameplay oriented games. If a game is more story-driven, even if it’s otherwise fairly long or complex, it often seems to be more crucial to focus on nailing down the details of the plot, instead. The value of a GDD really does depend on the type of designer you are, and on the type of game you are making.

Regardless of the genre or situation, however, I personally find it most useful to write a GDD that focuses on the actual design of the game, not on the technical specifications of how that design will be implemented. In other words, I find it more useful to focus on concepts such as why anyone would want to play this game, how the gameplay and narrative connect, what the overall atmosphere should be, and how the difficulty curve should feel, instead of how any given feature will be programmed. I believe that a GDD should be about vision – it should be about turning your ideas into a cohesive experience that you are truly excited about creating, and it should be about why this experience will matter to the people who might one day play it.


If you are interested in creating a GDD for your project, a simple Google search will offer plenty of ideas and examples. If you would like something to start from, you can also download and edit the GDD template that I generally use for my projects here. (Some of the terms and concepts used in my usual GDD, such as engagement types and micro and macro arcs, come from terms used specifically at my school. They’re fairly self explanatory, but you can find definitions of those terms here.)

Regardless of what type of GDD you choose, it is important to tailor the document to suit your own personal style and the needs of your game concept.