Skip to content

Best Practice: Starting & Managing a New Project

You are here:
Estimated reading time: 7 min

Best Practice: Starting & Managing a New Project

This document provides an overview of the best practices and overall strategy for starting and managing a new game project as a designer. It provides tips and guidance based on experience, to help set priorities and establish a pipeline so that the game can get a successful start and build momentum towards becoming a polished and finished Mega Cat Masterpiece.

Guiding Philosophy

The overall purpose of this doc is to make sure that everyone – designers, developers, artists – are doing what they need to be doing, in the right order and at the right time. This is especially useful in keeping everyone focused on what needs to be done to bring the game to the next step in its evolution towards a final product.

You can’t make the sauce without even finishing the main dish! – Len, MCS Game Designer


Every game will start as a concept, the product of divine inspiration or perhaps valiant cohesion of a brainstorming session. To gain inspiration, you may try to think of mashing up two genres, or taking a familiar concept and turning it on its head. You may try tweaks within a genre.

This talk by Bayonetta Developers Platinum Games provides some insight on how to create pillars of gameplay and subsystems that all support each other for different layers of depth, for different types of audiences (from more casual players to hardcore gamers).

As the designer, it is up to you to take everyone’s ideas (or your own) and turn them into a cohesive design. 

III. Initial Documentation

The best thing a designer or other team member can do to take this from concept to the foundation for a game is to write these ideas down. These initial documents will make your ideas shareable and actionable for other team members

Best Practices for Documentation

  • Be thorough and clear
  • Use an Index
  • Use Google Docs with editing privileges set to “anyone”
  • Make docs actionable
    • The doc should be meaningful and useable by the person you are sending it to. For example, when sending an “Enemy Doc” to an artist, they will need to know details about the enemy’s appearance, behavior, personality, and animations. An “Enemy Doc” for a developer, on the other hand, would contain more information about their stats, formulas, and behavior as related to other systems (what loot they carry, for example)
  • Have docs reviewed by other team members
  • Provide extra detail as necessary

Design Doc

This document should provide a bird’s eye view of the game. It should be an overview of the concept, major features/systems, the character, plot, world/lore, etc.

Remember that this doc should summarize each concept. The goal of the DD is to communicate the overall flavor of the game, and to give other team members a grasp of the major mechanics. The design document should convey the vision for the game, not the details.

Eventually, this doc will provide links to other docs/content.

The design doc will be shared with other members of the team, such as the developer, lead artist, etc. These individuals can provide helpful feedback and insight as to whether your designs are feasible, or they may ask questions to ensure that you are thinking about everything you need to be thinking about.

Vagrant Kit Instructions

A “vagrant kit” is all the art assets a developer would need to make a basic demo of the game. This generally includes:

  1. Player Character and animations
  2. One background/environment/level
  3. HUD
  4. One enemy or primary game object
  5. Misc Assets
    1. Such as collectables, projectiles for the player character or enemies, etc

It is important that this doc be geared towards an artist. That is, it should contain visual references for the style of the game or the appearance of the character/objects. 

For retro projects, a “Technical Considerations” section is necessary to provide some guidelines on the console restrictions, limits on the number of frames in each animation, guidelines for palettes, etc.


A game’s index page is like a table of contents to all of the documentations and resources for the project. It links to everything the game’s team will need to complete their tasks.

This is where you should be thorough and exhaustive. Include links here for EVERYTHING. 

Organize the documentation alphabetically by content area (with the exception of putting the DD as the first link). Use a bulleted list to nest related subtopics under a parent topic.

The index is a living document, that will expand and evolve with more links as new documentation is created.

Milestone Doc

The Milestone Doc is a comprehensive breakdown of the systems in the game and when they will be implemented. As a rule, it is important to put the core systems of a game on the first few milestones, and relegate content and smaller features to the last few milestones. We generally do four milestones for games.

It is also common to see a system across several milestones. On the first milestone, a mechanic can be established with a bit of content (for example, the “Equipment” milestone might at first simply creating the equipment screen and the logic behind it, as well as the system that supports the use of various weapons and armor). Later milestones would add content to that feature (so in the second milestone and beyond, the “Equipment” task would be implementing the stats or behavior for new chunks of equipment).

Best practices for a milestone doc include a few columns with links to the documentation and resources (art assets, SFX, etc) the developer will need for each line item. Each row should be a task. You should also create a column for time estimates for each task. On larger projects with more than one developer, a column with assignments for each task is also helpful.

Also include “bug testing and polish” as a line item for each milestone. Before the developer can claim a milestone, you want to make sure the game you have is polished and bug-free.

III. Vagrant Kit and First Build

After some of the initial documentation is in place and the vagrant kit assets are prepared, the developer can begin to create the first playable build of the game. 

Playtesting is crucial at this phase to ensure that basic mechanics you envisioned are in place and functioning properly. 

This is also when you should be thinking about the rest of the project and planning it out.

First Demo Sprint

The difference between the first build and first demo is that the first demo is something that could be shown to an external figure – a client, a fan at a convention, or even a potential publisher. Overall, this experience needs to be more polished and more content-rich.

The main goal here is a “core game loop.” A core game loop is basically a complete set of gameplay experiences, as well as the framing material for the game. This should include:

  • Title Screen/Main Menu
  • Core Gameplay Segments
    • This should be a finished level or “complete” experience with some win/loss mechanics. So if you are making a platformer, death and dying should be implemented
  • Game Over/Game Win Screens
    • These let the player know they have completed the demo, or failed to complete the demo

This demo will also have different levels of polish, depending on the audience. For example, a convention build that will be seen by fans only does not need as much production value as a build that is being sent to a client or publisher.

A good metaphor for this stage of the project is to think of the entire game as a house. For the first demo, we want to have a front door and really interesting, exciting room. We do not want to have a whole house of half-finished, broken rooms. Breadth of content is important, but only that which you can provide to a polished degree in the time allotted.

The Middle Phase

The most exciting times for any project are when it is started and when it is finished. These are periods of intense attention and enjoyment by everyone.

The middle phase, however, is where the work happens. Consequently, it is where most of the periphery people will fall away. It is up to you, as the designer, to make sure that your project is abandoned. You should continue to create content and playtest with the developer to ensure that the project progresses.

The middle phase can feel like a slog, and requires discipline and stamina. However, it is also extremely gratifying to work with your team and watch as the game we have planned comes to life.

The middle phase can also be exciting for designers, as this is where you will create most of the additional documentation for new content (new enemies, new levels, new bosses, etc). You always want to stay ahead of the developer, and have assets (art, SFX, etc) created ahead of time.

In general, it is best to introduce new systems with a small bit of content and then test to refine them. For example, rather than creating all 30 enemies for a game, it is best to create a few, test them and the mechanics of combat, make any necessary changes to the combat documentation, and then create new enemy content for each new area as you begin working on it. This will ensure that the system is refined before you load it up with content.

Additional Documentation

There will be much documentation created during this phase as you provide details for each new system or explain content for each new mechanic or content block. Remember to make these documents actionable for the team member you are sending them to. 

Also, remember to stay ahead of the dev in terms of art and other resources. Look at the milestone doc and make sure you have things ready well in advance, so that the developer is not waiting for you on anything.

Playtesting Doc

Create a playtesting/bug tracking doc and pin it to the project’s Slack channel. This should be used throughout development to track bugs and make notes on polish and improvements. We typically use a Google Sheet for this as it is fast, accessible, and easy. 

As the designer, it will be up to you to test the game to make sure things are functioning as intended/designed. We have a few specialists that can help with things like game feel, but in general it is up to you to test and see if the game is working properly.

Sprint Docs, Producer Lists, and Punch Lists

Sometimes it is necessary to create a document which is separate from the Milestone Doc that contains detailed information about exactly what the dev should be doing next. This can be helpful when the team is trying to focus on a specific set of tasks. 

For example, a convention may be coming up and the team knows they have to make the Snow Level as polished as possible, so rather than worrying about implementing new systems, everyone is focused on adding and refining content for this level.


No design survives the battlefield. Many times, after playing the game, you realize that a system needs rethought or redesigned. Do not get discouraged. This is a normal part of the game design process, and something which is necessary to improve games.

Many times, you will not see how a mechanic can be improved until you play it. Other times, the developer or artist may have a great idea that you can implement. Still in other cases you have a moment of inspiration while playing your creation. All of these elements can be harnessed to upgrade your game.

Project Conclusion

As the project comes to a close, more and more people will come to playtest it. Final touches will be added.

This is also a good time to reflect on the project and make a note about what went well, what can be repeated, and what should be avoided. The lessons learned from experience on one project can give you a leg up on your next project. 

Remember, wisdom is the scar tissue of life. So get in the trenches and take your game to victory.

Was this article helpful?
Dislike 0
Views: 20
Back To Top