So I have been wondering. Does anyone else have rules for how to scope a game correctly? I as an example always follow the rule that if I can’t make the core mechanics as a kind of prototype / vertical slice in a month, then it’s likely too complicated. Even though that isn’t a great rule lol. So I was curious to see if anyone followed specific rules. If you do feel free to share them here as it could help Devs struggling with scope.
2 Likes
I really don’t think there’s any set rules (except for NOT making a multiplayer MMO as your first project), as you don’t really know the full potential scope of a project until a prototype is made of the core mechanics.
Once it is made though, you’ll definitely know how far you can take that specific project. Also, different people will take different scopes, even if it’s the exact same idea.
1 Like
I worked a handful of years as a producer in the industry, on the developer side, and from that perspective, this is a truly bottomless question. Project managers with decades of experience still manage to misjudge timeframes every time - I’ve never ever seen nor heard of a game finishing ahead of schedule, or under budget, ever 
I think the main take-away from that is that things always take longer than you think. Remember that if you set too much time aside, you can reuse what you didn’t spend - if you set too little time aside, you may have to slash features, and potentially disrupt the whole development, and the final product. Happens all the time.
Scoping a project is essentially about matching your budget to your design. “Budget” meaning how much time and effort you’re willing to put in, and how soon you need it to be finished - this is entirely personal, and where some people find it easy to stick with a project for years, others find themselves getting bored with any project in months. Know yourself, but try to err on the side of caution - you can always expand on your ideas, and facing a mountain of work can be discouraging before you even begin.
It’s also good practice to focus on what will make your game good, rather than cool but unnecessary “stuff”. Identify what you need to have, what’s nice to have and what’s expendable, then get the design as sharp as possible. Sometimes a game actually benefits from having fewer features - imagine Slay the Spire with an added X-COM tactical subgame 
As for how to plan well, live by the rule that planning is cheaper than doing. If there’s anything you can meaningfully plan first instead of doing, plan it - make placeholder graphics, maintain a design document that describes exactly what each feature of the game does, playtest with table-top board game pieces, whatever you can do to hone your ideas before committing to them. This is unfortunately very difficult to hold oneself to - sometimes you just have to see something implemented before you realize it needs redesigning. I’d say that mastering this may be the holy grail of avoiding wasted time.
Beyond that, experience is the best teacher! Make stuff and have fun - having fun is what keeps us all motivated. The absence of fun leads to the dark side
3 Likes
You touched on a very important topic in project management. A lot of the frustration in Indie game dev, especially for beginners is scope creep. In my experience with Godot, I would say that you need to have the core player mechanic in a few days max. If you do that in a couple of days, you have a much bigger chance of finishing tha game. If you work by yourself and is not working on your dream project (in other words, you are still gaining experience), have one playground level and player core mechanic ready in one week and don’t add enemies that take 2 or 3 weeks to implement. Everything should be simple at first. Stay away from combat systems too unless you really know what you doing and have the resilience to finish the project. If you do that well in the first week, you still have some good 2-3 months of solid work to finish a polished platformer with traps, a few small levels and a few simple traps. This can vary from developer to developer, but chances are it won’t vary too much.
2 Likes