Cliff Harris wrote a great article here: https://www.positech.co.uk/cliffsblog/2021/10/14/common-mistakes-by-indie-game-developers/ and Ive made my own list:

Pick a software tool and stick with it. We used Unity 5 for Beautiful Desolation, only upgrading to 5 when we had hardware compatibility issues and we have now moved to the 2019 LTS branch and don’t intend to move until the game is shipped.  We use 3D Max 2019 and only just moved from 3D Max 2014! We pay for a subscription every year but we always use an older version and only upgrade if there are performance or plugin benefits. Dont use the cutting edge tool/plugin/lighting solutions, stick with the tried and tested methods. if you need to test fancy solutions, do it in your spare time or as a reward (see finishing early). Dont get sucked into the technology paralysis loop - use what works!

 

Use the assets store, sound sample websites, and pre-created graphics whenever possible. You can retexture a model or tweak a sound effect but it is a hundred times cheaper than commissioning it or doing it from scratch. You can always replace assets later if really needed. Dont listen to the neigh sayers who have never shipped a game. I swear by the A* Pathfinding Pro asset on Unity store. Ive written pathfinders and they dont come close to this asset - so why would I waste time trying to reinvent the wheel. All the C# scripts are provided, so I can check how things work under the hood. That goes for a host of other amazing premade scripts and tools.

 

Dont get sucked into the pre-production, over design stage of game development. Do a basic outline of what needs to happen in its barest form - no-frills and make it. Then iterate from there. Once you have a basic gameplay loop you can start planning out the story, puzzles etc.

 

Register on Steam EARLY, pay the fee and build often, you dont have to make the page public, keep it private. We use Steam to distribute our internal builds, if you batch this it takes minutes to disseminate. You can then test the game in the Steam environment and pickup errors early.

 

Backup, repo and version your work! Use GIT with some kind of offsite solution or at the very least work from a Dropbox folder. Use the 3,2,1 rule. 3 Copies at all times, 2 local, 1 off-site (online is fine).

 

Automatically track your build versions. You can run a post-build script automatically that increments a counter that shows in your main menu, this goes a long way in the early and late testing phase.

 

Build often. Initially, during your vertical slice, it should be daily, then when you are adding content at least weekly. In crunch, you will be doing it a few times a day. Issues WILL pop up in a deployed build that do not show in the editor environment.

 

Stick with your script framework between games and iterate, there is no need to reinvent the wheel each time. After hundreds of thousands of players have tested our games we would be nuts to start from scratch. It takes a day between games to rip out the old assets, clean up the repository and get into the next game. Dont reinvent technology each time, the idea is to make and finish the game.

 

Design your framework with future games in mind. Be mindful of folder structure, proper script naming, etc. As an Indie we need to use ever single trick in the book to get our games done faster and in budget.

 

Set a daily goal. If you are indie and working from home, set yourself a goal on where you need to be at the end of the day. Be realistic but make sure its done before you leave. If it’s done in half the time, then use the rest of the time constructively in the pursuit of the game. Reward yourself by working on a different aspect of the game or researching a new technology but don’t do something YOUR-non-indie-game-productive like watch a movie or play a game during work hours.

 

Pick a test machine that is your mid to lowest-tier pc and stick with it. I have the same test build machine that I have used for 3 games. I know that if it runs on this machine it should run on almost anything. I do try and keep Windows updated because we can assume most players do.

 

Pick one platform to launch on and make sure its Windows. You can add others later. We launched a game on Windows, OSX, and LINUX on day one and it was massive stress that could have been avoided. Players don’t mind a staggered release if you are honest about it. Get the bugs ironed out and players, playing.

 

Dont get distracted by Streams or the latest drama on Twitter/Discord and Reddit. These are a waste of time and suck your creativity. Do it on your lunch break or in the morning or after work.

 

The translation of your game should not be an afterthought, so dont hard-code any text strings.

 

Translation files should use .csv - avoid JSON or XML - they are hard to debug and hard for casual translators to work with.

 

Translation files should NOT contain logic. I am guilty of this, dont be me!

 

Don’t over plan. Just get the bare minimum on the screen and see how it feels. I always start with the player movement and build out from there.

 

Think about save/load mechanisms early, this should be next on your list once you get your gameplay loop done. Dont leave this to last! You need to think about how states and variables are stored.

 

Save game states should be version-independent! Make sure your saves will load regardless if you make changes to the scene or code. When you serialize data be very sure you can make significant changes and unserialize successfully. Test this early!

 

Savegames should work across platforms!

 

Build a debug tool early, you should be able to get feedback in a full build, check variables in-game. There are loads of pre-built solutions for this or doing your own is trivial. It doesn’t need to be fancy or look amazing. Just give you feedback on what is happening under the hood.

 

Allow super quick access to your game for artists or scene/level assemblers. They should be able to jump in quickly to test out an art asset or design. Don’t make them wait 5 minutes each time, if they iterate quickly the game will look better.

 

Optimize early, dont leave performance to the end of the production. Game developers will often tell you not to pre-optimize. As an indie, ignore this advice. Write as good clean code as possible and always keep poly counts, garbage collection, and so forth in mind. You should ALWAYS watch the FPS, Tris, Render count, etc. Build from asset bundles when possible, dont use the resource folder, etc. Read up on how the stack works and how to manage memory...If you have to optimize at a later date you will have a headache. You can iterate later if needed and trust me, your old code will be garbage a year down the line but that doesn’t matter. If you wrote it performant to start then it should be fine!

 

Pool everything. If you don’t know what pooling is then google it. A decent programmer should be able to whip up a solution in a few hours or use a prebuilt asset if you must.

 

Keep an eye on your frame rates in real builds, not the Editors. See BUILD OFTEN!

 

Once you have some kind of gameplay that you intend to take to completion, tweet about it. Shout about it, Discord about it. This is hard and we are still learning as well but you need to market early and consistently.

 

 

PART 2 Coming soon!

 

If you enjoyed this, please wishllst our next game: STASIS BONE TOTEM:

 

 

[xyz-ihs snippet="supportstasis2"]