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
In Swift use to see pattern such as - Model View View Model (MVVM), which for me hobbyist helped a lot to break it down and thing certain way about handling logic of program in structured way and also it’s easier to expand it then your own pot of noodles .
In Godot best way would looks to make a plugins with core mechanics and put them together with rest of beef but this is where you see , I haven’t finished single game without help of forum , tutorial .
But something handy for expanding on idea seem to be this design released on Zenva academy.
Also recently made post about this game which hit rank #1 in steam so maybe peek inside would make sense https://www.reddit.com/r/godot/comments/1rm7ueb/comment/o8zqpit/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button
2 Likes
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