Sicar Eneco
02.04.07, 04:08
It almost seems to become a weekly event that I stumble onto something interesting, but this time it actually has to do with NWN. Yay for that. I have to note, this post is mostly intended for mod/PW leaders. Upcoming mod/PW leaders actually. It's quite a long post (over 16000 characters) so it's split up in two, sorry for that. Enough whining, on to the actual post:
Hello. My name is Josh Sawyer. I am a game developer, formerly of Black Isle Studios, currently working for Midway San Diego. I’m not necessarily an expert on the game development process, but I have worked with quite a few producers and had the opportunity to see many different styles of project management and mismanagement. I see a lot of ambitious people set out to make mods, 90%+ of which are never completed. I don’t think it’s because the ideas aren’t sound or because the people involved are a bunch of idiots. I think it’s because the projects are a) poorly planned B) poorly scheduled and c) poorly managed in general.
It’s not common for projects to be successful in spite of mismanagement. Youcan certainly develop a game or mod without tight management, but you might as well wish, click your heels together, and hope that things will come together. Management takes time and is neither fun nor glamorous, but it is of vital importance to the success of a team endeavor. I’d like to suggest a process and some general tips on how to organize a mod project. These suggestions aren’t necessarily the best in the world. You may even think they are bad ideas, but they seem to work from my perspective. These suggestions assume that you, the initiator of the mod-making process, are the team leader/producer/god emperor. Don’t get too caught up on titles; only ego-tripping retards really give a damn anyway. If you’re the one coordinating things and getting the ball rolling, this post’s for you.
Before I begin with a phase breakdown, I’d like to suggest some general stuff:
Set up a web forum, IRC channel, mailing list, bug database and FTP site for your mod. There are a lot of free web forums. http://www.ezboard.com/ is a decent one. Finding an IRC server to host your random channel isn’t necessarily that difficult, but may take time and require jumping through hoops. However, real-time discussion on a weekly basis is pretty important for team communication, camaraderie, and general cohesion. Mailing lists are a good way to prick the ears of people who may not read the boards every day or who were effectively put on a waiting list to joint the mod team. Just don’t abuse it. http://www.bugzilla.org/ is a pretty damned good open license bug tracking software package. The FTP site may be hard to swing for some people, but it’s really useful for organizing assets. Just give uploading privileges to people, organize the folder structure as you see fit, and it will make things much easier for everyone.
Don’t let people (or the entire team) drift. Keep people focused on the tasks at hand. A lot of people who volunteer for a mod just want to do the high-level fun stuff. A lot of the stuff in game development is not fun. However, if you can keep people focused on the milestone tasks (even the un-fun ones), the milestone build should show enough progress to really get people pumped. Un-fun tasks are rewarding when the payoff exceeds the drudgery.
If possible, use something like http://www.wikimedia.org for your master documents. Always keep backups of the source files, but it is best if the entire team has access to one version of documents. It helps prevent confusion when changes are made. Of course, always inform your team members when documents have changed, and let them know what has changed and where they can see what has changed.
VISION PHASE (team lead)
Establish what you are trying to accomplish with your mod. Are you simply trying to create a set of new levels? Are you going to change the HUD? Are you going to add new weapons? Are you going to add new character models to the game with new animations? Cover breadth and depth. How many new levels? How many new monsters?
Justify why anyone should give a **** about what you’re doing. Why is this fun? If you want to make a mod because you personally think it’s fun, despite its narrow appeal, that’s fine. However, it’s easier to get people (including potential team members) excited about what you’re doing when you can quickly and clearly tell them why what you’re doing is going to be fun and exciting.
When you have determined what you want to do and why it will be fun, write it down in clear, concise terms for dissemination to people who may want to work on your mod. You really do not want to bring people on board only to have them leave halfway through the project because they misunderstood what the team/you was/were trying to accomplish. Keep everyone focused on your goals from the beginning, and remind yourself of them through the project.
Given the scope of your mod, make a rough estimate of how many team members you will need. At this stage, you are guessing, because you will not have a good idea of what is involved with every task. However, you should be able to estimate certain things. E.g., if your goal is to make new levels and use existing tools to modify things, you probably will not touch code and will not need programmers. However, you will need level designers to lay out maps and 2D artists to create textures. Break down your needs into four sub-team disciplines: design, art, programming, and audio.
For every discipline you will be staffing, try to find one really good team member. Do not try to staff the entire team immediately. As the project director, you have a good idea of the vision, but you may be abysmal at analyzing the details of implementing that vision. Before you throw 4-8 “artists” at a mod, you need a level-headed, informed analysis of your art needs. Find one good artist first. Find one good programmer if you need one. And hey, if one is all you need, that’s great. If a deluge of people volunteer, thank them for their submission, but tell them that it will be a short while before you fully staff up. Keep in contact with them throughout pre-production so they don’t drift away. PROTIP: You may find people who would like to help you, are super bitchin’, but just don’t have the time. Consider politely asking them for their help in analyzing other applicants, particularly if you don’t know enough about the discipline to separate the wheat from the chaff. Now that you have a core team, it’s time for pre-production.
PRE-PRODUCTION (team lead and core team)
Once you have established your core team, disseminate your vision document for analysis. The goal is for the core team to seriously analyze the scope of the project and break it down into realistic lists of tasks. THE ESTABLISHMENT OF A TASK LIST IS OF VITAL IMPORTANCE TO THE SUCCESSFUL MANAGEMENT OF YOUR PROJECT. Remember, for everything you want to accomplish, someone has to make it happen. Things don’t magically get done. Even the smallest tasks should be listed (within reason of course -- just try to be thorough). Accompanying the task lists should be asset lists. An asset is any object (usually an art object, but possibly a table file or other bit of data) that needs to be created for use in the game. E.g.: One of the tasks is the creation of Monster X. Implicit in the creation of Monster X are the creation of Monster X’s data (in code or through an editor), its model, its textures, its skeleton, and its animations. When you schedule these tasks out, you may group them in the task list for simplicity (i.e.: Monster X’s animations), but be sure to actually list all of those assets out in a team-available list somewhere. If you don’t list it, you might as well assume that it is not going to be created.
Create master documents for each discipline. These documents will effectively be the blueprints and guides for how your mod is completed. They will be referenced by other members of the core team and by the larger team during the production phase. The master documents should explain how each set of tasks will be completed and should list specifications for assets and processes where needed. If programmers will need a certain compiler or a set of libraries, make that perfectly clear. If the textures for level geometry need to all be power of two sizes, 4-bit, no larger than 512x512, .tga format, and come in under 2 megs on one load, it would be wise to list that out. The organization of these documents can be discussed by the core team, but the format should be decided by the team leader.
Organize your task list. Remove redundant entries. Promote communication between team members to recognize dependencies and risks. You may find that some of the core team members condemn an element of the vision as impossible or extremely high risk. If the team comes to a consensus on this, seriously consider revising the vision and scope of the project. Anything that is “risky” is something that should be implemented and tested as early as possible. This is particularly important if it’s an element of game play that could make or break the project. If you have a strange new mechanic or weapon that may drastically alter game play, implement it early and test it. If the whole project rests on that “new thing” and it sucks, there’s no point to continuing forward with the vision as written. Dependencies between tasks (e.g., you need this editor support before you can make this feature work) should be clearly noted for later integration into the schedule. All dependencies should be completed prior to the tasks that need them. I know it seems logical, but you’d be surprised how many people don’t “get it”.
Hello. My name is Josh Sawyer. I am a game developer, formerly of Black Isle Studios, currently working for Midway San Diego. I’m not necessarily an expert on the game development process, but I have worked with quite a few producers and had the opportunity to see many different styles of project management and mismanagement. I see a lot of ambitious people set out to make mods, 90%+ of which are never completed. I don’t think it’s because the ideas aren’t sound or because the people involved are a bunch of idiots. I think it’s because the projects are a) poorly planned B) poorly scheduled and c) poorly managed in general.
It’s not common for projects to be successful in spite of mismanagement. Youcan certainly develop a game or mod without tight management, but you might as well wish, click your heels together, and hope that things will come together. Management takes time and is neither fun nor glamorous, but it is of vital importance to the success of a team endeavor. I’d like to suggest a process and some general tips on how to organize a mod project. These suggestions aren’t necessarily the best in the world. You may even think they are bad ideas, but they seem to work from my perspective. These suggestions assume that you, the initiator of the mod-making process, are the team leader/producer/god emperor. Don’t get too caught up on titles; only ego-tripping retards really give a damn anyway. If you’re the one coordinating things and getting the ball rolling, this post’s for you.
Before I begin with a phase breakdown, I’d like to suggest some general stuff:
Set up a web forum, IRC channel, mailing list, bug database and FTP site for your mod. There are a lot of free web forums. http://www.ezboard.com/ is a decent one. Finding an IRC server to host your random channel isn’t necessarily that difficult, but may take time and require jumping through hoops. However, real-time discussion on a weekly basis is pretty important for team communication, camaraderie, and general cohesion. Mailing lists are a good way to prick the ears of people who may not read the boards every day or who were effectively put on a waiting list to joint the mod team. Just don’t abuse it. http://www.bugzilla.org/ is a pretty damned good open license bug tracking software package. The FTP site may be hard to swing for some people, but it’s really useful for organizing assets. Just give uploading privileges to people, organize the folder structure as you see fit, and it will make things much easier for everyone.
Don’t let people (or the entire team) drift. Keep people focused on the tasks at hand. A lot of people who volunteer for a mod just want to do the high-level fun stuff. A lot of the stuff in game development is not fun. However, if you can keep people focused on the milestone tasks (even the un-fun ones), the milestone build should show enough progress to really get people pumped. Un-fun tasks are rewarding when the payoff exceeds the drudgery.
If possible, use something like http://www.wikimedia.org for your master documents. Always keep backups of the source files, but it is best if the entire team has access to one version of documents. It helps prevent confusion when changes are made. Of course, always inform your team members when documents have changed, and let them know what has changed and where they can see what has changed.
VISION PHASE (team lead)
Establish what you are trying to accomplish with your mod. Are you simply trying to create a set of new levels? Are you going to change the HUD? Are you going to add new weapons? Are you going to add new character models to the game with new animations? Cover breadth and depth. How many new levels? How many new monsters?
Justify why anyone should give a **** about what you’re doing. Why is this fun? If you want to make a mod because you personally think it’s fun, despite its narrow appeal, that’s fine. However, it’s easier to get people (including potential team members) excited about what you’re doing when you can quickly and clearly tell them why what you’re doing is going to be fun and exciting.
When you have determined what you want to do and why it will be fun, write it down in clear, concise terms for dissemination to people who may want to work on your mod. You really do not want to bring people on board only to have them leave halfway through the project because they misunderstood what the team/you was/were trying to accomplish. Keep everyone focused on your goals from the beginning, and remind yourself of them through the project.
Given the scope of your mod, make a rough estimate of how many team members you will need. At this stage, you are guessing, because you will not have a good idea of what is involved with every task. However, you should be able to estimate certain things. E.g., if your goal is to make new levels and use existing tools to modify things, you probably will not touch code and will not need programmers. However, you will need level designers to lay out maps and 2D artists to create textures. Break down your needs into four sub-team disciplines: design, art, programming, and audio.
For every discipline you will be staffing, try to find one really good team member. Do not try to staff the entire team immediately. As the project director, you have a good idea of the vision, but you may be abysmal at analyzing the details of implementing that vision. Before you throw 4-8 “artists” at a mod, you need a level-headed, informed analysis of your art needs. Find one good artist first. Find one good programmer if you need one. And hey, if one is all you need, that’s great. If a deluge of people volunteer, thank them for their submission, but tell them that it will be a short while before you fully staff up. Keep in contact with them throughout pre-production so they don’t drift away. PROTIP: You may find people who would like to help you, are super bitchin’, but just don’t have the time. Consider politely asking them for their help in analyzing other applicants, particularly if you don’t know enough about the discipline to separate the wheat from the chaff. Now that you have a core team, it’s time for pre-production.
PRE-PRODUCTION (team lead and core team)
Once you have established your core team, disseminate your vision document for analysis. The goal is for the core team to seriously analyze the scope of the project and break it down into realistic lists of tasks. THE ESTABLISHMENT OF A TASK LIST IS OF VITAL IMPORTANCE TO THE SUCCESSFUL MANAGEMENT OF YOUR PROJECT. Remember, for everything you want to accomplish, someone has to make it happen. Things don’t magically get done. Even the smallest tasks should be listed (within reason of course -- just try to be thorough). Accompanying the task lists should be asset lists. An asset is any object (usually an art object, but possibly a table file or other bit of data) that needs to be created for use in the game. E.g.: One of the tasks is the creation of Monster X. Implicit in the creation of Monster X are the creation of Monster X’s data (in code or through an editor), its model, its textures, its skeleton, and its animations. When you schedule these tasks out, you may group them in the task list for simplicity (i.e.: Monster X’s animations), but be sure to actually list all of those assets out in a team-available list somewhere. If you don’t list it, you might as well assume that it is not going to be created.
Create master documents for each discipline. These documents will effectively be the blueprints and guides for how your mod is completed. They will be referenced by other members of the core team and by the larger team during the production phase. The master documents should explain how each set of tasks will be completed and should list specifications for assets and processes where needed. If programmers will need a certain compiler or a set of libraries, make that perfectly clear. If the textures for level geometry need to all be power of two sizes, 4-bit, no larger than 512x512, .tga format, and come in under 2 megs on one load, it would be wise to list that out. The organization of these documents can be discussed by the core team, but the format should be decided by the team leader.
Organize your task list. Remove redundant entries. Promote communication between team members to recognize dependencies and risks. You may find that some of the core team members condemn an element of the vision as impossible or extremely high risk. If the team comes to a consensus on this, seriously consider revising the vision and scope of the project. Anything that is “risky” is something that should be implemented and tested as early as possible. This is particularly important if it’s an element of game play that could make or break the project. If you have a strange new mechanic or weapon that may drastically alter game play, implement it early and test it. If the whole project rests on that “new thing” and it sucks, there’s no point to continuing forward with the vision as written. Dependencies between tasks (e.g., you need this editor support before you can make this feature work) should be clearly noted for later integration into the schedule. All dependencies should be completed prior to the tasks that need them. I know it seems logical, but you’d be surprised how many people don’t “get it”.