Principle #4 – Look both ways before crossing a stretch goal. For example, our current goal, The Depths™, will not be followed up with a stretch goal that will require a lot of programming support because even the first stage of The Depths will require a great deal of programming support. Thus, we won’t have two or three stretch goals in a row that require a large amount of programing support or support from certain parts of the art team. For us this means that when we pick our next stretch goal, we need to be sure that the sequence of stretch goals will not place an undue burden on parts of the team. We will look at the goal that precedes a new stretch goal and think about the goal that follows it. Rule #4 – Don’t be like a horse wearing blinders when laying out a stretch goal. Principle #3 – Work with the team you have, not with the imaginary team you don’t yet have. For us, this means that none of our early stretch goals can require the hiring of additional programmers (getting talented artists is less of a problem). Rushing to bring in new people can end up badly for a host of reasons (disruption of team chemistry, hiring the wrong people, etc.) and actually can set a project back. While Northern Virginia is a particularly difficult place to convince people to move to, even in more talent-rich environments adding qualified new people can be difficult, especially for smaller teams. Rule #3 – Don’t promise stretch goals that require adding too many new people to the team too quickly. Principle #2 – Size does matter and smaller is better! This will result in our stretch goals being a bit less sexy than they could be if we were focusing on using them to raise money by adding more complicated/demanding/WOWIE WOW WOW features. Thus, all of our stretch goals will be smaller in scope and the amount that we peg toward its development will be a little higher than we actually need. This is probably the worst mistake we could make because there’s a good chance that we would end up either late, in need of additional cash or both. Rule #2 – Don’t over-promise just to raise additional funding. Principle #1 – All of our stretch goals must add something very useful to the game. While it is tempting to be able to add lots of things to your game to reward the backers for their donations, some temptations are better left alone. As we (developers and players) know, feature creep is a very scary thing for any project, no matter how well managed. Rule #1 – Don’t add stretch goals to the game unless they add something that the vast majority of your backers want and that also improve the game (especially in comparison to the effort it takes to implement them). And they’ll be realistic based on the current talent on tap at the company, as Mark believes it a folly to make plans based on a non-existent team. As such the team states that after The Depths is achieved, they won’t be getting carried away with further stretch goals that might hinder the expected launch date of their title.īeyond that, each stretch goal will put stress on different parts of the development team so no one group gets overworked. Too much money from too much promises can be a bad thing. But #15 has arrived, making it perfectly clear how Mark Jacob’s feels about Kickstarter stretch goals and his self-coined term, expansion goals. It’s been quite a while since Camelot Unchained saw a new Foundational Principle from the CityState Entertainment team.
0 kommentar(er)
