How do you define the scope of a game development project?

I agree with Pete on that simple exercise of envisioning trailer and back of box. Killer technique. It reminds me that as a marketing partner I often include with the presentation of comms tactics and strategies we are recommending to a developer, comps of imaginary digital and/or printed coverage of their game in the trades - like a Kotaku headline, Game Informer cover, sometimes even tangential reaches like Wired magazine. By imagining where we want to be later in the pipeline we can engineer for it in the comms and if it’s early enough, even in the game.

I've found it productive to ask ourselves two questions very early and again during dev: 1. What do we imagine the trailer would look like? (Brainstorm cool yet achievable "trailer moments") 2. What are the 'back of the box' bullet points that will sell the game? (Unique selling points and features that the marketing team can use to sell the game.) Whether it's for mobile or Quad-A console, the goal is to generate internal discussion around core differentiating features and build enthusiasm across the team. We all want a game that looks, sounds and plays differently in the market and also reflects the values, sensibilities and ambition of the team. List all the features down and get a reality check from Engineering and Production.

Clear Direction: The vision outlines the desired player experience, providing a clear creative direction for the team. Scope Prioritization: Goals help distinguish essential core elements from extras, aiding in effective resource management. Risk Mitigation: A clear vision allows for early identification and mitigation of potential challenges, reducing the likelihood of costly setbacks.

This is where studying comps can be extremely powerful, as it is easier to break down something tangible as opposed to something nonexistent, as of yet. List out the features of your comp. Each screen in their menu is a feature. Each component of combat may be a feature. This can be a few bulllet point description per feature at this stage. Next organize the list into the features required for the core loop to function, and those that are ancillary. Now transform that list into the features for your game. What new features are you adding? Which can you ditch? And then, quite importantly, which can your team afford to develop?

Estimations are not an exact science. It has a lot of biases and subjective considerations. Keep this in mind and don't set the numbers in stone. After years of estimations and trying different methods, the best approach for me is relying on leads in each area to evaluate the effort on each task. Each discipline speaks its own language, so you have to translate it into a common baseline, and add some buffer from integrations. Even if you are good at, say, programming, always reach a lead to confirm. With all the estimations at hand, it is easier to prioritize tasks. Here you can detect bottlenecks and either discard or change the scope of tasks to expedite dates or reduce costs. Take into consideration the team available to set priorities.

A game is quite similar to any other software project. Before doing anything you need to validate that your idea is correct, creating prototypes for the core mechanincs, and iterate / validate they are fun enough to build something on top of it. Later you start a preproduction trying to find a cool L&F making art, some videos showing a better idea of the game. Once everything has been approved, pre-production would start trying to involve all the teams in the process to split things on goals, the goals on deliverables, and them into "epics" until you get into doable tasks. Once this is defined, you should have clear the scope roughly, but enough to start the production and the real work on it.