Wolf Introspective Game Production

An exploration into the solo Agile practices I developed while working on my MFA Thesis

Introduction

This article is dedicated to my attempts at building a solo agile workflow that I’m shorthand referring to as Wolf Introspective Production. The core of this idea is to perform self reflective retrospectives and task management structures. Many of the concepts and structures are pulled from a paper written by Ashby Brooks Hollar from 2006, titled Cowboy: An Agile Programming Methodology for a Solo Programmer. The PDF of the paper can be found below.

You can find the paper here

Wolf is based off of the idea that the team you are working on is solo (hence, lone wolf). It pulls many production facets such as Real, Scrum, and other Agile wrappers. It aims to take a more streamlined approach to solo development which balances components of self accountability, while also provoking introspective improvement to your own work via each of your different perspectives.

As listed in the paper attached above, Cowboy as a ruleset is meant to be lightweight, focusing mainly on realizing when a project is done rather than when it is at its best possible level.

This method of game production is meant to be used by either solo developers, or teams of isolated solo members each building an aspect of a project on their own. Much of Wolf is based on the idea that each person working alone holds full creative control over their process.

I don’t claim to have all the answers to prolific solo development. These methodologies kept me sane through the development of my Thesis. Not all rules apply to all situations, but they are strong generalizations to follow. Ultimately this is my guide to successful solo prototyping and production. More than anything, this article serves as a place to collect my thoughts on solo development and share them with you.

Core Ideas of Wolf

Define the a prototype

When we start development we can see our game in our head, just bursting to get out. Think about what aspects your game needs to be made. Now list all of those aspects out in a large list.

• From that list…

  • Choose the aspects which need to be the game, then…

  • Choose which aspects need to be in a Prototype, then…

• Sort those by priority, can you accomplish this task list in under 2 weeks? Trust yourself to understand how much work you can do within that time period.

• You must trust and rely on yourself to complete the work within the established timetable. If you cannot do what you need to do, the project will not be complete.

  • If you think you’re falling behind, thanks okay! Adjust your timetable and cut content.

Sub-Par Work is Acceptable Work. Acceptable Work is Done.

As a solo developer you need to prototype fast and build something. We are all perfectionists, but when working alone we need to meet an acceptable level we set for ourselves. This is an acceptable level of content polish which defines how refined each element we build is.

• The higher your Acceptable Level the longer your project will take. If you have an exuberant amount of time and money to iterate on one project, you can raise your Acceptable Level. If you are like me, working on this game on a tight timetable, you must lower your Acceptable Level if you’re going to get anywhere.

• The best thing you can do is lower your acceptable level for everything but the major aspects that matter.

  • Raising the acceptable level for your player controller makes sense. The player will be using that more than anything else.

  • Lowering the acceptable level for aspects which don’t receive much attention allows you to reduce scope (does every blade of grass really need a normal map?)

The Magic of Starting Over

Starting Over should be treated as a big red button that isn’t very hard to push. You shouldn’t want to push it, but if you ever need to, it’s there and ready for you.

• Starting Over doesn’t necessarily mean a new project. When making games we build tools, methodologies, and components which we can carry forward into new projects.

  • Catalogue and preserve these. Bring them with you when you start over.

• If/When you do start over, consider everything which you’ve learned throughout the process of developing your last iteration

  • What elements were good? What were bad?

  • Was the acceptable level of polish too high or too low?

  • Was your definition of a prototype too large?

Prototype Iteration Constraints

• Keep iterations under 2 weeks, then either start over or move on

  • This is to prevent getting stuck on one prototype

• Keep your iterations extremely accessible using version control

  • Git is your friend. Use it.

• Document your iterations with descriptions, builds, and screen captures so you can reference them in context with others when discussing your trajectory.

  • I did this in a Discord server to share with my friends & community

• **************************When you find The One you’ll know it.

  • Eventually you will discover a concept you absolutely love. When that happens, try and plan out the game further, and consider what a realistic timeline would look like for something like this.

Performing an Introspective (Retrospective for one)

This is by far the most important part of the Wolf process, and should be done religiously. Because we are working alone, it can be even more difficult to learn. It’s easy to improve once we have feedback, but it is wildly difficult to generate that feedback. An Introspective allows solo members to improve their own work by creating feedback for themselves.

Every week take a step back and separate yourself into different departments. When working on a game solo we are simultaneously artists, designers, programmers, musicians, and writers.

• The point of a Retrospective with team mates is to communicate with one another the struggles and issues you are having based off of each others actions. It is a method of gathering different production perspectives based off of each member’s specialty.

• The point of an Introspective is to allow the designer, programmer, musician, writer, or artist inside of yourself to view the project from different perspectives which you, as the sole member, hold.

• The artist inside you may tell the designer that complex 3D models will take a really long time, so what can we do to mitigate that? The easiest thing for the artist is to have simple, static environments, is that something that the designer on your solo-team is okay with? What does the programmer think?

  • You can create a Figma board with sections titled “Keep Doing, Stop, We should do…”

  • Put on a hat for one of your roles - what does the artist want to Keep Doing? Stop? What do they think we should do in the future?

  • It helps tremendously to limit your time in each hat to under 10 minutes.

• Using this method has allowed me to analyze and dissect different troubling elements of my own process, and given me boosts in production speed by eliminating needles elements from the pipeline.

  • Some examples of this in action:

    • In many cases the artist within me complained that my design concepts are too open and dynamic, this has resulted in me making simpler static design spaces to work in.

    • The musician within me felt that the audio and music of my work was being neglected significantly, which resulted in me allocating more time to this area in future projects.

    • My designer brain hated that I had to place enemies and spawn points individually in each and every level, so the developer within me helped out by building an automated placement system, saving time for both the developer and designer roles.

The Strength of Testing

• In order for your game to progress you must have playtesters

  • Get a broad swathe of testers

  • Testing and feedback collection are a huge part of the development process.

  • Are players playing how you want them to? What behaviours are they exhibiting?

• Once you’ve collected playtest data, consider what your players are/are not doing…

  • Are there any changes you can make to the game to influence player behaviour?

  • Were there any unexpected results of play? Did players do anything completely uncooth?

  • How many bugs were there? Add these to your Backlog

“No one walks into a closet and then emerges 10 months later with a perfect game - it just doesn’t happen.” ~ Eric Zimmerman

^ words to live by

Personal Client Cycle

The Client Cycle in this case works similarly to client cycles in most Agile environments, the difference here is that the Client should be thought of as yourself, and your stakeholders. Much like the Artist, Designer, etc from the Introspective example, there is a Client is a team member within ourselves too.

• Since you are the only solo developer of the game, the Client will be sparked with hundreds of ideas and solutions to each of your design problems.

• It is extremely easy as a solo developer to shrug and build every feature that the Client wants.

• Just like many other Agile production methods, you need to learn to say No to the client.

• However - in this case, as the client, you understand the implications of proposing a feature to the team. Instead of saying no straight away, you can carefully consider the implications of your new features. With most client-team relationships the client will propose ideas which they do not fully understand. Here, you understand everything, and you can measure exactly what it is you’ll need to build in order to reach your goal. Judge your distances carefully and consider your Personal Client.

Your Backlog, Frontlog, and Shortlog

• Backlog is all the tasks the entire game needs for it to be done

• Frontlog is all the tasks the prototype of the current iteration needs for it to be done

• Shortlog is the list of tasks which need to be completed for the current iteration to be playable

  • Shortlog is not simply “the game runs and the systems work” but more importantly, is a list of tasks built to create a game that is testable without the designer present.

• The faster your game reaches a point of playability, but even more so, enjoyment, without you standing over the should of a player explaining all the elements at hand, the faster you’ll reach your design goals.

• Focus on your Shortlog. Once that’s empty, reload it with your Frontlog. Once the Frontlog is empty, take a breather, recognize your milestone: You built a whole iteration of your game. Well done!

• Recognizing personal achievements is a huge proponent of a solo developer’s mental health. Really take a step back and think about how far you’ve come. Take a break. Go for a walk. Get your favorite food. Visit your favorite stores. Reward yourself, because this work is hard, and you just achieved something you set out for yourself.

Wolf Reminder: You’re only one person.

Considering all of this, remember that as a solo developer everything relies on you, and you alone. If this is your first solo game dev journey, one analogy I like to use is: “Living on your own for the first time.”

You’ve understood your whole life how to simply, live in a place. But it becomes completely different when you’re the only one living in that place. Every chore, task, run to the store, decoration, organization - it is all up to you now. You have a great responsibility placed on your shoulders to make this space into a home. It’s supposed to be comfortable, right? But also functional, and realistic? It shouldn’t be stressful - it is your home, after all. The weight of this task is heavy, but it is also a blessing. Being able to explore and create your own space is a unique experience. To me, this is representative of building your own game. Having total creative control is a totally different kind of design experience from the familiar collaborative processes we know. It is an opportunity to express your own voice in any way you want - which is genuinely overwhelming. Since you are the only one responsible for… everything, it can quickly become deafening. If you’re not careful you’ll find yourself in a hole of noise and darkness, unable to escape. Clutter, dust, and dirty dishes will pile up. It’s easy to get completely overwhelmed, and want to shut down forever.

Remember that you are one person. Burnout is exponential. Recovery is linear. You must enforce limitations and boundaries on yourself. The only successful production of a game is one in which everyone is happy with the process, and the end result. And remember that above all else…

Your health, wellbeing, and happiness come before the game.