Image credit: Nubelson Fernandes (@nublson) via Unsplash.
So a few years ago I published an indie game that went on to become a success. Back then I did the fairly cliche thing of quitting my job and focusing on building my game full time. I treated it as a sabbatical.
Before building games, I had a long career in corporate tech as a product manager. I knew that no matter how trash my game was before I completed my ‘sabbatical’ I needed to release something. If I didn’t release anything then it would have been hard to explain what I spent the time doing on return to my corporate career. If the game was good, that’s just a huge bonus. So I created a framework that helped me deliver based on practices I learned as a product manager. Upon reading a post in r/gamedev by u/Loonworks about stopping development on their game, I figured I’d share that framework, I've named Four Point Development, with you all.
Foundation: Your game needs to have a 'point'
With any successful game (or other tech product), you need to have a strong foundation. Every successful indie game has a ‘point’ and that ‘point’ is the game's foundation. This is essential to delivery because it will help you stay focused on what matters, and what matters is your game's 'point’.
You’re not gonna be able to create a standard action-adventure and manage to compete with a AAA studio, they will simply out-spend you. But if you have, for example, an interesting mechanic that you want to introduce to the action-adventure genre, then your game could still be worth pursuing. Your ‘point’ doesn’t need to be related to game mechanics. It could be a great story, an interesting marriage between genres, amazing art, just something that means that you’re not recreating a game that already exists.
Build: Don’t do anything you don’t have to
So now you have your 'point', you also have a core question you need to ask yourself every time you’re about to do something - does this thing I’m about to do directly relate to the 'point' of my game? Will players still ‘get’ the 'point' of the game without this? If the answer is no, then you need to think hard about if it’s worth doing. If you’re not willing to let the ‘thing’ go - then you need to ask, can I deprioritise this? How long can I wait till I absolutely must do this?
One notable exception here is probably game art and music. These are fairly essential marketing tools for most games. That being said, there are lower-cost art styles that still look timeless and beautiful. For example, pixel-art and various stylized 3d art styles. I’d recommend using store-bought or engine art fairly sparingly, or at least with some customizations (where allowed).
Buy: Before you do actually build, consider buying
This ties in closely with Build. Addons are your best friend when it comes to speedy delivery. Don't waste your time reinventing the wheel by building a common system that doesn’t push your ‘point’. The less you have to build common systems that don’t directly relate to your game's 'point’, the less risk you take on, the faster you deliver. Again, art and likely music is a notable exception to this.
Feedback: Release as early as you possibly can, then iterate, iterate, iterate
Early Access releases, alphas, and betas are seemingly becoming less popular among players. However, there is a definite type of player who loves to be an Early Access player. The earlier you release, the sooner you can iterate and make improvements. Once you have a prototype that accurately displays the ‘point’ of the game, with a reasonable amount of content, at least an hour, it’s worth releasing into Early Access. There is an important caveat here though - it’s essential you accurately set expectations with potential players. If you only have 20 minutes of content, your art isn’t completely done, or anything else that might make your early access release less impressive set that expectation. The worst thing you can do is overpromise and under-deliver. Oh, and it doesn’t hurt to give a steep discount.
Overall, this is essentially a de-risking strategy. It allows you to not buy in too deeply into concepts, systems, or really, your game's 'point’ if players don’t enjoy it. I’d also recommend floating the idea of your game through various advertising means, including a “coming soon” page on Steam, websites, social, teasers, trailers, explainers, dev updates, or gameplay videos.
Anyway, that’s my advice based on my experience as an indie. I followed these principles. I took a year to build my game. I was in Early Access roughly five months after I started, full release after twelve months. I wrote very, very little code, was on the list of the Steam hidden gems for a while, won a few awards. It went well.
How it relates to Product Management in my mind for those incredibly niche people who are interested in both Product Management and indie dev:
Foundation and Build: Loosely based on the concept of a minimum viable product (MVP) and agile software development
Buy: Not based on anything in particular, but common product management practice
Feedback: Loosely based on ‘fail fast’
