In recent months the game industry has seen the power and importance of crowd funding explode as Chris Roberts’ Star Citizen has continued its meteoric rise. Other crowdfunded games, including our own Camelot Unchained™, have also continued to raise additional funding after the close of their initial crowdfunding period. While this is a good thing for the developer in terms of having additional cash at hand, this cash generally comes with strings attached. One of these strings is, of course, in the form of players’ heightened expectations for the game with the additional content that was unlocked through stretch goals. Stretch goals are, in theory, generally a good thing for both players and developers. Players hope to get a deeper and richer game for their new and/or ongoing donations. Developers get more funding and usually have to grow the team to meet the demands of the expanded scope of the game. Unfortunately, while on the surface it looks all nice and serene, underneath the calm waters there is danger and that is the ever-looming problem of <insert theme from Jaws here> DELAYS. This FP is not going to be an examination of how other CF games have experienced, dealt with and will deal with delays but rather how CSE is going to handle this issue with Camelot Unchained. As always, I want to be very upfront with our backers so they understand what happens if donations continue over the next two years. For the purpose of this FP, I’m going to lay out our philosophy in a set of rules and how they will impact the continuing development of Camelot Unchained, in particular the stretch goals via laying out a corresponding set of principles:

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). As we (developers and players) know, feature creep is a very scary thing for any project, no matter how well managed. 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. Principle #1 – All of our stretch goals must add something very useful to the game.

Rule #2 – Don’t over-promise just to raise additional funding. 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. 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 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. Principle #2 – Size does matter and smaller is better!

Rule #3 – Don’t promise stretch goals that require adding too many new people to the team too quickly. 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. 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. 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). Principle #3 – Work with the team you have, not with the imaginary team you don’t yet have.

Rule #4 – Don’t be like a horse wearing blinders when laying out a stretch goal. We will look at the goal that precedes a new stretch goal and think about the goal that follows it. 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. 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 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. Principle #4 – Look both ways before crossing a stretch goal.

Rule #5 – Don’t continue to add new stretch goals even if the donations are continuing to rise. This may seem a repeat of Rule #1 but it isn’t. If donations to Camelot Unchained saw a big spike (not like Star Citizen, zero chance of that happening) I am ready, willing and able to stop enunciating stretch goals until I know that we are still in a place where we can meet our release schedule. I am also willing to promise that if reached 10M in total funding, I would happily stop promising any additional stretch goals until we met all of the goals that we had already promised and if the game was still on track for its scheduled release date. Principle #5 – Stop, in the name of sanity, just stop.

Rule #6 – Don’t try to fit everything in for launch. Most projects continue to pile on stretch goals like people on cruise ships pile their plates high from the buffet. If we do reach the point where we believe that we really want to add a feature but that it cannot be there for launch, we’ll call it an Expansion Goal. Principle #6 – MMORPGs grow over time and the stretch goals can do so with them.

Rule #7 – Never forget what you said to the backers when the project first sought funding. Nothing is more important than making a great game but when your backers decided to help fund (or entirely fund) your game, you told them that you wanted to release the game by an estimated date. While delays with games are almost de rigueur, you need to weigh whether adding that stretch goal is necessary to the game’s initial release. Yes, maybe adding a number of features does make the game better but if it ends up delaying the game’s launch by months or worse yet, years, how will the initial backers of this game feel? After all, how would I feel as a gamer if I were in their shoes? For us this means that as per above, I’ll simply stop adding new stretch goals if those goals put the estimated launch of Camelot Unchained at risk. I know that may sound like it is easy for me to say now, but I’ll use those words I rarely use, I PROMISE, ON BEHALF OF CSE, NEVER TO ADD, OR ALLOW TO BE ADDED, STRETCH GOALS THAT ENDANGER THE ESTIMATED LAUNCH OF CAMELOT UNCHAINED IN DECEMBER 2015. Okay, now it’s official. 🙂 Of course, a delay can always happen (hence the “estimated”) but it won’t be because we’ve added too many stretch goals. Principle #7 – Remember us Mark, always remember us.

So, all these words are one thing but what does this mean in 30 words or less? Well, how’s this for terse:

KISS, Don’t be greedy and remember your backers!

When we announce our next stretch goal I’ll start a discussion on the forums as to how that stretch goal fits in with these rules and principles. That pretty much wraps up almost everything I hoped to cover in this FP. As I’m fond of saying on the forums, no need to continue flailing an expired equine so…

-Mark