1. Planning ranges by scope
| Game size | Example | Rough time, part-time solo |
|---|---|---|
| Jam game | One mechanic, one level | 2 to 14 days |
| Small game | A short arcade or puzzle game | 2 to 6 months |
| Mid-size game | Several systems, 5 to 10 hours of play | 1 to 3 years |
| Large game | 20+ hours, many systems | 3+ years, usually with a team |
These ranges are our own rules of thumb for planning, not measured data. Your own pace matters more than any table.
2. Why games take longer than planned
- Scope grows as you play and get ideas.
- Polish, menus, save systems, settings and bug fixing take as long as the fun part.
- Learning a new engine or tool slows the first project.
- Life gets in the way: free hours rarely stay constant.
3. Estimate yours
List every feature, guess hours for each, add 50% to the total, then divide by the hours you really have each week. Our time estimator does this with a scope, your experience and your weekly hours.
4. Ways to shorten it
- Cut features, not quality: fewer systems done well.
- Use finished systems and assets: inventory, save and load and doors are solved problems.
- Build the vertical slice first.
- Set a release date and protect it.
How to scope your first indie game covers cutting, and Save Points is a weekly system for staying on schedule.
Questions
A small game can take a few months part-time. A larger solo game can take years. Scope is the biggest factor.
Engine choice matters less than scope. A small Unity game takes about as long as one in Godot, and using ready-made systems saves weeks.
Large studio games often take years with hundreds of people. Do not use them as a benchmark for a solo project.
Scope creep, underestimated polish work and unforeseen technical problems are the usual causes.
Who wrote this
Imersa Studios builds the Unity systems, low poly packs and field guides sold on itch.io. The code and techniques here come from shipping those products. More about the studio.