You're faced with conflicting viewpoints on a new gameplay feature. How do you navigate the diverse opinions?

Design by committee results in endless meetings, watered down design, copycat design, disjointed mechanics, steamrolled innovation, muddy vision, lack of consistency leading to unintuitive gameplay, and attrition of good leadership. A committee of unwilling participants that consider being given clear direction a tyrannical offense is a sign of a toxic team and a game that will end up cancelled. Everyone has ideas, very few have the ability to design a game (an idea isn’t a feature). Hire a good designer and do what they want. Design should be a designer telling directors the design and discussing priority. Directors then execute and deliver the features with risk/reward tuning parameters and audio/visual feedback loops back to design.

Ask a simple and short survey at the end of gameplay. Keep it simple and straight to the point. Don't add any questions that require typing, only include click-based questions. This type of survey is accurate and can be very invaluable if done right.

In my experience developing for Minecraft, Roblox, and Fortnite, I prioritize gathering feedback systematically. It happens to organize surveys, focus groups, and community forums to collect diverse opinions from team members, playtesters, and players. Understanding the reasoning behind each viewpoint helps me make informed decisions. For example, when introducing a new feature, community feedback highlighted crucial adjustments that significantly enhanced player engagement. This approach ensures we consider all perspectives, leading to a well-rounded and successful implementation.

The initial step should always be to listen and carefully consider every viewpoint, this will allow you to take a few curated actions next. After having a compendium of these viewpoints in mind you can sort them regarding similarity in execution, difficulty, or even what the target audience's reaction to such a feature might be. Gather data from history, have games with a similar premise in the past utilized such a feature? What did they do differently or similarly? Were there other aspects that allowed them to pull it off that you can or can not mimic? What was the reception of the feature like? Using all this info whittle down the choices to the applicable viewpoints and then? Playtest. Synergy can only be confirmed through practical use.

Every game should have a set of guiding pillars that every single decision gets filtered through. What is the goal of this feature? Does it satisfy the pillars? Is this game more about steady content release, or is more about quality with less content? Every game should know what it is and who it is for. Every single decision has tradeoffs, point to the pillars to understand if the tradeoffs are worth it, and for everyone to get on the same page about the product and who this game is for.

Always: * Check future impact of the game * Make it scalable in harware meaning * Make it scalable in software meaning * Now most importnat >> Can you make your make, scalable and incorporate it to the general API> making it scalable to the "GAME OVER ALL GAMES". * Did you hear about this concept?

Always encourage open discussion. Everyone has the potential to have such rewarding feedback and possibly the key piece of feedback that could mean your project is more profitable.

Promoting decisions through team workshops is a great way to lead to incredible ideas, but don't be afraid to apply some constraints to ensure the ideas are all realistic and aligned with the general direction Constraints make us creative to make the best of what we have in hand and the current circumstances

However, discussion without process is meaningless. If you bring everyone in a room to discuss just to make them feel better about it, that's not going to work either. After a while, people won't feel heard. Not everything on the game can be discussed at length, it's not possible given the timelines and budgets. A good rule of thumb to bring up a discussion would be if 3 people or more start having an issue with the new gameplay feature design.

Es cierto y hay que fomentarlo pero siempre con la claridad de que la misión y visión principal del proyecto es lo que impera y se debe crear un espacio acotado para ello puesto que el que se haga todo esto tendrá valor en tanto y en cuanto obedezca un un fin común.

Another benefit of rapid prototyping is its ability to uncover unforeseen technical challenges or limitations. What seems feasible in theory may present unexpected burdens in practice. By identifying these issues early, you can either adapt the feature or reallocate resources as needed, saving time and effort in the long run.

Rapid prototyping is a great approach for many situations. Whether its a gameplay feature or a tool, taking a blockout or proxy models to represent the desired mechanic would enable you to see any caveats and challengings ahead and save yourself time. Biggest advantage is to take some feedback, test it with your colleagues and see how you can improve it during the prototype stage. You can afford starting again and trying a different approach. Later in when you're going for a polished version the process will at least be quicker and have a set plan in place.

For my idea, prototyping is not neccesary. * Why? * Because, any device and any game will be part of my game. * Why I cant say more> Protecting my idea, against billioners. I

If you can prototype quickly you have more opportunities for adjustment through feedback. You can reduce costs on going down routes that are not viable or are not the most effective towards the teams goals. It can reduce overall cost and wasted development time.

Creating a working model of a new feature lets the team experience it firsthand, uncovering insights that discussions alone can't provide. For instance, prototyping a new game mechanic in Roblox allowed us to quickly identify and address potential issues. This hands-on approach facilitates swift iterations based on feedback, ensuring the feature is refined efficiently and effectively, ultimately leading to a more polished and engaging gameplay experience.

Have a hierarchy in place that promotes healthy decision making. Flat hierarchy's fall apart pretty quickly given the amount of decisions that do need to get made (thousands) on a game project. At the other end, having one creative genius is also a disaster waiting to happen. Each department should have a decision maker that makes the final call (game design, animation, art, engineering, audio, etc). There are cases where even those leads have trouble making a final call, and that's when a Creative Director or Studio Head needs to step in and do it, citing concrete reasons.

Affected and interested parties brainstorm and say their piece, but the lead designer presents the best option and the CEO calculates the financial cost of the decision. Its up to the CEO to make sure that all pivots or new features fit within the allocated budget. If not, then the lead designer offers another solution. The CEO does not make game design decisions. Only financial/budget/business/monetary ones. I've been in situations where the CEO made design decisions and doomed the project. The Lead Designer is the monarch when it comes to gameplay features and can veto everything. An open-minded, but omnipotent monarch when it comes to gameplay design.

At the end of the day, game development is a team sport. There is a 100% chance of disagreement on all game projects, so make sure you have the process, hierarchy, and prioritized plan to handle it!

You should have a clear sense of the things you are trying to achieve. This list will consist of multiple entries so an established hierarchy of priorities. This will be one input . The other is the effort required to achieve any suggested steps/points. If you and your teammates have different idea on what should be done next, being clear on what is the (first) priority for your project, anjd how much time each suggestion will take should help you make the decision on where to go fisrt at least. In reality you'll probably end up exploring both options and then some because rarely does anything work the first time around. Plan your budget and deadlines accordingly.

When I see internal conflicting viewpoints, it often comes from not having a clear owner or driver for the feature. Instead of taking risks and getting stakeholder support, you end up designing by compromise to keep everyone happy. From my experience, building a game with many compromises leads to an experience that doesn't stand out and feels like everything else - booooring! Ideally, the team should empower a driver, understanding that the feature comes with some risk of failure. Prototype, test, and analyze the data to see if you're on the right track. Game development is a team sport, and like every sport, it can be intense and lead to disagreements. That's fine! It's part of the process. Just be sure to keep it polite.