22
Projects are massive tasks that take many hours of work to complete. The role of project manager is used to monitor and track progress throughout development and be the guide on leading a team to the deadline. It is not always an easy job, and it is quite the amount of work when coordinating a team. The role of project manager should be somebody willing to see the project finished and can motivate the workers into completing it.
Building a game in Minecraft is considered a large project. Even small games take lots of work, and successful projects will take large teams an abundance of time to complete. Whether adventure maps or architectural builds, it is important to know that these do not materialize out of nowhere. Project managers have to manage the progress of them, and their task is crucial to seeing a final product. The task is big enough that project managers group the project development into a lifecycle with five phases. At the start of every project is an idea: Conceive. This idea is then used to plan out the rest of the project: Define. The project development begins using the plans as guides to keep progress steady: Develop. The big ending is releasing the project for everybody to experience: Launch. After the launch the team does not rest yet, they reflect on how they did: Close. Understanding these phases will help make project managers in their adventures of making a project of their own.
Conceive: Whereo s that piece of paper, thereo s an idea to be taken down. All projects start with an idea (perhaps money to hire people, too), but this step is not so easy. An idea picked for a project will greatly benefit if it is fun, original, and/or an improvement on an idea. The idea is to have a lot of players to enjoy the game, and that is not going to happen if something has been done really well already (if ito s popular, it is a good idea to leave the idea alone).
When you get your idea, get a good grasp on it. Having an expert knowledge on every detail is not what this is about; the point is to be able to inform somebody else enough that they understand. A great idea is to come up with one sentence that covers the project and story. E.g. o Players navigate a maze to find a key for the exit while being chased by a hostile, player-controlled Minotaur.o or o Steve, the last super-Human, crashes onto a strange world where he must fight to reunite his shipo s crew, surpass enemy forces that occupy the lands, evade an ancient evil, before learning that the world was built to destroy all life and decide to destroy it.o
A big bonus to have done during this phase is getting a name for the project. Sometimes names are easy to come up with, but other times it can be excruciatingly difficult. If the task proves difficult, a smart idea is to write down any relevant word down even if it is kind of/maybe/only sometimes related. From there, pick any selection of words that stand out; combine them, mix them up or anything. Even if the results are not going to end up with a name, there is a good chance they brought out a good idea. With others, the results will be plenty and more interesting.
Define: The idea is picked, and it is a good idea to work with. People will enjoy playing, players will spend hours in it, and the project can be built in Minecraft. Before development can begin, however, there is plenty of planning to be done. The project scope is the first target: how big does this project go? From a small arena to an epic adventure, a project manager needs to have a concrete grasp on what the project entails. This phase can be done in two ways: a project manager can plan the entire game out at once or get the concrete idea down first, plan the next few parts, and return to plan out the game. However, planning out the game is essential; a game outline covers as much as possible to avoid grey areas which are very likely to cause issues later. Unless the project will be done by one person, every other person on the team will refer to the game outline on anything they can encounter. A grey areas means that it is up to that person to come up with a solution which might mess up with other parts of the game or not be what the project manager thought it would be.
The project as a whole also needs to be planned out; a project manager needs to know if a team is needed, how large it is, and when the team can finish by. A starting team should limit itself to people who know at least one other person. It is easier for new project managers and for team interaction. The experienced teams can afford new people because the experienced ones are able to pick up some drag the new people will start with (it takes time to adjust for even experienced workers). It is, however, important to limit the team size to one the project manager can handle (big teams means loads of progress; the project manager has to be able to keep up with all of it).
To motivate the team, no matter the size, there should always be a deadline. Even if it is a distant one, it gives a date for people to work towards; something to look forward to. It helps the work flow, and things are done sooner than if there was no deadline. However, a distant deadline means a lot of work time. To ensure this time is not spend lying around, milestones can be planned to mark significant progress (e.g. 25%, 50%, 75% milestones). These milestones aid in guiding the project into finishing at the estimated deadline. It is important to know that first project timelines are expected to change in big ways; it takes some experience to know the pace which the team works at and later projects will be more accurate. Ensure these deadlines of the first projects are either very malleable or outright hidden to those following the development of the project.
Develop: With all the planning out of the way, development can begin. While the steps of development depend on the project, there are a few aspects that are important for all projects. Monitoring the project development will allow quicker resolutions to the issues faced through the duration of development along with keeping everything on schedule. It is also important so that the project manager knows when testing should begin (although it can never occur too early, there is time where testing is unnecessary).
Whether alone or managing a team, monitoring the development process helps keep things on track. Monitoring progress is important to make sure everybody is doing something productive in a timely manner so that others can begin on other areas building off of it. The goal is to meet the milestone on time, so it is important to know if there are problems some people are encountering or if a part of the project is taking more time than was planned for and, the worst case scenario, alter the schedule appropriately.
The time to test is when the game is reasonably playable. You want testing to start early so that bugs or gameplay can be dealt with early on and not be a problem throughout the development phase (you dono t want recurring bugs). Neglecting to test can lead to severe circumstances such as having to rebuild/redesign a portion of the game or figuring out that something isno t fun after a handful of them have been implemented. Dono t be afraid to test, and ensure that there is a large selection of people testing the game.
Launch: The project launch is the big finale, the project is nicely displayed and hundreds of players experience what was created. However, these events do not go unplanned; usually plans are started in the middle of development as there is much to plan. For a successful launch, effort needs to go into generating publicity. To get people interested, people need to see the project and its progress, and there is a bit of etiquette in gaining publicity. Hand in hand with gaining publicity is having content for the launch: interesting screenshots and exciting trailers will attract players. None of that title on a shade of blue stuff, go big or go home.
Getting publicity for the project is no easy feat. It takes persistence and work to have people become interested in a Minecraft project without a few hundred/thousand subscribers. What you do not want is to make a desperate move. Advertising on other peoples work, spamming links all over the place; these things let others know that the project is desperate for attention. Worst yet, it gets bad publicity. There is such a thing as bad publicity, and it is when people will burn any project related to one that made a desperate move. Desperate moves are insulting to others; they rarely work and are very rule to those in the spotlight the project attempted to steal. In contrast, creating substantial content and updates to public areas of high traffic, spreading word to friends and maybe some subtle attempts to get server mates interested in a concept your game is based off of; these are acceptable ways of getting publicity for the project. The task may be slow, but starting something takes time; just trust that future projects will have an easier time with this.
The big launch post is a big deal; it is unlikely that a Minecraft game will ever receive a huge launch party, big movie screening, or midnight release, so a post with thousands of views is what a project should look forward to. However, people do overlook this fact and many launch posts end in tragedy. Lacking good media, maybe there is a project name about, is that a description or the plot of Star Wars, a link that is bound to be earning the project money, and the user has two posts; these are symptoms of either a bad launch or a desperate launch. Desperate launches are akin to a desperate move, somebody wants money for no-effort content: a bad description, adfly link, and what is expected to be a dirt hut on a flat map for content. The project probably made its rounds on the internet, but desperate launches are not worth any attention: they lack effort. Bad launches suffer from the same problem: lack of effort. Bad launches differ from desperate launches in that the content is actually worth something, the project manager just failed to put enough effort into the launch. Successfully launching a project requires effort and media to admire. It is mandatory that there are enough screenshots to accurately picture the playable areas; it is important because it proves the project isno t desperate and screenshots can generate interest. Pictures are worth a thousand words. Now imagine a trailer for the project. Frame after frame of thousands of words; exciting trailers are guaranteed to attract interest. Content may be a bit harder to come by, but those that plan in advance will ask their testers to record their sessions: testing results and trailer content all in one. It is like a bonus, but it was all part of the planning.
Close: It is hard to say whether or not this is done a lot or not at all as project closure is for the benefit of the team and only seen by the team. When a project is complete it is beneficial to close the project in what is called a post-mortem (not to be mistaken for the surgical procedure). All team members (and parties who are financially tied to the project (people who commissioned/hired the team for the project)) participate in completing a post-mortem. Those outside the team (people providing funds) will participate in an individual post-mortem; team members participate in an individual and team post-mortem. The overall purpose of a post-mortem is to reflect on how the project went overall: what went well/not well, how the team communication/work environment waso ¦ etc. Individual post-mortems focus on individual opinions on the team and the development of the project (in the business world these are restricted to the eyes of the project manager and above as to keep the work environment positive). The team post-mortem focuses on how the team felt it did and reflects on the final product.
Public post-mortems do exist on occurrence. They are articles meant for the public to read and describe how the team thought it did and how it cooperated, covers any problems the team/project faced and how it dealt with it (if the project was a disaster, ito ll cover the how/where it started to fall), and whether or not the team was satisfied with the end results. These are not common, but they do exist and deserve attention; there are many people who enjoy reading about behind the scenes of a project, and those that follow of the team (not just the project) like to find out how they can support the team in their next project.
The lifecycle of a project can be a long one, especially those that are on a bigger scale. However, seeing a project from start to finish is a tough task, but knowing the stages a project passes through can improve the development of a project. A project starts with a good, solid idea of the game. This idea is then defined to scope out the project and plan out the development process. When in development, it is important to monitor progress, quickly act upon any issues that arise, and start testing early to reveal issues before they become larger issues. Before development is complete, it is important to start thinking about the project launch and what it will include; a bad launch is a desperate or unnoticed launch. Once the project is out, have the team complete a post-mortem to reflect on how the project went.
Next week will cover how to go about creating the world for the game. Terraforming, making an arena, level design; they are all aspects of creating a world to play in. But until then, thanks for reading this issue of o Building a Game: Minecrafto .
Building a game in Minecraft is considered a large project. Even small games take lots of work, and successful projects will take large teams an abundance of time to complete. Whether adventure maps or architectural builds, it is important to know that these do not materialize out of nowhere. Project managers have to manage the progress of them, and their task is crucial to seeing a final product. The task is big enough that project managers group the project development into a lifecycle with five phases. At the start of every project is an idea: Conceive. This idea is then used to plan out the rest of the project: Define. The project development begins using the plans as guides to keep progress steady: Develop. The big ending is releasing the project for everybody to experience: Launch. After the launch the team does not rest yet, they reflect on how they did: Close. Understanding these phases will help make project managers in their adventures of making a project of their own.
Conceive: Whereo s that piece of paper, thereo s an idea to be taken down. All projects start with an idea (perhaps money to hire people, too), but this step is not so easy. An idea picked for a project will greatly benefit if it is fun, original, and/or an improvement on an idea. The idea is to have a lot of players to enjoy the game, and that is not going to happen if something has been done really well already (if ito s popular, it is a good idea to leave the idea alone).
When you get your idea, get a good grasp on it. Having an expert knowledge on every detail is not what this is about; the point is to be able to inform somebody else enough that they understand. A great idea is to come up with one sentence that covers the project and story. E.g. o Players navigate a maze to find a key for the exit while being chased by a hostile, player-controlled Minotaur.o or o Steve, the last super-Human, crashes onto a strange world where he must fight to reunite his shipo s crew, surpass enemy forces that occupy the lands, evade an ancient evil, before learning that the world was built to destroy all life and decide to destroy it.o
A big bonus to have done during this phase is getting a name for the project. Sometimes names are easy to come up with, but other times it can be excruciatingly difficult. If the task proves difficult, a smart idea is to write down any relevant word down even if it is kind of/maybe/only sometimes related. From there, pick any selection of words that stand out; combine them, mix them up or anything. Even if the results are not going to end up with a name, there is a good chance they brought out a good idea. With others, the results will be plenty and more interesting.
Define: The idea is picked, and it is a good idea to work with. People will enjoy playing, players will spend hours in it, and the project can be built in Minecraft. Before development can begin, however, there is plenty of planning to be done. The project scope is the first target: how big does this project go? From a small arena to an epic adventure, a project manager needs to have a concrete grasp on what the project entails. This phase can be done in two ways: a project manager can plan the entire game out at once or get the concrete idea down first, plan the next few parts, and return to plan out the game. However, planning out the game is essential; a game outline covers as much as possible to avoid grey areas which are very likely to cause issues later. Unless the project will be done by one person, every other person on the team will refer to the game outline on anything they can encounter. A grey areas means that it is up to that person to come up with a solution which might mess up with other parts of the game or not be what the project manager thought it would be.
The project as a whole also needs to be planned out; a project manager needs to know if a team is needed, how large it is, and when the team can finish by. A starting team should limit itself to people who know at least one other person. It is easier for new project managers and for team interaction. The experienced teams can afford new people because the experienced ones are able to pick up some drag the new people will start with (it takes time to adjust for even experienced workers). It is, however, important to limit the team size to one the project manager can handle (big teams means loads of progress; the project manager has to be able to keep up with all of it).
To motivate the team, no matter the size, there should always be a deadline. Even if it is a distant one, it gives a date for people to work towards; something to look forward to. It helps the work flow, and things are done sooner than if there was no deadline. However, a distant deadline means a lot of work time. To ensure this time is not spend lying around, milestones can be planned to mark significant progress (e.g. 25%, 50%, 75% milestones). These milestones aid in guiding the project into finishing at the estimated deadline. It is important to know that first project timelines are expected to change in big ways; it takes some experience to know the pace which the team works at and later projects will be more accurate. Ensure these deadlines of the first projects are either very malleable or outright hidden to those following the development of the project.
Develop: With all the planning out of the way, development can begin. While the steps of development depend on the project, there are a few aspects that are important for all projects. Monitoring the project development will allow quicker resolutions to the issues faced through the duration of development along with keeping everything on schedule. It is also important so that the project manager knows when testing should begin (although it can never occur too early, there is time where testing is unnecessary).
Whether alone or managing a team, monitoring the development process helps keep things on track. Monitoring progress is important to make sure everybody is doing something productive in a timely manner so that others can begin on other areas building off of it. The goal is to meet the milestone on time, so it is important to know if there are problems some people are encountering or if a part of the project is taking more time than was planned for and, the worst case scenario, alter the schedule appropriately.
The time to test is when the game is reasonably playable. You want testing to start early so that bugs or gameplay can be dealt with early on and not be a problem throughout the development phase (you dono t want recurring bugs). Neglecting to test can lead to severe circumstances such as having to rebuild/redesign a portion of the game or figuring out that something isno t fun after a handful of them have been implemented. Dono t be afraid to test, and ensure that there is a large selection of people testing the game.
Launch: The project launch is the big finale, the project is nicely displayed and hundreds of players experience what was created. However, these events do not go unplanned; usually plans are started in the middle of development as there is much to plan. For a successful launch, effort needs to go into generating publicity. To get people interested, people need to see the project and its progress, and there is a bit of etiquette in gaining publicity. Hand in hand with gaining publicity is having content for the launch: interesting screenshots and exciting trailers will attract players. None of that title on a shade of blue stuff, go big or go home.
Getting publicity for the project is no easy feat. It takes persistence and work to have people become interested in a Minecraft project without a few hundred/thousand subscribers. What you do not want is to make a desperate move. Advertising on other peoples work, spamming links all over the place; these things let others know that the project is desperate for attention. Worst yet, it gets bad publicity. There is such a thing as bad publicity, and it is when people will burn any project related to one that made a desperate move. Desperate moves are insulting to others; they rarely work and are very rule to those in the spotlight the project attempted to steal. In contrast, creating substantial content and updates to public areas of high traffic, spreading word to friends and maybe some subtle attempts to get server mates interested in a concept your game is based off of; these are acceptable ways of getting publicity for the project. The task may be slow, but starting something takes time; just trust that future projects will have an easier time with this.
The big launch post is a big deal; it is unlikely that a Minecraft game will ever receive a huge launch party, big movie screening, or midnight release, so a post with thousands of views is what a project should look forward to. However, people do overlook this fact and many launch posts end in tragedy. Lacking good media, maybe there is a project name about, is that a description or the plot of Star Wars, a link that is bound to be earning the project money, and the user has two posts; these are symptoms of either a bad launch or a desperate launch. Desperate launches are akin to a desperate move, somebody wants money for no-effort content: a bad description, adfly link, and what is expected to be a dirt hut on a flat map for content. The project probably made its rounds on the internet, but desperate launches are not worth any attention: they lack effort. Bad launches suffer from the same problem: lack of effort. Bad launches differ from desperate launches in that the content is actually worth something, the project manager just failed to put enough effort into the launch. Successfully launching a project requires effort and media to admire. It is mandatory that there are enough screenshots to accurately picture the playable areas; it is important because it proves the project isno t desperate and screenshots can generate interest. Pictures are worth a thousand words. Now imagine a trailer for the project. Frame after frame of thousands of words; exciting trailers are guaranteed to attract interest. Content may be a bit harder to come by, but those that plan in advance will ask their testers to record their sessions: testing results and trailer content all in one. It is like a bonus, but it was all part of the planning.
Close: It is hard to say whether or not this is done a lot or not at all as project closure is for the benefit of the team and only seen by the team. When a project is complete it is beneficial to close the project in what is called a post-mortem (not to be mistaken for the surgical procedure). All team members (and parties who are financially tied to the project (people who commissioned/hired the team for the project)) participate in completing a post-mortem. Those outside the team (people providing funds) will participate in an individual post-mortem; team members participate in an individual and team post-mortem. The overall purpose of a post-mortem is to reflect on how the project went overall: what went well/not well, how the team communication/work environment waso ¦ etc. Individual post-mortems focus on individual opinions on the team and the development of the project (in the business world these are restricted to the eyes of the project manager and above as to keep the work environment positive). The team post-mortem focuses on how the team felt it did and reflects on the final product.
Public post-mortems do exist on occurrence. They are articles meant for the public to read and describe how the team thought it did and how it cooperated, covers any problems the team/project faced and how it dealt with it (if the project was a disaster, ito ll cover the how/where it started to fall), and whether or not the team was satisfied with the end results. These are not common, but they do exist and deserve attention; there are many people who enjoy reading about behind the scenes of a project, and those that follow of the team (not just the project) like to find out how they can support the team in their next project.
The lifecycle of a project can be a long one, especially those that are on a bigger scale. However, seeing a project from start to finish is a tough task, but knowing the stages a project passes through can improve the development of a project. A project starts with a good, solid idea of the game. This idea is then defined to scope out the project and plan out the development process. When in development, it is important to monitor progress, quickly act upon any issues that arise, and start testing early to reveal issues before they become larger issues. Before development is complete, it is important to start thinking about the project launch and what it will include; a bad launch is a desperate or unnoticed launch. Once the project is out, have the team complete a post-mortem to reflect on how the project went.
Next week will cover how to go about creating the world for the game. Terraforming, making an arena, level design; they are all aspects of creating a world to play in. But until then, thanks for reading this issue of o Building a Game: Minecrafto .
| Tags |
2538861
6
N3bu1u5
ScotsMiser
Sirframes
Team UNNAMED
fgsh
Iv411229
Arianwyn
Panda_Tyger
KeyDevy
Create an account or sign in to comment.