My “Rules” & Tools of Game Development

This is the DEVELOPMENT portion of a two-part post containing lessons learned from developing games in my career thus far. The DESIGN portion can be found here.

These are the rules and tools I use for developing and releasing games. This is a list I’ll add to, change or delete from at any point. Also, a good reason negates any rule, but kill your darlings. Game design and development is an artform, not a science.


Game Engine and Software

  1. The entire team should be using the same tools. Don’t have one level designer using Unity and another using Unreal.
  2. The entire team should be using the same version of these tools. Disable automatic updates, schedule them in your sprints so everyone updates together.

Planning and Scheduling

  1. Split your development into managable goals that will each take your team a couple of weeks to achieve. Bring the big mass of a GAME down into smaller chunks called SPRINTS. Look into SCRUM development to learn how this works.
  2. Set deadlines and milestones. You can make the same game from now til the end of eternity. If you want to get it out in a playable state before you run out of money, determine the smallest version of the game you’ll happily release that will generate revenue, and plan to release that. Take your biggest goals, plot them on a calendar and call these your milestones. Then make sure you meet them as a team.


  1. You only get one launch, whether it’s your actual launch, Kickstarter launch, new platform launch, Early Access launch – whatever. The press will never be impressed by your next “launch,” so get it right first time. (Thanks @timgarbos). Soft launching can help mitigate some of these issues, but that will be your launch in that country.
  2. Keep it casual. Keep your words short, your press releases short, your ads short, your hashtag short, your Twitter name short, etc. Make it easy for people to remember, write and share.

Preparing for Post-Release

  1. The first release needs to give developers the ability to force-update the app in case of critical bugs. Especially important in F2P mobile. Don’t leave this til after your first launch. You’ll thank me for this one.


  1. Never release on a Thursday or Friday. If there’s a bug, it’ll appear over the weekend when nobody is in the office to fix it.
  2. Keep an archive of each release build. When you do another release, install that, install your new version on top. Been bitten by this before. Then do a clean install and test. Been bitten by this too.

Tools for game development

  1. AutoHotKey – for somewhat automating those repetitive tasks. I have scripts that I use for copying and pasting translations into App Store and Google Play and selecting new languages for In App Purchases. Doing it manually every single time is draining, to say the least.
  2. Google Calendar – if you’re not using a Google Calendar to manage meetings, plan releases and generally keeping your team up to date on their schedules, you’re doing something wrong. Note: don’t use it for task tracking. It’s about meetings and communication.
  3. JIRA – JIRA is a very heavy task tracking tool, but it works well when the entire team knows how to use it. I don’t use all of its features, but we use it for managing sprints and communicating about issues.
  4. Confluence – a partner to JIRA. Essentially a wiki for discussing game design documents and processes. Easier to update that a Word document and easy to send links to for others to reference.