Make complex as necessary.
Sometimes the best solution is the simplest.
If you’ve ever researched a new topic online, the first results you probably encountered were literature on the best way to do things — a blog post on how to write the most flexible software architecture; a template for the most comprehensive task tracking system; a video tutorial on how to make your own custom-made level editing tools.
While these resources are useful, employing these will likely mean more work to implement and maintain them. And maintaining a system is no small task — while I haven’t had the chance to use it myself, you’ve probably seen more than a couple memes from producers pleading their team to keep their Jira tickets up to date.
These methodologies can make a lot of sense for a bigger team where someone can be exclusively responsible for the system, but in my experience working in tiny indie teams (<5 people) where everyone has to wear multiple hats, I believe that starting simple is the best way to begin.
A simple system is probably not “the optimal” solution. A simplistic code architecture may make it harder to add new features down the line, or a bare-bones level editor might slow down level design and iteration times. But the keywords here are may and might. When you’re a small team, your most valuable resource is time, and beginning with a simple solution saves time in the present, delaying any additional time investment until you’re sure you need it. Maybe you will realize that designers really need better tools to design levels, and program them later on. Or maybe, you will discover that the designers found out a creative way to create levels that eliminates the need for the custom tool you had in mind, saving you all the time you would have spent developing it.
The area where this philosophy has served me the most is in production, one of the many hats I wear at Smarto Club. While a crucial part of development, it personally is a great candidate for simplification due to the fact we’re a tiny team (3 people plus a couple contractors at times) and that any time I spend doing production is time I could spending doing more “critical” development tasks such as programming, game design and bizdev.
When developing Teacup, our first game, I felt like it was the perfect excuse to try something new and started with Codecks. After being used to of Kanban-like tools such as Trello and HacknPlan, Codecks was a fresh of breath of air, and I loved the playful analogy of decks, cards and hands.
But… loving it myself did not mean much if the rest of the team did not click with it. While they made a valiant effort in the beginning, after a couple of months they bounced off it and no longer updated their tasks without being prodded. I was still finishing my college degree during Teacup’s development, and did not have the time to update tasks myself nor the energy to constantly poke the rest of team, so in the end I decided we should move to another easier-to-use system.
At the same time, we were quickly realizing that a group chat wasn’t a particularly good place to talk about work and were looking at alternatives. We ended up trying out Guilded as our publisher was experimenting with it at the time. Guilded is a chat application similar to Discord that combines the familiar chat and voice channel based servers with integrated organization tools such as calendars, documents and to-do lists.
As you may have guessed, we began to use the to-do lists as our task manager. It was not a great system by any means, but it reduced friction — people did not forget about it as it was in the same place as the rest of our chats and documents and since it was so simple to use, the rest of team took initiative in creating and updating their tasks. All this freed time that allowed me to focus on other development tasks, and we successfully finished and launched Teacup.
To-do lists in Guilded were the simplest solution that worked for us at that moment in time, but as you may guess, this solution wasn’t going to work forever.
As we’ve accumulated a larger body of work as a studio, we began to require a better place to document and later be able to reference our work, and thus decided to move from Guilded to Notion, a popular productivity and note-taking tool.
One of the great things about Notion is its flexible database system that allows you to create databases with as many or as little properties as you want, making it a perfect candidate for creating systems that are only as complex as necessary. While there are no lack of project tracking templates for Notion, I preferred to start with a simple database similar to the to-do lists we had in Guilded that just had the task title, responsible team member, and a checkbox to mark the task as done.
Bubblegum Galaxy has been a much more complex project than Teacup though, and this simple system quickly became too simple, meaning that now was the right time to make it more complex.
For example, we added a priority checkbox to differentiate between higher priority tasks we aimed to work on in the short-term and tasks that would be tackled in the future. Notion’s filters made it easy to create different views of the same database where we could quickly alternate between looking at all created tasks or just the tasks we planned to work on during the next couple of weeks.
The other thing we realized that the “done/not done” binary was causing problems, so we changed it for a status field that allowed us to be more descriptive about the current state of a task. An area were this has been particularly helpful has been for art assets, as now we can easily differentiate between "done” and “done and implemented in-engine”, a pretty important distinction we frequently tripped on before when we only had a checkbox.
Of course, if you’ve ever worked in a producer role, this is all pretty basic stuff you’d take for granted in a proper project planning software. What makes it great in our case though is that by only adding “features” as we need them, it’s tailored to our personal experience working as a studio. In the end, every property has a clear purpose based on lessons we’ve learned from working without them, making it a lean system with no excess.
So the next time you have to design or build a new system for your game, ask yourself, “what’s the simplest way to get this done?” And then try that out first.
Sometimes it might be not enough and you’ll require something more complex. But sometimes, you might be surprised to discover that the simple system is actually all you needed to get the job done.