Mixing
As a client, trying to get a coder/programmer to develop my ideas into a functioning program, what should I be providing to my developer(s)?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
2
down vote
favorite
I am the director of a start-up game development group (I say "group" because it is not yet an official company). I have recently gained the willingness of a few coders who are willing to help me with the project, but they are asking for documentation.
I understand the need for documentation, and I have a lot of our ideas in a few different documents, but I imagine that I will want to organize it in some way that the developers can understand individually as well as collectively.
Is there anything I should leave out of such a document; if so, what kind of things? Is there an appropriate template for this kind of document; if yes, where can I find it? Is there anything else that I should know to offer the coders before they begin their work?
I know that I have many questions being asked here. I hope that isn't a problem. Thank you in advance for any guidance!
documentation design-document outsourcing
edited 1 hour ago
Alexandre Vaillancourt♦
12.1k103647
asked 2 hours ago
Graham Lewis
111
New contributor
Graham Lewis is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
2
down vote
favorite
I am the director of a start-up game development group (I say "group" because it is not yet an official company). I have recently gained the willingness of a few coders who are willing to help me with the project, but they are asking for documentation.
I understand the need for documentation, and I have a lot of our ideas in a few different documents, but I imagine that I will want to organize it in some way that the developers can understand individually as well as collectively.
Is there anything I should leave out of such a document; if so, what kind of things? Is there an appropriate template for this kind of document; if yes, where can I find it? Is there anything else that I should know to offer the coders before they begin their work?
I know that I have many questions being asked here. I hope that isn't a problem. Thank you in advance for any guidance!
documentation design-document outsourcing
edited 1 hour ago
Alexandre Vaillancourt♦
12.1k103647
asked 2 hours ago
Graham Lewis
111
New contributor
Graham Lewis is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I am the director of a start-up game development group (I say "group" because it is not yet an official company). I have recently gained the willingness of a few coders who are willing to help me with the project, but they are asking for documentation.
I understand the need for documentation, and I have a lot of our ideas in a few different documents, but I imagine that I will want to organize it in some way that the developers can understand individually as well as collectively.
Is there anything I should leave out of such a document; if so, what kind of things? Is there an appropriate template for this kind of document; if yes, where can I find it? Is there anything else that I should know to offer the coders before they begin their work?
I know that I have many questions being asked here. I hope that isn't a problem. Thank you in advance for any guidance!
documentation design-document outsourcing
edited 1 hour ago
Alexandre Vaillancourt♦
12.1k103647
asked 2 hours ago
Graham Lewis
111
New contributor
Graham Lewis is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
I am the director of a start-up game development group (I say "group" because it is not yet an official company). I have recently gained the willingness of a few coders who are willing to help me with the project, but they are asking for documentation.
I understand the need for documentation, and I have a lot of our ideas in a few different documents, but I imagine that I will want to organize it in some way that the developers can understand individually as well as collectively.
Is there anything I should leave out of such a document; if so, what kind of things? Is there an appropriate template for this kind of document; if yes, where can I find it? Is there anything else that I should know to offer the coders before they begin their work?
I know that I have many questions being asked here. I hope that isn't a problem. Thank you in advance for any guidance!
documentation design-document outsourcing
documentation design-document outsourcing
edited 1 hour ago
Alexandre Vaillancourt♦
12.1k103647
asked 2 hours ago
Graham Lewis
111
New contributor
Graham Lewis is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 1 hour ago
Alexandre Vaillancourt♦
12.1k103647
asked 2 hours ago
Graham Lewis
111
New contributor
Graham Lewis is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited 1 hour ago
Alexandre Vaillancourt♦
12.1k103647
edited 1 hour ago
Alexandre Vaillancourt♦
12.1k103647
edited 1 hour ago
Alexandre Vaillancourt♦
12.1k103647
12.1k103647
asked 2 hours ago
Graham Lewis
111
New contributor
Graham Lewis is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked 2 hours ago
Graham Lewis
111
asked 2 hours ago
Graham Lewis
111
111
New contributor
Graham Lewis is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Graham Lewis is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Graham Lewis is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
2
down vote
Game development usually works a bit different than application development. The reason is that games usually have far less and far stringent requirements. You don't have a well-defined business problem your software is supposed to solve. The only true requirements of a game are "runs properly on the target platform", "appeals to the target demographic" and "is fun to play" (and maybe "sells a lot of microtransactions" if you are in that section of the industry). Everything else is subject to change during the development.
However, in order to make sure that all developers of the game are working in the same direction and not end up fighting to the death over creative differences, you should have some codified "vision" of how you want the final game to look and play. This vision is usually codified in a Game Design Document. Such a document usually describes:
- The basic premise of the game:
- The elevator pitch: The main game idea, described as briefly as possible.
- What is the genre of the game?
- Who is your target demographic?
- Which platform(s) are you targeting?
- The game mechanics:
- What actions can the player perform in this game and how do they affect the game?
- What non-player entities are in the game, how do they behave, and how do they interact with each other and with the player?
- The scope:
- How much content do you want the game to have?
- What level of quality do you want that content to have?
- The aesthetic direction of the game:
- What general atmosphere do you want the game to have?
- How do you want the game to look?
- How do you want the game to sound?
- When it comes to story, it depends a lot on the genre. Some games need no story at all. Many games only need a few sentences. But if you are creating a plot-driven game, like an RPG or adventure, then this can be in fact the longest part of the design document and can include:
- A description of the world in which the game takes place and its key locations
- A description of the important characters, their looks, their personality and their backstory
- A basic outline of the plot which is told during the game
If you look around the web, you can find a lot of templates for game design documents. The game industry is a lot less into formalities and standardized processes than the rest of the industry, so you won't find the one ISO-standard to rule them all. Just try to find one style which fits your project, your team and your work methodology.
However, be open to changes during development. When game design documents of popular games leak to the public, either intentionally or unintentionally, you can usually notice something interesting. If you compare these early design notes to the finished game, there will usually be lots of considerable differences. This is usually the result of a design process game developers call Fail Faster:
- Come up with a rough design
- Create a simple prototype
- Playtest it with a critical mindset and figure out what does not work about it
- Revise your design
- Go back to stage 2
So do not be afraid to change or cut features when you realize during playtesting that they aren't actually as fun as they were in your head. Also, be open to suggestions from the team. Most people in the game development industry decided to join the industry because they want to put their own game ideas into practice. So giving your team some creative influence can be a great motivator for them. But as a good producer, it is also your duty to say "No!" if you think an idea wouldn't work or would exceed the budget.
I am looking forward to playing your game.
answered 1 hour ago
Philipp
75.1k19173226
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
Game development usually works a bit different than application development. The reason is that games usually have far less and far stringent requirements. You don't have a well-defined business problem your software is supposed to solve. The only true requirements of a game are "runs properly on the target platform", "appeals to the target demographic" and "is fun to play" (and maybe "sells a lot of microtransactions" if you are in that section of the industry). Everything else is subject to change during the development.
However, in order to make sure that all developers of the game are working in the same direction and not end up fighting to the death over creative differences, you should have some codified "vision" of how you want the final game to look and play. This vision is usually codified in a Game Design Document. Such a document usually describes:
- The basic premise of the game:
- The elevator pitch: The main game idea, described as briefly as possible.
- What is the genre of the game?
- Who is your target demographic?
- Which platform(s) are you targeting?
- The game mechanics:
- What actions can the player perform in this game and how do they affect the game?
- What non-player entities are in the game, how do they behave, and how do they interact with each other and with the player?
- The scope:
- How much content do you want the game to have?
- What level of quality do you want that content to have?
- The aesthetic direction of the game:
- What general atmosphere do you want the game to have?
- How do you want the game to look?
- How do you want the game to sound?
- When it comes to story, it depends a lot on the genre. Some games need no story at all. Many games only need a few sentences. But if you are creating a plot-driven game, like an RPG or adventure, then this can be in fact the longest part of the design document and can include:
- A description of the world in which the game takes place and its key locations
- A description of the important characters, their looks, their personality and their backstory
- A basic outline of the plot which is told during the game
If you look around the web, you can find a lot of templates for game design documents. The game industry is a lot less into formalities and standardized processes than the rest of the industry, so you won't find the one ISO-standard to rule them all. Just try to find one style which fits your project, your team and your work methodology.
However, be open to changes during development. When game design documents of popular games leak to the public, either intentionally or unintentionally, you can usually notice something interesting. If you compare these early design notes to the finished game, there will usually be lots of considerable differences. This is usually the result of a design process game developers call Fail Faster:
- Come up with a rough design
- Create a simple prototype
- Playtest it with a critical mindset and figure out what does not work about it
- Revise your design
- Go back to stage 2
So do not be afraid to change or cut features when you realize during playtesting that they aren't actually as fun as they were in your head. Also, be open to suggestions from the team. Most people in the game development industry decided to join the industry because they want to put their own game ideas into practice. So giving your team some creative influence can be a great motivator for them. But as a good producer, it is also your duty to say "No!" if you think an idea wouldn't work or would exceed the budget.
I am looking forward to playing your game.
answered 1 hour ago
Philipp
75.1k19173226
add a comment |Â
up vote
2
down vote
Game development usually works a bit different than application development. The reason is that games usually have far less and far stringent requirements. You don't have a well-defined business problem your software is supposed to solve. The only true requirements of a game are "runs properly on the target platform", "appeals to the target demographic" and "is fun to play" (and maybe "sells a lot of microtransactions" if you are in that section of the industry). Everything else is subject to change during the development.
However, in order to make sure that all developers of the game are working in the same direction and not end up fighting to the death over creative differences, you should have some codified "vision" of how you want the final game to look and play. This vision is usually codified in a Game Design Document. Such a document usually describes:
- The basic premise of the game:
- The elevator pitch: The main game idea, described as briefly as possible.
- What is the genre of the game?
- Who is your target demographic?
- Which platform(s) are you targeting?
- The game mechanics:
- What actions can the player perform in this game and how do they affect the game?
- What non-player entities are in the game, how do they behave, and how do they interact with each other and with the player?
- The scope:
- How much content do you want the game to have?
- What level of quality do you want that content to have?
- The aesthetic direction of the game:
- What general atmosphere do you want the game to have?
- How do you want the game to look?
- How do you want the game to sound?
- When it comes to story, it depends a lot on the genre. Some games need no story at all. Many games only need a few sentences. But if you are creating a plot-driven game, like an RPG or adventure, then this can be in fact the longest part of the design document and can include:
- A description of the world in which the game takes place and its key locations
- A description of the important characters, their looks, their personality and their backstory
- A basic outline of the plot which is told during the game
If you look around the web, you can find a lot of templates for game design documents. The game industry is a lot less into formalities and standardized processes than the rest of the industry, so you won't find the one ISO-standard to rule them all. Just try to find one style which fits your project, your team and your work methodology.
However, be open to changes during development. When game design documents of popular games leak to the public, either intentionally or unintentionally, you can usually notice something interesting. If you compare these early design notes to the finished game, there will usually be lots of considerable differences. This is usually the result of a design process game developers call Fail Faster:
- Come up with a rough design
- Create a simple prototype
- Playtest it with a critical mindset and figure out what does not work about it
- Revise your design
- Go back to stage 2
So do not be afraid to change or cut features when you realize during playtesting that they aren't actually as fun as they were in your head. Also, be open to suggestions from the team. Most people in the game development industry decided to join the industry because they want to put their own game ideas into practice. So giving your team some creative influence can be a great motivator for them. But as a good producer, it is also your duty to say "No!" if you think an idea wouldn't work or would exceed the budget.
I am looking forward to playing your game.
answered 1 hour ago
Philipp
75.1k19173226
add a comment |Â
up vote
2
down vote
up vote
2
down vote
Game development usually works a bit different than application development. The reason is that games usually have far less and far stringent requirements. You don't have a well-defined business problem your software is supposed to solve. The only true requirements of a game are "runs properly on the target platform", "appeals to the target demographic" and "is fun to play" (and maybe "sells a lot of microtransactions" if you are in that section of the industry). Everything else is subject to change during the development.
However, in order to make sure that all developers of the game are working in the same direction and not end up fighting to the death over creative differences, you should have some codified "vision" of how you want the final game to look and play. This vision is usually codified in a Game Design Document. Such a document usually describes:
- The basic premise of the game:
- The elevator pitch: The main game idea, described as briefly as possible.
- What is the genre of the game?
- Who is your target demographic?
- Which platform(s) are you targeting?
- The game mechanics:
- What actions can the player perform in this game and how do they affect the game?
- What non-player entities are in the game, how do they behave, and how do they interact with each other and with the player?
- The scope:
- How much content do you want the game to have?
- What level of quality do you want that content to have?
- The aesthetic direction of the game:
- What general atmosphere do you want the game to have?
- How do you want the game to look?
- How do you want the game to sound?
- When it comes to story, it depends a lot on the genre. Some games need no story at all. Many games only need a few sentences. But if you are creating a plot-driven game, like an RPG or adventure, then this can be in fact the longest part of the design document and can include:
- A description of the world in which the game takes place and its key locations
- A description of the important characters, their looks, their personality and their backstory
- A basic outline of the plot which is told during the game
If you look around the web, you can find a lot of templates for game design documents. The game industry is a lot less into formalities and standardized processes than the rest of the industry, so you won't find the one ISO-standard to rule them all. Just try to find one style which fits your project, your team and your work methodology.
However, be open to changes during development. When game design documents of popular games leak to the public, either intentionally or unintentionally, you can usually notice something interesting. If you compare these early design notes to the finished game, there will usually be lots of considerable differences. This is usually the result of a design process game developers call Fail Faster:
- Come up with a rough design
- Create a simple prototype
- Playtest it with a critical mindset and figure out what does not work about it
- Revise your design
- Go back to stage 2
So do not be afraid to change or cut features when you realize during playtesting that they aren't actually as fun as they were in your head. Also, be open to suggestions from the team. Most people in the game development industry decided to join the industry because they want to put their own game ideas into practice. So giving your team some creative influence can be a great motivator for them. But as a good producer, it is also your duty to say "No!" if you think an idea wouldn't work or would exceed the budget.
I am looking forward to playing your game.
answered 1 hour ago
Philipp
75.1k19173226
Game development usually works a bit different than application development. The reason is that games usually have far less and far stringent requirements. You don't have a well-defined business problem your software is supposed to solve. The only true requirements of a game are "runs properly on the target platform", "appeals to the target demographic" and "is fun to play" (and maybe "sells a lot of microtransactions" if you are in that section of the industry). Everything else is subject to change during the development.
However, in order to make sure that all developers of the game are working in the same direction and not end up fighting to the death over creative differences, you should have some codified "vision" of how you want the final game to look and play. This vision is usually codified in a Game Design Document. Such a document usually describes:
- The basic premise of the game:
- The elevator pitch: The main game idea, described as briefly as possible.
- What is the genre of the game?
- Who is your target demographic?
- Which platform(s) are you targeting?
- The game mechanics:
- What actions can the player perform in this game and how do they affect the game?
- What non-player entities are in the game, how do they behave, and how do they interact with each other and with the player?
- The scope:
- How much content do you want the game to have?
- What level of quality do you want that content to have?
- The aesthetic direction of the game:
- What general atmosphere do you want the game to have?
- How do you want the game to look?
- How do you want the game to sound?
- When it comes to story, it depends a lot on the genre. Some games need no story at all. Many games only need a few sentences. But if you are creating a plot-driven game, like an RPG or adventure, then this can be in fact the longest part of the design document and can include:
- A description of the world in which the game takes place and its key locations
- A description of the important characters, their looks, their personality and their backstory
- A basic outline of the plot which is told during the game
If you look around the web, you can find a lot of templates for game design documents. The game industry is a lot less into formalities and standardized processes than the rest of the industry, so you won't find the one ISO-standard to rule them all. Just try to find one style which fits your project, your team and your work methodology.
However, be open to changes during development. When game design documents of popular games leak to the public, either intentionally or unintentionally, you can usually notice something interesting. If you compare these early design notes to the finished game, there will usually be lots of considerable differences. This is usually the result of a design process game developers call Fail Faster:
- Come up with a rough design
- Create a simple prototype
- Playtest it with a critical mindset and figure out what does not work about it
- Revise your design
- Go back to stage 2
So do not be afraid to change or cut features when you realize during playtesting that they aren't actually as fun as they were in your head. Also, be open to suggestions from the team. Most people in the game development industry decided to join the industry because they want to put their own game ideas into practice. So giving your team some creative influence can be a great motivator for them. But as a good producer, it is also your duty to say "No!" if you think an idea wouldn't work or would exceed the budget.
I am looking forward to playing your game.
answered 1 hour ago
Philipp
75.1k19173226
edited 27 mins ago
answered 1 hour ago
Philipp
75.1k19173226
answered 1 hour ago
Philipp
75.1k19173226
answered 1 hour ago
Philipp
75.1k19173226
75.1k19173226
add a comment |Â
add a comment |Â
Graham Lewis is a new contributor. Be nice, and check out our Code of Conduct.
Graham Lewis is a new contributor. Be nice, and check out our Code of Conduct.
Graham Lewis is a new contributor. Be nice, and check out our Code of Conduct.
Graham Lewis is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fgamedev.stackexchange.com%2fquestions%2f164871%2fas-a-client-trying-to-get-a-coder-programmer-to-develop-my-ideas-into-a-functio%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
