Producing a Video Game

Setup Version Control

Version Control Systems (VCS) let you backup your work, keep a history of changes, and collaborate with multiple developers on the same project. Pick a system that works bet for you and your team.

A distributed VCS, such as Git, keeps a copy of the codebase and the change history on a repository on all machines. When a user pushes changes to the master repository, other users can pull those changes to their machines. Users can also make branches of the codebase to isolate development, then merge the changes into the master copy.

A centralized VCS, such as Perforce, keeps a master copy and the change history on a central server. Users connect to the server and checkout a copy of a file they would like to work on. Checking out a file locks it out, and prevents other users from modifying it until the file is checked back in.

Git is the most widely used VCS because it is easy to learn, setup, and use. Remote work is also easily supported thanks to the multitude of platforms that offer free cloud hosting for git repositories. But large files and large change histories may be an issue for machines with little local storage space.

Perforce is widely used in AAA Studios because it's excellent for projects with a lot of large assets and files. Users only have to copy files to their machine that they need to work on. Users also can't work on the same file simultaneously.

Select a VCS that works best for your team and the project's needs.

Version Control Recommendations

Version Control Systems

Git LogoPerforce LogoPlsticSCM LogoPerforce includes GUI Client.
Plastic includes GUI Client and offers Repo Hosting.

Version Control Repo Hosts

Github LogoBitbucket LogoGitlab LogoAssembla LogoGithub, Gitlab, and Bitbucket are mainly for Git repo hosting.
Assembla is mainly for Perforce hosting.

Git GUI Clients

Sourcetree LogoGitkraken Logo

Full list of Version Control Systems, Hosts, and Tools

Setup Task Management

Use a task management process in order to keep track of tasking on a daily, weekly, and monthly basis. Pick a method that works best for you and your team.

If you are working as a solo dev or in a small team, then it's usually best to use TODO lists and Kanban Boards. Some are as simple as paper TODO lists, sticky note scrum boards, or digital kanban boards.

If you are working with a very large team, then a more complex system is necessary. Agile task manamgement applications let teams plan out a production schedule, organize development, track progress, and report issues.

Use the system that fits your needs and works best for you.

Task Managment Recommendations

TODO Lists Methods

Pencil and Paper

Sticky Notes


Text File

TODO Lists Apps

Todoist LogoTickTick LogoEvernote Logo

Collaborative Tasking and File Sharing

Trello LogoGoogle Drive LogoConfluence LogoNotion LogoClickup Logo

Agile Production

Jira LogoAzure Devops LogoHansoft Logo

Full List of Task Management Software

Set Goals and Deadlines

Set goals for what you want to accomplish.
Set deadlines for when you want to accomplish them.

Make a list of tasks you would like to complete. Make these lists every day, week, or as often as you need to.

Set a goal for what state you want to game to be in after a week, two weeks, or a month of work. Set a deadline for when you want to release your game.

Deadlines are a means to motivate production, as they encourage team members to make progress on the project. Completing tasks regularly helps maintain your team's motivation. Don't forget to take a moment to celebrate when you achieve a major goal.

The most important factor is that progress is being made on developing your game. If you miss a deadline, re-evaluate your team's production capacity and set a new deadline.

If you'd like, you can make an estimate of how long it will take to produce your game. Estimate how long each feature will take to develop and sum them all up. Take the sum and then double it, this is to account for time needed to iterate design, polish gameplay, and fix bugs. For a more conservative estimate, triple the sum of the Feature estimates.

Major Production Goals

Proof of Concept (Prototype)
After rapid prototyping, a Proof of Concept build is made to validate the game's design. At this stage, the game should contain most of the core components that make up the game experience. The game should be fun on gameplay alone, as a majority of the visual and audio assets are placeholder.

Vertical Slice (Pre-alpha)
The Vertical Slice is a polished pre-alpha demo that showcases all of the game's core features with mostly finalized assets. The demo should contain all of the gameplay experiences that a player will encounter. It does not need to showcase all the content, but the content presented within the demo should be finished. The levels used to make the Vertical Slice don't have to be in the final product.

Code Complete (Alpha)
Code Complete is when all of the programming that makes up the game has been completed and fully implemented. At this stage, the game is considered to be in Alpha. Programmers will pivot to fixing bugs and glitches that exist in the game. If resources are available, developers can program features intended for the Desired Product.

Content Complete (Beta)
Content Complete is when all the art and audio assets have been created and implemented into the game. At this stage, the game is considered to be in Beta. Artists will fix or polish any issues with assets that exist in the game. If resources are available, artists and designers can continue making content for the Desired Product.

Gold Master (Final)
The Gold Master is a finished product that contains the minimum amount of content that was planned to be released to market. All features and content are complete and all critical bugs have been fixed. This version of the game is considered to be the Minimum Viable Product. Major and minor bugs may still exist and might get fixed either prior to getting printed to disc or as a Day 1 patch. If time is available, developers can work on additional features and content.

Post-Launch Updates (Sustainment)
After launch, developers transition into producing Post-Launch Updates, aka Downloadable Content (DLC). The most common updates are patches, which include bug fixes and balance changes. Content updates, aka Expansions, typically include new levels, characters, and gameplay experiences. Content updates can either be released for free or as paid DLC. Development of Post-Launch content may follow a similar set of production goals as the ones listed above.

Develop Iteratively

Just like modern Software Development, game development is an iterative process. To support frequent design changes, studios often utilize an Agile model of development using a Scrum Framework.

The premise of Agile is to make software with a focus on the end-user experience. Production is flexible and open to rapid design changes. Regular reviews of the product are done to verify and validate the product. Through continuous iteration and collaboration, the product continues to evolve and improve.

The Scrum Framework assists in achieving an Agile model of development. At the start of a project, development is brokendown into sprints. Each sprint has a set of features that developers work on implementing. At the end of the sprint, users and testers evaluate the product by submitting feedback and bug reports. Lastly, developers review the feedback and integrate plans for design changes and bug fixes into future sprints.

Agile 101 - Agile Alliance
What is Scrum? -

Facilitating Production

Create a Backlog of Tasks
Determine which features take priority for development and break them out into a collection of tasks. Assign tasks to the appropriate team members that will work on them during the sprint.

Set a Deadline for the Sprint
Set a weekly, biweekly, or monthly deadline for when the tasks in the backlog should be completed. You can also set deadlines for tasks within the sprint.

Develop the Game
Let team members work on the tasks assigned out to them. Review the work as it is delivered. Development continues until the end of the sprint.

Playtest the Game
Verify features are implemented and validate the user experience. Let testers provide feedback and report any bugs or glitches. If you have a dedicated test team, testing can be done alongside development.

Evaluate Production
Ask questions such as: How many tasks are still in the backlog? What is the teams production capacity? Is production on schedule? Are there any issues with team members that need to be addressed?

Review Feedback
Discuss any feedback and bugs. Prioritize and create future task work to address them.

Start a New Sprint
Rinse and Repeat.

Designs are Always Subject to Change

Video games are an artistic endeavor. The game you originally envisioned will not necessarily be the game that gets shipped.

Features need to be built and tested in order to validate a design. A Feature that looks good on paper may turn out to be a horrible gameplay experience. Along with criticism, players will often suggest improvements or changes to existing design. Even bugs and glitches can potentially become features or lead to other design changes.

Based on the feedback you receive, your team will have to decide whether to keep existing design, improve it, scrap it, or implement a new design.

Design changes can continue to be made long after a game is release. You can address feedback and introduce new features, new content, gameplay balancing, and bug fixes with post-launch updates.

Post Mortem

Congratulations!!! You’ve finished your game and released it to market.

Sales numbers are rolling in and you see a surge of active users. Your team gets word from the community of various bugs and glitches. Critics and users write reviews and provide feedback.

Or, the project was a complete mess.

Production was plagued by delays due to mismanagement and constant design changes. Team members couldn't work together and constantly argued over creative differences. Maybe you had to cancel development because the project ran out of money. Or maybe you still managed to release the game, but was met with poor sales and scathing reviews.

Post Mortems are meant to be a learning opportunity for team members. Ask questions such as: Did the team meet the original production schedule? Did the team have to Crunch and/or delay the release? Was production within budget? Does the game that was created match the original creative vision? Is the team satisfied with the results? Are players satisfied with the results? Did you reach your projected sales goals? How was the game received by the audience? What parts of the development process worked well? What mistakes were made along the way that could've been avoided? What processes could be improved and implemented in future projects? Is there any work that was completed that can be reused for future projects? Does the team feel like they can continue working together on future projects?

It’s important to learn from the experience and for everyone to provide constructive criticism. Nobody is perfect, and there is plenty of room for growth. Take what you learned and apply it to improve the success of future projects.

Last Modified: 2020/09/07