Nuts and Bolts: Great Tools for Indie Game Developers

Over my long career, I’ve developed a short list of game development principles. The list is pretty short because one of the principles is that there isn’t a single right way to make games.

The story of every great game’s development is unique. Different teams have found success with radically different approaches. Everything from team size to genre to current market conditions makes every project a unique challenge.

This is not to say that there aren’t some tried-and-true production processes. Yet I’m skeptical of producers who say they know the One True Way to deliver a game. Whether they’re passionate Agile advocates or old-school Waterfall disciples, too many producers and project managers stamp a one-size-fits-all process on top of every team – probably the one they have the most experience running.

Instead, what works best is to match the processes to the team. The larger the team, the more processes will be needed – if only to ensure communication is clear, departments are coordinated, and everything lands on schedule. But the team has to buy in and be an active part of that process, or it won’t work.

This extends to a choice of tools as well. No team is going to love a project’s task-tracking software, but it’s important to find something that doesn’t get in the way of how a team likes to work. If a team is steeped in an iterative development tradition and logs bugs and comments directly in a company playtest, it better be a quick and easy process – requiring as few parameters entered as possible – so they can get back to playing the game and giving feedback. 

For solo developers, choices about processes and tools are easier. Solo devs wear all the hats and are free to work in exactly the way they prefer.

Many of the problems that plague a larger team in the early going – debating the choice of engine, figuring out communication channels, and simply learning to work well together – aren’t issues that a solo dev has to grapple with.

As a freelance consultant, I work with a lot of different teams. For clients, unless I’m specifically contracted to help with process issues, I adopt whatever the existing processes are – the last thing a team needs, typically, is a temporary external contractor telling them how to work.

But for my solo project, I have a set of tools I’ve grown comfortable with over the years – tools that work for me and the type of game I’m building. They may not work for you, or they may not be suitable for the genre of game your team is making – but here they are anyway, as food for thought. 

Furnishing the Design Suite

You’re going to want to be able to make some documents. Maybe you’re not making the classic massive design document. Maybe you’re self-funded and not doing pitches for a publisher. But there’s no way you’re getting a game to market without setting some words to digital paper along the way.

In the early part of my career, I was weaned on the Microsoft suite of applications – Word, Excel, and PowerPoint. I still work with clients who prefer those tools, but I’ve moved on to Google’s GSuite / Google Workspace applications – Docs, Sheets, and Slides. Though I miss a few things from Excel in particular, and still use Excel now and then, I like the solid integration of the GSuite apps with Gmail and Chrome (still my browser of choice, despite some cruft and slowness in its modern iterations), and overall I prefer the way the applications work together.

A long time ago, I loved Microsoft’s Visio for flowcharting and general diagramming of UI flow. Visio has fallen by the wayside over the years, and the modern versions feel like an afterthought in the Microsoft stable of apps. It’s a program I’ve missed now and then, and I’ve had a lot of trouble finding a replacement I like.

Then a couple of years ago, I was introduced to Miro while working with the great folks at UX Is Fine. I’ve since become a huge advocate of the product; for artists and designers alike, it’s a great all-in-one application for everything from brainstorming to design presentations to flowcharts. I can’t recommend it highly enough; working with Miro is often transformative, changing the way I think about problems.

I also use the free version of Grammarly, a grammar app that goes far beyond the autocorrect and spellchecker functions in Google Docs or Microsoft Word. I resisted Grammarly for a while; my writing skills aren’t perfect, but I can generally string together proper sentences. (My English teacher mom drilled the basics into me at an early age.) 

I sometimes reject Grammarly’s suggestions, but I’ve grown to love the nature of the checks it does and the additional clarity it breathes into my work. I’d encourage its use for any developer, especially for anyone who struggles with writing. Good communication is so important in game development.

A Dash of Production

A small indie game needs less “production” than a bigger project, but I still want to track tasks and work towards basic milestones.

A host of project management software is out there, and I’ve used a lot of them when I’ve worked with bigger teams. From old-school dinosaurs like JIRA to up-and-comers like ClickUp; from heavyweight Agile-focused tools like Pivotal Tracker to lighter-weight customizable products like Asana – each production tool has its plusses and minuses.

But for a solo project, at least until I’m ready for external testing and need something more robust, a basic Trello board is sufficient. It’s lightweight, quick to set up, and highly customizable. It lets me keep lists of tasks in whatever buckets I want, at whatever level of depth I want, and toss new cards on a backlog quickly and easily.

The Crucial Engine Choice

If you’re a developer, you’re probably picking between Unreal, Unity, or the up-and-coming Godot engine. I can’t fault any solo developer for selecting any of the three. Despite the recent controversies on the licensing side and its slightly uncertain future, I’ve chosen Unity as the engine for my game.

I’m familiar with Unity’s quirks at this point, and several of my clients also use it for their projects. It’s fast to get something up and running in Unity, and I rarely hit a stumbling block I can’t overcome with a little effort. For the type of project I’m making – a small narrative game, only slightly more complex than a visual novel – Unreal is simply too heavyweight with too much overhead and baggage.

Speaking of narrative games, I can’t say enough about Ink, Inkle Studios’ engine for creating interactive events. Ink’s Unity plugin has been a lifesaver and is perfect for my needs, shortcutting the necessity of building an entire chunk of tech to drive variable text-based events.

I also lean heavily on third-party assets. Whether that’s sound effects or art under the Creative Commons license or Unity asset store bits and bobs, there’s a ton of great stuff out there that can be had for free or near-free – and looks or sounds far better than anything I’d make.

And, as I’ve mentioned before, I lean on AI tools as well. Whether it’s a bit of C# code from ChatGPT or a prototype art asset made in MidJourney, AI tools have proven to be a significant multiplier in how fast I can stand up the initial version of my game.

Move the Game Forward

I know that the last bullet point – using AI for my prototype – is controversial. As I’ve written before, I don’t currently plan to ship any AI art assets in the final product. However, using AI to help prototype has helped me get the vision for the game across in preparation for when I finally engage real artists.

Similarly, some old-school developers would gasp at using Google Suite products or Grammarly. There are valid security concerns about any web-based application – where’s your content ending up, and what big corporation could access it and misuse it? Could the grand plans for your innovative intellectual property leak out, and all your secrets be revealed?

For the next big triple-A title with big publisher backing and thousands of developers, these are valid concerns. But as a solo dev, I’d have to have a giant ego to think anyone cares about my tiny indie project enough to steal it. I’d be crazy to use subpar tools due to security concerns. 

So in the interest of moving forward, I set aside those questions and relied on the tools that worked best for me (assuming the licensing conditions are not prohibitive – a question that may become an issue in the long run with Unity).

That’s the takeaway for any solo developer. You’ll read a lot of conflicting information out there. Sorting through a thousand different takes on the best processes and tools can quickly paralyze you. 

I’ve described a set of tools that work for me, but the demands of your project may mean they’re not the right answer for you.

So find a set of tools that works for you, then move forward even if they’re flawed. Because there’s no one right way to make games – but to get to the finish line, you’ve got to spend the bulk of your time making games, not endlessly hunting for the perfect tool.

New blog content appears on Tuesdays. Follow Scree Games on Facebook and LinkedIn.