What are the best practices for delivering games on time and within budget?

Entenda seu escopo claramente, fa?a a avalia??o do budget x tempo disponível. N?o tenha medo de enxugar algumas coisas do escopo, antes feito do que perfeito. No mundo de hoje os jogos v?o crescendo com o tempo e isso te garante um feedback dos jogadores mais assertivo com o passar do tempo

While writing the GDD, be sure to include, concepts in-scopes and exclusions, enabling the responsible team to know what needs to be prioritized. Game overview, narrative, mechanics, audio, level designs, UI, technical requirements are some components within it, there could be more a well. Be sure to firstly communicate with the team on the objectives and at the end of the document have a timeline on the rough schedule for the production. Changes are bound to happen, so keeping the document lightweight but with sufficient information to keep the production going is important while be prepared for any changes along the way. Include a certain amount of buffer for your resources while keeping everyone updated for changes along the way.

In the gaming industry, meticulous planning is key to staying on track. Break down tasks, estimate costs, and prioritize features. Create a timeline with buffer time, monitor progress, and be adaptable to changes. By planning carefully, you increase the chances of delivering games on time and within budget.

When it comes to shipping nothing is more important than clear scope. What does the alpha look like, what should the public beta test look like, and what level of tolerance is acceptable for budget/schedule overruns. Feature creep happens, as do design changes and budgetary surprises. All of these should be, in principle captured and be part of the original, elastic scope.

There are difference between delivering a game on a time and materials (T&M) basis compared to milestone/deliverable basis. In each case defining the scope is important at the outset and having a “change control” process contained within the contract with your client or publisher to avoid scope creep and set out the procedure if one party wants to make material changes to that pre-agreed scope. For T&M projects the scope can be more abstract as the developer is reacting to the needs of the client and payment is based on the time/staff provided to the project. For milestone based projects, a more specific scope is better for the developer to refer back to in the event of a dispute about what was expected to be delivered for each milestone.

Clear set roles and seperating you project into chunks always helps. You must make sure there are clear lines for communication between different sectors otherwise have everything broken up could actually slow production down. Manageable chunks - Clear Communication are vital.

Use a RACI matrix to note down the tasks and determining which team or person is responsible for completing the task, accountable for owning a set of decisions, consulted for input related to the work or informed about the task status. IF need be, you may add in supportive for personnel providing assistance to the task, making it RASCI matrix instead. When the development is too massive of a scale, consider Work Breakdown Structure to help in organizing the load. This ought to help in projecting a task's timeline and schedule for various task by breaking down down into manageable portions. While these are tools used by various PMs, there are also various other tools that could help in this. Use the one that best suits the team.

Some work-for-hire or publishing agreements list certain employees as "Key Staff" to which the project is deemed critical, and should such Key Staff leave the project it might give your client or publisher the ability to terminate the contract (normally following a period where you can replace that individual with someone else of equivalent skill/position). It is best practice for any list of Key Employees to be as short as possible i.e. it should not be the entire development team, and focus on discipline / project leads only. If there is not a mechanism to replace Key Employees without avoiding a breach of the contract then add one in!

Allow for contingency when planning your project, this can either be when estimating time for tasks or in the final budget. It's also important to remember all work is work so allow time for meetings, feedback and reviews. Auroch's method for this which has worked for multiple projects over the years is to plan development work for 4 days in a week and leaving a 5th day of time available to soak up everything else.

Throughout the development, having a plan to note and track will help to ensure the timeline for the game is kept. Kanban make use of post-its intensively, moving the things as progress reaches the completion stage, easily understood. Gantt chart provides an overview of timeline of each task, and measuring it according to the dates. Burn-down chart is useful to see the number of tasks reducing as you reach the end point. Budget planning will be tricky one, but if possible ensure you have enough buffers and use simulations like Monte Carlo or Decision Tree analysis to do some estimations through spreadsheets. There are many tools but it is always ideal to discuss with the team on the one that suits the team best.

When pitching your game to publishers having bronze, silver and gold options for funding x end product can help you plan what games features and content are possible for different budgets and schedules. It can also help you reach a realistic compromise with the publisher about what the finished product might include, and the time in which you can deliver it. In each case build some contingency into each milestone to help manage cash flow

This is part of the quality management phase, and continuous improvement is always needed which is vital for the longevity of game. Consider accessibility early and often, and encourage others on the team to do so too. Help users to help developers during the feedback phase so the team is able to obtain as much information needed for improvement and act on it. Consider the framework of PDCA: Plan: Identify issue and root cause, brainstorming solutions Do: Fix the issue/problem Check: Compare results to goal, determining if it is fixed. Act: Fine tune the fix to ensure continuous improvement. This process should be active and iterative, and as times goes it should be optimized and inducted as a best practice.

For client projects, or when working with publishers, having a delivery > evaluation > feedback mechanism is crucial. That way the developer has clarity as to when it has to deliver each deliverable or milestone. Additionally this should set out the criteria that the client or publisher is reviewing that deliverable or milestone against - this should tie to scope or milestone schedule. Such mechanism should also be clear as to how long the client/publisher has to review each deliverable, and how long the developer has to fix any material defects in what was delivered. As a developer ensure the contract contains a cure period in event of late delivery and allows for extensions of time for delays caused by the client or publisher.

Performance optimization will highly depend on game engine that you'll be going to use and target platforms. You should take into account that people will probably not play something that runs at 5 fps at their hardware. In regards to bugs - you should make sure that there's at least no critical or high priority bugs left in your backlog before going live.

If working with a publisher ensure that your agreed budget also includes costs covering post-launch support and big fixing. Most publishers will insist on a warranty period and, depending on the size of the game, anywhere from 3-12 months could be considered reasonable. This will be longer if it is a live service game. In theory game revenues will and should cover costs to provide post launch support but confirm revenue forecasts with your publisher to be certain when they anticipate they will break even and you will receive revenue from sales if you have not negotiated a revenue from the first copy sold.

(1) Manage ambition, scope and feature creep, identify priorities and cut non-essential elements (2) Critically review budgets to identify available costs and optimise production (3) Test with community feedback and early access (4) Research and analyse data to support decision making.

For video game developers, both the time for delivery and the budget available are largely determined by your publishing agreement. It is important to agree on a realistic milestone schedule and budget which leaves room for unforeseen circumstances. Additionally, it is important to: 1. have some clauses for unforeseen circumstances which mess up the timeline; 2. Prevent that if a Milestone is not accepted, a ‘negative spiral’ situation is created. I sometimes see that the delays caused by the rejection of milestones as well as the budget that isn’t paid (as payment is associated to accepted milestones) has a negative snowball effect on the progression of development.

Check the payment terms in your contract! How long does it take for the client or publisher to pay you your monthly fees or development costs after a deliverable has been approved. Build contingency into the budget to help with cash flow and be wary of payment terms longer than 30 days. Similarly for contracts where you are receiving a revenue share ensure the contract is clear about what deductions the client or publisher can make from gross receipts, whether they have to provide a report of copies sold etc., and how long it will take them to pay you any royalties.

As a producer/project manager/leader/director, saying NO goes a long way. Not an absolute NO, but offering trade-offs of what's possible or not. Sometimes, people forget that our NOs come from a place of caring, of wanting to deliver the game on quality and time, and keeping the team health without crunching. In my career, I've had to say NO and defend the reasons why I didn't think it was a good idea to introduce certain features/polishes in order to protect the delivery and the team.