As a long time user of Classic (and still developing with it), I can draw from the classic side of things to use as reference to debate the pro's and con's of MP addition. Ultimately, I would draw from my experience as a programmer/developer and say that TGC would ultimately know when best to implement such a feature. They have the road map, they know what needs to be done, they would know (as do I with some of our current projects) that in order to add item H, they may need to jump ahead to insert item K, then fall back to E to ensure it works, then proceed to item H. In a perfect world, we would get everything we want at once. In reality, it does not go according to plan, let alone all at once. I would also add that it is not exactly easy on the part of TGC to "fix" an issue that arises, as we have seen many times how some people have "issues" while others have not. Systems are so diverse (as are the users and their knowledge/skills) that it can become quite frustrating to track something that does not make sense or cannot be replicated.
For the hobbyist(s), I can see where MP addition might be the selling point. They want to get something made and spread around their group of people to have some fun. For the developer(s) (developers in this instance refers to people like myself that do this for a living), the MP addition would also be a benefit, but in order to make it successful, it needs to work proper. To implement a feature whilst a core function is struggling would start the snowball effect of a project becoming less and less useful and people getting frustrated and migrating to something else that works. In our case, MP would be something good to try out, but it is not a necessity at our current time frame. When we reach that point and it is ready, then we can attempt it. But let's be sure it works to what it should be at and does not break some key item in the core. There is nothing worse as a developer when you spends months on a development, see the light at the end of the tunnel after 6+ months, build said development only to discover multiple issues. Not all of us have a large development team, and having to ditch a development because of issues is costly and takes food off our table.
If drawing more users to the software is the primary goal, then one would need to ensure each feature added works properly and has not affected a previous item. Otherwise you risk drawing people to a product only to discover it does not work as intended and word of mouth spreads fast nowadays on the net. Forget about the David vs Golioth analogy- that is a moot point. I've seen games from earlier years that are still widely regarded far more than current games, and they were made on systems using less graphics. Everything depends on the person's need- the developers that make games for a living and their target audience; the hobbyists that make games for their target audience or usage; the programmers that create the tools we use to do what we like to do. While we are only using the tools we have purchased, we have to rely on the fact that TGC's team would know when a feature is best implemented at what stage in order to not make a release unstable and cause major backlash.
Quote: "I'd also like to add to Shaky's list, and say that TGC needs to (re)clarify their Gold Pledge info....and take out the bit about Gold Pledgers getting Alpha Cadences every few weeks; with non-gold pledgers getting a new beta build once every month or so. That simply isn't true anymore, as everyone gets the latest build when it's ready; whether you've paid for gold or for bronze. I imagine the Steam Community is going to zero in on that little tid-bit. I'm honestly surprised it hasn't already been brought up, by someone other than me. Be straight-forward and factual."
I agree with KeithC's assessment on this. This was one area that really frustrated us as purchasers/customers. You really should be straight-forward and factual; clear and concise. If you need to change something you made a commitment on, then amend it to be clear so there are no misconceptions. As an example. if you say "can build 50 levels", then know *exactly* what that means. Having to either scrap a development or come up with a workaround to build 10 levels on a product because the product can't do what you advertise renders your statement false. If a user has to spend large amounts of time scouring a forum for answers to a problem or has been told to "Google it" regarding an issue that should not have been allowed to happen in the first place (or could have been fixed ahead of time), then you risk losing future sales from that user. If he/she have ten plus people they know with the same issue and they decide to "vote with their feet" and move to another engine, now you just lost more sales. Use classic as an example- don't let this product follow history where people were told they need to "upgrade" their version to fix, because I can attest straight out that was false in some cases. Take your time and do it right, don't cave to the masses that want every feature added now (right now) because they think it is best. It is your road map, you follow what you know works, adjust along the way.
For us, we have gotten to where we are at using classic and did good. We wait until this product is done and will give it a full workout. At best, we would use it to make a development (regardless of what gets added when- we would not be using it for a development until it was 100% ready to do so); at worst, we lost the investment and move on. So MP is not a "make it or break it" for us- it falls into the category of "better to have it and not need it" than "need it and not have it" and need to switch to something that does have it and start the development all over.
PS. Hey Uman!! I am not sure, but I did a word count and almost tied you
Kidding, just had to poke at you
PSS One thing to add with the "clear and concise" portion- upgrades. You release this product so we developers/hobbyist have the full tool to make our developments, then you come up with an upgrade to address an issue or add something (like you did in past). Let's be sure the information is concise as far as upgrades, meaning if we have to restart a development once upgrading then make that well known or if the development can be used in an upgrade then let that be known. I cannot begin to count how many times issues from the classic side were reported and a lot of them stemmed from the fact that people were taking projects from an older version and working in a new upgrade. Make it crystal clear so that the onus is on the user, not on TGC to try and fix the problem that really was not theirs to fix in the first place. That takes time away from your (TGC) road map and causes you to divert assets onto something which then delays your goals as well.
There's no problem that can't be solved without applying a little scripting.
